Re: [PATCH 1/1] KVM: pass through CPUID(0x80000006)

[Takahiro Itazuri <itazur@amazon.com>]

On Wed, 12 Jul 2023, Sean Christopherson wrote:
> Trimmed the Cc to remove folks that no longer directly work on any of this stuff.

I apologize for it and appreciate your reply on this.

> > Regard security aspect, I'm a bit concerned that it could help malicious
> > guests to know something to allow cache side channel attacks. However,
> > CPUID 0x80000006 has already passed through L2 Cache and TLB and L3
> > Cache Information. If passing through CPUID 0x80000006 is really fine,
> > I'm guessing it is the case with CPUID 0x80000005 as well.
> 
> It's definitely harmless from a security perspective.  Userspace already has
> access to this information as CPUID is NOT a priveleged instructions.  And the
> kernel also publishes this information in sysfs, e.g. /sys/devices/system/cpu/cpuN/cache,
> and AFAIK that's not typically restricted.

I'm releaved to hear that.

> I'm mildly tempted to remove 0x80000006, for similar reasons as commit 45e966fcca03
> ("KVM: x86: Do not return host topology information from KVM_GET_SUPPORTED_CPUID"),
> but I suspect that would do more harm than good, e.g. Linux falls back to
> 0x80000005 and 0x80000006 when running on AMD without extended topology info.

Actually I also saw the commit and I was a bit confused about which
leaves to pass through. As you mentioned, CPUID is accessible from
userspace and VMM can query it if they want.

> I think it makes sense to enumerate 0x80000005.  Reporting 0x80000006 but not
> 0x80000005 seems to be the *worst* behavior, so as I see it, the decision is
> really between adding 0x80000005 and removing 0x80000006.  Adding 0x80000005
> appears to be the least risky choice given that KVM has reported 0x80000006 for
> over three years.

I'm on the same page that either reporting both or none of them is
better. I'll create a patch for the least risky one.

Best regards,
Takahiro Itazuri