Alexander Graf <graf@xxxxxxxxxx> writes: > 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 :). ... > > I'm happy for CoCo to stay smoke and mirrors :). "Only a Sith deals in absolutes" :-) > 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. Launch measurements are what they are, they describe the state of your guest before it started booting. There are multiple mechanisms in Linux which change CPL0 code already: self-modifying code like static keys, loadable modules, runtime patching, kexec,... In case some specific deployment requires stronger guarantees we can probably introduce something like 'full lockdown' mode (as a compile time option, I guess) which would disable all of the aforementioned mechanisms. It will still not be a hard proof that the running code matches launch measurements (because vulnerabilities/bugs may still exist) I guess but could be an improvement. Basically, what I wanted to argue is that kexec does not need to be treated 'specially' for CVMs if we keep all other ways to modify kernel code. Making these methods 'attestable' is currently a challenge indeed. -- Vitaly _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
