Messages in this thread | | | Date | Fri, 3 May 2024 10:32:13 +0200 | Subject | Re: [PATCH v4 0/4] x86/snp: Add kexec support | From | Alexander Graf <> |
| |
On 02.05.24 14:18, Vitaly Kuznetsov wrote: > Alexander Graf <graf@amazon.com> writes: > >> Hey Ashish, >> >> On 09.04.24 22:42, Ashish Kalra wrote: >>> From: Ashish Kalra <ashish.kalra@amd.com> >>> >>> 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
| |