On 31/03/2022 12:19, Borislav Petkov wrote: > On Wed, Mar 30, 2022 at 09:11:54AM +0300, Dov Murik wrote: >> If that's the case, we don't need a secure channel and secret injection. >> You can use a simple "sev=debug" (or whatever) in the kernel >> command-line to indicate your needs. > > Yeah, that would work for a normal SEV guest. > > However, if it is an -ES guest, you need to somehow tell it as the guest > owner: "hey you're being debugged and that's fine." > > Because if you want to singlestep the thing, you're going to land in > the #VC handler and destroy registers so you want to save them first if > you're being debugged and then shovel them out to the host somehow. And > that's another question but first things first. > > And "if you're being debugged" needs to be somehow told the guest > through a secure channel so that the HV doesn't go and simply enable > debugging by booting with "sev=debug" and bypass it all. > Note that the HV can also start the VM with SEV completely turned off. Similarly, it can enable debugging and "fool" the guest. Of course all this tricks will affect the measurement, and then the Guest Owner will know that something is wrong and won't inject the secrets. If you don't rely on secret injection anyway, then I think a kernel command-line param is good enough. (I might be missing a scenario though) Maybe you can use KVM_SEV_GET_ATTESTATION_REPORT (ask the host to do it for you). But I think it returns only the launch digest, and you can't figure out the SEV Policy field from it. > And SNP has access to the policy in the attestation report, says Tom, so > that's possible there. True. But not in really early boot? This is all in the sev-guest platform driver. > > So we need a way to add the debugging aspect to the measurement and be > able to recreate that measurement quickly so that a simple debugging > session of a kernel in a guest can work pretty much the same with a SEV* > guest. > > I'm still digging the details tho... >
