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: <B72756BE-F15B-46D6-B44E-2FBC79E837C3@zytor.com>
Date: Wed, 15 Oct 2025 08:36:36 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Xin Li <xin@...or.com>, Borislav Petkov <bp@...nel.org>,
        Xin Li <xin3.li@...el.com>
CC: X86 ML <x86@...nel.org>, LKML <linux-kernel@...r.kernel.org>,
        "Borislav Petkov (AMD)" <bp@...en8.de>
Subject: Re: [PATCH] x86/cpufeatures: Correct LKGS feature flag description

On October 15, 2025 8:34:00 AM PDT, Xin Li <xin@...or.com> wrote:
>On 10/15/2025 11:18 PM, H. Peter Anvin wrote:
>> On October 15, 2025 8:08:17 AM PDT, Xin Li <xin@...or.com> wrote:
>>> On 10/15/2025 6:35 PM, Borislav Petkov wrote:
>>>> From: "Borislav Petkov (AMD)" <bp@...en8.de>
>>>> 
>>>> Quotation marks in cpufeatures.h comments are special and when the
>>>> comment begins with a quoted string, that string lands in /proc/cpuinfo,
>>>> turning it into a user-visible one.
>>>> 
>>>> The LKGS comment doesn't begin with a quoted string but just in case
>>>> drop the quoted "kernel" in there to avoid confusion. And while at it,
>>>> simply change the description into what the LKGS instruction does for
>>>> more clarity.
>>>> 
>>>> No functional changes.
>>>> 
>>>> Signed-off-by: Borislav Petkov (AMD) <bp@...en8.de>
>>>> ---
>>>>    arch/x86/include/asm/cpufeatures.h       | 2 +-
>>>>    tools/arch/x86/include/asm/cpufeatures.h | 2 +-
>>>>    2 files changed, 2 insertions(+), 2 deletions(-)
>>>> 
>>>> diff --git a/arch/x86/include/asm/cpufeatures.h b/arch/x86/include/asm/cpufeatures.h
>>>> index 80b68f4726e7..4fb5e12dbdbf 100644
>>>> --- a/arch/x86/include/asm/cpufeatures.h
>>>> +++ b/arch/x86/include/asm/cpufeatures.h
>>>> @@ -320,7 +320,7 @@
>>>>    #define X86_FEATURE_FSRS		(12*32+11) /* Fast short REP STOSB */
>>>>    #define X86_FEATURE_FSRC		(12*32+12) /* Fast short REP {CMPSB,SCASB} */
>>>>    #define X86_FEATURE_FRED		(12*32+17) /* "fred" Flexible Return and Event Delivery */
>>>> -#define X86_FEATURE_LKGS		(12*32+18) /* Load "kernel" (userspace) GS */
>>>> +#define X86_FEATURE_LKGS		(12*32+18) /* MSR_KERNEL_GS_BASE = GS.base */
>>> 
>>> Yes, the assignment is more clearer to us programmers.
>>> 
>>> I'm just not sure if "correct" in the shortlog is accurate; it sounds the
>>> existing one is wrong.  Otherwise,
>>> 
>>> Reviewed-by: Xin Li (Intel) <xin@...or.com>
>>> 
>> 
>> That "assignment" is rather wrong, though; it implies that the two are identical, which they are not; nor does it imply the relationship is fixed (that is provided by FRED, not LKGS). Perhaps just call it "Load user space GS".
>
>I see your point, is the following assignment better?
>
>    MSR_KERNEL_GS_BASE = gs_sel->base
>

Except that that is also wrong, because that's not all of what the instruction does. "Load user space GS" is really what it does, despite the initiate historical naming.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