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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20231004075836.GBZR0bLC/Y09sSSYWw@fat_crate.local>
Date:   Wed, 4 Oct 2023 09:58:44 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     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>,
        Paolo Bonzini <pbonzini@...hat.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 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?

When you think about it, CPUID is the best thing we have.

> No one is likely to query CPUID.80000021H.EAX[bit 21] today, but if
> someone does query the bit in the future, they can reasonably expect
> that WRMSR({FS,GS,KERNELGS}_BASE) is a serializing operation whenever
> this bit is clear. Therefore, any hypervisor that doesn't pass the bit
> through is broken. Sadly, this also means that for a heterogenous
> migration pool, the hypervisor must set this bit in the guest CPUID if
> it is set on any host in the pool. Yes, that means that the legacy
> behavior may sometimes be present in a VM that enumerates the CPUID
> bit, but that's the best we can do.

Yes, add this to your commit message.

> I'm a little surprised at the pushback, TBH. Are you implying that
> there is some advantage to *not* passing this bit through?

We don't add stuff which is not worth adding. There has to be *at*
*least* some justification for it.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette