On Wed, Oct 20, 2021 at 08:01:07PM +0200, Borislav Petkov wrote:

On Wed, Oct 20, 2021 at 11:10:23AM -0500, Michael Roth wrote:

quoted

[Sorry for the wall of text, just trying to work through everything.]

And I'm going to respond in a couple of mails just for my own sanity.

quoted

I'm not sure if this is pertaining to using the CPUID table prior to
sme_enable(), or just the #VC-based SEV MSR read. The following comments
assume the former. If that assumption is wrong you can basically ignore
the rest of this email :)

This is pertaining to me wanting to show you that the design of this SNP
support needs to be sane and maintainable and every function needs to
make sense not only now but in the future.

Absolutely.

In this particular example, we should set sev_status *once*, *before*
anything accesses it so that it is prepared when something needs it. Not
do a #VC and go, "oh, btw, is sev_status set? No? Ok, lemme set it."
which basically means our design is seriously lacking.

Yes, taking a step back there are some things that could probably be
improved upon there.

currently:

  - boot kernel initializes sev_status in set_sev_encryption_mask()
  - run-time kernel initializes sev_status in sme_enable()

with this series the following are introduced:

  - boot kernel initializes sev_status on-demand in sev_snp_enabled()
    - initially used by snp_cpuid_init_boot(), which happens before
      set_sev_encryption_mask()
  - run-time kernel initializes sev_status on-demand via #VC handler
    - initially used by snp_cpuid_init(), which happens before
      sme_enable()

Fortunately, all the code makes use of sev_status to get at the SEV MSR
bits, so breaking the appropriate bits out of sme_enable() into an earlier
sev_init() routine that's the exclusive writer of sev_status sounds like a
promising approach.

It makes sense to do it immediately after the first #VC handler is set
up, so CPUID is available, and since that's where SNP CPUID table
initialization would need to happen if it's to be made available in
#VC handler.

It may even be similar enough between boot/compressed and run-time kernel
that it could be a shared routine in sev-shared.c. But then again it also
sounds like the appropriate place to move the snp_cpuid_init*() calls,
and locating the cc_blob, and since there's differences there it might make
sense to keep the boot/compressed and kernel proper sev_init() routines
separate to avoid #ifdeffery).

Not to get ahead of myself though. Just seems like a good starting point
for how to consolidate the various users.

And I had suggested a similar thing for TDX and tglx was 100% right in
shooting it down because we do properly designed things - not, get stuff
in so that vendor is happy and then, once the vendor programmers have
disappeared to do their next enablement task, the maintainers get to mop
up and maintain it forever.

Because this mopping up doesn't scale - trust me.

Got it, and my apologies if I've given you that impression as it's
certainly not my intent. (though I'm sure you've heard that before.)

quoted

[The #VC-based SEV MSR read is not necessary for anything in sme_enable(),
it's simply a way to determine whether the guest is an SNP guest, without
any reliance on CPUID, which seemed useful in the context of doing some
additional sanity checks against the SNP CPUID table and determining that
it's appropriate to use it early on (rather than just trust that this is an
SNP guest by virtue of the CC blob being present, and then failing later
once sme_enable() checks for the SNP feature bits through the normal
mechanism, as was done in v5).]

So you need to make up your mind here design-wise, what you wanna do.

The proper thing to do would be, to detect *everything*, detect whether
this is an SNP guest, yadda yadda, everything your code is going to need
later on, and then be done with it.

Then you continue with the boot and now your other code queries
everything that has been detected up til now and uses it.

Agreed, if we need to check SEV MSR early for the purposes of SNP it makes
sense to move the overall SEV feature detection code earlier as well. I
should have looked into that aspect more closely before introducing the
changes.

End of mail 1.

-- 
Regards/Gruss,
    Boris.

https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpeople.kernel.org%2Ftglx%2Fnotes-about-netiquette&data=04%7C01%7Cmichael.roth%40amd.com%7C1f46689b40da4a700a6308d993f3993a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637703496776826912%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Kdi9h%2FTzuzoLn64BRsRMLWHkew14BxZHR28QsORsSxs%3D&reserved=0