Hello Alexander,
On 5/2/2024 7:01 AM, Alexander Graf wrote:
Hey Ashish,
On 09.04.24 22:42, Ashish Kalra wrote:
From: Ashish Kalra <ashish.kalra@xxxxxxx>
The patchset adds bits and pieces to get kexec (and crashkernel) work on
SNP guest.
With this patch set (and similar for the TDX one), you enable the
typical kdump case, which is great!
However, if a user is running with direct kernel boot - which is very
typical in SEV-SNP setup, especially for Kata Containers and similar -
the initial launch measurement is a natural indicator of the target
environment. Kexec basically allows them to completely bypass that:
You would be able to run a completely different environment than the
one you measure through the launch digest. I'm not sure it's a good
idea to even allow that by default in CoCo environments - at least not
if the kernel is locked down.
I thought that kexec is disabled if kernel is in locked-down mode.
Or is it that KEXEC_LOAD syscall is not supported/disabled in kernel
locked-down mode and KEXEC_FILE_LOAD syscall is supported ?
Do you have any plans to build a CoCo native kexec where you allow a
VM to create a new VM context with a guest provided seed? The new
context could rerun all of the attestation and so enable users to
generate a new launch digest. If you then atomically swap into the new
context, it would in turn enable them to natively "kexec" into a
completely new VM context including measurements.
No, currently i don't think there any any such plans.
Thanks, Ashish
I understand that an SVSM + TPM implementation may help to some extent
here by integrating with IMA and adding the new kernel into the IMA
log. But that quickly becomes very convoluted (hence difficult to
assess correctness for) and the same measurement question arises just
one level up then: How do you update your SVSM while maintaining a
full measurement and trust chain?
Thanks,
Alex
_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec
