linux-kernel - Re: [PATCH v4 2/6] x86/cpu: Move CPU capability override arrays from BSS to __ro_after

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: <CAMzpN2g0LBXiQk+YvrMi8UVqv9rYfqEZrugdDGYdjNiRCEn40Q@mail.gmail.com>
Date: Mon, 19 May 2025 08:01:54 -0400
From: Brian Gerst <brgerst@...il.com>
To: Ard Biesheuvel <ardb+git@...gle.com>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org, 
	Ard Biesheuvel <ardb@...nel.org>, Ingo Molnar <mingo@...nel.org>, 
	Linus Torvalds <torvalds@...ux-foundation.org>, "Kirill A. Shutemov" <kirill@...temov.name>
Subject: Re: [PATCH v4 2/6] x86/cpu: Move CPU capability override arrays from
 BSS to __ro_after_init

On Sat, May 17, 2025 at 5:16 AM Ard Biesheuvel <ardb+git@...gle.com> wrote:
>
> From: Ard Biesheuvel <ardb@...nel.org>
>
> In order to allow CPU capability overrides to be set arbitrarily early
> during the boot, the underlying data objects should not be wiped along
> with the rest of BSS, and so they will need to be moved out.
>
> Given that CPU capabilities are set at init time, and shouldn't be
> modified after that, move them into __ro_after_init, which is part of
> the statically initialized kernel image.
>
> Signed-off-by: Ard Biesheuvel <ardb@...nel.org>
> ---
>  arch/x86/kernel/cpu/common.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
> index 67cdbd916830..579d5b84e183 100644
> --- a/arch/x86/kernel/cpu/common.c
> +++ b/arch/x86/kernel/cpu/common.c
> @@ -704,8 +704,8 @@ static const char *table_lookup_model(struct cpuinfo_x86 *c)
>  }
>
>  /* Aligned to unsigned long to avoid split lock in atomic bitmap ops */
> -__u32 cpu_caps_cleared[NCAPINTS + NBUGINTS] __aligned(sizeof(unsigned long));
> -__u32 cpu_caps_set[NCAPINTS + NBUGINTS] __aligned(sizeof(unsigned long));
> +__u32 __ro_after_init cpu_caps_cleared[NCAPINTS + NBUGINTS] __aligned(sizeof(unsigned long));
> +__u32 __ro_after_init cpu_caps_set[NCAPINTS + NBUGINTS] __aligned(sizeof(unsigned long));
>
>  #ifdef CONFIG_X86_32
>  /* The 32-bit entry code needs to find cpu_entry_area. */
> --
> 2.49.0.1101.gccaa498523-goog
>

Reviewed-by: Brian Gerst <brgerst@...il.com>

On a slight tangent here, is there any reason that BSS can't be
cleared immediately on boot like 32-bit?  The only potential issue I
can see is with __bss_decrypted, which depends on getting cleared
after encryption is enabled.


Brian Gerst