sync: rvck #285: riscv: backport follow-up fixes for user CFI support- #285 by ieiao · Pull Request #249 · RVCK-Project/rvck-olk

ieiao · 2026-08-06T09:19:01Z

Sync commits from rvck PR 285.
Source PR: RVCK-Project/rvck#285

mainline inclusion from mainline-6.6 commit adacfc6 ("kbuild: unify vdso_install rules") category: feature bugzilla: RVCK-Project/rvck#255 -------------------------------- [ Upstream commit 56769ba4b297a629148eb24d554aef72d1ddfd9e ] Currently, there is no standard implementation for vdso_install, leading to various issues: 1. Code duplication Many architectures duplicate similar code just for copying files to the install destination. Some architectures (arm, sparc, x86) create build-id symlinks, introducing more code duplication. 2. Unintended updates of in-tree build artifacts The vdso_install rule depends on the vdso files to install. It may update in-tree build artifacts. This can be problematic, as explained in commit 19514fc ("arm, kbuild: make "make install" not depend on vmlinux"). 3. Broken code in some architectures Makefile code is often copied from one architecture to another without proper adaptation. 'make vdso_install' for parisc does not work. 'make vdso_install' for s390 installs vdso64, but not vdso32. To address these problems, this commit introduces a generic vdso_install rule. Architectures that support vdso_install need to define vdso-install-y in arch/*/Makefile. vdso-install-y lists the files to install. For example, arch/x86/Makefile looks like this: vdso-install-$(CONFIG_X86_64) += arch/x86/entry/vdso/vdso64.so.dbg vdso-install-$(CONFIG_X86_X32_ABI) += arch/x86/entry/vdso/vdsox32.so.dbg vdso-install-$(CONFIG_X86_32) += arch/x86/entry/vdso/vdso32.so.dbg vdso-install-$(CONFIG_IA32_EMULATION) += arch/x86/entry/vdso/vdso32.so.dbg These files will be installed to $(MODLIB)/vdso/ with the .dbg suffix, if exists, stripped away. vdso-install-y can optionally take the second field after the colon separator. This is needed because some architectures install a vdso file as a different base name. The following is a snippet from arch/arm64/Makefile. vdso-install-$(CONFIG_COMPAT_VDSO) += arch/arm64/kernel/vdso32/vdso.so.dbg:vdso32.so This will rename vdso.so.dbg to vdso32.so during installation. If such architectures change their implementation so that the base names match, this workaround will go away. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Acked-by: Sven Schnelle <svens@linux.ibm.com> # s390 Reviewed-by: Nicolas Schier <nicolas@fjasle.eu> Reviewed-by: Guo Ren <guoren@kernel.org> Acked-by: Helge Deller <deller@gmx.de> # parisc Acked-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Stable-dep-of: fc2f5f10f9bc ("s390/vdso: Create .build-id links for unstripped vdso files") Signed-off-by: Sasha Levin <sashal@kernel.org> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

community inclusion category: feature bugzilla: RVCK-Project/rvck#255 -------------------------------- Signed-off-by: Han Gao <gaohan@iscas.ac.cn> Signed-off-by: Yanteng Si <si.yanteng@linux.dev> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

community inclusion category: feature bugzilla: RVCK-Project/rvck#255 Signed-off-by: Han Gao <gaohan@iscas.ac.cn> Signed-off-by: Yanteng Si <si.yanteng@linux.dev> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

mainline inclusion from mainline-6.19 commit 818d78ba1b3f ("riscv: signal: abstract header saving for setup_sigcontext") category: feature bugzilla: RVCK-Project/rvck#255 -------------------------------- The function save_v_state() served two purposes. First, it saved extension context into the signal stack. Then, it constructed the extension header if there was no fault. The second part is independent of the extension itself. As a result, we can pull that part out, so future extensions may reuse it. This patch adds arch_ext_list and makes setup_sigcontext() go through all possible extensions' save() callback. The callback returns a positive value indicating the size of the successfully saved extension. Then the kernel proceeds to construct the header for that extension. The kernel skips an extension if it does not exist, or if the saving fails for some reasons. The error code is propagated out on the later case. This patch does not introduce any functional changes. Signed-off-by: Andy Chiu <andybnac@gmail.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-16-b55691eacf4f@rivosinc.com Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

mainline inclusion from mainline-7.0 commit 81723e3ac388 ("random: vDSO: add missing c-getrandom-y in Makefile") category: feature Link: RVCK-Project/rvck#255 -------------------------------- Same as for the gettimeofday CVDSO implementation, add c-getrandom-y to ease the inclusion of lib/vdso/getrandom.c in architectures' VDSO builds. Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

mainline inclusion from mainline-7.0 commit ee0d03053e70 ("RISC-V: vDSO: Wire up getrandom() vDSO implementation") category: feature Link: RVCK-Project/rvck#255 -------------------------------- Hook up the generic vDSO implementation to the generic vDSO getrandom implementation by providing the required __arch_chacha20_blocks_nostack and getrandom_syscall implementations. Also wire up the selftests. The benchmark result: vdso: 25000000 times in 2.466341333 seconds libc: 25000000 times in 41.447720005 seconds syscall: 25000000 times in 41.043926672 seconds vdso: 25000000 x 256 times in 162.286219353 seconds libc: 25000000 x 256 times in 2953.855018685 seconds syscall: 25000000 x 256 times in 2796.268546000 seconds [ alex: - Fix dynamic relocation - Squash Nathan's fix https://lore.kernel.org/all/20250423-riscv-fix-compat_vdso-lld-v2-1-b7bbbc244501@kernel.org/ - Add comment from Loongarch ] Signed-off-by: Xi Ruoyao <xry111@xry111.site> Link: https://lore.kernel.org/r/20250411024600.16045-1-xry111@xry111.site Tested-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

mainline inclusion from mainline-7.0 commit f955aa8723a6 ("riscv: entry: Convert ret_from_fork() to C") category: feature Link: RVCK-Project/rvck#255 -------------------------------- Move the main section of ret_from_fork() to C to allow inlining of syscall_exit_to_user_mode(). Signed-off-by: Charlie Jenkins <charlie@rivosinc.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/all/20250320-riscv_optimize_entry-v6-1-63e187e26041@rivosinc.com Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

mainline inclusion from mainline-7.0 commit 5b3d6103b343 ("riscv: entry: Split ret_from_fork() into user and kernel") category: feature Link: RVCK-Project/rvck#255 -------------------------------- This function was unified into a single function in commit ab9164d ("riscv: entry: Consolidate ret_from_kernel_thread into ret_from_fork"). However that imposed a performance degradation. Partially reverting this commit to have ret_from_fork() split again, results in a 1% increase on the number of times fork is able to be called per second. Signed-off-by: Charlie Jenkins <charlie@rivosinc.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/all/20250320-riscv_optimize_entry-v6-2-63e187e26041@rivosinc.com Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

