Re: [PATCH v6 08/42] x86/sev-es: initialize sev_status/features within #VC handler
From: Borislav Petkov <bp@alien8.de>
Date: 2021-10-20 18:08:42
Also in:
kvm, linux-efi, linux-mm, lkml, platform-driver-x86
On Wed, Oct 20, 2021 at 11:10:23AM -0500, Michael Roth wrote:
quoted
1. Code checks SME/SEV support leaf. HV lies and says there's none. So guest doesn't boot encrypted. Oh well, not a big deal, the cloud vendor won't be able to give confidentiality to its users => users go away or do unencrypted like now. Problem is solved by political and economical pressure. 2. Check SEV and SME bit. HV lies here. Oh well, same as the above.I'd be worried about the possibility that, through some additional exploits or failures in the attestation flow,
Well, that puts forward an important question: how do you verify *reliably* that this is an SNP guest? - attestation? - CPUID? - anything else? I don't see this written down anywhere. Because this assumption will guide the design in the kernel.
a guest owner was tricked into booting unencrypted on a compromised host and exposing their secrets. Their attestation process might even do some additional CPUID sanity checks, which would at the point be via the SNP CPUID table and look legitimate, unaware that the kernel didn't actually use the SNP CPUID table until after 0x8000001F was parsed (if we were to only initialize it after/as-part-of sme_enable()).
So what happens with that guest owner later? How is she to notice that she booted unencrypted?
Fortunately in this scenario I think the guest kernel actually would fail to boot due to the SNP hardware unconditionally treating code/page tables as encrypted pages. I tested some of these scenarios just to check, but not all, and I still don't feel confident enough about it to say that there's not some way to exploit this by someone who is more clever/persistant than me.
All this design needs to be preceded with: "We protect against cases A,
B and C and not against D, E, etc."
So that it is clear to all parties involved what we're working with and
what we're protecting against and what we're *not* protecting against.
End of mail 2, more later.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette