Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Takahiro Itazuri <itazur@amazon.com>
To:     <seanjc@google.com>
CC:     <itazur@amazon.com>, <jmattson@google.com>, <kvm@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>, <pbonzini@redhat.com>,
        <x86@kernel.org>, <zulinx86@gmail.com>
Subject: Re: [PATCH 1/1] KVM: pass through CPUID(0x80000006)
Date:   Wed, 12 Jul 2023 18:02:58 +0100
Message-ID: <20230712170258.75355-1-itazur@amazon.com>
In-Reply-To: <ZK7NmfKI9xur/Mop@google.com>
References: <ZK7NmfKI9xur/Mop@google.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain
Precedence: bulk

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