| 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
| ||
|
Message-ID: <41bdc5a77013796fa8cb6e61c410af3e064e274b.camel@redhat.com>
Date: Wed, 24 Jul 2024 13:51:07 -0400
From: Maxim Levitsky <mlevitsk@...hat.com>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>, Vitaly Kuznetsov
<vkuznets@...hat.com>, kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
Hou Wenlong <houwenlong.hwl@...group.com>, Kechen Lu <kechenl@...dia.com>,
Oliver Upton <oliver.upton@...ux.dev>, Binbin Wu
<binbin.wu@...ux.intel.com>, Yang Weijiang <weijiang.yang@...el.com>,
Robert Hoo <robert.hoo.linux@...il.com>
Subject: Re: [PATCH v2 23/49] KVM: x86: Handle kernel- and KVM-defined CPUID
words in a single helper
On Mon, 2024-07-08 at 14:18 -0700, Sean Christopherson wrote:
> On Thu, Jul 04, 2024, Maxim Levitsky wrote:
> > On Fri, 2024-05-17 at 10:39 -0700, Sean Christopherson wrote:
> > > Merge kvm_cpu_cap_init() and kvm_cpu_cap_init_kvm_defined() into a single
> > > helper. The only advantage of separating the two was to make it somewhat
> > > obvious that KVM directly initializes the KVM-defined words, whereas using
> > > a common helper will allow for hardening both kernel- and KVM-defined
> > > CPUID words without needing copy+paste.
> > >
> > > No functional change intended.
> > >
> > > Signed-off-by: Sean Christopherson <seanjc@...gle.com>
> > > ---
> > > arch/x86/kvm/cpuid.c | 44 +++++++++++++++-----------------------------
> > > 1 file changed, 15 insertions(+), 29 deletions(-)
> > >
> > > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> > > index f2bd2f5c4ea3..8efffd48cdf1 100644
> > > --- a/arch/x86/kvm/cpuid.c
> > > +++ b/arch/x86/kvm/cpuid.c
> > > @@ -622,37 +622,23 @@ static __always_inline u32 raw_cpuid_get(struct cpuid_reg cpuid)
> > > return *__cpuid_entry_get_reg(&entry, cpuid.reg);
> > > }
> > >
> > > -/* Mask kvm_cpu_caps for @leaf with the raw CPUID capabilities of this CPU. */
> > > -static __always_inline void __kvm_cpu_cap_mask(unsigned int leaf)
> > > +static __always_inline void kvm_cpu_cap_init(u32 leaf, u32 mask)
> > > {
> > > const struct cpuid_reg cpuid = x86_feature_cpuid(leaf * 32);
> > >
> > > - reverse_cpuid_check(leaf);
> > > + /*
> > > + * For kernel-defined leafs, mask the boot CPU's pre-populated value.
> > > + * For KVM-defined leafs, explicitly set the leaf, as KVM is the one
> > > + * and only authority.
> > > + */
> > > + if (leaf < NCAPINTS)
> > > + kvm_cpu_caps[leaf] &= mask;
> > > + else
> > > + kvm_cpu_caps[leaf] = mask;
> >
> > Hi,
> >
> > I have an idea, how about we just initialize the kvm only leafs to 0xFFFFFFFF
> > and then treat them exactly in the same way as kernel regular leafs?
> >
> > Then the user won't have to figure out (assuming that the user doesn't read
> > the comment, who does?) why we use mask as init value.
> >
> > But if you prefer to leave it this way, I won't object either.
>
> Huh, hadn't thought of that. It's a small code change, but I'm leaning towards
> keeping the current code as we'd still need a comment to explain why KVM sets
> all bits by default.
I agree that the comment is needed, but the comment in my case is more natural -
KVM only leaves don't come from boot_cpu_info, so naturally all features there are '1'.
> And in the unlikely case that we royally screw up and fail
> to call kvm_cpu_cap_init() on a word, starting with 0xff would result in all
> features in the uninitialized word being treated as supported.
Yes, but IMHO the chances of this happening are very low.
I understand your concerns though, but then IMHO it's better to keep the
kvm_cpu_cap_init_kvm_defined, because this way at least the function name
cleanly describes the difference instead of the difference being buried in the function
itself (the comment helps but still it is less noticeable than a function name).
I don't have a very strong opinion on this though,
because IMHO the kvm_cpu_cap_init_kvm_defined is also not very user friendly,
so if you really think that the new code is more readable, let it be.
Best regards,
Maxim Levitsky
>
> For posterity...
>
> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> index 18ded0e682f2..6fcfb0fa4bd6 100644
> --- a/arch/x86/kvm/cpuid.c
> +++ b/arch/x86/kvm/cpuid.c
> @@ -762,11 +762,7 @@ do { \
> u32 kvm_cpu_cap_emulated = 0; \
> u32 kvm_cpu_cap_synthesized = 0; \
> \
> - if (leaf < NCAPINTS) \
> - kvm_cpu_caps[leaf] &= (mask); \
> - else \
> - kvm_cpu_caps[leaf] = (mask); \
> - \
> + kvm_cpu_caps[leaf] &= (mask); \
> kvm_cpu_caps[leaf] &= (raw_cpuid_get(cpuid) | \
> kvm_cpu_cap_synthesized); \
> kvm_cpu_caps[leaf] |= kvm_cpu_cap_emulated; \
> @@ -780,7 +776,7 @@ do { \
>
> void kvm_set_cpu_caps(void)
> {
> - memset(kvm_cpu_caps, 0, sizeof(kvm_cpu_caps));
> + memset(kvm_cpu_caps, 0xff, sizeof(kvm_cpu_caps));
>
> BUILD_BUG_ON(sizeof(kvm_cpu_caps) - (NKVMCAPINTS * sizeof(*kvm_cpu_caps)) >
> sizeof(boot_cpu_data.x86_capability));
>
Powered by blists - more mailing lists