On 02.05.24 14:18, Vitaly Kuznetsov wrote:
Alexander Graf <graf@xxxxxxxxxx> writes:
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.
Isn't it the same when we just allow loading kernel modules? I'm sure
you can also achieve a 'completely different environment' with that :-)
With SecureBoot / lockdown we normally require modules to pass signature
check, I guess we can employ the same mechanism for kexec. I.e. in
lockdown, we require signature check on the kexec-ed kernel. Also, it
may make sense to check initramfs too (with direct kernel boot it's also
part of launch measurements, right?) and there's UKI for that already).
Correct. With IMA, you even do exactly that: Enforce a signature check
of the next binary with kexec.
The problem is that you typically want to update the system because
something is broken; most likely your original environment had a
security issue somewhere. From a pure SEV-SNP attestation point of view,
you can not distinguish between the patched and unpatched environment:
Both look the same.
So while kexec isn't the problem, it's the fact that you can't tell
anyone that you're now running a fixed version of the code :).
Personally, I believe that if we simply forbid kexec for CoCo in
lockdown mode, the feature will become mostly useless in 'full stack'
(which boot through firmware) production envrironments.
I'm happy for CoCo to stay smoke and mirrors :). But I believe that if
you want to genuinely draw a trust chain back to an AMD/Intel
certificate, we need to come up with a good way of making updates work
with a working trust chain so that whoever checks whether you're running
sanctioned code is able to validate the claim.
Alex
_______________________________________________
kexec mailing list
kexec@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/kexec