mainline inclusion from mainline-7.0 commit ad14f7ca9f0d ("riscv: hwprobe: do not produce frtace relocation") category: feature Link: RVCK-Project/rvck#255 -------------------------------- Such relocation causes crash of android linker similar to one described in commit e05d57d ("riscv: Fixup __vdso_gettimeofday broke dynamic ftrace"). Looks like this relocation is added by CONFIG_DYNAMIC_FTRACE which is disabled in the default android kernel. Before: readelf -rW arch/riscv/kernel/vdso/vdso.so: Relocation section '.rela.dyn' at offset 0xd00 contains 1 entry: Offset Info Type 0000000000000d20 0000000000000003 R_RISCV_RELATIVE objdump: 0000000000000c86 <__vdso_riscv_hwprobe@@LINUX_4.15>: c86: 0001 nop c88: 0001 nop c8a: 0001 nop c8c: 0001 nop c8e: e211 bnez a2,c92 <__vdso_riscv_hwprobe... After: readelf -rW arch/riscv/kernel/vdso/vdso.so: There are no relocations in this file. objdump: 0000000000000c86 <__vdso_riscv_hwprobe@@LINUX_4.15>: c86: e211 bnez a2,c8a <__vdso_riscv_hwprobe... c88: c6b9 beqz a3,cd6 <__vdso_riscv_hwprobe... c8a: e739 bnez a4,cd8 <__vdso_riscv_hwprobe... c8c: ffffd797 auipc a5,0xffffd Also disable SCS since it also should not be available in vdso. Fixes: aa5af0a ("RISC-V: Add hwprobe vDSO function and data") Signed-off-by: Roman Artemev <roman.artemev@syntacore.com> Signed-off-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Guo Ren <guoren@kernel.org> Link: https://lore.kernel.org/r/20240313085843.17661-1-vladimir.isaev@syntacore.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

mainline inclusion from mainline-7.0 commit 9a0ebe5011f4 ("kbuild: use $(obj)/ instead of $(src)/ for common pattern rules") category: feature Link: RVCK-Project/rvck#255 -------------------------------- Kbuild conventionally uses $(obj)/ for generated files, and $(src)/ for checked-in source files. It is merely a convention without any functional difference. In fact, $(obj) and $(src) are exactly the same, as defined in scripts/Makefile.build: src := $(obj) Before changing the semantics of $(src) in the next commit, this commit replaces $(obj)/ with $(src)/ in pattern rules where the prerequisite might be a generated file. C, assembly, Rust, and DTS files are sometimes generated by tools, so they could be either generated files or real sources. The $(obj)/ prefix works for both cases with the help of VPATH. As mentioned above, $(obj) and $(src) are the same at this point, hence this commit has no functional change. I did not modify scripts/Makefile.userprogs because there is no use case where userspace C files are generated. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

mainline inclusion from mainline-7.0 commit 98036587a475 ("mm: add VM_SHADOW_STACK definition for riscv") category: feature Link: RVCK-Project/rvck#255 -------------------------------- VM_HIGH_ARCH_5 is used for riscv. Reviewed-by: Zong Li <zong.li@sifive.com> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Acked-by: David Hildenbrand <david@redhat.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-1-b55691eacf4f@rivosinc.com [pjw@kernel.org: clarify subject; update to apply] Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

mainline inclusion from mainline-7.0 commit f94645fc03b8 ("dt-bindings: riscv: document zicfilp and zicfiss in extensions.yaml") category: feature Link: RVCK-Project/rvck#255 -------------------------------- Make an entry for cfi extensions in extensions.yaml. Signed-off-by: Deepak Gupta <debug@rivosinc.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-2-b55691eacf4f@rivosinc.com [pjw@kernel.org: updated subject] Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

mainline inclusion from mainline-7.0 commit df11708566d7 ("riscv: zicfiss / zicfilp enumeration") category: feature Link: RVCK-Project/rvck#255 -------------------------------- This patch adds support for detecting the RISC-V ISA extensions Zicfiss and Zicfilp. Zicfiss and Zicfilp stand for the unprivileged integer spec extensions for shadow stack and indirect branch tracking, respectively. This patch looks for Zicfiss and Zicfilp in the device tree and accordingly lights up the corresponding bits in the cpu feature bitmap. Furthermore this patch adds detection utility functions to return whether shadow stack or landing pads are supported by the cpu. Reviewed-by: Zong Li <zong.li@sifive.com> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-3-b55691eacf4f@rivosinc.com [pjw@kernel.org: updated to apply; cleaned up patch description] Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

mainline inclusion from mainline-7.0 commit 41a2452c99f3 ("riscv: add Zicfiss / Zicfilp extension CSR and bit definitions") category: feature Link: RVCK-Project/rvck#255 -------------------------------- The Zicfiss and Zicfilp extensions are enabled via b3 and b2 in *envcfg CSRs. menvcfg controls enabling for S/HS mode. henvcfg controls enabling for VS. senvcfg controls enabling for U/VU mode. The Zicfilp extension extends *status CSRs to hold an 'expected landing pad' bit. A trap or interrupt can occur between an indirect jmp/call and target instruction. The 'expected landing pad' bit from the CPU is recorded into the xstatus CSR so that when the supervisor performs xret, the 'expected landing pad' state of the CPU can be restored. Zicfiss adds one new CSR, CSR_SSP, which contains the current shadow stack pointer. Signed-off-by: Deepak Gupta <debug@rivosinc.com> Reviewed-by: Charlie Jenkins <charlie@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-4-b55691eacf4f@rivosinc.com [pjw@kernel.org: grouped CSR_SSP macro with the other CSR macros; clarified patch description] Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

… entry/exit mainline inclusion from mainline-7.0 commit 79dd4f2f40d0 ("riscv: Add usercfi state for task and save/restore of CSR_SSP on trap entry/exit") category: feature Link: RVCK-Project/rvck#255 -------------------------------- Carve out space in the RISC-V architecture-specific thread struct for cfi status and shadow stack in usermode. This patch: - defines a new structure cfi_status with status bit for cfi feature - defines shadow stack pointer, base and size in cfi_status structure - defines offsets to new member fields in thread in asm-offsets.c - saves and restores shadow stack pointer on trap entry (U --> S) and exit (S --> U) Shadow stack save/restore is gated on feature availability and is implemented using alternatives. CSR_SSP can be context-switched in 'switch_to' as well, but as soon as kernel shadow stack support gets rolled in, the shadow stack pointer will need to be switched at trap entry/exit point (much like 'sp'). It can be argued that a kernel using a shadow stack deployment scenario may not be as prevalent as user mode using this feature. But even if there is some minimal deployment of kernel shadow stack, that means that it needs to be supported. Thus save/restore of shadow stack pointer is implemented in entry.S instead of in 'switch_to.h'. Reviewed-by: Charlie Jenkins <charlie@rivosinc.com> Reviewed-by: Zong Li <zong.li@sifive.com> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-5-b55691eacf4f@rivosinc.com [pjw@kernel.org: cleaned up patch description] Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

