linux.git/arch/x86/tools, branch v6.16

x86/insn: Stop decoding i64 instructions in x86-64 mode at opcode

2025-05-06T10:03:16+00:00

In commit 2e044911be75 ("x86/traps: Decode 0xEA instructions as #UD")
FineIBT starts using 0xEA as an invalid instruction like UD2. But
insn decoder always returns the length of "0xea" instruction as 7
because it does not check the (i64) superscript.

The x86 instruction decoder should also decode 0xEA on x86-64 as
a one-byte invalid instruction by decoding the "(i64)" superscript tag.

This stops decoding instruction which has (i64) but does not have (o64)
superscript in 64-bit mode at opcode and skips other fields.

With this change, insn_decoder_test says 0xea is 1 byte length if
x86-64 (-y option means 64-bit):

   $ printf "0:\tea\t\n" | insn_decoder_test -y -v
   insn_decoder_test: success: Decoded and checked 1 instructions

Signed-off-by: Masami Hiramatsu (Google) 
Signed-off-by: Ingo Molnar 
Cc: Adrian Hunter 
Cc: H. Peter Anvin 
Cc: Peter Zijlstra 
Link: https://lore.kernel.org/r/174580490000.388420.5225447607417115496.stgit@devnote2

x86/tools: Drop duplicate unlikely() definition in insn_decoder_test.c

2025-03-28T21:57:44+00:00

After commit c104c16073b7 ("Kunit to check the longest symbol length"),
there is a warning when building with clang because there is now a
definition of unlikely from compiler.h in tools/include/linux, which
conflicts with the one in the instruction decoder selftest:

  arch/x86/tools/insn_decoder_test.c:15:9: warning: 'unlikely' macro redefined [-Wmacro-redefined]

Remove the second unlikely() definition, as it is no longer necessary,
clearing up the warning.

Fixes: c104c16073b7 ("Kunit to check the longest symbol length")
Signed-off-by: Nathan Chancellor 
Signed-off-by: Ingo Molnar 
Acked-by: Shuah Khan 
Link: https://lore.kernel.org/r/20250318-x86-decoder-test-fix-unlikely-redef-v1-1-74c84a7bf05b@kernel.org

Merge tag 'linux_kselftest-kunit-6.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest

2025-03-28T02:06:07+00:00

Pull kunit updates from Shuah Khan:
 "kunit tool:
   - Changes to kunit tool to use qboot on QEMU x86_64, and build GDB
     scripts
   - Fixes kunit tool bug in parsing test plan
   - Adds test to kunit tool to check parsing late test plan

  kunit:
   - Clarifies kunit_skip() argument name
   - Adds Kunit check for the longest symbol length
   - Changes qemu_configs for sparc to use Zilog console"

* tag 'linux_kselftest-kunit-6.15-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest:
  kunit: tool: add test to check parsing late test plan
  kunit: tool: Fix bug in parsing test plan
  Kunit to check the longest symbol length
  kunit: Clarify kunit_skip() argument name
  kunit: tool: Build GDB scripts
  kunit: qemu_configs: sparc: use Zilog console
  kunit: tool: Use qboot on QEMU x86_64

x86/cpufeatures: Use AWK to generate {REQUIRED|DISABLED}_MASK_BIT_SET in

2025-03-19T10:15:12+00:00

Generate the {REQUIRED|DISABLED}_MASK_BIT_SET macros in the newly added AWK
script that generates .

Suggested-by: Brian Gerst 
Signed-off-by: Xin Li (Intel) 
Signed-off-by: Borislav Petkov (AMD) 
Signed-off-by: Ingo Molnar 
Reviewed-by: Brian Gerst 
Reviewed-by: Nikolay Borisov 
Cc: Linus Torvalds 
Link: https://lore.kernel.org/r/20250228082338.73859-6-xin@zytor.com

x86/cpufeatures: Generate the header based on build config

2025-03-19T10:15:11+00:00

Introduce an AWK script to auto-generate the  header
with required and disabled feature masks based on 
and the current build config.

Thus for any CPU feature with a build config, e.g., X86_FRED, simply add:

  config X86_DISABLED_FEATURE_FRED
	def_bool y
	depends on !X86_FRED

to arch/x86/Kconfig.cpufeatures, instead of adding a conditional CPU
feature disable flag, e.g., DISABLE_FRED.

