linux.git/arch/x86/kernel/vmlinux.lds.S, branch v6.12

x86/stackprotector: Work around strict Clang TLS symbol requirements

2024-11-08T12:16:00+00:00

GCC and Clang both implement stack protector support based on Thread Local
Storage (TLS) variables, and this is used in the kernel to implement per-task
stack cookies, by copying a task's stack cookie into a per-CPU variable every
time it is scheduled in.

Both now also implement -mstack-protector-guard-symbol=, which permits the TLS
variable to be specified directly. This is useful because it will allow to
move away from using a fixed offset of 40 bytes into the per-CPU area on
x86_64, which requires a lot of special handling in the per-CPU code and the
runtime relocation code.

However, while GCC is rather lax in its implementation of this command line
option, Clang actually requires that the provided symbol name refers to a TLS
variable (i.e., one declared with __thread), although it also permits the
variable to be undeclared entirely, in which case it will use an implicit
declaration of the right type.

The upshot of this is that Clang will emit the correct references to the stack
cookie variable in most cases, e.g.,

  10d:       64 a1 00 00 00 00       mov    %fs:0x0,%eax
                     10f: R_386_32   __stack_chk_guard

However, if a non-TLS definition of the symbol in question is visible in the
same compilation unit (which amounts to the whole of vmlinux if LTO is
enabled), it will drop the per-CPU prefix and emit a load from a bogus
address.

Work around this by using a symbol name that never occurs in C code, and emit
it as an alias in the linker script.

Fixes: 3fb0fdb3bbe7 ("x86/stackprotector/32: Make the canary into a regular percpu variable")
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Brian Gerst 
Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Nathan Chancellor 
Tested-by: Nathan Chancellor 
Cc: stable@vger.kernel.org
Link: https://github.com/ClangBuiltLinux/linux/issues/1854
Link: https://lore.kernel.org/r/20241105155801.1779119-2-brgerst@gmail.com

x86: fix user address masking non-canonical speculation issue

2024-10-25T16:53:03+00:00

It turns out that AMD has a "Meltdown Lite(tm)" issue with non-canonical
accesses in kernel space.  And so using just the high bit to decide
whether an access is in user space or kernel space ends up with the good
old "leak speculative data" if you have the right gadget using the
result:

  CVE-2020-12965 “Transient Execution of Non-Canonical Accesses“

Now, the kernel surrounds the access with a STAC/CLAC pair, and those
instructions end up serializing execution on older Zen architectures,
which closes the speculation window.

But that was true only up until Zen 5, which renames the AC bit [1].
That improves performance of STAC/CLAC a lot, but also means that the
speculation window is now open.

Note that this affects not just the new address masking, but also the
regular valid_user_address() check used by access_ok(), and the asm
version of the sign bit check in the get_user() helpers.

It does not affect put_user() or clear_user() variants, since there's no
speculative result to be used in a gadget for those operations.

Reported-by: Andrew Cooper 
Link: https://lore.kernel.org/all/80d94591-1297-4afb-b510-c665efd37f10@citrix.com/
Link: https://lore.kernel.org/all/20241023094448.GAZxjFkEOOF_DM83TQ@fat_crate.local/ [1]
Link: https://www.amd.com/en/resources/product-security/bulletin/amd-sb-1010.html
Link: https://arxiv.org/pdf/2108.10771
Cc: Josh Poimboeuf 
Cc: Borislav Petkov 
Tested-by: Maciej Wieczor-Retman  # LAM case
Fixes: 2865baf54077 ("x86: support user address masking instead of non-speculative conditional")
Fixes: 6014bc27561f ("x86-64: make access_ok() independent of LAM")
Fixes: b19b74bc99b1 ("x86/mm: Rework address range check in get_user() and put_user()")
Signed-off-by: Linus Torvalds

runtime constants: move list of constants to vmlinux.lds.h

2024-08-19T07:48:14+00:00

Refactor the list of constant variables into a macro.
This should make it easier to add more constants in the future.