mainline inclusion from mainline-7.0 commit 6c7559f22b6f ("riscv/mm: ensure PROT_WRITE leads to VM_READ | VM_WRITE") category: feature Link: RVCK-Project/rvck#255 -------------------------------- 'arch_calc_vm_prot_bits' is implemented on risc-v to return VM_READ | VM_WRITE if PROT_WRITE is specified. Similarly 'riscv_sys_mmap' is updated to convert all incoming PROT_WRITE to (PROT_WRITE | PROT_READ). This is to make sure that any existing apps using PROT_WRITE still work. Earlier 'protection_map[VM_WRITE]' used to pick read-write PTE encodings. Now 'protection_map[VM_WRITE]' will always pick PAGE_SHADOWSTACK PTE encodings for shadow stack. The above changes ensure that existing apps continue to work because underneath, the kernel will be picking 'protection_map[VM_WRITE|VM_READ]' PTE encodings. Reviewed-by: Zong Li <zong.li@sifive.com> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-6-b55691eacf4f@rivosinc.com Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

mainline inclusion from mainline-7.0 commit f56ffb8ada46 ("riscv/mm: manufacture shadow stack ptes") category: feature Link: RVCK-Project/rvck#255 -------------------------------- This patch implements the creation of a shadow stack pte on riscv. Creating shadow stack PTE on riscv means clearing RWX and then setting W=1. Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Zong Li <zong.li@sifive.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-7-b55691eacf4f@rivosinc.com [pjw@kernel.org: cleaned up patch description] Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

mainline inclusion from mainline-7.0 commit c68c2ef9d641 ("riscv/mm: teach pte_mkwrite to manufacture shadow stack PTEs") category: feature Link: RVCK-Project/rvck#255 -------------------------------- pte_mkwrite() creates PTEs with WRITE encodings for the underlying architecture. The underlying architecture can have two types of writeable mappings: one that can be written using regular store instructions, and another one that can only be written using specialized store instructions (like shadow stack stores). pte_mkwrite can select write PTE encoding based on VMA range (i.e. VM_SHADOW_STACK) Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Zong Li <zong.li@sifive.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-8-b55691eacf4f@rivosinc.com [pjw@kernel.org: cleaned up patch description] Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

mainline inclusion from mainline-7.0 commit 540de7ade1e1 ("riscv/mm: update write protect to work on shadow stacks") category: feature Link: RVCK-Project/rvck#255 -------------------------------- 'fork' implements copy-on-write (COW) by making pages readonly in both child and parent. ptep_set_wrprotect() and pte_wrprotect() clear _PAGE_WRITE in PTE. The assumption is that the page is readable and, on a fault, copy-on-write happens. To implement COW on shadow stack pages, clearing the W bit makes them XWR = 000. This will result in the wrong PTE setting, which allows no permissions, but with V=1 and the PFN field pointing to the final page. Instead, the desired behavior is to turn it into a readable page, take an access (load/store) fault on sspush/sspop (shadow stack) and then perform COW on such pages. This way regular reads would still be allowed and not lead to COW maintaining current behavior of COW on non-shadow stack but writeable memory. On the other hand, this doesn't interfere with existing COW for read-write memory. The assumption is always that _PAGE_READ must have been set, and thus, setting _PAGE_READ is harmless. Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Zong Li <zong.li@sifive.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-9-b55691eacf4f@rivosinc.com [pjw@kernel.org: clarify patch description] Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

mainline inclusion from mainline-7.0 commit c70772afd5cc ("riscv/mm: Implement map_shadow_stack() syscall") category: feature Link: RVCK-Project/rvck#255 -------------------------------- As discussed extensively in the changelog for the addition of this syscall on x86 ("x86/shstk: Introduce map_shadow_stack syscall") the existing mmap() and madvise() syscalls do not map entirely well onto the security requirements for shadow stack memory since they lead to windows where memory is allocated but not yet protected or stacks which are not properly and safely initialised. Instead a new syscall map_shadow_stack() has been defined which allocates and initialises a shadow stack page. This patch implements this syscall for riscv. riscv doesn't require tokens to be setup by kernel because user mode can do that by itself. However to provide compatibility and portability with other architectues, user mode can specify token set flag. Signed-off-by: Deepak Gupta <debug@rivosinc.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-10-b55691eacf4f@rivosinc.com Link: https://lore.kernel.org/linux-riscv/aXfRPJvoSsOW8AwM@debug.ba.rivosinc.com/ [pjw@kernel.org: added allocate_shadow_stack() fix per Deepak; fixed bug found by sparse] Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

mainline inclusion from mainline-7.0 commit fd44a4a85516 ("riscv/shstk: If needed allocate a new shadow stack on clone") category: feature Link: RVCK-Project/rvck#255 -------------------------------- Userspace specifies CLONE_VM to share address space and spawn new thread. 'clone' allows userspace to specify a new stack for a new thread. However there is no way to specify a new shadow stack base address without changing the API. This patch allocates a new shadow stack whenever CLONE_VM is given. In case of CLONE_VFORK, the parent is suspended until the child finishes; thus the child can use the parent's shadow stack. In case of !CLONE_VM, COW kicks in because entire address space is copied from parent to child. 'clone3' is extensible and can provide mechanisms for specifying the shadow stack as an input parameter. This is not settled yet and is being extensively discussed on the mailing list. Once that's settled, this code should be adapted. Reviewed-by: Zong Li <zong.li@sifive.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-11-b55691eacf4f@rivosinc.com [pjw@kernel.org: cleaned up patch description] Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

mainline inclusion from mainline-7.0 commit 61a0200211d3 ("riscv: Implement arch-agnostic shadow stack prctls") category: feature Link: RVCK-Project/rvck#255 -------------------------------- Implement an architecture-agnostic prctl() interface for setting and getting shadow stack status. The prctls implemented are PR_GET_SHADOW_STACK_STATUS, PR_SET_SHADOW_STACK_STATUS and PR_LOCK_SHADOW_STACK_STATUS. As part of PR_SET_SHADOW_STACK_STATUS/PR_GET_SHADOW_STACK_STATUS, only PR_SHADOW_STACK_ENABLE is implemented because RISCV allows each mode to write to their own shadow stack using 'sspush' or 'ssamoswap'. PR_LOCK_SHADOW_STACK_STATUS locks the current shadow stack enablement configuration. Reviewed-by: Zong Li <zong.li@sifive.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-12-b55691eacf4f@rivosinc.com [pjw@kernel.org: cleaned up patch description] Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

