- 31 Aug, 2023 9 commits
-
-
Palmer Dabbelt authored
Greg Ungerer <gerg@kernel.org> says: The following changes add the ability to run ELF format binaries when running RISC-V in nommu mode. That support is actually part of the ELF-FDPIC loader, so these changes are all about making that work on RISC-V. The first issue to deal with is making the ELF-FDPIC loader capable of handling 64-bit ELF files. As coded right now it only supports 32-bit ELF files. Secondly some changes are required to enable and compile the ELF-FDPIC loader on RISC-V and to pass the ELF-FDPIC mapping addresses through to user space when execing the new program. These changes have not been used to run actual ELF-FDPIC binaries. It is used to load and run normal ELF - compiled -pie format. Though the underlying changes are expected to work with full ELF-FDPIC binaries if or when that is supported on RISC-V in gcc. To avoid needing changes to the C-library (tested with uClibc-ng currently) there is a simple runtime dynamic loader (interpreter) available to do the final relocations, https://github.com/gregungerer/uldso. The nice thing about doing it this way is that the same program binary can also be loaded with the usual ELF loader in MMU linux. The motivation here is to provide an easy to use alternative to the flat format binaries normally used for RISC-V nommu based systems. * b4-shazam-merge: riscv: support the elf-fdpic binfmt loader binfmt_elf_fdpic: support 64-bit systems Link: https://lore.kernel.org/r/20230711130754.481209-1-gerg@kernel.orgSigned-off-by:
Palmer Dabbelt <palmer@rivosinc.com>
-
Palmer Dabbelt authored
Sami Tolvanen <samitolvanen@google.com> says: This series adds KCFI support for RISC-V. KCFI is a fine-grained forward-edge control-flow integrity scheme supported in Clang >=16, which ensures indirect calls in instrumented code can only branch to functions whose type matches the function pointer type, thus making code reuse attacks more difficult. Patch 1 implements a pt_regs based syscall wrapper to address function pointer type mismatches in syscall handling. Patches 2 and 3 annotate indirectly called assembly functions with CFI types. Patch 4 implements error handling for indirect call checks. Patch 5 disables CFI for arch/riscv/purgatory. Patch 6 finally allows CONFIG_CFI_CLANG to be enabled for RISC-V. Note that Clang 16 has a generic architecture-agnostic KCFI implementation, which does work with the kernel, but doesn't produce a stable code sequence for indirect call checks, which means potential failures just trap and won't result in informative error messages. Clang 17 includes a RISC-V specific back-end implementation for KCFI, which emits a predictable code sequence for the checks and a .kcfi_traps section with locations of the traps, which patch 5 uses to produce more useful errors. The type mismatch fixes and annotations in the first three patches also become necessary in future if the kernel decides to support fine-grained CFI implemented using the hardware landing pad feature proposed in the in-progress Zicfisslp extension. Once the specification is ratified and hardware support emerges, implementing runtime patching support that replaces KCFI instrumentation with Zicfisslp landing pads might also be feasible (similarly to KCFI to FineIBT patching on x86_64), allowing distributions to ship a unified kernel binary for all devices. * b4-shazam-merge: riscv: Allow CONFIG_CFI_CLANG to be selected riscv/purgatory: Disable CFI riscv: Add CFI error handling riscv: Add ftrace_stub_graph riscv: Add types to indirectly called assembly functions riscv: Implement syscall wrappers Link: https://lore.kernel.org/r/20230710183544.999540-8-samitolvanen@google.comSigned-off-by:
-
Alexandre Ghiti authored
This function is only used at boot time so mark it as __init. Fixes: 96f9d4da ("riscv: Rework kasan population functions") Signed-off-by:
Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20230704074357.233982-2-alexghiti@rivosinc.com Cc: stable@vger.kernel.org Signed-off-by:
-
Alexandre Ghiti authored
tmp_pg_dir, tmp_p4d and tmp_pud are only used in kasan_init.c so they should be declared as static. Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202306282202.bODptiGE-lkp@intel.com/ Fixes: 96f9d4da ("riscv: Rework kasan population functions") Signed-off-by:
-
Ye Xingchen authored
bitmap_zero() is faster than bitmap_clear(), so use bitmap_zero() instead of bitmap_clear(). Signed-off-by:
Ye Xingchen <ye.xingchen@zte.com.cn> Reviewed-by:
Anup Patel <anup@brainfault.org> Link: https://lore.kernel.org/r/202305061711417142802@zte.com.cnSigned-off-by:
-
Palmer Dabbelt authored
Chen Jiahao <chenjiahao16@huawei.com> says: On riscv, the current crash kernel allocation logic is trying to allocate within 32bit addressible memory region by default, if failed, try to allocate without 4G restriction. In need of saving DMA zone memory while allocating a relatively large crash kernel region, allocating the reserved memory top down in high memory, without overlapping the DMA zone, is a mature solution. Hence this patchset introduces the parameter option crashkernel=X,[high,low]. One can reserve the crash kernel from high memory above DMA zone range by explicitly passing "crashkernel=X,high"; or reserve a memory range below 4G with "crashkernel=X,low". Besides, there are few rules need to take notice: 1. "crashkernel=X,[high,low]" will be ignored if "crashkernel=size" is specified. 2. "crashkernel=X,low" is valid only when "crashkernel=X,high" is passed and there is enough memory to be allocated under 4G. 3. When allocating crashkernel above 4G and no "crashkernel=X,low" is specified, a 128M low memory will be allocated automatically for swiotlb bounce buffer. See Documentation/admin-guide/kernel-parameters.txt for more information. To verify loading the crashkernel, adapted kexec-tools is attached below: https://github.com/chenjh005/kexec-tools/tree/build-test-riscv-v2 Following test cases have been performed as expected: 1) crashkernel=256M //low=256M 2) crashkernel=1G //low=1G 3) crashkernel=4G //high=4G, low=128M(default) 4) crashkernel=4G crashkernel=256M,high //high=4G, low=128M(default), high is ignored 5) crashkernel=4G crashkernel=256M,low //high=4G, low=128M(default), low is ignored 6) crashkernel=4G,high //high=4G, low=128M(default) 7) crashkernel=256M,low //low=0M, invalid 8) crashkernel=4G,high crashkernel=256M,low //high=4G, low=256M 9) crashkernel=4G,high crashkernel=4G,low //high=0M, low=0M, invalid 10) crashkernel=512M@0xd0000000 //low=512M 11) crashkernel=1G,high crashkernel=0M,low //high=1G, low=0M * b4-shazam-merge: docs: kdump: Update the crashkernel description for riscv riscv: kdump: Implement crashkernel=X,[high,low] Link: https://lore.kernel.org/r/20230726175000.2536220-1-chenjiahao16@huawei.comSigned-off-by:
-
Palmer Dabbelt authored
Nam Cao <namcaov@gmail.com> says: Simulate some currently rejected instructions. Still to be simulated are: - c.jal - c.ebreak * b4-shazam-merge: riscv: kprobes: simulate c.beqz and c.bnez riscv: kprobes: simulate c.jr and c.jalr instructions riscv: kprobes: simulate c.j instruction Link: https://lore.kernel.org/r/cover.1690704360.git.namcaov@gmail.comSigned-off-by: -
Jisheng Zhang authored
Allow to force all function address 64B aligned as it is possible for other architectures. This may be useful when verify if performance bump is caused by function alignment changes. Before commit 1bf18da6 ("lib/Kconfig.debug: add ARCH dependency for FUNCTION_ALIGN option"), riscv supports enabling the DEBUG_FORCE_FUNCTION_ALIGN_64B option, but after that commit, each arch needs to claim the support explicitly. Signed-off-by:
Jisheng Zhang <jszhang@kernel.org> Reviewed-by:
Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230727160356.3874-1-jszhang@kernel.orgSigned-off-by:
-
Nam Cao authored
Some mv instructions were useful when first introduced to preserve a0 and a1 before function calls. However the code has changed and they are now redundant. Remove them. Signed-off-by:
Nam Cao <namcaov@gmail.com> Reviewed-by:
-
- 23 Aug, 2023 10 commits
-
-
Greg Ungerer authored
Add support for enabling and using the binfmt_elf_fdpic program loader on RISC-V platforms. The most important change is to setup registers during program load to pass the mapping addresses to the new process. One of the interesting features of the elf-fdpic loader is that it also allows appropriately compiled ELF format binaries to be loaded on nommu systems. Appropriate being those compiled with -pie. Signed-off-by:
Greg Ungerer <gerg@kernel.org> Acked-by:
Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20230711130754.481209-3-gerg@kernel.orgSigned-off-by:
-
Greg Ungerer authored
The binfmt_flat_fdpic code has a number of 32-bit specific data structures associated with it. Extend it to be able to support and be used on 64-bit systems as well. The new code defines a number of key 64-bit variants of the core elf-fdpic data structures - along side the existing 32-bit sized ones. A common set of generic named structures are defined to be either the 32-bit or 64-bit ones as required at compile time. This is a similar technique to that used in the ELF binfmt loader. For example: elf_fdpic_loadseg is either elf32_fdpic_loadseg or elf64_fdpic_loadseg elf_fdpic_loadmap is either elf32_fdpic_loadmap or elf64_fdpic_loadmap the choice based on ELFCLASS32 or ELFCLASS64. Signed-off-by:
-
Sami Tolvanen authored
Select ARCH_SUPPORTS_CFI_CLANG to allow CFI_CLANG to be selected on riscv. Reviewed-by:
Nathan Chancellor <nathan@kernel.org> Signed-off-by:
Sami Tolvanen <samitolvanen@google.com> Link: https://lore.kernel.org/r/20230710183544.999540-14-samitolvanen@google.comSigned-off-by:
-
Sami Tolvanen authored
Filter out CC_FLAGS_CFI when CONFIG_CFI_CLANG. Reviewed-by:
-
Sami Tolvanen authored
With CONFIG_CFI_CLANG, the compiler injects a type preamble immediately before each function and a check to validate the target function type before indirect calls: ; type preamble .word <id> function: ... ; indirect call check lw t1, -4(a0) lui t2, <hi20> addiw t2, t2, <lo12> beq t1, t2, .Ltmp0 ebreak .Ltmp0: jarl a0 Implement error handling code for the ebreak traps emitted for the checks. This produces the following oops on a CFI failure (generated using lkdtm): [ 21.177245] CFI failure at lkdtm_indirect_call+0x22/0x32 [lkdtm] (target: lkdtm_increment_int+0x0/0x18 [lkdtm]; expected type: 0x3ad55aca) [ 21.178483] Kernel BUG [#1] [ 21.178671] Modules linked in: lkdtm [ 21.179037] CPU: 1 PID: 104 Comm: sh Not tainted 6.3.0-rc6-00037-g37d5ec6297ab #1 [ 21.179511] Hardware name: riscv-virtio,qemu (DT) [ 21.179818] epc : lkdtm_indirect_call+0x22/0x32 [lkdtm] [ 21.180106] ra : lkdtm_CFI_FORWARD_PROTO+0x48/0x7c [lkdtm] [ 21.180426] epc : ffffffff01387092 ra : ffffffff01386f14 sp : ff20000000453cf0 [ 21.180792] gp : ffffffff81308c38 tp : ff6000000243f080 t0 : ff20000000453b78 [ 21.181157] t1 : 000000003ad55aca t2 : 000000007e0c52a5 s0 : ff20000000453d00 [ 21.181506] s1 : 0000000000000001 a0 : ffffffff0138d170 a1 : ffffffff013870bc [ 21.181819] a2 : b5fea48dd89aa700 a3 : 0000000000000001 a4 : 0000000000000fff [ 21.182169] a5 : 0000000000000004 a6 : 00000000000000b7 a7 : 0000000000000000 [ 21.182591] s2 : ff20000000453e78 s3 : ffffffffffffffea s4 : 0000000000000012 [ 21.183001] s5 : ff600000023c7000 s6 : 0000000000000006 s7 : ffffffff013882a0 [ 21.183653] s8 : 0000000000000008 s9 : 0000000000000002 s10: ffffffff0138d878 [ 21.184245] s11: ffffffff0138d878 t3 : 0000000000000003 t4 : 0000000000000000 [ 21.184591] t5 : ffffffff8133df08 t6 : ffffffff8133df07 [ 21.184858] status: 0000000000000120 badaddr: 0000000000000000 cause: 0000000000000003 [ 21.185415] [<ffffffff01387092>] lkdtm_indirect_call+0x22/0x32 [lkdtm] [ 21.185772] [<ffffffff01386f14>] lkdtm_CFI_FORWARD_PROTO+0x48/0x7c [lkdtm] [ 21.186093] [<ffffffff01383552>] lkdtm_do_action+0x22/0x34 [lkdtm] [ 21.186445] [<ffffffff0138350c>] direct_entry+0x128/0x13a [lkdtm] [ 21.186817] [<ffffffff8033ed8c>] full_proxy_write+0x58/0xb2 [ 21.187352] [<ffffffff801d4fe8>] vfs_write+0x14c/0x33a [ 21.187644] [<ffffffff801d5328>] ksys_write+0x64/0xd4 [ 21.187832] [<ffffffff801d53a6>] sys_write+0xe/0x1a [ 21.188171] [<ffffffff80003996>] ret_from_syscall+0x0/0x2 [ 21.188595] Code: 0513 0f65 a303 ffc5 53b7 7e0c 839b 2a53 0363 0073 (9002) 9582 [ 21.189178] ---[ end trace 0000000000000000 ]--- [ 21.189590] Kernel panic - not syncing: Fatal exception Reviewed-by: -
Sami Tolvanen authored
Commit 883bbbff ("ftrace,kcfi: Separate ftrace_stub() and ftrace_stub_graph()") added a separate ftrace_stub_graph function for CFI_CLANG. Add the stub to fix FUNCTION_GRAPH_TRACER compatibility with CFI. Reviewed-by:
-
Sami Tolvanen authored
With CONFIG_CFI_CLANG, assembly functions indirectly called from C code must be annotated with type identifiers to pass CFI checking. Use the SYM_TYPED_START macro to add types to the relevant functions. Reviewed-by:
-
Sami Tolvanen authored
Commit f0bddf50 ("riscv: entry: Convert to generic entry") moved syscall handling to C code, which exposed function pointer type mismatches that trip fine-grained forward-edge Control-Flow Integrity (CFI) checks as syscall handlers are all called through the same syscall_t pointer type. To fix the type mismatches, implement pt_regs based syscall wrappers similarly to x86 and arm64. This patch is based on arm64 syscall wrappers added in commit 4378a7d4 ("arm64: implement syscall wrappers"), where the main goal was to minimize the risk of userspace-controlled values being used under speculation. This may be a concern for riscv in future as well. Following other architectures, the syscall wrappers generate three functions for each syscall; __riscv_<compat_>sys_<name> takes a pt_regs pointer and extracts arguments from registers, __se_<compat_>sys_<name> is a sign-extension wrapper that casts the long arguments to the correct types for the real syscall implementation, which is named __do_<compat_>sys_<name>. Reviewed-by:
-
Palmer Dabbelt authored
Alexandre Ghiti <alexghiti@rivosinc.com> says: riscv used to allow direct access to cycle/time/instret counters, bypassing the perf framework, this patchset intends to allow the user to mmap any counter when accessed through perf. **Important**: The default mode is now user access through perf only, not the legacy so some applications will break. However, we introduce a sysctl perf_user_access like arm64 does, which will allow to switch to the legacy mode described above. This version needs openSBI v1.3 *and* a kernel fix that went upstream lately (https://lore.kernel.org/lkml/20230616114831.3186980-1-maz@kernel.org/T/). * b4-shazam-merge: perf: tests: Adapt mmap-basic.c for riscv tools: lib: perf: Implement riscv mmap support Documentation: admin-guide: Add riscv sysctl_perf_user_access drivers: perf: Implement perf event mmap support in the SBI backend drivers: perf: Implement perf event mmap support in the legacy backend riscv: Prepare for user-space perf event mmap support drivers: perf: Rename riscv pmu sbi driver riscv: Make legacy counter enum match the HW numbering include: riscv: Fix wrong include guard in riscv_pmu.h perf: Fix wrong comment about default event_idx Link: https://lore.kernel.org/r/20230802080328.1213905-1-alexghiti@rivosinc.comSigned-off-by:
-
Björn Töpel authored
Some V configurations implicitly turn on '-fno-omit-frame-pointer', but leaving FRAME_POINTER disabled. This makes it hard to reason about the FRAME_POINTER config, and also triggers build failures introduced in by the commit in the Fixes: tag. Select FRAME_POINTER explicitly for these configurations. Fixes: ebc9cb03 ("riscv: stack: Fixup independent softirq stack for CONFIG_FRAME_POINTER=n") Signed-off-by:
Björn Töpel <bjorn@rivosinc.com> Tested-by:
Randy Dunlap <rdunlap@infradead.org> Acked-by:
-
- 16 Aug, 2023 15 commits
-
-
Chen Jiahao authored
Now "crashkernel=" parameter on riscv has been updated to support crashkernel=X,[high,low]. Through which we can reserve memory region above/within 32bit addressible DMA zone. Here update the parameter description accordingly. Signed-off-by:
Chen Jiahao <chenjiahao16@huawei.com> Reviewed-by:
Guo Ren <guoren@kernel.org> Reviewed-by:
Simon Horman <horms@kernel.org> Reviewed-by:
Zhen Lei <thunder.leizhen@huawei.com> Acked-by:
Baoquan He <bhe@redhat.com> Link: https://lore.kernel.org/r/20230726175000.2536220-3-chenjiahao16@huawei.comSigned-off-by:
-
Chen Jiahao authored
On riscv, the current crash kernel allocation logic is trying to allocate within 32bit addressible memory region by default, if failed, try to allocate without 4G restriction. In need of saving DMA zone memory while allocating a relatively large crash kernel region, allocating the reserved memory top down in high memory, without overlapping the DMA zone, is a mature solution. Here introduce the parameter option crashkernel=X,[high,low]. One can reserve the crash kernel from high memory above DMA zone range by explicitly passing "crashkernel=X,high"; or reserve a memory range below 4G with "crashkernel=X,low". Signed-off-by:
-
Nam Cao authored
kprobes currently rejects instruction c.beqz and c.bnez. Implement them. Signed-off-by:
Charlie Jenkins <charlie@rivosinc.com> Link: https://lore.kernel.org/r/1d879dba4e4ee9a82e27625d6483b5c9cfed684f.1690704360.git.namcaov@gmail.comSigned-off-by:
-
Nam Cao authored
kprobes currently rejects c.jr and c.jalr instructions. Implement them. Signed-off-by:
-
Nam Cao authored
kprobes currently rejects c.j instruction. Implement it. Signed-off-by:
-
Alexandre Ghiti authored
riscv now supports mmaping hardware counters to userspace so adapt the test to run on this architecture. Signed-off-by:
Andrew Jones <ajones@ventanamicro.com> Reviewed-by:
Atish Patra <atishp@rivosinc.com> Reviewed-by:
Ian Rogers <irogers@google.com>
-
Alexandre Ghiti authored
riscv now supports mmaping hardware counters so add what's needed to take advantage of that in libperf. Signed-off-by:
-
Alexandre Ghiti authored
riscv now uses this sysctl so document its usage for this architecture. Signed-off-by: -
Alexandre Ghiti authored
We used to unconditionnally expose the cycle and instret csrs to userspace, which gives rise to security concerns. So now we only allow access to hw counters from userspace through the perf framework which will handle context switches, per-task events...etc. A sysctl allows to revert the behaviour to the legacy mode so that userspace applications which are not ready for this change do not break. But the default value is to allow userspace only through perf: this will break userspace applications which rely on direct access to rdcycle. This choice was made for security reasons [1][2]: most of the applications which use rdcycle can instead use rdtime to count the elapsed time. [1] https://groups.google.com/a/groups.riscv.org/g/sw-dev/c/REWcwYnzsKE?pli=1 [2] https://www.youtube.com/watch?v=3-c4C_L2PRQ&ab_channel=IEEESymposiumonSecurityandPrivacySigned-off-by:
-
Alexandre Ghiti authored
Implement the needed callbacks in the legacy driver so that we can directly access the counters through perf in userspace. Signed-off-by:
-
Alexandre Ghiti authored
Provide all the necessary bits in the generic riscv pmu driver to be able to mmap perf events in userspace: the heavy lifting lies in the driver backend, namely the legacy and sbi implementations. Note that arch_perf_update_userpage is almost a copy of arm64 code. Signed-off-by:
-
Alexandre Ghiti authored
That's just cosmetic, no functional changes. Signed-off-by:
-
Alexandre Ghiti authored
RISCV_PMU_LEGACY_INSTRET used to be set to 1 whereas the offset of this hardware counter from CSR_CYCLE is actually 2: make this offset match the real hw offset so that we can directly expose those values to userspace. Signed-off-by:
-
Alexandre Ghiti authored
The current include guard prevents the inclusion of asm/perf_event.h which uses the same include guard: fix the one in riscv_pmu.h so that it matches the file name. Signed-off-by:
-
Alexandre Ghiti authored
Since commit c719f560 ("perf: Fix and clean up initialization of pmu::event_idx"), event_idx default implementation has returned 0, not idx + 1, so fix the comment that can be misleading. Signed-off-by:
-
- 02 Aug, 2023 2 commits
-
-
Yuan Tan authored
In the usage of ALTERNATIVE, "always" is misspelled as "alwyas". Signed-off-by:
Yuan Tan <tanyuan@tinylab.org> Reviewed-by:
-
Justin Stitt authored
`strncpy` is deprecated for use on NUL-terminated destination strings [1]. Favor not copying strings onto stack and instead use strings directly. This avoids hard-coding sizes and buffer lengths all together. Link: https://github.com/KSPP/linux/issues/90 Cc: linux-hardening@vger.kernel.org Suggested-by:
Justin Stitt <justinstitt@google.com> Reviewed-by:
-
- 25 Jul, 2023 4 commits
-
-
Palmer Dabbelt authored
Conor Dooley <conor.dooley@microchip.com> says: Based on my latest iteration of deprecating riscv,isa [1], here's an implementation of the new properties for Linux. The first few patches, up to "RISC-V: split riscv_fill_hwcap() in 3", are all prep work that further tames some of the extension related code, on top of my already applied series that cleans up the ISA string parser. Perhaps "RISC-V: shunt isa_ext_arr to cpufeature.c" is a bit gratuitous, but I figured a bit of coalescing of extension related data structures would be a good idea. Note that riscv,isa will still be used in the absence of the new properties. Palmer suggested adding a Kconfig option to turn off the fallback for DT, which I have gone and done. It's locked behind the NONPORTABLE option for good reason. * b4-shazam-merge: RISC-V: provide Kconfig & commandline options to control parsing "riscv,isa" RISC-V: try new extension properties in of_early_processor_hartid() RISC-V: enable extension detection from dedicated properties RISC-V: split riscv_fill_hwcap() in 3 RISC-V: add single letter extensions to riscv_isa_ext RISC-V: add missing single letter extension definitions RISC-V: repurpose riscv_isa_ext array in riscv_fill_hwcap() RISC-V: shunt isa_ext_arr to cpufeature.c RISC-V: drop a needless check in print_isa_ext() RISC-V: don't parse dt/acpi isa string to get rv32/rv64 RISC-V: Provide a more helpful error message on invalid ISA strings Link: https://lore.kernel.org/r/20230713-target-much-8ac624e90df8@wendySigned-off-by:
-
Conor Dooley authored
As it says on the tin, provide Kconfig option to control parsing the "riscv,isa" devicetree property. If either option is used, the kernel will fall back to parsing "riscv,isa", where "riscv,isa-base" and "riscv,isa-extensions" are not present. The Kconfig options are set up so that the default kernel configuration will enable the fallback path, without needing the commandline option. Suggested-by:
-
Conor Dooley authored
To fully deprecate the kernel's use of "riscv,isa", of_early_processor_hartid() needs to first try using the new properties, before falling back to "riscv,isa". Reviewed-by:
-
Conor Dooley authored
Add support for parsing the new riscv,isa-extensions property in riscv_fill_hwcap(), by means of a new "property" member of the riscv_isa_ext_data struct. For now, this shadows the name of the extension for all users, however this may not be the case for all extensions, based on how the dt-binding is written. For the sake of backwards compatibility, fall back to the old scheme if the new properties are not detected. For now, just inform, rather than warn, when that happens. Reviewed-by:
-
