pm24.git/arch/x86/entry/Makefile, branch cpufreq-rust

x86/entry: Merge thunk_64.S and thunk_32.S into thunk.S

2024-04-09T07:57:56Z

The code in thunk_64.S and thunk_32.S are exactly the same except for the comments. Merge them in to thunk.S. And since thunk_32.S was originated from thunk_64.S, the new merged thunk.S is actually renamed from thunk_64.S. Signed-off-by: Lai Jiangshan Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20240407090558.3395-9-jiangshanlai@gmail.com

x86/fred: FRED entry/exit and dispatch code

2024-01-31T21:02:31Z

The code to actually handle kernel and event entry/exit using FRED. It is split up into two files thus: - entry_64_fred.S contains the actual entrypoints and exit code, and saves and restores registers. - entry_fred.c contains the two-level event dispatch code for FRED. The first-level dispatch is on the event type, and the second-level is on the event vector. [ bp: Fold in an allmodconfig clang build fix: https://lore.kernel.org/r/20240129064521.5168-1-xin3.li@intel.com and a CONFIG_IA32_EMULATION=n build fix: https://lore.kernel.org/r/20240127093728.1323-3-xin3.li@intel.com] Suggested-by: Thomas Gleixner Originally-by: Megha Dey Co-developed-by: Xin Li Signed-off-by: H. Peter Anvin (Intel) Signed-off-by: Xin Li Signed-off-by: Thomas Gleixner Signed-off-by: Borislav Petkov (AMD) Tested-by: Shan Kang Link: https://lore.kernel.org/r/20231209214214.2932-1-xin3.li@intel.com

x86/entry: Build thunk_$(BITS) only if CONFIG_PREEMPTION=y

2022-08-04T10:23:50Z

With CONFIG_PREEMPTION disabled, arch/x86/entry/thunk_$(BITS).o becomes an empty object file. With some old versions of binutils (i.e., 2.35.90.20210113-1ubuntu1) the GNU assembler doesn't generate a symbol table for empty object files and objtool fails with the following error when a valid symbol table cannot be found: arch/x86/entry/thunk_64.o: warning: objtool: missing symbol table To prevent this from happening, build thunk_$(BITS).o only if CONFIG_PREEMPTION is enabled. BugLink: https://bugs.launchpad.net/bugs/1911359 Fixes: 320100a5ffe5 ("x86/entry: Remove the TRACE_IRQS cruft") Signed-off-by: Andrea Righi Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/Ys/Ke7EWjcX+ZlXO@arighi-desktop

x86/bugs: Add retbleed=ibpb

2022-06-27T08:34:00Z

jmp2ret mitigates the easy-to-attack case at relatively low overhead. It mitigates the long speculation windows after a mispredicted RET, but it does not mitigate the short speculation window from arbitrary instruction boundaries. On Zen2, there is a chicken bit which needs setting, which mitigates "arbitrary instruction boundaries" down to just "basic block boundaries". But there is no fix for the short speculation window on basic block boundaries, other than to flush the entire BTB to evict all attacker predictions. On the spectrum of "fast & blurry" -> "safe", there is (on top of STIBP or no-SMT): 1) Nothing System wide open 2) jmp2ret May stop a script kiddy 3) jmp2ret+chickenbit Raises the bar rather further 4) IBPB Only thing which can count as "safe". Tentative numbers put IBPB-on-entry at a 2.5x hit on Zen2, and a 10x hit on Zen1 according to lmbench. [ bp: Fixup feature bit comments, document option, 32-bit build fix. ] Suggested-by: Andrew Cooper Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Borislav Petkov Reviewed-by: Josh Poimboeuf Signed-off-by: Borislav Petkov

x86/syscalls: Don't adjust CFLAGS for syscall tables

2021-05-25T14:59:23Z

The syscall_*.c files only contain data (the syscall tables). There is no need to adjust CFLAGS for tracing and stack protector since they contain no code. Signed-off-by: Brian Gerst Signed-off-by: Thomas Gleixner Reviewed-by: Masahiro Yamada Link: https://lore.kernel.org/r/20210524181707.132844-4-brgerst@gmail.com

x86/syscalls: Remove -Wno-override-init for syscall tables

2021-05-25T14:59:23Z

Commit 44fe4895f47c ("Stop filling syscall arrays with *_sys_ni_syscall") removes the need for -Wno-override-init, since the table is now filled sequentially instead of overriding a default value. Signed-off-by: Brian Gerst Signed-off-by: Thomas Gleixner Reviewed-by: Masahiro Yamada Link: https://lore.kernel.org/r/20210524181707.132844-3-brgerst@gmail.com

x86/entry: Actually disable stack protector

2020-07-19T11:07:10Z

Some builds of GCC enable stack protector by default. Simply removing the arguments is not sufficient to disable stack protector, as the stack protector for those GCC builds must be explicitly disabled. Remove the argument removals and add -fno-stack-protector. Additionally include missed x32 argument updates, and adjust whitespace for readability. Fixes: 20355e5f73a7 ("x86/entry: Exclude low level entry code from sanitizing") Signed-off-by: Kees Cook Signed-off-by: Thomas Gleixner Link: https://lkml.kernel.org/r/202006261333.585319CA6B@keescook

x86/entry: Make entry_64_compat.S objtool clean

2020-06-11T13:14:40Z

Currently entry_64_compat is exempt from objtool, but with vmlinux mode there is no hiding it. Make the following changes to make it pass: - change entry_SYSENTER_compat to STT_NOTYPE; it's not a function and doesn't have function type stack setup. - mark all STT_NOTYPE symbols with UNWIND_HINT_EMPTY; so we do validate them and don't treat them as unreachable. - don't abuse RSP as a temp register, this confuses objtool mightily as it (rightfully) thinks we're doing unspeakable things to the stack. Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Thomas Gleixner Reviewed-by: Alexandre Chartre Acked-by: Andy Lutomirski Link: https://lkml.kernel.org/r/20200505134341.272248024@linutronix.de

x86/entry: Exclude low level entry code from sanitizing

2020-06-11T13:14:35Z

The sanitizers are not really applicable to the fragile low level entry code. Entry code needs to carefully setup a normal 'runtime' environment. Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Thomas Gleixner Reviewed-by: Alexandre Chartre Link: https://lkml.kernel.org/r/20200505134059.970057117@linutronix.de

x86/entry/64: Split X32 syscall table into its own file

2020-03-21T15:03:21Z

Since X32 has its own syscall table now, move it to a separate file. Signed-off-by: Brian Gerst Signed-off-by: Thomas Gleixner Reviewed-by: Dominik Brodowski Link: https://lkml.kernel.org/r/20200313195144.164260-8-brgerst@gmail.com