mainline inclusion from mainline-6.13 commit 91e102e79740 ("prctl: arch-agnostic prctl for shadow stack") category: feature Link: RVCK-Project/rvck#255 -------------------------------- Three architectures (x86, aarch64, riscv) have announced support for shadow stacks with fairly similar functionality. While x86 is using arch_prctl() to control the functionality neither arm64 nor riscv uses that interface so this patch adds arch-agnostic prctl() support to get and set status of shadow stacks and lock the current configuation to prevent further changes, with support for turning on and off individual subfeatures so applications can limit their exposure to features that they do not need. The features are: - PR_SHADOW_STACK_ENABLE: Tracking and enforcement of shadow stacks, including allocation of a shadow stack if one is not already allocated. - PR_SHADOW_STACK_WRITE: Writes to specific addresses in the shadow stack. - PR_SHADOW_STACK_PUSH: Push additional values onto the shadow stack. These features are expected to be inherited by new threads and cleared on exec(), unknown features should be rejected for enable but accepted for locking (in order to allow for future proofing). This is based on a patch originally written by Deepak Gupta but modified fairly heavily, support for indirect landing pads is removed, additional modes added and the locking interface reworked. The set status prctl() is also reworked to just set flags, if setting/reading the shadow stack pointer is required this could be a separate prctl. Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Yury Khrustalev <yury.khrustalev@arm.com> Signed-off-by: Mark Brown <broonie@kernel.org> Reviewed-by: Deepak Gupta <debug@rivosinc.com> Link: https://lore.kernel.org/r/20241001-arm64-gcs-v13-4-222b78d87eee@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

mainline inclusion from mainline-6.13 commit 3630e82ab6bd ("mman: Add map_shadow_stack() flags") category: feature Link: RVCK-Project/rvck#255 -------------------------------- In preparation for adding arm64 GCS support make the map_shadow_stack() SHADOW_STACK_SET_TOKEN flag generic and add _SET_MARKER. The existing flag indicates that a token usable for stack switch should be added to the top of the newly mapped GCS region while the new flag indicates that a top of stack marker suitable for use by unwinders should be added above that. For arm64 the top of stack marker is all bits 0. Reviewed-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Acked-by: Yury Khrustalev <yury.khrustalev@arm.com> Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20241001-arm64-gcs-v13-5-222b78d87eee@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

mainline inclusion from mainline-7.0 commit 5ca243f6e3c3 ("prctl: add arch-agnostic prctl()s for indirect branch tracking") category: feature Link: RVCK-Project/rvck#255 -------------------------------- Three architectures (x86, aarch64, riscv) have support for indirect branch tracking feature in a very similar fashion. On a very high level, indirect branch tracking is a CPU feature where CPU tracks branches which use a memory operand to transfer control. As part of this tracking, during an indirect branch, the CPU expects a landing pad instruction on the target PC, and if not found, the CPU raises some fault (architecture-dependent). x86 landing pad instr - 'ENDBRANCH' arch64 landing pad instr - 'BTI' riscv landing instr - 'lpad' Given that three major architectures have support for indirect branch tracking, this patch creates architecture-agnostic 'prctls' to allow userspace to control this feature. They are: - PR_GET_INDIR_BR_LP_STATUS: Get the current configured status for indirect branch tracking. - PR_SET_INDIR_BR_LP_STATUS: Set the configuration for indirect branch tracking. The following status options are allowed: - PR_INDIR_BR_LP_ENABLE: Enables indirect branch tracking on user thread. - PR_INDIR_BR_LP_DISABLE: Disables indirect branch tracking on user thread. - PR_LOCK_INDIR_BR_LP_STATUS: Locks configured status for indirect branch tracking for user thread. Reviewed-by: Mark Brown <broonie@kernel.org> Reviewed-by: Zong Li <zong.li@sifive.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-13-b55691eacf4f@rivosinc.com [pjw@kernel.org: cleaned up patch description, code comments] Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

mainline inclusion from mainline-7.0 commit 8a9e22d2ca58 ("riscv: Implement indirect branch tracking prctls") category: feature Link: RVCK-Project/rvck#255 -------------------------------- This patch adds a RISC-V implementation of the following prctls: PR_SET_INDIR_BR_LP_STATUS, PR_GET_INDIR_BR_LP_STATUS and PR_LOCK_INDIR_BR_LP_STATUS. Reviewed-by: Zong Li <zong.li@sifive.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-14-b55691eacf4f@rivosinc.com [pjw@kernel.org: clean up patch description] Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

mainline inclusion from mainline-7.0 commit 9d42fc28fc17 ("riscv/traps: Introduce software check exception and uprobe handling") category: feature Link: RVCK-Project/rvck#255 -------------------------------- The Zicfiss and Zicfilp extensions introduce a new exception, the 'software check exception', in the privileged ISA, with cause code = 18. This patch implements support for software check exceptions. Additionally, the patch implements a CFI violation handler which checks the code in the xtval register. If xtval=2, the software check exception happened because of an indirect branch that didn't land on a 4 byte aligned PC or on a 'lpad' instruction, or the label value embedded in 'lpad' didn't match the label value set in the x7 register. If xtval=3, the software check exception happened due to a mismatch between the link register (x1 or x5) and the top of shadow stack (on execution of `sspopchk`). In case of a CFI violation, SIGSEGV is raised with code=SEGV_CPERR. SEGV_CPERR was introduced by the x86 shadow stack patches. To keep uprobes working, handle the uprobe event first before reporting the CFI violation in the software check exception handler. This is because, when the landing pad is activated, if the uprobe point is set at the lpad instruction at the beginning of a function, the system triggers a software check exception instead of an ebreak exception due to the exception priority. This would prevent uprobe from working. Reviewed-by: Zong Li <zong.li@sifive.com> Co-developed-by: Zong Li <zong.li@sifive.com> Signed-off-by: Zong Li <zong.li@sifive.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-15-b55691eacf4f@rivosinc.com [pjw@kernel.org: cleaned up the patch description] Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

mainline inclusion from mainline-7.0 commit 66c9c713de59 ("riscv/signal: save and restore the shadow stack on a signal") category: feature Link: RVCK-Project/rvck#255 -------------------------------- Save the shadow stack pointer in the sigcontext structure when delivering a signal. Restore the shadow stack pointer from sigcontext on sigreturn. As part of the save operation, the kernel uses the 'ssamoswap' instruction to save a snapshot of the current shadow stack on the shadow stack itself (this can be called a "save token"). During restore on sigreturn, the kernel retrieves the save token from the top of the shadow stack and validates it. This ensures that user mode can't arbitrarily pivot to any shadow stack address without having a token and thus provides a strong security assurance during the window between signal delivery and sigreturn. Use an ABI-compatible way of saving/restoring the shadow stack pointer into the signal stack. This follows the vector extension, where extra registers are placed in a form of extension header + extension body in the stack. The extension header indicates the size of the extra architectural states plus the size of header itself, and a magic identifier for the extension. Then, the extension body contains the new architectural states in the form defined by uapi. Signed-off-by: Andy Chiu <andy.chiu@sifive.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-17-b55691eacf4f@rivosinc.com [pjw@kernel.org: cleaned patch description, code comments; resolved checkpatch warning] Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

