The previous kernel (linux-image-5.4.0-91-generic) boots correctly with SEV.
Bisection of the kernels b/w 5.4.0-91 and 5.4.0-92 identified the following commit as the source of regresssion :
# git bisect good
Bisecting: 0 revisions left to test after this (roughly 1 step)
[5f79bc17fd8d078378a9f3c8773ebcb506cb6f40] Revert "UBUNTU: SAUCE: (lockdown) Make get_cert_list() not complain about cert lists that aren't present."
Since the panic happens in very early stages of boot, no trace of the panic is present in the log files and apparently it is not possible to collect a kernel crash dump, the crashkernel has not been enabled yet.
The latest Focal kernel (linux- image-5. 4.0-92- generic) fails to boot when SEV is enabled.
The kernel panics with the following backtrace :
[ 1.531125] ledtrig-cpu: registered to indicate activity on CPUs mokvar_ sysfs_init+ 0x9d/0x184 01bdf8 EFLAGS: 00010202 0(0000) GS:ffff97843f6c 0000(0000) knlGS:000000000 0000000 sysfs_init+ 0x29a/0x29a initcall+ 0x4a/0x200 init_freeable+ 0x1c0/0x263 init+0xe/ 0x110 fork+0x22/ 0x40 mokvar_ sysfs_init+ 0x9d/0x184 01bdf8 EFLAGS: 00010202 0(0000) GS:ffff97843f6c 0000(0000) knlGS:000000000 0000000 000-0xffffffffb fffffff)
[ 1.531760] EFI Variables Facility v0.08 2004-May-17
[ 1.532575] general protection fault: 0000 [#1] SMP NOPTI
[ 1.533116] CPU: 11 PID: 1 Comm: swapper/0 Not tainted 5.4.157-debug6 #15
[ 1.533788] Hardware name: Scaleway SCW-ENT1-L, BIOS 0.0.0 02/06/2015
[ 1.534429] RIP: 0010:efi_
[ 1.534949] Code: 00 48 85 c0 0f 85 b3 00 00 00 48 c7 c7 b0 db e2 a1 41 bd f4 ff ff ff e8 98 90 16 ff e9 e6 00 00 00 48 85 d2 0f 85 a5 00 00 00 <80> 3b 00 0f 84 b5 00 00 00 48 85 db 0f 84 ac 00 00 00 48 8b 3d 85
[ 1.535120] RSP: 0018:ffffb96e40
[ 1.535120] RAX: b6262a23e510e179 RBX: b625e392251db281 RCX: 0000000000000000
[ 1.535120] RDX: ffffb96e400cd000 RSI: ffff978437e5dc38 RDI: ffffffffa2121860
[ 1.535120] RBP: ffffb96e4001be10 R08: 0000000000000000 R09: 0000000000000228
[ 1.538947] R10: 0000000000000001 R11: 0000000000000000 R12: ffff978437e555a0
[ 1.538947] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 1.538947] FS: 000000000000000
[ 1.538947] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1.538947] CR2: 00000000ffffffff CR3: 00080011a060a001 CR4: 0000000000360ee0
[ 1.538947] Call Trace:
[ 1.538947] ? efi_rci2_
[ 1.538947] do_one_
[ 1.538947] kernel_
[ 1.538947] ? rest_init+0xb0/0xb0
[ 1.538947] kernel_
[ 1.538947] ret_from_
[ 1.538947] Modules linked in:
[ 1.545871] ---[ end trace 815dc8177e65da02 ]---
[ 1.546328] RIP: 0010:efi_
[ 1.546872] Code: 00 48 85 c0 0f 85 b3 00 00 00 48 c7 c7 b0 db e2 a1 41 bd f4 ff ff ff e8 98 90 16 ff e9 e6 00 00 00 48 85 d2 0f 85 a5 00 00 00 <80> 3b 00 0f 84 b5 00 00 00 48 85 db 0f 84 ac 00 00 00 48 8b 3d 85
[ 1.548703] RSP: 0018:ffffb96e40
[ 1.549218] RAX: b6262a23e510e179 RBX: b625e392251db281 RCX: 0000000000000000
[ 1.549916] RDX: ffffb96e400cd000 RSI: ffff978437e5dc38 RDI: ffffffffa2121860
[ 1.550617] RBP: ffffb96e4001be10 R08: 0000000000000000 R09: 0000000000000228
[ 1.551337] R10: 0000000000000001 R11: 0000000000000000 R12: ffff978437e555a0
[ 1.552036] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 1.552737] FS: 000000000000000
[ 1.553529] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1.554093] CR2: 00000000ffffffff CR3: 00080011a060a001 CR4: 0000000000360ee0
[ 1.554818] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 1.555335] Kernel Offset: 0x1fa00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000
[ 1.555335] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
-
The previous kernel (linux- image-5. 4.0-91- generic) boots correctly with SEV.
Bisection of the kernels b/w 5.4.0-91 and 5.4.0-92 identified the following commit as the source of regresssion :
# git bisect good 8378a9f3c8773eb cb506cb6f40] Revert "UBUNTU: SAUCE: (lockdown) Make get_cert_list() not complain about cert lists that aren't present."
Bisecting: 0 revisions left to test after this (roughly 1 step)
[5f79bc17fd8d07
Since the panic happens in very early stages of boot, no trace of the panic is present in the log files and apparently it is not possible to collect a kernel crash dump, the crashkernel has not been enabled yet.