linux-kernel - Re: [PATCH] x86: KVM: Add feature flag for AMD's FsGsKernelGsBaseNonSerializing

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 for Android: free password hash cracker in your pocket

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

Message-ID: <8c810f89-43f3-3742-60b8-1ba622321be8@redhat.com>
Date:   Thu, 5 Oct 2023 18:38:56 +0200
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Borislav Petkov <bp@...en8.de>, Jim Mattson <jmattson@...gle.com>
Cc:     Dave Hansen <dave.hansen@...el.com>, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
        Jiaxi Chen <jiaxi.chen@...ux.intel.com>,
        Kim Phillips <kim.phillips@....com>,
        Sean Christopherson <seanjc@...gle.com>,
        "H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Ingo Molnar <mingo@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] x86: KVM: Add feature flag for AMD's
 FsGsKernelGsBaseNonSerializing

On 10/4/23 09:58, Borislav Petkov wrote:
> On Tue, Oct 03, 2023 at 07:44:51PM -0700, Jim Mattson wrote:
>> The business of declaring breaking changes to the architectural
>> specification in a CPUID bit has never made much sense to me.
> How else should they be expressed then?
> 
> In some flaky PDF which changes URLs whenever the new corporate CMS gets
> installed?
> 
> Or we should do f/m/s matching which doesn't make any sense for VMs?

Nothing *needs* to be done other than documenting this retroactive 
change to what constitutes architectural behavior.  It's not a CPUID 
that can be queried to change behavior; the user can use CPUID to 
diagnose that something has broken, but the broken program cannot know 
in the first place that the CPUID bit exists.

I agree with Jim that it would be nice to have some bits from Intel, and 
some bits from AMD, that current processors always return as 1.  Future 
processors can change those to 0 as desired.

Intel did something similar with VMX.  They have a bunch of bits for 
which we don't know the meaning, but we know it is something that "right 
now always causes vmexits".  Even if in the future you might be able to 
disable it, the polarity of the bit is the same as for all other vmexit 
controls.

Paolo