mainline inclusion from mainline-7.0 commit 9d0e75e25e3b ("riscv/kernel: update __show_regs() to print shadow stack register") category: feature Link: RVCK-Project/rvck#255 -------------------------------- Update __show_regs() to print the captured shadow stack pointer. On tasks where shadow stack is disabled, simply print 0. Signed-off-by: Deepak Gupta <debug@rivosinc.com> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-18-b55691eacf4f@rivosinc.com [pjw@kernel.org: cleaned up patch description] Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

…e files mainline inclusion from mainline-7.0 commit 2af7c9cf021c ("riscv/ptrace: expose riscv CFI status and state via ptrace and in core files") category: feature Link: RVCK-Project/rvck#255 -------------------------------- Expose a new register type NT_RISCV_USER_CFI for risc-v CFI status and state. Intentionally, both landing pad and shadow stack status and state are rolled into the CFI state. Creating two different NT_RISCV_USER_XXX would not be useful and would waste a note type. Enabling, disabling and locking the CFI feature is not allowed via ptrace set interface. However, setting 'elp' state or setting shadow stack pointer are allowed via the ptrace set interface. It is expected that 'gdb' might need to fixup 'elp' state or 'shadow stack' pointer. Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-19-b55691eacf4f@rivosinc.com [pjw@kernel.org: updated to apply; cleaned patch description and comments; addressed checkpatch issues] Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

mainline inclusion from mainline-7.0 commit 462a94fb8ae8 ("riscv: hwprobe: add support for RISCV_HWPROBE_KEY_IMA_EXT_1") category: feature Link: RVCK-Project/rvck#255 -------------------------------- We've run out of bits to describe RISC-V ISA extensions in our initial hwprobe key, RISCV_HWPROBE_KEY_IMA_EXT_0. So, let's add RISCV_HWPROBE_KEY_IMA_EXT_1, along with the framework to set the appropriate hwprobe tuple, and add testing for it. Based on a suggestion from Andrew Jones <andrew.jones@oss.qualcomm.com>, also fix the documentation for RISCV_HWPROBE_KEY_IMA_EXT_0. Reviewed-by: Andrew Jones <andrew.jones@oss.qualcomm.com> Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

mainline inclusion from mainline-7.0 commit 30c3099036a9 ("riscv/hwprobe: add zicfilp / zicfiss enumeration in hwprobe") category: feature Link: RVCK-Project/rvck#255 -------------------------------- Add enumeration of the zicfilp and zicfiss extensions in the hwprobe syscall. Reviewed-by: Zong Li <zong.li@sifive.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-20-b55691eacf4f@rivosinc.com [pjw@kernel.org: updated to apply; extend into RISCV_HWPROBE_KEY_IMA_EXT_1; clean patch description] Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

mainline inclusion from mainline-7.0 commit c9b859c4d8f5 ("riscv: add kernel command line option to opt out of user CFI") category: feature Link: RVCK-Project/rvck#255 -------------------------------- Add a kernel command line option to disable part or all of user CFI. User backward CFI and forward CFI can be controlled independently. The kernel command line parameter "riscv_nousercfi" can take the following values: - "all" : Disable forward and backward cfi both - "bcfi" : Disable backward cfi - "fcfi" : Disable forward cfi Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-21-b55691eacf4f@rivosinc.com [pjw@kernel.org: fixed warnings from checkpatch; cleaned up patch description, doc, printk text] Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

mainline inclusion from mainline-7.0 commit 41213bf2ae6c ("riscv: enable kernel access to shadow stack memory via the FWFT SBI call") category: feature Link: RVCK-Project/rvck#255 -------------------------------- The kernel has to perform shadow stack operations on the user shadow stack. During signal delivery and sigreturn, the shadow stack token must be created and validated respectively. Thus shadow stack access for the kernel must be enabled. In the future, when kernel shadow stacks are enabled, they must be enabled as early as possible for better coverage and to prevent any imbalance between the regular stack and the shadow stack. After 'relocate_enable_mmu' has completed, this is the earliest that it can be enabled. Reviewed-by: Zong Li <zong.li@sifive.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-22-b55691eacf4f@rivosinc.com [pjw@kernel.org: updated to apply; cleaned up commit message] Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

mainline inclusion from mainline-7.0 commit c6898d66fd19 ("riscv: Check that vdso does not contain any dynamic relocations") category: feature Link: RVCK-Project/rvck#255 -------------------------------- Like other architectures, use the common cmd_vdso_check to make sure of that. Reviewed-by: Björn Töpel <bjorn@rivosinc.com> Tested-by: Vladimir Isaev <vladimir.isaev@syntacore.com> Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Guo Ren <guoren@kernel.org> Link: https://lore.kernel.org/r/20241016083625.136311-3-alexghiti@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

mainline inclusion from mainline-7.0 commit 37f57bd3faea ("arch/riscv: compile vdso with landing pad and shadow stack note") category: feature Link: RVCK-Project/rvck#255 -------------------------------- User mode tasks compiled with Zicfilp may call indirectly into the vdso (like hwprobe indirect calls). Add support for compiling landing pads into the vdso. Landing pad instructions in the vdso will be no-ops for tasks which have not enabled landing pads. Furthermore, add support for the C sources of the vdso to be compiled with shadow stack and landing pads enabled as well. Landing pad and shadow stack instructions are emitted only when the VDSO_CFI cflags option is defined during compile. Signed-off-by: Jim Shu <jim.shu@sifive.com> Reviewed-by: Zong Li <zong.li@sifive.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-23-b55691eacf4f@rivosinc.com [pjw@kernel.org: cleaned up patch description, issues reported by checkpatch] Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

mainline inclusion from mainline-7.0 commit ccad8c1336b6 ("arch/riscv: add dual vdso creation logic and select vdso based on hw") category: feature Link: RVCK-Project/rvck#255 -------------------------------- Shadow stack instructions are taken from the Zimop ISA extension, which is mandated on RVA23. Any userspace with shadow stack instructions in it will fault on hardware that doesn't have support for Zimop. Thus, a shadow stack-enabled userspace can't be run on hardware that doesn't support Zimop. It's not known how Linux userspace providers will respond to this kind of binary fragmentation. In order to keep kernel portable across different hardware, 'arch/riscv/kernel/vdso_cfi' is created which has Makefile logic to compile 'arch/riscv/kernel/vdso' sources with CFI flags, and 'arch/riscv/kernel/vdso.c' is modified to select the appropriate vdso depending on whether the underlying CPU implements the Zimop extension. Since the offset of vdso symbols will change due to having two different vdso binaries, there is added logic to include a new generated vdso offset header and dynamically select the offset (like for rt_sigreturn). Signed-off-by: Deepak Gupta <debug@rivosinc.com> Acked-by: Charles Mirabile <cmirabil@redhat.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-24-b55691eacf4f@rivosinc.com [pjw@kernel.org: cleaned up patch description] Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

