On Wed, Oct 20, 2021 at 09:05:42PM -0500, Michael Roth wrote:

According to the APM at least, (Rev 3.37, 15.34.10, "SEV_STATUS MSR"), the
SEV MSR is the appropriate source for guests to use. This is what is used
in the EFI code as well. So that seems to be the right way to make the
initial determination.

Yap.

There's a dependency there on the SEV CPUID bit however, since setting the
bit to 0 would generally result in a guest skipping the SEV MSR read and
assuming 0. So for SNP it would be more reliable to make use of the CPUID
table at that point, since it's less-susceptible to manipulation, or do the
#VC-based SEV MSR read (or both).

So the CPUID page is supplied by the firmware, right?

Then, you parse it and see that the CPUID bit is 1, then you start using
the SEV_STATUS MSR and all good.

If there *is* a CPUID page but that bit is 0, then you can safely assume
that something is playing tricks on ya so you simply refuse booting.

Fully-unencrypted should result in a crash due to the reasons below.

Crash is a good thing in confidential computing. :)

But there may exist some carefully crafted outside influences that could
goad the guest into, perhaps, not marking certain pages as private. The
best that can be done to prevent that is to audit/harden all the code in the
boot stack so that it is less susceptible to that kind of outside
manipulation (via mechanisms like SEV-ES, SNP page validation, SNP CPUID
table, SNP restricted injection, etc.)

So to me I wonder why would one use anything *else* but an SNP guest. We
all know that those previous technologies were just the stepping stones
towards SNP.

Then of course that boot stack needs to be part of the attestation process
to provide any meaningful assurances about the resulting guest state.

Outside of the boot stack the guest owner might take some extra precautions.
Perhaps custom some kernel driver to verify encryption/validated status of
guest pages, some checks against the CPUID table to verify it contains sane
values, but not really worth speculating on that aspect as it will be
ultimately dependent on how the cloud vendor decides to handle things after
boot.

Well, I've always advocated having a best-practices writeup somewhere
goes a long way to explain this technology to people and how to get
their feet wet. And there you can give hints how such verification could
look like in detail...

That would indeed be useful. Perhaps as a nice big comment in sme_enable()
and/or the proposed sev_init() so that those invariants can be maintained,
or updated in sync with future changes. I'll look into that for the next
spin and check with Brijesh on the details.

There is Documentation/x86/amd-memory-encryption.rst, for example.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette