linux-kernel - Re: [PATCH] x86: Clear LAM and FRED feature bits

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: <32382f60-79fb-4cfa-87b4-581f92c980da@zytor.com>
Date: Tue, 22 Jul 2025 02:08:28 -0700
From: Xin Li <xin@...or.com>
To: Wieczor-Retman Maciej <maciej.wieczor-retman@...el.com>
Cc: Gleixner Thomas <tglx@...utronix.de>, Molnar Ingo <mingo@...hat.com>,
        Petkov Borislav <bp@...en8.de>,
        Hansen Dave <dave.hansen@...ux.intel.com>, x86@...nel.org,
        "Anvin H. Peter" <hpa@...or.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86: Clear LAM and FRED feature bits


> On Jul 22, 2025, at 12:54 AM, Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com> wrote:
> 
> If LAM (CONFIG_ADDRESS_MASKING) or FRED (CONFIG_X86_FRED) are disabled
> during compile time, they still are enumerated in macros such as
> cpu_has() or this_cpu_has() that use the x86_capability bitmask. The
> features are also visible in /proc/cpuinfo even though they are not
> enabled - which is contrary to what the documentation states about the
> file.

I'm curious how this bug is introduced with my patch set that adds the
AWK script which automatically generates the CPU feature mask header.

> 
> The documentation for x86/cpuinfo.rst also states how to handle features
> disabled at compile time:
> 
>    The kernel disabled support for it at compile-time
>    --------------------------------------------------
> 
>    For example, if Linear Address Masking (LAM) is not enabled when
>    building (i.e., CONFIG_ADDRESS_MASKING is not selected) the flag
>    "lam" will not show up. Even though the feature will still be
>    detected via CPUID, the kernel disables it by clearing via
>    setup_clear_cpu_cap(X86_FEATURE_LAM).
> 
> Clear feature bits if they are present in the DISABLED_MASK.
> 
> Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@...el.com>

And we need a Fixes tag and CC stable.

> ---
> arch/x86/kernel/cpu/common.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
> 
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index 77afca95cced..1c5af795cedc 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -1782,6 +1782,16 @@ static void __init early_identify_cpu(struct cpuinfo_x86 *c)
>    if (!pgtable_l5_enabled())
>        setup_clear_cpu_cap(X86_FEATURE_LA57);
> 
> +    /*
> +     * If a feature is disabled during compile time clear its feature
> +     * bit to prevent it from showing up in the x86_capability bitmask.
> +     */
> +    if (!cpu_feature_enabled(X86_FEATURE_LAM))
> +        setup_clear_cpu_cap(X86_FEATURE_LAM);
> +
> +    if (!cpu_feature_enabled(X86_FEATURE_FRED))
> +        setup_clear_cpu_cap(X86_FEATURE_FRED);
> +

The following code will work as a generic fix:

	c->x86_capability[i] &= ~DISABLED_MASK(i);

And DISABLED_MASK(x) needs to be defined like DISABLED_MASK_BIT_SET(x).

Thanks!
     Xin