…port mainline inclusion from mainline-7.0 commit 22c1e263af2a ("riscv: create a Kconfig fragment for shadow stack and landing pad support") category: feature Link: RVCK-Project/rvck#255 -------------------------------- This patch creates a Kconfig fragment for shadow stack support and landing pad instruction support. Shadow stack support and landing pad instruction support can be enabled by selecting 'CONFIG_RISCV_USER_CFI'. Selecting 'CONFIG_RISCV_USER_CFI' wires up the path to enumerate CPU support. If support exists, the kernel will support CPU-assisted user mode CFI. If CONFIG_RISCV_USER_CFI is selected, select 'ARCH_USES_HIGH_VMA_FLAGS', 'ARCH_HAS_USER_SHADOW_STACK' and 'DYNAMIC_SIGFRAME' for riscv. Reviewed-by: Zong Li <zong.li@sifive.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-25-b55691eacf4f@rivosinc.com [pjw@kernel.org: cleaned up patch description, Kconfig text; added CONFIG_MMU exclusion] Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

mainline inclusion from mainline-7.0 commit f6eeb67b9172 ("riscv: add documentation for landing pad / indirect branch tracking") category: feature Link: RVCK-Project/rvck#255 -------------------------------- Add documentation on landing pad aka indirect branch tracking on riscv and the kernel interfaces exposed for user tasks to enable it. Reviewed-by: Zong Li <zong.li@sifive.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-26-b55691eacf4f@rivosinc.com [pjw@kernel.org: cleaned up the documentation] Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

mainline inclusion from mainline-7.0 commit c8350aa2ed78 ("riscv: add documentation for shadow stack") category: feature Link: RVCK-Project/rvck#255 -------------------------------- Add documentation on shadow stack for user mode on riscv and the kernel interfaces exposed for user tasks to enable it. Reviewed-by: Zong Li <zong.li@sifive.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-27-b55691eacf4f@rivosinc.com [pjw@kernel.org: cleaned up the documentation, patch description] Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

mainline inclusion from mainline-7.0 commit d30c1683aaec ("kselftest/riscv: add kselftest for user mode CFI") category: feature Link: RVCK-Project/rvck#255 -------------------------------- Add a kselftest for RISC-V control flow integrity implementation for user mode. There is not a lot going on in the kernel to enable landing pad for user mode. CFI selftests are intended to be compiled with a zicfilp and zicfiss enabled compiler. This kselftest simply checks if landing pads and shadow stacks for the process are enabled or not and executes ptrace selftests on CFI. The selftest then registers a SIGSEGV signal handler. Any control flow violations are reported as SIGSEGV with si_code = SEGV_CPERR. The test will fail on receiving any SEGV_CPERR. The shadow stack part has more changes in the kernel, and thus there are separate tests for that. - Exercise 'map_shadow_stack' syscall - 'fork' test to make sure COW works for shadow stack pages - gup tests Kernel uses FOLL_FORCE when access happens to memory via /proc/<pid>/mem. Not breaking that for shadow stack. - signal test. Make sure signal delivery results in token creation on shadow stack and consumes (and verifies) token on sigreturn - shadow stack protection test. attempts to write using regular store instruction on shadow stack memory must result in access faults - ptrace test: adds landing pad violation, clears ELP and continues In case the toolchain doesn't support the CFI extension, the CFI kselftest won't be built. Test output =========== """ TAP version 13 1..5 This is to ensure shadow stack is indeed enabled and working This is to ensure shadow stack is indeed enabled and working ok 1 shstk fork test ok 2 map shadow stack syscall ok 3 shadow stack gup tests ok 4 shadow stack signal tests ok 5 memory protections of shadow stack memory """ Suggested-by: Charlie Jenkins <charlie@rivosinc.com> Signed-off-by: Charlie Jenkins <charlie@rivosinc.com> Signed-off-by: Deepak Gupta <debug@rivosinc.com> Tested-by: Andreas Korb <andreas.korb@aisec.fraunhofer.de> # QEMU, custom CVA6 Tested-by: Valentin Haudiquet <valentin.haudiquet@canonical.com> Link: https://patch.msgid.link/20251112-v5_user_cfi_series-v23-28-b55691eacf4f@rivosinc.com [pjw@kernel.org: updated to apply; cleaned up patch description, code comments] Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

mainline inclusion from mainline-7.0 commit 87ad7cc9aa7f ("riscv: use _BITUL macro rather than BIT() in ptrace uapi and kselftests") category: feature Link: RVCK-Project/rvck#255 -------------------------------- Fix the build of non-kernel code that includes the RISC-V ptrace uapi header, and the RISC-V validate_v_ptrace.c kselftest, by using the _BITUL() macro rather than BIT(). BIT() is not available outside the kernel. Based on patches and comments from Charlie Jenkins, Michael Neuling, and Andreas Schwab. Fixes: 30eb191c895b ("selftests: riscv: verify ptrace rejects invalid vector csr inputs") Fixes: 2af7c9cf021c ("riscv/ptrace: expose riscv CFI status and state via ptrace and in core files") Cc: Andreas Schwab <schwab@suse.de> Cc: Michael Neuling <mikey@neuling.org> Cc: Charlie Jenkins <thecharlesjenkins@gmail.com> Link: https://patch.msgid.link/20260330024248.449292-1-mikey@neuling.org Link: https://lore.kernel.org/linux-riscv/20260309-fix_selftests-v2-1-9d5a553a531e@gmail.com/ Link: https://lore.kernel.org/linux-riscv/20260309-fix_selftests-v2-3-9d5a553a531e@gmail.com/ Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

mainline inclusion from mainline-7.0 commit a621d9cdc8d0 ("riscv: ptrace: cfi: fix "PRACE" typo in uapi header") category: feature Link: RVCK-Project/rvck#255 -------------------------------- A CFI-related macro defined in arch/riscv/uapi/asm/ptrace.h misspells "PTRACE" as "PRACE"; fix this. Fixes: 2af7c9cf021c ("riscv/ptrace: expose riscv CFI status and state via ptrace and in core files") Cc: Deepak Gupta <debug@rivosinc.com> Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

