mirror of
https://github.com/torvalds/linux.git
synced 2026-10-17 06:20:02 +02:00
master
1810 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Ziyi Guo
|
4d0697f192 |
riscv: entry: gate shadow call stack reload on sstatus.SPP, not tp
Under CONFIG_SHADOW_CALL_STACK, handle_exception() reloads the kernel
shadow call stack pointer (gp) only when the trap came from userspace.
It made that decision with scs_load_current_if_task_changed, which
compares the trap-time tp (read back from sscratch into s5) against the
current tp:
beq \prev, tp, _skip_scs
scs_load_current
_skip_scs:
tp is a user-writable register. A user task that sets tp to the
linear-map address of its own task_struct (¤t) before trapping
makes the comparison succeed (can achieve by brute force with KASLR
enable under our test), so the kernel skips scs_load_current and
keeps running with the gp that userspace left in place. Under
CONFIG_SHADOW_CALL_STACK gp is the shadow call stack pointer and
load_global_pointer is a no-op, so the compiler-emitted
"sd ra, -8(gp)" / "ld ra, -8(gp)" in every non-leaf function then write
to, and return through, an attacker-controlled address -- an
unprivileged kernel arbitrary-write and control-flow-hijack primitive.
The poisoned gp is saved to task_struct.scs_sp on return, so the reload
is skipped on every subsequent entry as well.
Decide "came from userspace" from the hardware sstatus.SPP bit (already
in s1 at this point) instead of from tp, mirroring the check that
ret_from_exception already uses a few instructions later. SPP is
written by hardware on trap entry and cannot be forged from U-mode.
Legitimate behaviour is unchanged: user entries (SPP=0) reload the task
shadow call stack, nested kernel entries (SPP=1) skip it.
Fixes:
|
||
|
Zongmin Zhou
|
59052a88ba |
riscv: ptrace: Zero-initialize regset buffers before copyin
user_regset_copyin() only copies `count` bytes, so a PTRACE_SETREGSET request with a short iov_len leaves the rest of the stack buffer uninitialized. In riscv_vr_set() that garbage is validated and copied into the target's vstate, and in riscv_cfi_set() it can be stored as the target's shadow stack pointer. Zero both buffers, as the get path already does. Fixes: |
||
|
Chen Pei
|
adadf6df0b |
riscv: ptrace: reject CFI regset access when extensions are absent
riscv_cfi_get() and riscv_cfi_set() do not check whether the Zicfilp
or Zicfiss extensions are present. On systems without them,
PTRACE_GETREGSET on REGSET_CFI still succeeds and returns a zeroed
user_cfi_state, misleading debuggers into believing the register set
is available, and PTRACE_SETREGSET silently accepts writes that have
no effect (e.g. clearing SR_ELP).
Reject the access with -EINVAL when neither branch landing pads nor
shadow stack is available to userspace, using the same availability
helpers as the prctl path.
Fixes:
|
||
|
Wei-Jie Hung
|
a510e1ae8c |
riscv: patch: fix handling of bpf-jit execmem addresses
Commit |
||
|
Yong-Xuan Wang
|
6694612317 |
RISC-V: Clear HSTATUS.HU on CPU initialization
The RISC-V privileged specification does not mandate HSTATUS reset values, leaving the HU bit potentially set after hardware reset. When HU=1, hypervisor instructions (HLV/HLVX/HSV) can execute in U-mode to access guest memory, which may cause unintended behavior if not explicitly controlled. Clear HSTATUS.HU during CPU initialization to ensure hypervisor instructions are only available in HS-mode, preventing unexpected guest memory access from U-mode code. Signed-off-by: Yong-Xuan Wang <yongxuan.wang@sifive.com> Reviewed-by: Samuel Holland <samuel.holland@sifive.com> Link: https://patch.msgid.link/20260924-hstatus_hu-v2-1-7e970f5f1d8d@sifive.com Cc: stable@vger.kernel.org [pjw@kernel.org: capitalized RISCV_ISA_EXT_h to fix build; added stable cc] Signed-off-by: Paul Walmsley <pjw@kernel.org> |
||
|
Linus Torvalds
|
ac7445c28e |
Random number generator fixes for Linux 7.3-rc6.
-----BEGIN PGP SIGNATURE----- iQJPBAABCAA5FiEEq5lC5tSkz8NBJiCnSfxwEqXeA64FAmq/uGEbFIAAAAAABAAO bWFudTIsMi41KzEuMTIsMiwyAAoJEEn8cBKl3gOumEgQAK0gjA0n40rHWGlmgIJO WTqMZGcbTvVXpPRyEXuNE7tTRsDDopen4UnmDqDGafXkBO1vU1LaxN72JonPjp7O sg4EqCi0iciuiDvLrjwQ1oPtpkL/feyjcNuNzSH/h2E4hJCUcEnyhTpeaRHCm3t4 IGDXqqYYqjAQV4N6dWrzwN5K2oM75IOzccr0hyROkN/DBrqNZtupOco725MKxSsr FGTgoh0a6GlN3Yp+AIjqaHcPca/aUZApPUKmBzoWeqZmSqAmpzUIJgaHsBZAQS88 oMcSh71Fzi2tOepiazjaAK9nZC3Nh2xeRU8cwUtvLvluzYA6wnBhcuTBOqThJmp3 gEYz8yPbvil0aDIhfXB3xW2dxxsHaJrKJDLz0Smhi43D2lLKteQT3BE/2jQQ7OSa 6FcV905hys3lIxlHeCa2wE/7NgiNAy3qE1aazkIKRfI8dRJxIuhogvW3VpKGCAue TwvjfvuoVtkaPAW/gLyDGRsMzrUvGPFa8yVvP5JTPrYQh5P+bEIM8CozWO2ScVcH Cdu0/TDe9TTS5mIwh0CrSX3shV/80bvHTINL14sTAKBGtN0N0vJgA8NSdIYt8OaF 8qDDMg/XV5LY7sbMB3/Kru//wyfUw4LJdYhZSIJ0tZvzaRRIRiZGL1lT+X12PCrq uoaJ4AoDCf/ZiDaVTXEVf+28 =GmSm -----END PGP SIGNATURE----- Merge tag 'random-7.3-rc6-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/crng/random Pull random number generator fixes from Jason Donenfeld: - VMGENID memory needs to be mapped with the decrypted tag, so that SEV-SNP machines can boot - A fix for an initialization race in VMGENID, followed by a cleanup - Trivial kernel doc cleanups in siphash and random.c - A fix for a new compilation failure with recent clang on PPC and RISC-V, due to generating an out-of-line memset in the vDSO * tag 'random-7.3-rc6-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/crng/random: random: vDSO: avoid call to memset() when zeroing reserved parameter random: fix vgetrandom_opaque_params kernel-doc random: vDSO: fix repeated word 'to' in comment siphash: clean up kernel-doc comments virt: vmgenid: move to using dev_set/get_drvdata virt: vmgenid: set driver_data before registering notification handlers virt: vmgenid: remap memory as decrypted |
||
|
Nathan Chancellor
|
eb13a1ff27 |
random: vDSO: avoid call to memset() when zeroing reserved parameter
After a recent change in LLVM [1], builds with the random vDSO implementation, such as PowerPC and RISC-V, fail when checking the vDSO: arch/powerpc/kernel/vdso/vdso32.so.dbg: dynamic relocations are not supported arch/riscv/kernel/vdso/vdso.so.dbg: dynamic relocations are not supported memset() is now generated when zeroing params->reserved for some builds because LLVM has an optimization (now run in more instances) that can recognize at compile time when it is assigning a static value to a contiguous area of memory and turn that into a call to memset(). Both clang and GCC assume memset() is always available [2]. Clang has an internal fiddly hook, -max-store-memset, which we can set to a high number, to disable generating out of line memset calls [3]. Similarly, GCC has -finline-stringops=memset to do the same [4], should this issue ever hit future version of GCC. While these options wouldn't make sense for normal kernel code, it is fine for the extremely limited and intentionally compact vDSO code. Link: |
||
|
JinRui
|
248dbaf777 |
riscv: report Zfhmin/Zvfhmin when Zfh/Zvfh are present
The RISC-V ISA manual specifies that Zfh implies Zfhmin, a normative rule clarified in https://github.com/riscv/riscv-isa-manual/pull/3070. Zvfh likewise implies Zvfhmin, as stated by the vector extension specification. The kernel currently reports ZFH and ZFHMIN (and ZVFH and ZVFHMIN) as independent hwprobe bits derived only from what the device tree declares. Platforms that declare just "zfh" (Zfh being a superset that already contains all Zfhmin instructions) therefore report RISCV_HWPROBE_EXT_ZFHMIN=0, which breaks userspace RVA23 conformance checks (e.g. snapd installing core26 on riscv64). Use the existing superset mechanism to set the implied subset bits: - zfh implies zfhmin - zvfh implies zvfhmin Add a hwprobe selftest asserting the implication holds and update the hwprobe documentation accordingly. This is complementary to the rva23u64 base behavior discussion: the RVA23 conformance query proposed there is derived from the per-extension bits fixed here, so correct EXT_0 reporting is a prerequisite for it to work on harts whose device tree declares only "zfh". Tested on a RISC-V QEMU VM whose device tree only declares "zfh" and "zvfh": with this change both /proc/cpuinfo and the hwprobe RISCV_HWPROBE_KEY_IMA_EXT_0 bitmap report ZFHMIN and ZVFHMIN, and the hwprobe selftest (including the new implication check) passes. Link: https://lore.kernel.org/kvm-riscv/20260206002349.96740-1-andrew.jones@oss.qualcomm.com/ Signed-off-by: JinRui <jinrui@haiwei.tech> Link: https://patch.msgid.link/7190E4DB338251C3+20260811081513.2849980-1-jinrui@haiwei.tech [pjw@kernel.org: trimmed superfluous blank line in tags] Signed-off-by: Paul Walmsley <pjw@kernel.org> |
||
|
Andy Chiu
|
d0fc6fab20 |
riscv: hwprobe: initialize pair->value in hwprobe_one_pair()
The vendor-extension handlers reached from hwprobe_one_pair()
(hwprobe_isa_vendor_ext_thead_0() and friends) only OR the present bits
into pair->value via VENDOR_EXTENSION_SUPPORTED() and clear their own
missing bits; they assume the caller has already zeroed pair->value.
That holds for hwprobe_get_values() (it zeroes each pair) and
hwprobe_get_cpus() (it re-initializes its scratch pair per key), but not
for complete_hwprobe_vdso_data(), which reuses a single pair across all
keys without re-zeroing. A vendor key therefore inherits stale bits from
the previously probed key, and the wrong value is cached in the vDSO
all_cpu_hwprobe_values[] and handed to userspace on the fast patih.
Zero pair->value once at the top of hwprobe_one_pair() so every handler
starts from a clean value regardless of the caller, and drop the now
redundant zeroing in the *_BLOCK_SIZE cases. hwprobe_isa_ext0() keeps its
own zeroing because hwprobe_ext0_has() calls it directly, bypassing
hwprobe_one_pair().
Fixes:
|
||
|
Dmitry Antipov
|
12381af010 |
riscv: use string helper in setup_global_riscv_enable()
Prefer the convenient string choice 'str_disabled_enabled()' helper over hardcoded strings in 'setup_global_riscv_enable()'. Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Link: https://patch.msgid.link/20260819160546.3219942-1-dmantipov@yandex.ru Signed-off-by: Paul Walmsley <pjw@kernel.org> |
||
|
Samuel Holland
|
2d2184ac90 |
Revert "riscv: Reset pmm when PR_TAGGED_ADDR_ENABLE is not set"
This reverts commit |
||
|
Xiaofeng Yuan
|
8718e5a309 |
riscv: patch: skip fixmap mapping when kernel text is already writable
patch_map() always creates a temporary writable mapping via fixmap for kernel text addresses, even when CONFIG_STRICT_KERNEL_RWX is disabled and the kernel text is already mapped with _PAGE_WRITE. This is unnecessary overhead at best, and on minimal configurations it can cause page faults. Skip the fixmap path for kernel text when CONFIG_STRICT_KERNEL_RWX is not enabled, since the text pages are already writable in that case. The module text path is already gated on CONFIG_STRICT_MODULE_RWX and is kept unchanged. Reported-by: Klara Modin <klara@kasm.eu> Closes: https://lore.kernel.org/all/ant_8TaBbov_GS4i@soda.int.kasm.eu/ Reported-by: Lad Prabhakar <prabhakar.csengg@gmail.com> Closes: https://lore.kernel.org/all/CA+V-a8tQK8rih9SGGTyqrEBGpNkx4H0eX2YccCRrgkVAPr+EBg@mail.gmail.com/ Tested-by: Klara Modin <klarasmodin@gmail.com> Tested-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Link: https://patch.msgid.link/20260814082742.148403-3-xiaofengmian@163.com Signed-off-by: Paul Walmsley <pjw@kernel.org> |
||
|
Linus Torvalds
|
7bb6284aa7 |
Arm:
* Add support for 'slot' based PMU events, paired with new UAPI that
compels the user to select a specific PMU implementation
* Lazy save/restore of vCPU state for pKVM, along with various fixes
and cleanups to the management of vCPU state between the untrusted
host and pKVM hypervisor
* Disable traps of EL1 registers for nested hypervisors when FEAT_NV2p1
is present, guaranteeing that EL2-specific register bits are stateful
in the EL1 counterpart
* Leverage FEAT_NV3 to avoid unnecessary ERET/TLBI traps when the scope
of those instructions remains 'in host' (i.e. L1 kernel/userspace)
* Pile of fixes for the management of the VNCR pseudo-TLB, such as
under-invalidations and races with concurrent TLBIs on other vCPUs
* Consolidate the non-protected and pKVM view of ICH_VTR_EL2 to a
runtime-patched constant, allowing the same data to be shared with
pKVM prior to dropping host privileges
* Considerable pile of LLM-assisted fixes around the shop but mostly in
the VGIC, our in-kernel generator of bugs (and sometimes interrupts)
LoongArch:
* Advertise already-supported capabilities.
* Some bug fixes about timer and MMIO.
* Some hardening about interrupt injection.
* Replace kvm_err() with kvm_pr_unimpl().
* Add FPU/LSX/LASX test cases for selftests.
RISC-V:
* Svadu/Zicfiss/Zicfilp FWFT support for Guest
* Use try_cmpxchg for IMSIC MRIF RMW
* More arch-specific tracepoints in KVM RISC-V
* Eager page splitting when enabling dirty logging
* Optimize hfence request handling for SMP Guests
* Improve dirty log clearing by skipping zero bits in mask
* Guard HFENCE range loops against overflow
* CPU PM notifiers in KVM RISC-V for non-retentive idle states
* Fix kernel-mode vector context save/restore for Guest
s390:
* Fixes for vfio-ap
* Fixes for the gmap rework
* Fixes for vsie
* AI triggered fixes all over
* diag9c tracing
* code move preparation for the additional arm64 support
* enable CONTEXT_ANALYSIS
x86:
* Perform spring cleaning on x86.{c,h} and asm/kvm_host.h, by adding regs.c
(the kvm_cache_regs.h => regs.h is already applied) and msrs.{c,h}, and moving
relevant code out of x86.c.
* Split kvm_mmu in three parts, respectively to describe the format of page
tables, walking the guest page tables and building the page tables. Always
use the same page table walker kvm->arch.gva_walk as the entry point to
convert a guest's virtual address, where the previous code used two
different kvm_mmu structs depending on whether the walk included nested
EPT/NPT or not. Make page fault vmexits reuse the permission checking
machinery that is used for guest page faults. This is both a cleanup
and a baby step towards supporting XS/XU memory permissions.
* Document some of the "fun" gotchas with the APIC base when creating IRQCHIPs
on x86.
* Remove a defunct masterclock update from kvm_xen_shared_info_init(). It
could result in incorrect kvmclock due to triggering an unnecessary
switch to/from masterclock mode.
* Skip Xen runstate time updates if time has effectively gone backwards, so
that the guest doesn't report 100% steal time for a very, very long time.
* Drop KVM's runtime updates of the Xen PV timing CPUID leaf, as KVM was
updating the wrong sub-leaf, and upstream KVM will soon provide all the
information needed by userspace to populate the CPUID field itself.
* Fix a bug where KVM would walk a newly created rmap without holding the rmap
lock (or mmu_lock) during aging.
* Fix a bug where aging TDP MMU SPTEs could clobber FROZEN SPTEs.
* Fix a variety of #DB priority bugs.
* Fix a class of races related to enabling Hyper-V emulation on a vCPU after
the vCPU is visible to the rest of KVM.
* Use static calls for nested virtualization ops.
* Move more KVM-internal code out of x86's kvm_host.h.
* Enumerate support for a variety of Zhaoxin instructions that don't require
explicit virtualization.
* Fix missing EFER validation bugs, including in the KVM_SET_SREGS* path.
* Harden kvm_vcpu_map() against double-mapping and thus leaking references.
* Misc fixes and cleanups, e.g. for largely benign syzkaller splats.
x86 (Intel):
* Zero a vCPU's entry in VMX's Posted Interrupt Descriptor table used for IPI
virtualization when the vCPU is freed, to fix a use-after-free where hardware
will write to a freed vCPU's PID.
* Service local TLB flushes on a failed nested VM-Enter to fix a bug where KVM
could miss a TLB on a future, successful VM-Enter with the same L2 VPID.
* Cap the maximum value shoved into the VMX Preemption Timer to workaround an
erratum that affects all existing Intel CPUs that support CPUID 0x15.
* Fix VPID virtualization bugs where KVM would fail to flush hardware TLBs.
* Harden the TDX "populate" ioctls against bad input, and to prepare
for supporting in-place private<=>shared conversion.
x86 (AMD):
* Forcefully invalidate SNP VMSA pages if their backing guest_memfd page is
zapped/invalidated, e.g. due to a PUNCH_HOLE in response to a Page-State
Change request.
* Remove a dying VM from the GA Log notifier list before the VM is actually
destroyed, to fix a potential use-after-free.
* While FOLL_WRITE was needed in the past to trigger CoW unsharing, nowadays
FOLL_LONGTERM does that already even without FOLL_WRITE, and in fact,
get_user_pages() actually disallows FOLL_WRITE together with FOLL_LONGTERM.
So don't pass FOLL_WRITE when registering encrypted memory regions, i.e. when
pinning SEV/SEV-ES guest memory, to fix a regression with file-backed memory
introduced by KVM's (correct) usage of long-term pins.
(This was reviewed by mm maintainers; for more information, see commit
|
||
|
Linus Torvalds
|
073e62fd33 |
RISC-V updates for v7.3
- Add initial definitions and discovery for the Smcsrind, Sscsrind, Smcntrpmf, Ssccfg, Smcdeleg, Zicclsm, Ziccamoa, Ziccif, Ziccrse, Za64rs, and Ssqosid RISC-V ISA extensions - Improve the RISC-V update_mmu_cache_range() implementation by using flush-by-ASID, enabling performance improvements on microarchitectures that support related optimizations; and by taking advantage of the Svinval RISC-V ISA extension on microarchitectures that support it - Shrink CFI shadow stack allocation further (to 512MB) to save virtual address space (and physical memory on systems with strict overcommit policies) - Add initial CPU context switch support for QoS tagging (Ssqosid) - Change our vector misaligned access speed test code to be synchronous, avoiding a bunch of bugs related to unnecessary asynchronicity - Enable ARCH_HAS_ACPI_TABLE_UPGRADE for RISC-V to help with ACPI table debugging (similar to ARM64 and x86) - Extract vDSO section offsets at build time, rather than run time, to avoid the boot time overhead - Use assembler directives to control the use of instructions from the RISC-V ISA extensions Zacas and Zabha, rather than compiler -march flags that could affect the whole kernel (similar to ARM64) - Add a kselftest for kprobes support for the c.jal instruction on RISC-V - When UEFI runtime services are available, use them to restart and power off - Fix ARCH_HAS_ACPI_TABLE_UPGRADE for RISC-V by adding a missing include file to the ACPI code - Move contiguous DMA memory reservation later in the boot, to ensure that the correct global and per-node pools are allocated when CONFIG_CMA_SIZE_PERNUMA is enabled - Disallow probes on breakpoint handlers to avoid recursing indefinitely into do_trap_break() - Patch the compat vDSO during runtime alternatives processing, not only the standard vDSO - Remove some leftover XIP support elements missed by commit |
||
|
Linus Torvalds
|
3424d8c18a |
Generic entry code updates:
- Make syscall user dispatching configurable
Not all architectures can makes use of syscall user dispatching. Allow
them to disable the feature completely.
- Consolidate stack randomization for the generic entry code and the
architectures using it.
Stack randomization on syscall entry was sprinkled throughout the
architecture specific low level entry code and in some cases at the
wrong points, e.g. before establishing state, which violates the
non-instrumentable constraints of that code.
Clean this up by integrating stack randomization into the generic entry
code helpers so that it is invoked at the earliest possible point right
after establishing state and converting all generic entry code using
architecture over.
- Clean up the syscall number handling in the generic entry code. It
works correctly for architectures which have a separate return value
storage in pt_regs, but fails to distinguish the case where user space
handed in -1 as syscall number from the case where the entry code
rejects it by returning -1 to the callers. Aside of that the return
value functionality of those interfaces is not really intuitive.
Fix this by separating the decision to reject a syscall (user dispatch,
ptrace, seccomp ...) from the potential modification of the syscall
number through these mechanisms.
This solves most of the problems for architectures which do not have a
separate return value storage in pt_regs except for the case where a
tracepoint has a BPF script or a probe attached which overwrite both
the syscall number and the return value. But that's a problem which
cannot be solved in the generic code, that only can be addressed by
separating the storage model in the affected architectures.
-----BEGIN PGP SIGNATURE-----
iQJEBAABCgAuFiEEQp8+kY+LLUocC4bMphj1TA10mKEFAmqCs10QHHRnbHhAa2Vy
bmVsLm9yZwAKCRCmGPVMDXSYoaf6D/0ZBG1Yb0/C/6lrI185qPu38aGOROuAcxP+
RV1O1x6C83w2hCLBH8LeswY2x4/iGbdftne/hfmvu8eNCE5MzBfYvXhLL4If75Tc
IJ6C8uummnDmrT1TFuWHryTAfjyF28gt0+GGq0Zy5Hyz9b4CTJqOMx5u6KV4cZuJ
odoNQpE/GlWo40wCSTYP/Tt5xONrogk2pMQtFyV8JEoaXkdYSj/V815yojEmofYU
fmgPPO5/vOnZzE4b29gZyndXnU1Boah7r1l5fg7c9za376yCEEzh/ApPhovHyY0A
t8zjnrtooZ27IUKbcsyycrAM14asfcmViDNDgaCj8ttBioQaCnxO1BpKWjVxEZhE
AbM6q3Q66ER4Df6GNhZjPqT5Lr7E7+vLLarhXLWztsGQklIx4AFbrsa73hA20UC9
1PSeMd45JSxH3yA8vMauXAGHFK1tD1V8Lgofu69+2Z3jtKB+aU0fqWeL1jesSEM0
oCGhUb3hIC1pz3KVA0MGmNTm0yyQJYTGZL7wADYNV5NbxJVqXgo37qa/0n94Gf/4
TG3OwY4Sb/H/sve7v/eY4IvxVh+xs3dLZP8ZoqMlPCp9JIxc6iNoe6VHqPI7PFnM
fXwDtsy+bRF/SKnB/32qxnR7UJqmdNH3XIjd+lXWliKt6UYoC79/MEKN5DmJcO9P
CykZUWa72A==
=XUd9
-----END PGP SIGNATURE-----
Merge tag 'core-entry-2026-08-17' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull generic entry code updates from Thomas Gleixner:
- Make syscall user dispatching configurable
Not all architectures can makes use of syscall user dispatching.
Allow them to disable the feature completely.
- Consolidate stack randomization for the generic entry code and the
architectures using it.
Stack randomization on syscall entry was sprinkled throughout the
architecture specific low level entry code and in some cases at the
wrong points, e.g. before establishing state, which violates the
non-instrumentable constraints of that code.
Clean this up by integrating stack randomization into the generic
entry code helpers so that it is invoked at the earliest possible
point right after establishing state and converting all generic entry
code using architecture over.
- Clean up the syscall number handling in the generic entry code. It
works correctly for architectures which have a separate return value
storage in pt_regs, but fails to distinguish the case where user
space handed in -1 as syscall number from the case where the entry
code rejects it by returning -1 to the callers. Aside of that the
return value functionality of those interfaces is not really
intuitive.
Fix this by separating the decision to reject a syscall (user
dispatch, ptrace, seccomp ...) from the potential modification of the
syscall number through these mechanisms.
This solves most of the problems for architectures which do not have
a separate return value storage in pt_regs except for the case where
a tracepoint has a BPF script or a probe attached which overwrite
both the syscall number and the return value. But that's a problem
which cannot be solved in the generic code, that only can be
addressed by separating the storage model in the affected
architectures.
* tag 'core-entry-2026-08-17' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (23 commits)
entry, treewide: Make syscall_enter_from_user_mode[_work]() indicate syscall execution
entry: Make return type of syscall_trace_enter() bool
entry: Rework trace_syscall_enter()
entry: Rework syscall_audit_enter()
syscall_user_dispatch: Introduce ARCH_SUPPORTS_SYSCALL_USER_DISPATCH
entry: Fix seccomp bypass after ptrace with TSYNC
x86/entry: Simplify the syscall number logic
x86/entry: Get rid of the sys_ni_syscall() indirection
x86/entry: Make syscall functions static
ptrace, treewide: Rename ptrace_report_syscall_entry() to ptrace_report_syscall_permit_entry()
seccomp, treewide: Rename and convert __secure_computing() to return boolean
entry: Use syscall number instead of rereading it
entry: Remove syscall_enter_from_user_mode()
x86/syscall: Use [syscall_]enter_from_user_mode_randomize_stack()
s390/syscall: Use enter_from_user_mode_randomize_stack()
riscv/syscall: Use syscall_enter_from_user_mode_randomize_stack()
powerpc/syscall: Use syscall_enter_from_user_mode_randomize_stack()
loongarch/syscall: Use syscall_enter_from_user_mode_randomize_stack()
entry: Provide [syscall_]enter_from_user_mode_randomize_stack()
randomize_kstack: Provide add_random_kstack_offset_irqsoff()
...
|
||
|
Linus Torvalds
|
ba24659b1d |
kexec: updates for v7.3-rc1
* Deduplicate crash memory allocation and the exclusion of reserved crash kernel regions from architecture specific code into a generic crash_prepare_headers() and enable crashkernel CMA reservation on arm64 and riscv reservation on arm64 and riscv. * Skip purgatory checksum verification when the kexec segments cannot be corrupted by DMA, which saves about 250ms on kexec. * Replace __ASSEMBLY__ with the compiler provided __ASSEMBLER__ in include/linux/kexec.h. * Fix a keyring refcount imbalance in the kdump kernel's dm-crypt key restore path, which over-dropped the user keyring reference when more than one key was restored. -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEeOVYVaWZL5900a/pOQOGJssO/ZEFAmp9ouoACgkQOQOGJssO /ZEH/Af/b1qmnw8uUe2wzd1zcAEEsk6YwF8lmS5o4k7skiVKlHWQuDzPrwrxFTvg d6obJrLllMN2ULyLQ8ghMKbsdo8RCGBIpXF+bPEXmIF8bA/PhtDaxvi3scsxvie6 zU3geZbExlzg0Ik525I0DyPoEZc2JAg5ietp8bF6ZN5HNkDtBoNvi2ROc4mR9kzO agrczVnIEuIE3Tk+IfD6081iS3Wz/PjRC+yPBU1yYFobA6/bL7kFma7kED8PnxvI 2+oENcd1FtC/WBlmluZE0BC4SjNcsT1geyzAFlGlRvNzbHdtj13j6mTBSsbRpJMW WdewVpIpFGUqRbUIIdvOISLOcf62lg== =PjFs -----END PGP SIGNATURE----- Merge tag 'kexec-v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/liveupdate/linux Pull kexec updates from Mike Rapoport: - Deduplicate crash memory allocation and the exclusion of reserved crash kernel regions from architecture specific code into a generic crash_prepare_headers() and enable crashkernel CMA reservation on arm64 and riscv reservation on arm64 and riscv. - Skip purgatory checksum verification when the kexec segments cannot be corrupted by DMA, which saves about 250ms on kexec. - Replace __ASSEMBLY__ with the compiler provided __ASSEMBLER__ in include/linux/kexec.h. - Fix a keyring refcount imbalance in the kdump kernel's dm-crypt key restore path, which over-dropped the user keyring reference when more than one key was restored. * tag 'kexec-v7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/liveupdate/linux: crash_dump: release keyring reference at the correct time kexec: Replace __ASSEMBLY__ with __ASSEMBLER__ in header file kexec_file: skip checksum verification when safe riscv: kexec_file: Add support for crashkernel CMA reservation arm64: kexec_file: Add support for crashkernel CMA reservation powerpc/kexec_file: Use crash_exclude_core_ranges() helper LoongArch: kexec_file: Use crash_prepare_headers() helper to simplify code riscv: kexec_file: Use crash_prepare_headers() helper to simplify code x86/crash: Use crash_prepare_headers() helper to simplify code arm64: kexec_file: Use crash_prepare_headers() helper to simplify code crash: Add crash_prepare_headers() to exclude crash kernel memory powerpc/crash: sort crash memory ranges before preparing elfcorehdr riscv: kexec_file: Fix crashk_low_res not exclude bug |
||
|
Paolo Bonzini
|
4136288688 |
LoongArch KVM changes for v7.3
1. Advertise already-supported capabilities. 2. Some bug fixes about timer and MMIO. 3. Some hardening about interrupt injection. 4. Replace kvm_err() with kvm_pr_unimpl(). 5. Add FPU/LSX/LASX test cases for selftests. -----BEGIN PGP SIGNATURE----- iQJKBAABCAA0FiEEzOlt8mkP+tbeiYy5AoYrw/LiJnoFAmp9ca4WHGNoZW5odWFj YWlAa2VybmVsLm9yZwAKCRAChivD8uImelAuD/4jhprQWR9b8RMQ9bGYaBDml+98 fCRW8NPyicnct+97U/E9EXJrrMyyDOqJtOSnNQOVmTjz3IGQtzLoHULaJPqUv0Dh 7xUbpmb7qkqxrykUEUa81tDnClpISfLcgUBWKsg0VGLyF7MIEnbtECTadbzQEd10 hNXy/Pv8OiAIZe4rtlGWxOU5JxU6OVf0zEmXiS6cbqXrwxVl4STbF97/5ULqjU+D 4KMMs1IcOdf4klQeoE1oKvWsCiedZQBkKbtsv2hpDMmY4lUdheJg9+0atr8Oh7VS TtlO6Fmt7ilK9eFOCapDcs4gf5WQgs8WXKAyVUYSoteyEXQ9kSF2bHMYiC+WaKhb kMRR9ZyJa086FwDvW9/TyMrP8HLR4ORa7ksOeBnGt4Uv9A92ZbGqvEqLILPoKsIR LBJUM17XuLlR9J56sYNtid3Rdq88VLo84Wfc0hW966b+6oNdOVQBPI2YRpk4wDT1 Mtra60dtzwQ3jCW/GTjJThueEC4lqOFKHpYPIP3rd4aL8oCvfgLYlYZ4TiXHUjpX MgQ9rm8nDZAWipsjvt2yADFnv3YW4kD6hrn1S0EaDJXsTtT7pB6Mr0jlxQE/ZJdA ibXSubO5cakIdpMnAylL78ZyGZOWn6YOSG1pEjHjkI+in73sZ5a89k4s5ErxKxtB Hnc/FXwVWbylUdJkKw== =eMRy -----END PGP SIGNATURE----- Merge tag 'loongarch-kvm-7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson into HEAD LoongArch KVM changes for v7.3 1. Advertise already-supported capabilities. 2. Some bug fixes about timer and MMIO. 3. Some hardening about interrupt injection. 4. Replace kvm_err() with kvm_pr_unimpl(). 5. Add FPU/LSX/LASX test cases for selftests. |
||
|
Andy Chiu
|
b5060a4aa3 |
RISC-V: KVM: fix vcpu vector context handling for kernel-mode vector
Running vector workloads like perf + mcf on KVM can result in an
unexpected termination due to a vtype corruption. This happens because
the kernel-mode vector (KMV) misattributes the guest's vcpu context as
the user's context and source from a wrong status.VS.
The simplified call chain that results in this problem is shown as
follow:
__riscv_sys_ioctl()
kvm_arch_vcpu_ioctl_run()
kvm_riscv_vcpu_exit()
kvm_riscv_vcpu_sbi_ecall()
kvm_riscv_vcpu_pmu_ctr_stop()
kvm_vcpu_write_guest()
__copy_to_user()
enter_vector_usercopy()
kernel_vector_begin()
kernel_vector_begin() should use the sstatus.VS from guest's vcpu
context instead of task_pt_reg(current). Also, it should not save
guest's v-reg into the user's context memory.
To resolve this, the vcpu context must be correctly saved when KMV is
serving a guest. However, invoking KVM functions directly from generic
RISC-V architecture code introduces a reverse dependency, breaking
builds when KVM is configured as N or M.
Address this by registering an RCU-protected callback for context
flushing. KVM registers this callback at module initialization and
unregisters it on exit. When KMV starts a kernel context, it can now
safely flush the vector context via the callback.
Fixes:
|
||
|
Andy Chiu
|
848a973c5f |
riscv: vector: allow non-preemptible kernel-mode vector with IRQs off
Similar to commit
|
||
|
Andy Chiu
|
8f798d6d7f |
riscv: vector: refactor riscv_v_start_kernel_context
Refactor riscv_v_start_kernel_context() to drop `is_nested` variable and simplify the logic. This introduces no functional change and works as a preparatory patch for the kernel-mode vector fix. Signed-off-by: Andy Chiu <tchiu@tenstorrent.com> Reviewed-by: Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/20260803215250.824417-2-tchiu@tenstorrent.com Signed-off-by: Anup Patel <anup@brainfault.org> |
||
|
Thomas Weißschuh
|
42cd1e1fc8 |
riscv: alternative: Also patch the compat vDSO
The vDSO for compat processes can also contain alternative entries. Patch those, too. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://patch.msgid.link/20260630-riscv-vdso32-alternative-v1-3-a32fd89b7b1c@linutronix.de Signed-off-by: Paul Walmsley <pjw@kernel.org> |
||
|
Thomas Weißschuh
|
63aecaba41 |
riscv: alternative: Use the statically extracted vDSO section offsets
Currently the alternative sections are extracted from the vDSO binaries at runtime. This has runtime overhead and also doesn't work for the compat vDSO. Use the offsets generated during the build instead, fixing both issues. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://patch.msgid.link/20260630-riscv-vdso32-alternative-v1-2-a32fd89b7b1c@linutronix.de Signed-off-by: Paul Walmsley <pjw@kernel.org> |
||
|
Thomas Weißschuh
|
7f2a7bbcd9 |
riscv: vdso: Add symbols for the alternative section boundaries
Currently the alternative sections are extracted from the vDSO binaries at runtime. This has runtime overhead and also doesn't work for the compat vDSO. Extract the offsets of the alternative section during the build with the existing symbol extraction machinery. Also add dummy symbols as fallback. Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://patch.msgid.link/20260630-riscv-vdso32-alternative-v1-1-a32fd89b7b1c@linutronix.de Signed-off-by: Paul Walmsley <pjw@kernel.org> |
||
|
Andrew Jones
|
f61959a3a8 |
riscv: Add Ziccamoa, Ziccif, Ziccrse, and Za64rs to cpufeature and hwprobe
Add Ziccamoa, Ziccif, and Za64rs to riscv_isa_ext[] so they can be parsed from devicetree/ACPI ISA strings. Ziccrse is already present in cpufeature; this patch only adds its hwprobe exposure. Expose all four extensions via hwprobe through new bits in RISCV_HWPROBE_KEY_IMA_EXT_1 (RISCV_HWPROBE_EXT_ZICCAMOA, _ZICCIF, _ZICCRSE, _ZA64RS), so userspace can probe each of these RVA23U64-mandatory extensions individually. Reviewed-by: Jesse Taube <jtaubepe@redhat.com> Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Signed-off-by: Guodong Xu <docular.xu@gmail.com> Link: https://patch.msgid.link/20260701-rva23u64-hwprobe-v2-v5-6-2c61f94a695a@gmail.com [pjw@kernel.org: updated to apply] Signed-off-by: Paul Walmsley <pjw@kernel.org> |
||
|
Jesse Taube
|
3cd63bc30c |
riscv: Add Zicclsm to cpufeature and hwprobe
Zicclsm requires misaligned support for all regular load and store instructions, both scalar and vector, but not AMOs or other specialized forms of memory access, to main memory regions with both the cacheability and coherence PMAs, as defined in the profiles spec. Even though mandated, misaligned loads and stores might execute extremely slowly. Standard software distributions should assume their existence only for correctness, not for performance. Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Andy Chiu <andy.chiu@sifive.com> Reviewed-by: Charlie Jenkins <charlie@rivosinc.com> Tested-by: Charlie Jenkins <charlie@rivosinc.com> Signed-off-by: Jesse Taube <jesse@rivosinc.com> [andrew.jones: Rebased, rewrote doc text, minor commit message revisions] Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Signed-off-by: Guodong Xu <docular.xu@gmail.com> Link: https://patch.msgid.link/20260701-rva23u64-hwprobe-v2-v5-5-2c61f94a695a@gmail.com [pjw@kernel.org: updated to apply; added Andrew's username to his tag comments] Signed-off-by: Paul Walmsley <pjw@kernel.org> |
||
|
Guodong Xu
|
fdef048705 |
riscv: cpufeature: Clarify ISA spec version for canonical order
Specify that chapter 27 refers to version 20191213 of the RISC-V ISA
Unprivileged Architecture. The chapter numbering differs across
specification versions - for example, in version 20250508, the ISA
Extension Naming Conventions is chapter 36, not chapter 27.
Historical versions of the RISC-V specification can be found via Link [1].
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://riscv.org/specifications/ratified/ [1]
Fixes:
|
||
|
Charlie Jenkins
|
0c5a9ab519 |
riscv: Standardize extension capitalization
The base extensions are often lowercase and were written as lowercase in hwcap, but other references to these extensions in the kernel are uppercase. Standardize the case to make it easier to handle macro expansion. Acked-by: Anup Patel <anup@brainfault.org> Reviewed-by: Anup Patel <anup@brainfault.org> Signed-off-by: Charlie Jenkins <thecharlesjenkins@gmail.com> [andrew.jones: Apply KVM_ISA_EXT_ARR(), fixup all KVM use.] Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Signed-off-by: Guodong Xu <docular.xu@gmail.com> Link: https://patch.msgid.link/20260701-rva23u64-hwprobe-v2-v5-4-2c61f94a695a@gmail.com [pjw@kernel.org: fixed a checkpatch warning; added Andrew's username to his tag comments] Signed-off-by: Paul Walmsley <pjw@kernel.org> |
||
|
Rui Qi
|
e7d8ea6c6d |
riscv: kprobes: Prevent probes in breakpoint handlers
The ftrace selftest multiple_kprobes.tc registers kprobe events on the first 256 text symbols from /proc/kallsyms. If handle_break() is selected as a probe target on RISC-V, the breakpoint exception path can trap again before it reaches the kprobe breakpoint handler. That recursively enters do_trap_break() and can make the system unresponsive. Mark handle_break() and its local probe dispatch helpers as nokprobe symbols so they are added to the kprobe blacklist, matching other low-level breakpoint exception paths. Signed-off-by: Rui Qi <qirui.001@bytedance.com> Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://patch.msgid.link/20260806043807.2583001-1-qirui.001@bytedance.com Signed-off-by: Paul Walmsley <pjw@kernel.org> |
||
|
Jisheng Zhang
|
abcdefbe49 |
riscv: further remove XIP
After commit
|
||
|
Drew Fustini
|
326ba66db9 |
riscv: Add support for srmcfg CSR from Ssqosid extension
Add support for the srmcfg CSR defined in the Ssqosid ISA extension. The CSR contains two fields: - Resource Control ID (RCID) for resource allocation - Monitoring Counter ID (MCID) for tracking resource usage Requests from a hart to shared resources are tagged with these IDs, allowing resource usage to be associated with the running task. Add a srmcfg field to thread_struct with the same format as the CSR. The context-switch path writes the field to the CSR, and resctrl_arch_set_closid_rmid() updates it when a task is assigned to a resctrl control or monitoring group. A per-cpu cpu_srmcfg_default holds the default srmcfg for each CPU, set by resctrl_arch_set_cpu_default_closid_rmid() on CPU group assignment. On context switch, RCID and MCID inherit from the CPU default independently: a task whose thread RCID field is zero takes the CPU default's RCID, and likewise for MCID. A per-cpu cpu_srmcfg variable mirrors the CSR state to avoid redundant writes. L1D-hot memory access is faster than a CSR read and avoids traps under virtualization. Link: https://github.com/riscv/riscv-ssqosid/releases/tag/v1.0 Assisted-by: Claude:claude-opus-4-7 Co-developed-by: Kornel Dulęba <mindal@semihalf.com> Signed-off-by: Kornel Dulęba <mindal@semihalf.com> Signed-off-by: Drew Fustini <fustini@kernel.org> Link: https://patch.msgid.link/20260729-dfustini-atl-sc-cbqri-dt-v6-3-7c22b05d461b@kernel.org Signed-off-by: Paul Walmsley <pjw@kernel.org> |
||
|
Drew Fustini
|
5a17eb5f1c |
riscv: Detect the Ssqosid extension
Ssqosid is the RISC-V Quality-of-Service (QoS) Identifiers specification which defines the Supervisor Resource Management Configuration (srmcfg) register. Link: https://github.com/riscv/riscv-ssqosid/releases/tag/v1.0 Co-developed-by: Kornel Dulęba <mindal@semihalf.com> Signed-off-by: Kornel Dulęba <mindal@semihalf.com> Signed-off-by: Drew Fustini <fustini@kernel.org> Link: https://patch.msgid.link/20260729-dfustini-atl-sc-cbqri-dt-v6-2-7c22b05d461b@kernel.org [pjw@kernel.org: updated to apply] Signed-off-by: Paul Walmsley <pjw@kernel.org> |
||
|
Atish Patra
|
ebdec8d2c1 |
RISC-V: Add Ssccfg/Smcdeleg ISA extension definition and parsing
Smcdeleg extension allows the M-mode to delegate selected counters to S-mode so that it can access those counters and correpsonding hpmevent CSRs without M-mode. Ssccfg (‘Ss’ for Privileged architecture and Supervisor-level extension, ‘ccfg’ for Counter Configuration) provides access to delegated counters and new supervisor-level state. This patch just enables these definitions and enable parsing. Signed-off-by: Atish Patra <atishp@rivosinc.com> Reviewed-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Link: https://patch.msgid.link/20260807-counter_delegation-v9-9-58658104e487@meta.com Signed-off-by: Paul Walmsley <pjw@kernel.org> |
||
|
Atish Patra
|
9e35091314 |
RISC-V: Add Smcntrpmf extension parsing
Smcntrpmf extension allows M-mode to enable privilege mode filtering for cycle/instret counters. However, the cyclecfg/instretcfg CSRs are available in Ssccfg only if Smcntrpmf is present. That's why, kernel needs to detect presence of Smcntrpmf extension and enable privilege mode filtering for cycle/instret counters. Reviewed-by: Clément Léger <cleger@rivosinc.com> Signed-off-by: Atish Patra <atishp@rivosinc.com> Reviewed-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Tested-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Link: https://patch.msgid.link/20260807-counter_delegation-v9-6-58658104e487@meta.com Signed-off-by: Paul Walmsley <pjw@kernel.org> |
||
|
Atish Patra
|
0ce0702f5e |
RISC-V: Add Smcsrind and Sscsrind ISA extension definition and parsing
The S[m|s]csrind extensions extend the indirect CSR access mechanism defined in Smaia/Ssaia extensions. This patch just enables the definition and parsing. Signed-off-by: Atish Patra <atishp@rivosinc.com> Reviewed-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Tested-by: Charlie Jenkins <thecharlesjenkins@gmail.com> [pjw@kernel.org: use official RISC-V extension names in the patch description] Link: https://patch.msgid.link/20260807-counter_delegation-v9-3-58658104e487@meta.com Signed-off-by: Paul Walmsley <pjw@kernel.org> |
||
|
Nam Cao
|
7e14e42edf |
Revert "riscv: hwprobe: Fix stale vDSO data for late-initialized keys at boot"
This reverts commit
|
||
|
Nam Cao
|
34c9cfcde2 |
riscv: unaligned: stop using kthread for check_vector_unaligned_access()
A kthread is used to run check_vector_unaligned_access() to optimize boot time, allowing the kernel to continue booting without waiting for the unaligned vector speed probe to finish. However, this asynchronous approach introduces several complications. First, the kthread may not complete before a user reads vDSO data, resulting in incorrect values. This was previously addressed by commit |
||
|
Thorsten Blum
|
9e29ec46f7 |
riscv: Mark default_power_off() as __noreturn
Since default_power_off() never returns, annotate it with the __noreturn attribute to improve compiler optimizations. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Link: https://patch.msgid.link/20260727100339.410466-2-thorsten.blum@linux.dev Signed-off-by: Paul Walmsley <pjw@kernel.org> |
||
|
Zong Li
|
2ee1cc0bbd |
riscv: cfi: reduce shadow stack size limit from 2GB to 512MB
Change the shadow stack size calculation from RLIMIT_STACK/2 (capped at 2GB) to RLIMIT_STACK/8 (capped at 512MB), following David Laight's analysis and recommendation. Rationale: David Laight pointed out that the focus should be on the ratio between shadow stack size and the normal stack size, rather than just the absolute upper limit. His analysis showed that while there are many functions with small stack frames, the majority have stack deltas of over 64 bytes due to saved registers and local variables. Shadow stacks only store return addresses (8 bytes per entry on 64-bit systems), whereas normal stack frames typically consume 64+ bytes. This 8:64 byte ratio means that programs using a lot of stack space are dominated by large buffer allocations and local variables, not extreme recursion depths with minimal local data. For example, with the default RLIMIT_STACK of 8MB: - RLIMIT_STACK/2 gives a 4MB shadow stack supporting 512K nested calls - RLIMIT_STACK/8 gives a 1MB shadow stack supporting 128K nested calls Given typical stack frame sizes of 64+ bytes, RLIMIT_STACK/8 is still conservative and provides adequate depth for practical applications. David noted that this could even be safely halved again. This reduction also better accommodates memory-constrained platforms. On systems with limited physical memory, allocating large shadow stacks can cause virtual memory allocation failures when overcommit mode is set to OVERCOMMIT_GUESS or OVERCOMMIT_NEVER. Suggested-by: David Laight <david.laight.linux@gmail.com> Link: https://lore.kernel.org/all/20260518105725.7afe7a4c@pumpkin/ Signed-off-by: Zong Li <zong.li@sifive.com> Link: https://patch.msgid.link/20260522093634.3530233-1-zong.li@sifive.com Signed-off-by: Paul Walmsley <pjw@kernel.org> |
||
|
Thomas Weißschuh
|
9cfff2edcc |
riscv: vdso: Simplify cflags remove logic
Listing all flags for each object file is tedious and error-prone. Replace it with a simpler solution. Link: https://lore.kernel.org/all/20260630135316-f26f0e0f-c08c-4d4d-9963-10f9985a7689@linutronix.de/ Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Link: https://patch.msgid.link/20260701-riscv-vdso-lto-v1-2-89db0cd82077@linutronix.de Signed-off-by: Paul Walmsley <pjw@kernel.org> |
||
|
Nam Cao
|
0d4a777c4c |
riscv: kprobes: add test case for c.jal instruction simulation
Add a test case validating that kprobes correctly simulates the c.jal instruction on RV32. The test uses two probe points: a forward c.jal and a backward c.jal, and verifies that the containing function returns the expected magic value KPROBE_TEST_MAGIC after kprobe interception. Co-developed-by: Xiaofeng Yuan <xiaofengmian@163.com> Signed-off-by: Nam Cao <namcao@linutronix.de> Signed-off-by: Xiaofeng Yuan <xiaofengmian@163.com> Reviewed-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Tested-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Link: https://patch.msgid.link/20260701081033.49871-3-xiaofengmian@163.com Signed-off-by: Paul Walmsley <pjw@kernel.org> |
||
|
Xiaofeng Yuan
|
540ad5ad05 |
riscv: probes: simulate c.jal instruction
The c.jal instruction is currently marked REJECTED in kprobes instruction decoding, but it should be SIMULATED like other compressed jump instructions. Add simulate_c_jal() which saves the return address to RA and sets the program counter to the target offset, reusing simulate_c_j for the common jump logic. Although c.jal is RV32-only, the function compiles unconditionally. On RV64, riscv_insn_is_c_jal() always returns 0, so the simulation code is never invoked and the small overhead in kernel size is acceptable. Signed-off-by: Xiaofeng Yuan <xiaofengmian@163.com> Reviewed-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Tested-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Reviewed-by: Nam Cao <namcao@linutronix.de> Tested-by: Nam Cao <namcao@linutronix.de> Link: https://patch.msgid.link/20260701081033.49871-2-xiaofengmian@163.com Signed-off-by: Paul Walmsley <pjw@kernel.org> |
||
|
Vivian Wang
|
6a48dea344 |
riscv: acpi: Enable ARCH_HAS_ACPI_TABLE_UPGRADE
Implement the various required hooks and enable ARCH_HAS_ACPI_TABLE_UPGRADE to allow use for ACPI_TABLE_UPGRADE, which is useful for debugging ACPI table problems. The implementation is based on arm64's of the same feature due to the similarities of the requirements of the two platforms. Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Link: https://patch.msgid.link/20260616-riscv-acpi-table-upgrade-v1-2-45902d2dedf9@iscas.ac.cn [pjw@kernel.org: updated to apply] Signed-off-by: Paul Walmsley <pjw@kernel.org> |
||
|
Atish Patra
|
c888e324b2 |
riscv: Restart via EFI runtime services when available
Firmware-preferred reset and EFI capsule update support requires reset via EFI runtime services rather than direction M-mode firmware invocation via SBI. Unlike poweroff, restart mechanism is directly controlled from machine_restart function though. Prefer the EFI runtime ResetSystem() service for restart when UEFI runtime services are available. Signed-off-by: Atish Patra <atishp@meta.com> Reviewed-by: Sunil V L <sunilvl@oss.qualcomm.com> Link: https://patch.msgid.link/20260615-efi_reset_shutdown-v1-2-9414edcbbab0@meta.com Signed-off-by: Paul Walmsley <pjw@kernel.org> |
||
|
Atish Patra
|
d8d0fb556e |
riscv: efi: Power off via EFI runtime services when available
When booted via UEFI with runtime services enabled, EFI Reset Shutdown is the firmware-preferred shutdown path: it lets firmware run its own shutdown hooks which may invoke SBI SRST extension internally. However, RISC-V always powers off via the SBI SRST extension today and EFI runtime path is never used even when firmware provides it. Enable the poweroff via EFI by overriding efi_poweroff_required() Signed-off-by: Atish Patra <atishp@meta.com> Reviewed-by: Sunil V L <sunilvl@oss.qualcomm.com> Link: https://patch.msgid.link/20260615-efi_reset_shutdown-v1-1-9414edcbbab0@meta.com Signed-off-by: Paul Walmsley <pjw@kernel.org> |
||
|
Rui Qi
|
994dad686e |
riscv: hwprobe: Register unaligned probes before usermode
The hwprobe vDSO data is populated by the first riscv_hwprobe syscall.
Some values, such as MISALIGNED_VECTOR_PERF, may depend on the async
vector unaligned access speed probe registered by
check_unaligned_access_all_cpus().
That initcall currently runs at late_initcall level. However,
rootfs_initcall enables usermode helpers before late initcalls run, so an
early helper can execute userspace and call riscv_hwprobe first.
In that case complete_hwprobe_vdso_data() consumes the initial
pending_boot_probes reference, populates the vDSO cache, and marks it
ready before the later async probe is registered. The eventual probe
result then cannot update the already-ready cache.
Move check_unaligned_access_all_cpus() to fs_initcall_sync. This still
runs after clocksource_done_booting(), so the ktime_get_mono_fast_ns()
benchmark uses a stable clocksource, but it runs before rootfs_initcall
enables usermode helpers.
Any async hwprobe probe is therefore registered before userspace can
trigger the one-time vDSO cache population.
Cc: stable@vger.kernel.org
Fixes:
|
||
|
Pu Lehui
|
2820d227ad |
riscv: ftrace: Fix ftrace_modify_call failure on kprobed functions
We are frequently hitting the following splat during the riscv bpf
selftests:
00000000026dc75a: expected (7c3ff297) but got (00100073)
------------[ ftrace bug ]------------
ftrace failed to modify
[<ffffffff03c44c1c>] bpf_kfunc_common_test+0x4/0x20 [bpf_testmod]
actual: e7:82:c2:ce
Updating ftrace call site to call a different ftrace function
ftrace record flags: 80100002
(2)
expected tramp: ffffffff80043904
------------[ cut here ]------------
WARNING: kernel/trace/ftrace.c:2278 at ftrace_bug+0x46e/0x4b0, CPU#1: test_progs/98
...
[<ffffffff80008f4e>] ftrace_bug+0x46e/0x4b0
[<ffffffff803d3e86>] ftrace_replace_code+0x16e/0x170
[<ffffffff803d42b6>] ftrace_modify_all_code+0x12e/0x1b8
[<ffffffff800430f4>] arch_ftrace_update_code+0x14/0x28
[<ffffffff803e0324>] ftrace_startup+0x14c/0x2a0
[<ffffffff803e133c>] ftrace_startup_subops+0x584/0x1050
[<ffffffff804500e6>] register_ftrace_graph+0x4e6/0x1018
[<ffffffff804cf9f6>] register_fprobe_ips+0xc66/0x12f8
[<ffffffff8049abe8>] bpf_kprobe_multi_link_attach+0x5d8/0xe68
[<ffffffff8050fcaa>] __sys_bpf+0x3d5a/0x47f0
[<ffffffff805107ee>] __riscv_sys_bpf+0xae/0x168
[<ffffffff80034d78>] syscall_handler+0x60/0x100
[<ffffffff8228b4f4>] do_trap_ecall_u+0x174/0x208
[<ffffffff822b69c4>] handle_exception+0x16c/0x178
After debugging, it can be triggered by similar commands below:
```
echo do_nanosleep > set_ftrace_filter
echo function > current_tracer
echo 'p do_nanosleep' > kprobe_events
echo 1 > events/kprobes/enable
echo 'f do_nanosleep' > dynamic_events
echo 1 > events/fprobes/enable
```
The reason is that attaching a kprobe to an ftrace-traced function entry
replaces its initial auipc insn with ebreak. When ftrace_modify_call
later runs, it expects auipc insn, so verification fails and triggers
ftrace_bug.
The expected auipc logic remains conceptually unchanged, and kprobe
single-stepping ensures normal execution. Therefore, if the first insn
is ebreak, bypassing the check to continue patching the jalr insn is
safe and avoids ftrace failures.
Fixes:
|
||
|
Anirudh Srinivasan
|
f51fed61ee |
riscv: drop __init from vec_check_unaligned_access_speed_all_cpus
This function runs within a kthread and need not necessarily finish
before system finishes boot and free_initmem() unmaps the .init.text
section. This function makes calls to SBI for probing unaligned access
speed, and if this is slow for some reason (say some debug prints were
added to SBI), the kthread can still be running at this point and result
in an instruction page fault when trying to fetch from the freed region.
[ 25.642087] Unable to handle kernel paging request at virtual address ffffffff80a04ef8
[ 25.646694] Current vec_check_unali pgtable: 4K pagesize, 48-bit VAs, pgdp=0x00004000316e9000
[ 25.653170] [ffffffff80a04ef8] pgd=000010004be7e401, p4d=000010004be7e401, pud=000010004be7e001, pmd=000010000c3000e3
[ 25.661244] Oops [#1]
[ 25.662997] Modules linked in:
[ 25.665357] CPU: 3 UID: 0 PID: 42 Comm: vec_check_unali Not tainted 7.0.0-tt-blackhole-asrinivasan-00007-g30ff73f18211 #570 PREEMPTLAZY
[ 25.674669] Hardware name: Tenstorrent Blackhole (DT)
[ 25.678545] epc : vec_check_unaligned_access_speed_all_cpus+0x18/0x2c
[ 25.683458] ra : vec_check_unaligned_access_speed_all_cpus+0x18/0x2c
[ 25.688372] epc : ffffffff80a04ef8 ra : ffffffff80a04ef8 sp : ffff8f8000203e20
[ 25.693874] gp : ffffffff814dc168 tp : ffffaf8001ad9900 t0 : 0000000000000000
[ 25.699401] t1 : fffffffffffffff0 t2 : ffffaf8001ad9a10 s0 : ffff8f8000203e30
[ 25.704912] s1 : ffffaf80018dc780 a0 : 0000000000000000 a1 : 0000000000000002
[ 25.710407] a2 : 00000000000001f0 a3 : 0000000000000018 a4 : 0000000000000000
[ 25.715917] a5 : 0000000000000000 a6 : ffffaf8001c03d98 a7 : ffffaf8001c03e30
[ 25.721419] s2 : ffff8f8000023c98 s3 : ffffaf8001aa1240 s4 : ffffffff80a04ee0
[ 25.726937] s5 : 0000000000000000 s6 : 0000000000000000 s7 : 0000000000000000
[ 25.732450] s8 : 0000000000000000 s9 : 0000000000000000 s10: 0000000000000000
[ 25.737944] s11: 0000000000000000 t3 : 0000000000000002 t4 : 0000000000000402
[ 25.743481] t5 : 0000000000000040 t6 : 0000000000000004 ssp : 0000000000000000
[ 25.749024] status: 0000000200000120 badaddr: ffffffff80a04ef8 cause: 000000000000000c
[ 25.755060] [<ffffffff80a04ef8>] vec_check_unaligned_access_speed_all_cpus+0x18/0x2c
[ 25.760964] [<ffffffff80047a10>] kthread+0xd8/0xfc
[ 25.764660] [<ffffffff80010c48>] ret_from_fork_kernel+0x18/0x1c4
[ 25.769220] [<ffffffff80895fe6>] ret_from_fork_kernel_asm+0x16/0x18
[ 25.774018] Code: cccc cccc cccc cccc cccc cccc cccc cccc cccc cccc (cccc) cccc
Drop __init from its signature so that this doesn't happen.
Fixes:
|
||
|
Thomas Gleixner
|
05c033db7e |
entry, treewide: Make syscall_enter_from_user_mode[_work]() indicate syscall execution
The return values of syscall_enter_from_user_mode[_work]() are
non-intuitive. Both functions return the syscall number which should be
invoked by the architecture specific syscall entry code. The returned
number can be:
- the unmodified syscall number which was handed in by the caller
- a modified syscall number (ptrace, seccomp, trace/probe/bpf)
That has an additional twist. If the return value is -1L then the caller is
not allowed to modify the return value as that indicates that the modifying
entity requests to abort the syscall and set the return value already. That
can obviously not be differentiated from a syscall which handed in -1 as
syscall number.
The most trivial way to deal with that is:
set_return_value(regs, -ENOSYS);
nr = syscall_enter_from_user_mode(regs, nr);
if (valid(nr))
handle_syscall(regs, nr);
That's what LOONGARCH, RISCV, and X86 do. But PowerPC and S390 do not
preset the return value, so when user space hands in -1 and there is
nothing setting the return value in the entry work code, then the syscall
is skipped but the return value is whatever random data has been in the
return value register.
Change the return values of syscall_enter_from_user_mode[_work]() to
boolean and return false, when either ptrace or seccomp request to skip the
syscall. If they return true, update the syscall number as it might have
been changed.
That results in slightly different behaviour of the architectures versus
tracing.
If the syscall tracepoint has probe/BPF attached, those might set the
syscall number to -1 and also set the return value. PowerPC and S390 will
then overwrite that value with -ENOSYS. The other architectures will just
ignore it like any other invalid syscall and use the modified one.
Originally-by: Michal Suchánek <msuchanek@suse.de>
Signed-off-by: Thomas Gleixner <tglx@kernel.org>
Tested-by: Michal Suchánek <msuchanek@suse.de>
Link: https://patch.msgid.link/20260712141346.772209074@kernel.org
|
||
|
Mark Harris
|
5caae1deee |
riscv: hwprobe: Avoid uninitialized read in hwprobe_get_cpus()
When cpusetsize < cpumask_size(), hwprobe_get_cpus() did not fully
initialize its copy of the cpu mask, which could cause non-deterministic
results from the riscv_hwprobe syscall on a system with more than 8 CPUs
when the supplied cpu mask is empty. Address this by fully initializing
the cpu mask.
Fixes:
|
||
|
Aurelien Jarno
|
e4bf6eb4c7 |
arch/riscv: vdso: remove CFI landing pad from rt_sigreturn
When CONFIG_RISCV_USER_CFI is enabled, the CFI version of the vDSO, has a CFI landing pad instruction at the start of __vdso_rt_sigreturn. This breaks libgcc's unwinding code which matches on the first two instructions. Other unwinders that rely on similar instruction matching may also be affected. Since __vdso_rt_sigreturn is reached as part of signal-return handling rather than via an indirect call/jump from userspace, it does not need a CFI landing pad. Remove it and restore the instruction sequence expected by existing unwinding code. This matches what was done on arm64 in commit |