Thread (96 messages) 96 messages, 7 authors, 2021-11-11

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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help