…i headers mainline inclusion from mainline-7.0 commit ac4e61c730d7 ("riscv: ptrace: expand "LP" references to "branch landing pads" in uapi headers") category: feature Link: RVCK-Project/rvck#255 -------------------------------- Per Linus' comments about the unreadability of abbreviations such as "LP", rename the RISC-V ptrace landing pad CFI macro names to be more explicit. This primarily involves expanding "LP" in the names to some variant of "branch landing pad." Link: https://lore.kernel.org/linux-riscv/CAHk-=whhSLGZAx3N5jJpb4GLFDqH_QvS07D+6BnkPWmCEzTAgw@mail.gmail.com/ Cc: Deepak Gupta <debug@rivosinc.com> Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

…explicit mainline inclusion from mainline-7.0 commit adfc80dd0d78 ("prctl: rename branch landing pad implementation functions to be more explicit") category: feature Link: RVCK-Project/rvck#255 -------------------------------- Per Linus' comments about the unreadability of abbreviations such as "indir_br_lp", rename the three prctl() implementation functions to be more explicit. This involves renaming "indir_br_lp_status" in the function names to "branch_landing_pad_state". While here, add _prctl_ into the function names, following the speculation control prctl implementation functions. Link: https://lore.kernel.org/linux-riscv/CAHk-=whhSLGZAx3N5jJpb4GLFDqH_QvS07D+6BnkPWmCEzTAgw@mail.gmail.com/ Cc: Deepak Gupta <debug@rivosinc.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mark Brown <broonie@kernel.org> Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

…headers mainline inclusion from mainline-7.0 commit e5342fe2c1bb ("riscv: ptrace: cfi: expand "SS" references to "shadow stack" in uapi headers") category: feature Link: RVCK-Project/rvck#255 -------------------------------- Similar to the recent change to expand "LP" to "branch landing pad", let's expand "SS" in the ptrace uapi macros to "shadow stack" as well. This aligns with the existing prctl() arguments, which use the expanded "shadow stack" names, rather than just the abbreviation. Link: https://lore.kernel.org/linux-riscv/CAHk-=whhSLGZAx3N5jJpb4GLFDqH_QvS07D+6BnkPWmCEzTAgw@mail.gmail.com/ Cc: Deepak Gupta <debug@rivosinc.com> Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

mainline inclusion from mainline-7.0 commit a6ede084c4b7 ("riscv: cfi: clear CFI lock status in start_thread()") category: feature Link: RVCK-Project/rvck#255 -------------------------------- When libc locks the CFI status through the following prctl: - PR_LOCK_SHADOW_STACK_STATUS - PR_LOCK_INDIR_BR_LP_STATUS A newly execd address space will inherit the lock status if it does not clear the lock bits. Since the lock bits remain set, libc will later fail to enable the landing pad and shadow stack. Signed-off-by: Zong Li <zong.li@sifive.com> Link: https://patch.msgid.link/20260323065640.4045713-1-zong.li@sifive.com [pjw@kernel.org: ensure we unlock before changing state; cleaned up subject line] Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

…tive mainline inclusion from mainline-7.0 commit 08ee1559052b ("prctl: cfi: change the branch landing pad prctl()s to be more descriptive") category: feature Link: RVCK-Project/rvck#255 -------------------------------- Per Linus' comments requesting the replacement of "INDIR_BR_LP" in the indirect branch tracking prctl()s with something more readable, and suggesting the use of the speculation control prctl()s as an exemplar, reimplement the prctl()s and related constants that control per-task forward-edge control flow integrity. This primarily involves two changes. First, the prctls are restructured to resemble the style of the speculative execution workaround control prctls PR_{GET,SET}_SPECULATION_CTRL, to make them easier to extend in the future. Second, the "indir_br_lp" abbrevation is expanded to "branch_landing_pads" to be less telegraphic. The kselftest and documentation is adjusted accordingly. Link: https://lore.kernel.org/linux-riscv/CAHk-=whhSLGZAx3N5jJpb4GLFDqH_QvS07D+6BnkPWmCEzTAgw@mail.gmail.com/ Cc: Deepak Gupta <debug@rivosinc.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mark Brown <broonie@kernel.org> Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

mainline inclusion from mainline-7.0 commit 7eb2e2954687 ("selftests: riscv: Add license to cfi selftest") category: feature Link: RVCK-Project/rvck#255 -------------------------------- The cfi selftest was missing a license so add it. Signed-off-by: Charlie Jenkins <thecharlesjenkins@gmail.com> Reviewed-by: Deepak Gupta <debug@rivosinc.com> Link: https://patch.msgid.link/20260309-fix_selftests-v2-4-9d5a553a531e@gmail.com Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Fangyu Yu <fangyu.yu@linux.alibaba.com> Signed-off-by: ZhenXing Zhu <zhenxing.zhu@linux.alibaba.com> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

github-actions · 2026-08-06T09:19:29Z

开始测试 log: https://github.com/RVCK-Project/rvck-olk/actions/runs/31088584668

参数解析结果

args	value
repository	RVCK-Project/rvck-olk
head ref	pull/249/head
base ref	OLK-6.6
LAVA repo	RVCK-Project/lavaci
LAVA hardware	['qemu']
LAVA Testcase path	lava-testcases/common-test/ltp/ltp.yaml
need run job	kunit-test,kernel-build,check-patch,lava-trigger

测试完成

详细结果:

check	result
kunit-test	success
kernel-build	success
check-patch	failure
lava-trigger-qemu	success
lava-trigger-sg2042	skipped
lava-trigger-k1	skipped
lava-trigger-lpi4a	skipped

Kunit Test Result

[09:24:09] Testing complete. Ran 482 tests: passed: 466, skipped: 16

detail log: https://github.com/RVCK-Project/rvck-olk/actions/runs/31088584668/attempts/1/#summary-92573878500

Kernel Build Result

Kernel build succeeded: RVCK-Project/rvck-olk/249_31088584668_1/
e6ba34030512d6b419a01d7bd031c34b /srv/guix_result/aab5e3ac461bab48dae1b5c64ffb2a5ce4edd219/Image
1d9215bb27e9316a48eef67281a63725 /root/initramfs.img
detail log: https://github.com/RVCK-Project/rvck-olk/actions/runs/31088584668/attempts/1/#summary-92573878523

Check Patch Result


Total Errors	3
Total Warnings	55

detail log: https://github.com/RVCK-Project/rvck-olk/actions/runs/31088584668/attempts/1/#summary-92573878551

LAVA Check (qemu)

args	value
testcase_repo	RVCK-Project/lavaci
lava_template	lava-job-template/qemu/qemu-ltp.yaml
testcase_path	lava-testcases/common-test/ltp/ltp.yaml
kernel_download_url	http://10.30.190.110/openEuler-RISC-V/RVCK/OERV-RVCI/RVCK-Project/rvck-olk/249_31088584668_1/Image
initramfs_download_url	http://10.30.190.110/openEuler-RISC-V/RVCK/OERV-RVCI/RVCK-Project/rvck-olk/249_31088584668_1/initramfs.img
rootfs_download_url	https://fast-mirror.isrc.ac.cn/openeuler-sig-riscv/openEuler-RISC-V/RVCK/openEuler24.03-LTS-SP1/openeuler-rootfs.img.zst
testcase_ref	main
testitem_name	RVCK-Project_rvck-olk_pull_request_target_249__common-test_qemu

