* Borislav Petkov (bp@alien8.de) wrote:

On Thu, Oct 21, 2021 at 04:56:09PM +0100, Dr. David Alan Gilbert wrote:

quoted

I can imagine a malicious hypervisor trying to return different cpuid
answers to different threads or even the same thread at different times.

Haha, I guess that will fail not because of SEV* but because of the
kernel not really being able to handle heterogeneous CPUIDs.

My worry is if it fails cleanly or fails in a way an evil hypervisor can
exploit.

quoted

Well, the spec (AMD 56860 SEV spec) says:

  'If firmware encounters a CPUID function that is in the standard or extended ranges, then the
firmware performs a check to ensure that the provided output would not lead to an insecure guest
state'

so I take that 'firmware' to be the PSP; that wording doesn't say that
it checks that the CPUID is identical, just that it 'would not lead to
an insecure guest' - so a hypervisor could hide any 'no longer affected
by' flag for all the CPUs in it's migration pool and the firmware
shouldn't complain; so it should be OK to pessimise.

AFAIU this, I think this would depend on "[t]he policy used by the
firmware to assess CPUID function output can be found in [PPR]."

So if the HV sets the "no longer affected by" flag but the firmware
deems this set flag as insecure, I'm assuming the firmare will clear
it when it returns the CPUID leafs. I guess I need to go find that
policy...

<digs - ppr_B1_pub_1 55898 rev 0.50 >

OK, so that bit is 8...21 Eax ext2eax bit 6 page 1-109

then 2.1.5.3 CPUID policy enforcement shows 8...21 EAX as
'bitmask'
'bits set in the GuestVal must also be set in HostVal.
This is often applied to feature fields where each bit indicates
support for a feature'

So that's right isn't it?

Dave

-- 
Regards/Gruss,
    Boris.

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

-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK