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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20230712170258.75355-1-itazur@amazon.com>
Date:   Wed, 12 Jul 2023 18:02:58 +0100
From:   Takahiro Itazuri <itazur@...zon.com>
To:     <seanjc@...gle.com>
CC:     <itazur@...zon.com>, <jmattson@...gle.com>, <kvm@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <pbonzini@...hat.com>,
        <x86@...nel.org>, <zulinx86@...il.com>
Subject: Re: [PATCH 1/1] KVM: pass through CPUID(0x80000006)

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