Signed-off-by: Jann Horn 
Reviewed-by: Alexander Gordeev 
Reviewed-by: Thomas Gleixner 
Acked-by: Arnd Bergmann 
Acked-by: Will Deacon 
Signed-off-by: Arnd Bergmann

runtime constants: add x86 architecture support

2024-06-19T19:34:34+00:00

This implements the runtime constant infrastructure for x86, allowing
the dcache d_hash() function to be generated using as a constant for
hash table address followed by shift by a constant of the hash index.

Signed-off-by: Linus Torvalds

Merge tag 'x86-build-2024-05-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2024-05-14T01:05:08+00:00

Pull x86 build updates from Ingo Molnar:

 - Use -fpic to build the kexec 'purgatory' (the self-contained
   code that runs between two kernels)

 - Clean up vmlinux.lds.S generation

 - Simplify the X86_EXTENDED_PLATFORM section of the x86 Kconfig

 - Misc cleanups & fixes

* tag 'x86-build-2024-05-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/Kconfig: Merge the two CONFIG_X86_EXTENDED_PLATFORM entries
  x86/purgatory: Switch to the position-independent small code model
  x86/boot: Replace __PHYSICAL_START with LOAD_PHYSICAL_ADDR
  x86/vmlinux.lds.S: Take __START_KERNEL out conditional definition
  x86/vmlinux.lds.S: Remove conditional definition of LOAD_OFFSET
  vmlinux.lds.h: Fix a typo in comment

x86: Rename __{start,end}_init_task to __{start,end}_init_stack

2024-03-22T08:32:41+00:00

The stack of a task has been separated from the memory of a task_struct
struture for a long time on x86, as a result __{start,end}_init_task no
longer mark the start and end of the init_task structure, but its stack
only.

Rename __{start,end}_init_task to __{start,end}_init_stack.

Note other architectures are not affected because __{start,end}_init_task
are used on x86 only.

Signed-off-by: Xin Li (Intel) 
Signed-off-by: Ingo Molnar 
Reviewed-by: Juergen Gross 
Link: https://lore.kernel.org/r/20240322081616.3346181-1-xin@zytor.com

x86/boot: Simplify boot stack setup

2024-03-21T19:17:54+00:00

Define the symbol __top_init_kernel_stack instead of duplicating
the offset from __end_init_task in multiple places.

Signed-off-by: Brian Gerst 
Signed-off-by: Ingo Molnar 
Cc: Kees Cook 
Cc: Uros Bizjak 
Cc: Linus Torvalds 
Cc: Andy Lutomirski 
Link: https://lore.kernel.org/r/20240321180506.89030-1-brgerst@gmail.com

x86/vmlinux.lds.S: Take __START_KERNEL out conditional definition

2024-03-13T10:29:11+00:00

If CONFIG_X86_32=y, the section start address is defined to be
"LOAD_OFFSET + LOAD_PHYSICAL_ADDR", which is the same as
__START_KERNEL_map.

Unify it with the 64-bit definition to simplify the code.

Signed-off-by: Wei Yang 
Signed-off-by: Ingo Molnar 
Link: https://lore.kernel.org/r/20240313075839.8321-5-richard.weiyang@gmail.com

x86/vmlinux.lds.S: Remove conditional definition of LOAD_OFFSET

2024-03-13T10:29:10+00:00

In vmlinux.lds.S, we define LOAD_OFFSET conditionally to __PAGE_OFFSET
or __START_KERNEL_map. While __START_KERNEL_map is already defined to
the same value with the same condition.

So it is fine to define LOAD_OFFSET to __START_KERNEL_map directly.

Signed-off-by: Wei Yang 
Signed-off-by: Ingo Molnar 
Link: https://lore.kernel.org/r/20240313075839.8321-4-richard.weiyang@gmail.com

Merge branch 'x86/bugs' into x86/core, to pick up pending changes before dependent patches

2024-02-14T09:49:37+00:00

Merge in pending alternatives patching infrastructure changes, before
applying more patches.

Signed-off-by: Ingo Molnar