result: Lava check done!

lava log: https://lava.oerv.ac.cn/scheduler/job/3553
lava result count: [pass]: 10
detail log: https://github.com/RVCK-Project/rvck-olk/actions/runs/31088584668/attempts/1/#summary-92586074485

xmzzz · 2026-08-06T12:15:27Z

kbuild: unify vdso_install rules
riscv: xtheadvector: enable vector function
xtheadvector: fix it used as v-ext when hwprobe is used

想问下前三个 commit 的目的是什么，与这个PR相关吗？
@ieiao

ieiao · 2026-08-07T00:10:22Z

kbuild: unify vdso_install rules riscv: xtheadvector: enable vector function xtheadvector: fix it used as v-ext when hwprobe is used

想问下前三个 commit 的目的是什么，与这个PR相关吗？ @ieiao

添加riscv: xtheadvector: enable vector function和vector: fix it used as v-ext when hwprobe is used是因为
00a90d6 用到了has_xtheadvector这个函数，需要引入否则无法正常编译。

添加kbuild: unify vdso_install rules是因为这个PR涉及到vDSO相关的改动，比如 1507793 ，而这些改动是在unify vdso install rules之上的，如果不添加的话无法进行合并。

xmzzz · 2026-08-07T01:30:40Z

kbuild: unify vdso_install rules riscv: xtheadvector: enable vector function xtheadvector: fix it used as v-ext when hwprobe is used
想问下前三个 commit 的目的是什么，与这个PR相关吗？ @ieiao

添加riscv: xtheadvector: enable vector function和vector: fix it used as v-ext when hwprobe is used是因为 00a90d6 用到了has_xtheadvector这个函数，需要引入否则无法正常编译。

感谢回复。这些是非主线的补丁，我看到这里已经有了主线补丁反合，需要关注下这个PR，用主线方案：
RVCK-Project/rvck#355

添加kbuild: unify vdso_install rules是因为这个PR涉及到vDSO相关的改动，比如 1507793 ，而这些改动是在unify vdso install rules之上的，如果不添加的话无法进行合并。

这个为什么在rvck/rvck-6.6仓库里没有检索到该补丁

ieiao · 2026-08-07T10:47:46Z

kbuild: unify vdso_install rules riscv: xtheadvector: enable vector function xtheadvector: fix it used as v-ext when hwprobe is used
想问下前三个 commit 的目的是什么，与这个PR相关吗？ @ieiao

添加riscv: xtheadvector: enable vector function和vector: fix it used as v-ext when hwprobe is used是因为 00a90d6 用到了has_xtheadvector这个函数，需要引入否则无法正常编译。

感谢回复。这些是非主线的补丁，我看到这里已经有了主线补丁反合，需要关注下这个PR，用主线方案： RVCK-Project/rvck#355

添加kbuild: unify vdso_install rules是因为这个PR涉及到vDSO相关的改动，比如 1507793 ，而这些改动是在unify vdso install rules之上的，如果不添加的话无法进行合并。

这个为什么在rvck/rvck-6.6仓库里没有检索到该补丁

好的，thead的补丁我关注一下rvck的改动，不过这个pr现在有1534个commit，看起来不太对，需要确认一下。

vDSO这个补丁在rvck/rvck-6.6中存在，是这个提交 RVCK-Project/rvck@adacfc6dec4c4

xmzzz · 2026-08-12T09:36:04Z

添加kbuild: unify vdso_install rules是因为这个PR涉及到vDSO相关的改动，比如 1507793 ，而这些改动是在unify vdso install rules之上的，如果不添加的话无法进行合并。

这个为什么在rvck/rvck-6.6仓库里没有检索到该补丁

好的，thead的补丁我关注一下rvck的改动，不过这个pr现在有1534个commit，看起来不太对，需要确认一下。

RVCK-Project/rvck#355 作者已更新。

vDSO这个补丁在rvck/rvck-6.6中存在，是这个提交 RVCK-Project/rvck@adacfc6dec4c4

现在rvck-6.6好像是因为浅克隆看不到之前的历史，这个commit已确认在 v6.6.33 tag 里。

这个PR计划在上面 xtheadvector 的问题解决后合并。

@ieiao

ieiao · 2026-08-21T12:20:12Z

rvck xtheadvector已合并，正在同步中，此pr暂时关闭，后续rebase后重新提交

masahir0y and others added 30 commits July 10, 2026 20:33

xtheadvector: fix it used as v-ext when hwprobe is used

b52bd58

community inclusion category: feature bugzilla: RVCK-Project/rvck#255 Signed-off-by: Han Gao <gaohan@iscas.ac.cn> Signed-off-by: Yanteng Si <si.yanteng@linux.dev> [sync from rvck.] Signed-off-by: WeiHao Li <cn.liweihao@gmail.com>

Paul Walmsley and others added 19 commits July 10, 2026 20:34

ieiao closed this Aug 21, 2026

Navigation Menu

Repository navigation

sync: rvck #285: riscv: backport follow-up fixes for user CFI support- #285 - #249

sync: rvck #285: riscv: backport follow-up fixes for user CFI support- #285#249
ieiao wants to merge 49 commits into
RVCK-Project:OLK-6.6from
ieiao:PR285@rvck

ieiao commented Aug 6, 2026

Uh oh!

github-actions Bot commented Aug 6, 2026 •

edited

Loading

Kunit Test Result

Kernel Build Result

Check Patch Result

LAVA Check (qemu)

result: Lava check done!

Uh oh!

xmzzz commented Aug 6, 2026

Uh oh!

ieiao commented Aug 7, 2026

Uh oh!

xmzzz commented Aug 7, 2026

Uh oh!

ieiao commented Aug 7, 2026

Uh oh!

xmzzz commented Aug 12, 2026 •

edited

Loading

Uh oh!

ieiao commented Aug 21, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

14 participants

Conversation

ieiao commented Aug 6, 2026

Uh oh!

github-actions Bot commented Aug 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Kunit Test Result

Kernel Build Result

Check Patch Result

LAVA Check (qemu)

result: Lava check done!

Uh oh!

xmzzz commented Aug 6, 2026

Uh oh!

ieiao commented Aug 7, 2026

Uh oh!

xmzzz commented Aug 7, 2026

Uh oh!

ieiao commented Aug 7, 2026

Uh oh!

xmzzz commented Aug 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ieiao commented Aug 21, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

14 participants

github-actions Bot commented Aug 6, 2026 •

edited

Loading

xmzzz commented Aug 12, 2026 •

edited

Loading