Lastly, the generated required and disabled feature masks will be added to
their corresponding feature masks for this particular compile-time
configuration.

  [ Xin: build integration improvements ]
  [ mingo: Improved changelog and comments ]

Signed-off-by: H. Peter Anvin (Intel) 
Signed-off-by: Xin Li (Intel) 
Signed-off-by: Borislav Petkov (AMD) 
Signed-off-by: Ingo Molnar 
Reviewed-by: Nikolay Borisov 
Cc: Linus Torvalds 
Link: https://lore.kernel.org/r/20250305184725.3341760-3-xin@zytor.com

Kunit to check the longest symbol length

2025-03-16T00:13:31+00:00

The longest length of a symbol (KSYM_NAME_LEN) was increased to 512
in the reference [1]. This patch adds kunit test suite to check the longest
symbol length. These tests verify that the longest symbol length defined
is supported.

This test can also help other efforts for longer symbol length,
like [2].

The test suite defines one symbol with the longest possible length.

The first test verify that functions with names of the created
symbol, can be called or not.

The second test, verify that the symbols are created (or
not) in the kernel symbol table.

[1] https://lore.kernel.org/lkml/20220802015052.10452-6-ojeda@kernel.org/
[2] https://lore.kernel.org/lkml/20240605032120.3179157-1-song@kernel.org/

Link: https://lore.kernel.org/r/20250302221518.76874-1-sergio.collado@gmail.com
Tested-by: Martin Rodriguez Reboredo 
Reviewed-by: Shuah Khan 
Reviewed-by: Rae Moar 
Signed-off-by: Sergio González Collado 
Link: https://github.com/Rust-for-Linux/linux/issues/504
Reviewed-by: Rae Moar 
Acked-by: David Gow 
Signed-off-by: Shuah Khan

x86/percpu/64: Remove INIT_PER_CPU macros

2025-02-18T09:15:50+00:00

Now that the load and link addresses of percpu variables are the same,
these macros are no longer necessary.

Signed-off-by: Brian Gerst 
Signed-off-by: Ingo Molnar 
Reviewed-by: Ard Biesheuvel 
Reviewed-by: Uros Bizjak 
Cc: Linus Torvalds 
Link: https://lore.kernel.org/r/20250123190747.745588-12-brgerst@gmail.com

x86/boot/64: Remove inverse relocations

2025-02-18T09:15:47+00:00

Inverse relocations were needed to offset the effects of relocation for
RIP-relative accesses to zero-based percpu data.  Now that the percpu
section is linked normally as part of the kernel image, they are no
longer needed.

Signed-off-by: Brian Gerst 
Signed-off-by: Ingo Molnar 
Reviewed-by: Ard Biesheuvel 
Cc: Linus Torvalds 
Link: https://lore.kernel.org/r/20250123190747.745588-11-brgerst@gmail.com

x86/percpu/64: Remove fixed_percpu_data

2025-02-18T09:15:43+00:00

Now that the stack protector canary value is a normal percpu variable,
fixed_percpu_data is unused and can be removed.

Signed-off-by: Brian Gerst 
Signed-off-by: Ingo Molnar 
Reviewed-by: Ard Biesheuvel 
Reviewed-by: Uros Bizjak 
Cc: Linus Torvalds 
Link: https://lore.kernel.org/r/20250123190747.745588-10-brgerst@gmail.com

x86/percpu/64: Use relative percpu offsets

2025-02-18T09:15:27+00:00

The percpu section is currently linked at absolute address 0, because
older compilers hard-coded the stack protector canary value at a fixed
offset from the start of the GS segment.  Now that the canary is a
normal percpu variable, the percpu section does not need to be linked
at a specific address.

x86-64 will now calculate the percpu offsets as the delta between the
initial percpu address and the dynamically allocated memory, like other
architectures.  Note that GSBASE is limited to the canonical address
width (48 or 57 bits, sign-extended).  As long as the kernel text,
modules, and the dynamically allocated percpu memory are all in the
negative address space, the delta will not overflow this limit.

Signed-off-by: Brian Gerst 
Signed-off-by: Ingo Molnar 
Reviewed-by: Ard Biesheuvel 
Reviewed-by: Uros Bizjak 
Cc: Linus Torvalds 
Link: https://lore.kernel.org/r/20250123190747.745588-9-brgerst@gmail.com