February 2025 - Linux-kselftest-mirror

[PATCH v5 0/7] ptrace: introduce PTRACE_SET_SYSCALL_INFO API

by Dmitry V. Levin

PTRACE_SET_SYSCALL_INFO is a generic ptrace API that complements PTRACE_GET_SYSCALL_INFO by letting the ptracer modify details of system calls the tracee is blocked in. This API allows ptracers to obtain and modify system call details in a straightforward and architecture-agnostic way, providing a consistent way of manipulating the system call number and arguments across architectures. As in case of PTRACE_GET_SYSCALL_INFO, PTRACE_SET_SYSCALL_INFO also does not aim to address numerous architecture-specific system call ABI peculiarities, like differences in the number of system call arguments for such system calls as pread64 and preadv. The current implementation supports changing only those bits of system call information that are used by strace system call tampering, namely, syscall number, syscall arguments, and syscall return value. Support of changing additional details returned by PTRACE_GET_SYSCALL_INFO, such as instruction pointer and stack pointer, could be added later if needed, by using struct ptrace_syscall_info.flags to specify the additional details that should be set. Currently, "flags" and "reserved" fields of struct ptrace_syscall_info must be initialized with zeroes; "arch", "instruction_pointer", and "stack_pointer" fields are currently ignored. PTRACE_SET_SYSCALL_INFO currently supports only PTRACE_SYSCALL_INFO_ENTRY, PTRACE_SYSCALL_INFO_EXIT, and PTRACE_SYSCALL_INFO_SECCOMP operations. Other operations could be added later if needed. Ideally, PTRACE_SET_SYSCALL_INFO should have been introduced along with PTRACE_GET_SYSCALL_INFO, but it didn't happen. The last straw that convinced me to implement PTRACE_SET_SYSCALL_INFO was apparent failure to provide an API of changing the first system call argument on riscv architecture [1]. ptrace(2) man page: long ptrace(enum __ptrace_request request, pid_t pid, void *addr, void *data); ... PTRACE_SET_SYSCALL_INFO Modify information about the system call that caused the stop. The "data" argument is a pointer to struct ptrace_syscall_info that specifies the system call information to be set. The "addr" argument should be set to sizeof(struct ptrace_syscall_info)). [1] https://lore.kernel.org/all/59505464-c84a-403d-972f-d4b2055eeaac@gmail.com/ Notes: v5: * ptrace: Extend the commit message to say that the new API does not aim to address numerous architecture-specific syscall ABI peculiarities * selftests: Add a workaround for s390 16-bit syscall numbers * Add more Acked-by * v4: https://lore.kernel.org/all/20250203065849.GA14120@strace.io/ v4: * Split out syscall_set_return_value() for hexagon into a separate patch * s390: Change the style of syscall_set_arguments() implementation as requested * Add more Reviewed-by * v3: https://lore.kernel.org/all/20250128091445.GA8257@strace.io/ v3: * powerpc: Submit syscall_set_return_value() fix for "sc" case separately * mips: Do not introduce erroneous argument truncation on mips n32, add a detailed description to the commit message of the mips_get_syscall_arg() change * ptrace: Add explicit padding to the end of struct ptrace_syscall_info, simplify obtaining of user ptrace_syscall_info, do not introduce PTRACE_SYSCALL_INFO_SIZE_VER0 * ptrace: Change the return type of ptrace_set_syscall_info_* functions from "unsigned long" to "int" * ptrace: Add -ERANGE check to ptrace_set_syscall_info_exit(), add comments to -ERANGE checks * ptrace: Update comments about supported syscall stops * selftests: Extend set_syscall_info test, fix for mips n32 * Add Tested-by and Reviewed-by v2: * Add patch to fix syscall_set_return_value() on powerpc * Add patch to fix mips_get_syscall_arg() on mips * Add syscall_set_return_value() implementation on hexagon * Add syscall_set_return_value() invocation to syscall_set_nr() on arm and arm64. * Fix syscall_set_nr() and mips_set_syscall_arg() on mips * Add a comment to syscall_set_nr() on arc, powerpc, s390, sh, and sparc * Remove redundant ptrace_syscall_info.op assignments in ptrace_get_syscall_info_* * Minor style tweaks in ptrace_get_syscall_info_op() * Remove syscall_set_return_value() invocation from ptrace_set_syscall_info_entry() * Skip syscall_set_arguments() invocation in case of syscall number -1 in ptrace_set_syscall_info_entry() * Split ptrace_syscall_info.reserved into ptrace_syscall_info.reserved and ptrace_syscall_info.flags * Use __kernel_ulong_t instead of unsigned long in set_syscall_info test Dmitry V. Levin (7): mips: fix mips_get_syscall_arg() for o32 hexagon: add syscall_set_return_value() syscall.h: add syscall_set_arguments() syscall.h: introduce syscall_set_nr() ptrace_get_syscall_info: factor out ptrace_get_syscall_info_op ptrace: introduce PTRACE_SET_SYSCALL_INFO request selftests/ptrace: add a test case for PTRACE_SET_SYSCALL_INFO arch/arc/include/asm/syscall.h | 25 + arch/arm/include/asm/syscall.h | 37 ++ arch/arm64/include/asm/syscall.h | 29 + arch/csky/include/asm/syscall.h | 13 + arch/hexagon/include/asm/syscall.h | 21 + arch/loongarch/include/asm/syscall.h | 15 + arch/m68k/include/asm/syscall.h | 7 + arch/microblaze/include/asm/syscall.h | 7 + arch/mips/include/asm/syscall.h | 70 ++- arch/nios2/include/asm/syscall.h | 16 + arch/openrisc/include/asm/syscall.h | 13 + arch/parisc/include/asm/syscall.h | 19 + arch/powerpc/include/asm/syscall.h | 20 + arch/riscv/include/asm/syscall.h | 16 + arch/s390/include/asm/syscall.h | 21 + arch/sh/include/asm/syscall_32.h | 24 + arch/sparc/include/asm/syscall.h | 22 + arch/um/include/asm/syscall-generic.h | 19 + arch/x86/include/asm/syscall.h | 43 ++ arch/xtensa/include/asm/syscall.h | 18 + include/asm-generic/syscall.h | 30 + include/uapi/linux/ptrace.h | 7 +- kernel/ptrace.c | 179 +++++- tools/testing/selftests/ptrace/Makefile | 2 +- .../selftests/ptrace/set_syscall_info.c | 519 ++++++++++++++++++ 25 files changed, 1145 insertions(+), 47 deletions(-) create mode 100644 tools/testing/selftests/ptrace/set_syscall_info.c -- ldv

4 months, 2 weeks

1
0
0 0

[PATCH v9 00/26] riscv control-flow integrity for usermode

by Deepak Gupta

Basics and overview =================== Software with larger attack surfaces (e.g. network facing apps like databases, browsers or apps relying on browser runtimes) suffer from memory corruption issues which can be utilized by attackers to bend control flow of the program to eventually gain control (by making their payload executable). Attackers are able to perform such attacks by leveraging call-sites which rely on indirect calls or return sites which rely on obtaining return address from stack memory. To mitigate such attacks, risc-v extension zicfilp enforces that all indirect calls must land on a landing pad instruction `lpad` else cpu will raise software check exception (a new cpu exception cause code on riscv). Similarly for return flow, risc-v extension zicfiss extends architecture with - `sspush` instruction to push return address on a shadow stack - `sspopchk` instruction to pop return address from shadow stack and compare with input operand (i.e. return address on stack) - `sspopchk` to raise software check exception if comparision above was a mismatch - Protection mechanism using which shadow stack is not writeable via regular store instructions More information an details can be found at extensions github repo [1]. Equivalent to landing pad (zicfilp) on x86 is `ENDBRANCH` instruction in Intel CET [3] and branch target identification (BTI) [4] on arm. Similarly x86's Intel CET has shadow stack [5] and arm64 has guarded control stack (GCS) [6] which are very similar to risc-v's zicfiss shadow stack. x86 and arm64 support for user mode shadow stack is already in mainline. Kernel awareness for user control flow integrity ================================================ This series picks up Samuel Holland's envcfg changes [2] as well. So if those are being applied independently, they should be removed from this series. Enabling: In order to maintain compatibility and not break anything in user mode, kernel doesn't enable control flow integrity cpu extensions on binary by default. Instead exposes a prctl interface to enable, disable and lock the shadow stack or landing pad feature for a task. This allows userspace (loader) to enumerate if all objects in its address space are compiled with shadow stack and landing pad support and accordingly enable the feature. Additionally if a subsequent `dlopen` happens on a library, user mode can take a decision again to disable the feature (if incoming library is not compiled with support) OR terminate the task (if user mode policy is strict to have all objects in address space to be compiled with control flow integirty cpu feature). prctl to enable shadow stack results in allocating shadow stack from virtual memory and activating for user address space. x86 and arm64 are also following same direction due to similar reason(s). clone/fork: On clone and fork, cfi state for task is inherited by child. Shadow stack is part of virtual memory and is a writeable memory from kernel perspective (writeable via a restricted set of instructions aka shadow stack instructions) Thus kernel changes ensure that this memory is converted into read-only when fork/clone happens and COWed when fault is taken due to sspush, sspopchk or ssamoswap. In case `CLONE_VM` is specified and shadow stack is to be enabled, kernel will automatically allocate a shadow stack for that clone call. map_shadow_stack: x86 introduced `map_shadow_stack` system call to allow user space to explicitly map shadow stack memory in its address space. It is useful to allocate shadow for different contexts managed by a single thread (green threads or contexts) risc-v implements this system call as well. signal management: If shadow stack is enabled for a task, kernel performs an asynchronous control flow diversion to deliver the signal and eventually expects userspace to issue sigreturn so that original execution can be resumed. Even though resume context is prepared by kernel, it is in user space memory and is subject to memory corruption and corruption bugs can be utilized by attacker in this race window to perform arbitrary sigreturn and eventually bypass cfi mechanism. Another issue is how to ensure that cfi related state on sigcontext area is not trampled by legacy apps or apps compiled with old kernel headers. In order to mitigate control-flow hijacting, kernel prepares a token and place it on shadow stack before signal delivery and places address of token in sigcontext structure. During sigreturn, kernel obtains address of token from sigcontext struture, reads token from shadow stack and validates it and only then allow sigreturn to succeed. Compatiblity issue is solved by adopting dynamic sigcontext management introduced for vector extension. This series re-factor the code little bit to allow future sigcontext management easy (as proposed by Andy Chiu from SiFive) config and compilation: Introduce a new risc-v config option `CONFIG_RISCV_USER_CFI`. Selecting this config option picks the kernel support for user control flow integrity. This optin is presented only if toolchain has shadow stack and landing pad support. And is on purpose guarded by toolchain support. Reason being that eventually vDSO also needs to be compiled in with shadow stack and landing pad support. vDSO compile patches are not included as of now because landing pad labeling scheme is yet to settle for usermode runtime. To get more information on kernel interactions with respect to zicfilp and zicfiss, patch series adds documentation for `zicfilp` and `zicfiss` in following: Documentation/arch/riscv/zicfiss.rst Documentation/arch/riscv/zicfilp.rst How to test this series ======================= Toolchain --------- $ git clone git@github.com:sifive/riscv-gnu-toolchain.git -b cfi-dev $ riscv-gnu-toolchain/configure --prefix=<path-to-where-to-build> --with-arch=rv64gc_zicfilp_zicfiss --enable-linux --disable-gdb --with-extra-multilib-test="rv64gc_zicfilp_zicfiss-lp64d:-static" $ make -j$(nproc) Qemu ---- Get the lastest qemu $ cd qemu $ mkdir build $ cd build $ ../configure --target-list=riscv64-softmmu $ make -j$(nproc) Opensbi ------- $ git clone git@github.com:deepak0414/opensbi.git -b v6_cfi_spec_split_opensbi $ make CROSS_COMPILE=<your riscv toolchain> -j$(nproc) PLATFORM=generic Linux ----- Running defconfig is fine. CFI is enabled by default if the toolchain supports it. $ make ARCH=riscv CROSS_COMPILE=<path-to-cfi-riscv-gnu-toolchain>/build/bin/riscv64-unknown-linux-gnu- -j$(nproc) defconfig $ make ARCH=riscv CROSS_COMPILE=<path-to-cfi-riscv-gnu-toolchain>/build/bin/riscv64-unknown-linux-gnu- -j$(nproc) In case you're building your own rootfs using toolchain, please make sure you pick following patch to ensure that vDSO compiled with lpad and shadow stack. "arch/riscv: compile vdso with landing pad" Branch where above patch can be picked https://github.com/deepak0414/linux-riscv-cfi/tree/vdso_user_cfi_v6.12-rc1 Running ------- Modify your qemu command to have: -bios <path-to-cfi-opensbi>/build/platform/generic/firmware/fw_dynamic.bin -cpu rv64,zicfilp=true,zicfiss=true,zimop=true,zcmop=true vDSO related Opens (in the flux) ================================= I am listing these opens for laying out plan and what to expect in future patch sets. And of course for the sake of discussion. Shadow stack and landing pad enabling in vDSO ---------------------------------------------- vDSO must have shadow stack and landing pad support compiled in for task to have shadow stack and landing pad support. This patch series doesn't enable that (yet). Enabling shadow stack support in vDSO should be straight forward (intend to do that in next versions of patch set). Enabling landing pad support in vDSO requires some collaboration with toolchain folks to follow a single label scheme for all object binaries. This is necessary to ensure that all indirect call-sites are setting correct label and target landing pads are decorated with same label scheme. How many vDSOs --------------- Shadow stack instructions are carved out of zimop (may be operations) and if CPU doesn't implement zimop, they're illegal instructions. Kernel could be running on a CPU which may or may not implement zimop. And thus kernel will have to carry 2 different vDSOs and expose the appropriate one depending on whether CPU implements zimop or not. References ========== [1] - https://github.com/riscv/riscv-cfi [2] - https://lore.kernel.org/all/20240814081126.956287-1-samuel.holland@sifive.c… [3] - https://lwn.net/Articles/889475/ [4] - https://developer.arm.com/documentation/109576/0100/Branch-Target-Identific… [5] - https://www.intel.com/content/dam/develop/external/us/en/documents/catc17-i… [6] - https://lwn.net/Articles/940403/ --- changelog --------- v9: - rebased on master (39a803b754d5 fix braino in "9p: fix ->rename_sem exclusion") - dropped "mm: Introduce ARCH_HAS_USER_SHADOW_STACK" (master has it from arm64/gcs) - dropped "prctl: arch-agnostic prctl for shadow stack" (master has it from arm64/gcs) v8: - rebased on palmer/for-next - dropped samuel holland's `envcfg` context switch patches. they are in parlmer/for-next v7: - Removed "riscv/Kconfig: enable HAVE_EXIT_THREAD for riscv" Instead using `deactivate_mm` flow to clean up. see here for more context https://lore.kernel.org/all/20230908203655.543765-1-rick.p.edgecombe@intel.… - Changed the header include in `kselftest`. Hopefully this fixes compile issue faced by Zong Li at SiFive. - Cleaned up an orphaned change to `mm/mmap.c` in below patch "riscv/mm : ensure PROT_WRITE leads to VM_READ | VM_WRITE" - Lock interfaces for shadow stack and indirect branch tracking expect arg == 0 Any future evolution of this interface should accordingly define how arg should be setup. - `mm/map.c` has an instance of using `VM_SHADOW_STACK`. Fixed it to use helper `is_shadow_stack_vma`. - Link to v6: https://lore.kernel.org/r/20241008-v5_user_cfi_series-v6-0-60d9fe073f37@riv… v6: - Picked up Samuel Holland's changes as is with `envcfg` placed in `thread` instead of `thread_info` - fixed unaligned newline escapes in kselftest - cleaned up messages in kselftest and included test output in commit message - fixed a bug in clone path reported by Zong Li - fixed a build issue if CONFIG_RISCV_ISA_V is not selected (this was introduced due to re-factoring signal context management code) v5: - rebased on v6.12-rc1 - Fixed schema related issues in device tree file - Fixed some of the documentation related issues in zicfilp/ss.rst (style issues and added index) - added `SHADOW_STACK_SET_MARKER` so that implementation can define base of shadow stack. - Fixed warnings on definitions added in usercfi.h when CONFIG_RISCV_USER_CFI is not selected. - Adopted context header based signal handling as proposed by Andy Chiu - Added support for enabling kernel mode access to shadow stack using FWFT (https://github.com/riscv-non-isa/riscv-sbi-doc/blob/master/src/ext-firmware…) - Link to v5: https://lore.kernel.org/r/20241001-v5_user_cfi_series-v1-0-3ba65b6e550f@riv… (Note: I had an issue in my workflow due to which version number wasn't picked up correctly while sending out patches) v4: - rebased on 6.11-rc6 - envcfg: Converged with Samuel Holland's patches for envcfg management on per- thread basis. - vma_is_shadow_stack is renamed to is_vma_shadow_stack - picked up Mark Brown's `ARCH_HAS_USER_SHADOW_STACK` patch - signal context: using extended context management to maintain compatibility. - fixed `-Wmissing-prototypes` compiler warnings for prctl functions - Documentation fixes and amending typos. - Link to v4: https://lore.kernel.org/all/20240912231650.3740732-1-debug@rivosinc.com/ v3: - envcfg logic to pick up base envcfg had a bug where `ENVCFG_CBZE` could have been picked on per task basis, even though CPU didn't implement it. Fixed in this series. - dt-bindings As suggested, split into separate commit. fixed the messaging that spec is in public review - arch_is_shadow_stack change arch_is_shadow_stack changed to vma_is_shadow_stack - hwprobe zicfiss / zicfilp if present will get enumerated in hwprobe - selftests As suggested, added object and binary filenames to .gitignore Selftest binary anyways need to be compiled with cfi enabled compiler which will make sure that landing pad and shadow stack are enabled. Thus removed separate enable/disable tests. Cleaned up tests a bit. - Link to v3: https://lore.kernel.org/lkml/20240403234054.2020347-1-debug@rivosinc.com/ v2: - Using config `CONFIG_RISCV_USER_CFI`, kernel support for riscv control flow integrity for user mode programs can be compiled in the kernel. - Enabling of control flow integrity for user programs is left to user runtime - This patch series introduces arch agnostic `prctls` to enable shadow stack and indirect branch tracking. And implements them on riscv. --- Changes in v9: - EDITME: describe what is new in this series revision. - EDITME: use bulletpoints and terse descriptions. - Link to v8: https://lore.kernel.org/r/20241111-v5_user_cfi_series-v8-0-dce14aa30207@riv… Changes in v8: - EDITME: describe what is new in this series revision. - EDITME: use bulletpoints and terse descriptions. - Link to v7: https://lore.kernel.org/r/20241029-v5_user_cfi_series-v7-0-2727ce9936cb@riv… --- Andy Chiu (1): riscv: signal: abstract header saving for setup_sigcontext Clément Léger (1): riscv: Add Firmware Feature SBI extensions definitions Deepak Gupta (24): mm: helper `is_shadow_stack_vma` to check shadow stack vma dt-bindings: riscv: zicfilp and zicfiss in dt-bindings (extensions.yaml) riscv: zicfiss / zicfilp enumeration riscv: zicfiss / zicfilp extension csr and bit definitions riscv: usercfi state for task and save/restore of CSR_SSP on trap entry/exit riscv/mm : ensure PROT_WRITE leads to VM_READ | VM_WRITE riscv mm: manufacture shadow stack pte riscv mmu: teach pte_mkwrite to manufacture shadow stack PTEs riscv mmu: write protect and shadow stack riscv/mm: Implement map_shadow_stack() syscall riscv/shstk: If needed allocate a new shadow stack on clone riscv: Implements arch agnostic shadow stack prctls prctl: arch-agnostic prctl for indirect branch tracking riscv/traps: Introduce software check exception riscv/signal: save and restore of shadow stack for signal riscv/kernel: update __show_regs to print shadow stack register riscv/ptrace: riscv cfi status and state via ptrace and in core files riscv/hwprobe: zicfilp / zicfiss enumeration in hwprobe riscv: enable kernel access to shadow stack memory via FWFT sbi call riscv: kernel command line option to opt out of user cfi riscv: create a config for shadow stack and landing pad instr support riscv: Documentation for landing pad / indirect branch tracking riscv: Documentation for shadow stack on riscv kselftest/riscv: kselftest for user mode cfi Documentation/arch/riscv/index.rst | 2 + Documentation/arch/riscv/zicfilp.rst | 115 +++++ Documentation/arch/riscv/zicfiss.rst | 176 +++++++ .../devicetree/bindings/riscv/extensions.yaml | 14 + arch/riscv/Kconfig | 20 + arch/riscv/include/asm/asm-prototypes.h | 1 + arch/riscv/include/asm/cpufeature.h | 13 + arch/riscv/include/asm/csr.h | 16 + arch/riscv/include/asm/entry-common.h | 2 + arch/riscv/include/asm/hwcap.h | 2 + arch/riscv/include/asm/mman.h | 25 + arch/riscv/include/asm/mmu_context.h | 7 + arch/riscv/include/asm/pgtable.h | 30 +- arch/riscv/include/asm/processor.h | 2 + arch/riscv/include/asm/sbi.h | 26 + arch/riscv/include/asm/thread_info.h | 3 + arch/riscv/include/asm/usercfi.h | 89 ++++ arch/riscv/include/asm/vector.h | 3 + arch/riscv/include/uapi/asm/hwprobe.h | 2 + arch/riscv/include/uapi/asm/ptrace.h | 22 + arch/riscv/include/uapi/asm/sigcontext.h | 1 + arch/riscv/kernel/Makefile | 1 + arch/riscv/kernel/asm-offsets.c | 8 + arch/riscv/kernel/cpufeature.c | 2 + arch/riscv/kernel/entry.S | 31 +- arch/riscv/kernel/head.S | 12 + arch/riscv/kernel/process.c | 26 +- arch/riscv/kernel/ptrace.c | 83 ++++ arch/riscv/kernel/signal.c | 142 +++++- arch/riscv/kernel/sys_hwprobe.c | 2 + arch/riscv/kernel/sys_riscv.c | 10 + arch/riscv/kernel/traps.c | 43 ++ arch/riscv/kernel/usercfi.c | 524 +++++++++++++++++++++ arch/riscv/mm/init.c | 2 +- arch/riscv/mm/pgtable.c | 17 + include/linux/cpu.h | 4 + include/uapi/linux/elf.h | 1 + include/uapi/linux/prctl.h | 27 ++ kernel/sys.c | 30 ++ mm/gup.c | 2 +- mm/mmap.c | 2 +- mm/vma.h | 10 +- tools/testing/selftests/riscv/Makefile | 2 +- tools/testing/selftests/riscv/cfi/.gitignore | 3 + tools/testing/selftests/riscv/cfi/Makefile | 10 + tools/testing/selftests/riscv/cfi/cfi_rv_test.h | 84 ++++ tools/testing/selftests/riscv/cfi/riscv_cfi_test.c | 78 +++ tools/testing/selftests/riscv/cfi/shadowstack.c | 375 +++++++++++++++ tools/testing/selftests/riscv/cfi/shadowstack.h | 37 ++ 49 files changed, 2106 insertions(+), 33 deletions(-) --- base-commit: 39a803b754d5224a3522016b564113ee1e4091b2 change-id: 20240930-v5_user_cfi_series-3dc332f8f5b2 -- - debug

4 months, 2 weeks

4
37
0 0

Re: [PATCH 0/6] KUnit test moves / renames

by Stephen Rothwell

Hi all, On Mon, 10 Feb 2025 04:43:28 +0530 Shuah Khan <skhan(a)linuxfoundation.org> wrote: > > On Sun, Feb 9, 2025, 2:44 AM Kees Cook <kees(a)kernel.org> wrote: > > > On Fri, Oct 11, 2024 at 07:53:43AM -0600, Shuah Khan wrote: > > > On 10/11/24 01:25, David Gow wrote: > > > > As discussed in [1], the KUnit test naming scheme has changed to avoid > > > > name conflicts (and tab-completion woes) with the files being tested. > > > > These renames and moves have caused a nasty set of merge conflicts, so > > > > this series collates and rebases them all to be applied via > > > > mm-nonmm-unstable alongside any lib/ changes[2]. > > > > Shall I carry this in the hardening tree? I didn't see it land in the > > merge window, and I still don't see it in -next? > > > > My thinking was that this series would go through Andrew's tree to avoid > conflicts. Please take it through yours. If they have been rebased onto mm-nonmm-unstable, then they really need to go through Andrew' tree (since mm-nonmm-unstable gets rebased often). -- Cheers, Stephen Rothwell

4 months, 2 weeks

1
0
0 0

[PATCH RFCv2 00/13] iommu: Add MSI mapping support with nested SMMU

by Nicolin Chen

[ Background ] On ARM GIC systems and others, the target address of the MSI is translated by the IOMMU. For GIC, the MSI address page is called "ITS" page. When the IOMMU is disabled, the MSI address is programmed to the physical location of the GIC ITS page (e.g. 0x20200000). When the IOMMU is enabled, the ITS page is behind the IOMMU, so the MSI address is programmed to an allocated IO virtual address (a.k.a IOVA), e.g. 0xFFFF0000, which must be mapped to the physical ITS page: IOVA (0xFFFF0000) ===> PA (0x20200000). When a 2-stage translation is enabled, IOVA will be still used to program the MSI address, though the mappings will be in two stages: IOVA (0xFFFF0000) ===> IPA (e.g. 0x80900000) ===> PA (0x20200000) (IPA stands for Intermediate Physical Address). If the device that generates MSI is attached to an IOMMU_DOMAIN_DMA, the IOVA is dynamically allocated from the top of the IOVA space. If attached to an IOMMU_DOMAIN_UNMANAGED (e.g. a VFIO passthrough device), the IOVA is fixed to an MSI window reported by the IOMMU driver via IOMMU_RESV_SW_MSI, which is hardwired to MSI_IOVA_BASE (IOVA==0x8000000) for ARM IOMMUs. So far, this IOMMU_RESV_SW_MSI works well as kernel is entirely in charge of the IOMMU translation (1-stage translation), since the IOVA for the ITS page is fixed and known by kernel. However, with virtual machine enabling a nested IOMMU translation (2-stage), a guest kernel directly controls the stage-1 translation with an IOMMU_DOMAIN_DMA, mapping a vITS page (at an IPA 0x80900000) onto its own IOVA space (e.g. 0xEEEE0000). Then, the host kernel can't know that guest-level IOVA to program the MSI address. There have been two approaches to solve this problem: 1. Create an identity mapping in the stage-1. VMM could insert a few RMRs (Reserved Memory Regions) in guest's IORT. Then the guest kernel would fetch these RMR entries from the IORT and create an IOMMU_RESV_DIRECT region per iommu group for a direct mapping. Eventually, the mappings would look like: IOVA (0x8000000) === IPA (0x8000000) ===> 0x20200000 This requires an IOMMUFD ioctl for kernel and VMM to agree on the IPA. 2. Forward the guest-level MSI IOVA captured by VMM to the host-level GIC driver, to program the correct MSI IOVA. Forward the VMM-defined vITS page location (IPA) to the kernel for the stage-2 mapping. Eventually: IOVA (0xFFFF0000) ===> IPA (0x80900000) ===> PA (0x20200000) This requires a VFIO ioctl (for IOVA) and an IOMMUFD ioctl (for IPA). Worth mentioning that when Eric Auger was working on the same topic with the VFIO iommu uAPI, he had the approach (2) first, and then switched to the approach (1), suggested by Jean-Philippe for reduction of complexity. The approach (1) basically feels like the existing VFIO passthrough that has a 1-stage mapping for the unmanaged domain, yet only by shifting the MSI mapping from stage 1 (guest-has-no-iommu case) to stage 2 (guest-has- iommu case). So, it could reuse the existing IOMMU_RESV_SW_MSI piece, by sharing the same idea of "VMM leaving everything to the kernel". The approach (2) is an ideal solution, yet it requires additional effort for kernel to be aware of the 1-stage gIOVA(s) and 2-stage IPAs for vITS page(s), which demands VMM to closely cooperate. * It also brings some complicated use cases to the table where the host or/and guest system(s) has/have multiple ITS pages. [ Execution ] Though these two approaches feel very different on the surface, they can share some underlying common infrastructure. Currently, only one pair of sw_msi functions (prepare/compose) are provided by dma-iommu for irqchip drivers to directly use. There could be different versions of functions from different domain owners: for existing VFIO passthrough cases and in- kernel DMA domain cases, reuse the existing dma-iommu's version of sw_msi functions; for nested translation use cases, there can be another version of sw_msi functions to handle mapping and msi_msg(s) differently. To support both approaches, in this series - Get rid of the duplication in the "compose" function - Introduce a function pointer for the previously "prepare" function - Allow different domain owners to set their own "sw_msi" implementations - Implement an iommufd_sw_msi function to additionally support a nested translation use case using the approach (2), i.e. the RMR solution - Add a pair of IOMMUFD options for a SW_MSI window for kernel and VMM to agree on (for approach 1) - Add a new VFIO ioctl to set the MSI(x) vector(s) for iommufd_sw_msi() to update the msi_desc structure accordingly (for approach 2) A missing piece - Potentially another IOMMUFD_CMD_IOAS_MAP_MSI ioctl for VMM to map the IPAs of the vITS page(s) in the stage-2 io page table. (for approach 2) (in this RFC, conveniently reuse the new IOMMUFD SW_MSI options to set the vITS page's IPA, which works finely in a single-vITS-page case.) This is a joint effort that includes Jason's rework in irq/iommu/iommufd base level and my additional patches on top of that for new uAPIs. This series is on github: https://github.com/nicolinc/iommufd/commits/iommufd_msi-rfcv2 Pairing QEMU branch for testing (approach 1): https://github.com/nicolinc/qemu/commits/wip/for_iommufd_msi-rfcv2-rmr Pairing QEMU branch for testing (approach 2): https://github.com/nicolinc/qemu/commits/wip/for_iommufd_msi-rfcv2-vits Changelog v2 * Rebase on v6.13-rc6 * Drop all the irq/pci patches and rework the compose function instead * Add a new sw_msi op to iommu_domain for a per type implementation and let iommufd core has its own implementation to support both approaches * Add RMR-solution (approach 1) support since it is straightforward and have been used in some out-of-tree projects widely v1 https://lore.kernel.org/kvm/cover.1731130093.git.nicolinc@nvidia.com/ Thanks! Nicolin Jason Gunthorpe (5): genirq/msi: Store the IOMMU IOVA directly in msi_desc instead of iommu_cookie genirq/msi: Rename iommu_dma_compose_msi_msg() to msi_msg_set_msi_addr() iommu: Make iommu_dma_prepare_msi() into a generic operation irqchip: Have CONFIG_IRQ_MSI_IOMMU be selected by the irqchips that need it iommufd: Implement sw_msi support natively Nicolin Chen (8): iommu: Turn fault_data to iommufd private pointer iommufd: Make attach_handle generic iommu: Turn iova_cookie to dma-iommu private pointer iommufd: Add IOMMU_OPTION_SW_MSI_START/SIZE ioctls iommufd/selftes: Add coverage for IOMMU_OPTION_SW_MSI_START/SIZE iommufd/device: Allow setting IOVAs for MSI(x) vectors vfio-iommufd: Provide another layer of msi_iova helpers vfio/pci: Allow preset MSI IOVAs via VFIO_IRQ_SET_ACTION_PREPARE drivers/iommu/Kconfig | 1 - drivers/irqchip/Kconfig | 4 + kernel/irq/Kconfig | 1 + drivers/iommu/iommufd/iommufd_private.h | 69 ++-- include/linux/iommu.h | 58 ++-- include/linux/iommufd.h | 6 + include/linux/msi.h | 43 ++- include/linux/vfio.h | 25 ++ include/uapi/linux/iommufd.h | 18 +- include/uapi/linux/vfio.h | 8 +- drivers/iommu/dma-iommu.c | 63 ++-- drivers/iommu/iommu.c | 29 ++ drivers/iommu/iommufd/device.c | 312 ++++++++++++++++-- drivers/iommu/iommufd/fault.c | 122 +------ drivers/iommu/iommufd/hw_pagetable.c | 5 +- drivers/iommu/iommufd/io_pagetable.c | 4 +- drivers/iommu/iommufd/ioas.c | 34 ++ drivers/iommu/iommufd/main.c | 15 + drivers/irqchip/irq-gic-v2m.c | 5 +- drivers/irqchip/irq-gic-v3-its.c | 13 +- drivers/irqchip/irq-gic-v3-mbi.c | 12 +- drivers/irqchip/irq-ls-scfg-msi.c | 5 +- drivers/vfio/iommufd.c | 27 ++ drivers/vfio/pci/vfio_pci_intrs.c | 46 +++ drivers/vfio/vfio_main.c | 3 + tools/testing/selftests/iommu/iommufd.c | 53 +++ .../selftests/iommu/iommufd_fail_nth.c | 14 + 27 files changed, 712 insertions(+), 283 deletions(-) -- 2.43.0

4 months, 2 weeks

10
63
0 0

[PATCH v2 0/2] tools/nolibc: add support for directory access

by Thomas Weißschuh

Add support opendir(), readdir_r(), closedir() and friends. Signed-off-by: Thomas Weißschuh <linux(a)weissschuh.net> --- Changes in v2: - Move definitions to dirent.h - Reserve space for the trailing NULL byte of d_name - Implement readdir_r() instead of readdir() - Expand commit message - Link to v1: https://lore.kernel.org/r/20250130-nolibc-dir-v1-0-ea9950b52e29@weissschuh.… --- Thomas Weißschuh (2): tools/nolibc: add support for sys_llseek() tools/nolibc: add support for directory access tools/include/nolibc/Makefile | 1 + tools/include/nolibc/dirent.h | 98 ++++++++++++++++++++++++++++ tools/include/nolibc/nolibc.h | 1 + tools/include/nolibc/sys.h | 29 +++++++- tools/testing/selftests/nolibc/nolibc-test.c | 39 +++++++++++ 5 files changed, 167 insertions(+), 1 deletion(-) --- base-commit: c1f4a7a84037249d086a4114c0c4332a260e9091 change-id: 20250130-nolibc-dir-980c2e2b661a Best regards, -- Thomas Weißschuh <linux(a)weissschuh.net>

4 months, 2 weeks

2
3
0 0

[PATCH] selftests: mm: Fixed typo

by Eric Salem

Fixed misspelling. Signed-off-by: Eric Salem <ericsalem(a)gmail.com> --- tools/testing/selftests/mm/uffd-common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/mm/uffd-common.c b/tools/testing/selftests/mm/uffd-common.c index 717539eddf98..f23c57d9d1bd 100644 --- a/tools/testing/selftests/mm/uffd-common.c +++ b/tools/testing/selftests/mm/uffd-common.c @@ -323,7 +323,7 @@ int uffd_test_ctx_init(uint64_t features, const char **errmsg) ret = userfaultfd_open(&features); if (ret) { if (errmsg) - *errmsg = "possible lack of priviledge"; + *errmsg = "possible lack of privilege"; return ret; } -- 2.48.1

4 months, 2 weeks

1
0
0 0

[PATCH v4 0/2] lib/prime_numbers: convert self-test to KUnit

by Tamir Duberstein

This is a clear example of a unit test. I tested this using: $ tools/testing/kunit/kunit.py run --arch arm64 --make_options LLVM=1 math-prime_numbers On success: ; [08:51:41] ============== math-prime_numbers (1 subtest) ============== ; [08:51:41] [PASSED] prime_numbers_test ; [08:51:41] =============== [PASSED] math-prime_numbers ================ ; [08:51:41] ============================================================ ; [08:51:41] Testing complete. Ran 1 tests: passed: 1 On failure: ; [08:50:19] ============== math-prime_numbers (1 subtest) ============== ; [08:50:19] # prime_numbers_test: ASSERTION FAILED at lib/math/tests/prime_numbers_kunit.c:28 ; [08:50:19] Expected slow == fast, but ; [08:50:19] slow == 0 (0x0) ; [08:50:19] fast == 1 (0x1) ; [08:50:19] is-prime(2) ; [08:50:19] [FAILED] prime_numbers_test ; [08:50:19] # module: prime_numbers_kunit ; [08:50:19] # math-prime_numbers: primes.{last=61, .sz=64, .primes[]=...x28208a20a08a28ac} = 2-3,5,7,11,13,17,19,23,29,31,37,41,43,47,53,59,61 ; [08:50:19] =============== [FAILED] math-prime_numbers ================ ; [08:50:19] ============================================================ ; [08:50:19] Testing complete. Ran 1 tests: failed: 1 Signed-off-by: Tamir Duberstein <tamird(a)gmail.com> --- Changes in v4: - Use `#if IS_ENABLED` to handle `CONFIG_PRIME_NUMBERS_KUNIT_TEST=m`. (Andrew Morton) - Link to v3: https://lore.kernel.org/r/20250208-prime_numbers-kunit-convert-v3-0-8ffd581… Changes in v3: - Remove `selftest_max` again; snuck into v2. - Restore `#include <linux/slab.h>`. - Sending v3 early because kernel test robot is sad. - Link to v2: https://lore.kernel.org/r/20250208-prime_numbers-kunit-convert-v2-0-8631194… Changes in v2: - Keep all the details hidden in prime_numbers.c; expose `with_primes` for debug logging in the test. (David Gow) - Link to v1: https://lore.kernel.org/r/20250207-prime_numbers-kunit-convert-v1-0-6067f2b… --- Tamir Duberstein (2): lib/math: Hook up tests/Makefile lib/prime_numbers: convert self-test to KUnit lib/Kconfig.debug | 14 +++++ lib/math/Makefile | 4 +- lib/math/prime_numbers.c | 76 ++++------------------------ lib/math/prime_numbers_private.h | 17 +++++++ lib/math/tests/Makefile | 1 + lib/math/tests/prime_numbers_kunit.c | 59 +++++++++++++++++++++ tools/testing/selftests/lib/config | 1 - tools/testing/selftests/lib/prime_numbers.sh | 4 -- 8 files changed, 102 insertions(+), 74 deletions(-) --- base-commit: 2014c95afecee3e76ca4a56956a936e23283f05b change-id: 20250207-prime_numbers-kunit-convert-71c9b3c1d1d4 Best regards, -- Tamir Duberstein <tamird(a)gmail.com>

4 months, 2 weeks

1
2
0 0

[PATCH v3 0/2] lib/prime_numbers: convert self-test to KUnit

by Tamir Duberstein

This is a clear example of a unit test. I tested this using: $ tools/testing/kunit/kunit.py run --arch arm64 --make_options LLVM=1 math-prime_numbers On success: ; [08:51:41] ============== math-prime_numbers (1 subtest) ============== ; [08:51:41] [PASSED] prime_numbers_test ; [08:51:41] =============== [PASSED] math-prime_numbers ================ ; [08:51:41] ============================================================ ; [08:51:41] Testing complete. Ran 1 tests: passed: 1 On failure: ; [08:50:19] ============== math-prime_numbers (1 subtest) ============== ; [08:50:19] # prime_numbers_test: ASSERTION FAILED at lib/math/tests/prime_numbers_kunit.c:28 ; [08:50:19] Expected slow == fast, but ; [08:50:19] slow == 0 (0x0) ; [08:50:19] fast == 1 (0x1) ; [08:50:19] is-prime(2) ; [08:50:19] [FAILED] prime_numbers_test ; [08:50:19] # module: prime_numbers_kunit ; [08:50:19] # math-prime_numbers: primes.{last=61, .sz=64, .primes[]=...x28208a20a08a28ac} = 2-3,5,7,11,13,17,19,23,29,31,37,41,43,47,53,59,61 ; [08:50:19] =============== [FAILED] math-prime_numbers ================ ; [08:50:19] ============================================================ ; [08:50:19] Testing complete. Ran 1 tests: failed: 1 Signed-off-by: Tamir Duberstein <tamird(a)gmail.com> --- Changes in v3: - Remove `selftest_max` again; snuck into v2. - Restore `#include <linux/slab.h>`. - Sending v3 early because kernel test robot is sad. - Link to v2: https://lore.kernel.org/r/20250208-prime_numbers-kunit-convert-v2-0-8631194… Changes in v2: - Keep all the details hidden in prime_numbers.c; expose `with_primes` for debug logging in the test. (David Gow) - Link to v1: https://lore.kernel.org/r/20250207-prime_numbers-kunit-convert-v1-0-6067f2b… --- Tamir Duberstein (2): lib/math: Hook up tests/Makefile lib/prime_numbers: convert self-test to KUnit lib/Kconfig.debug | 14 +++++ lib/math/Makefile | 4 +- lib/math/prime_numbers.c | 76 ++++------------------------ lib/math/prime_numbers_private.h | 17 +++++++ lib/math/tests/Makefile | 1 + lib/math/tests/prime_numbers_kunit.c | 59 +++++++++++++++++++++ tools/testing/selftests/lib/config | 1 - tools/testing/selftests/lib/prime_numbers.sh | 4 -- 8 files changed, 102 insertions(+), 74 deletions(-) --- base-commit: 2014c95afecee3e76ca4a56956a936e23283f05b change-id: 20250207-prime_numbers-kunit-convert-71c9b3c1d1d4 Best regards, -- Tamir Duberstein <tamird(a)gmail.com>

4 months, 2 weeks

2
4
0 0

[PATCH v2 0/2] lib/prime_numbers: convert self-test to KUnit

by Tamir Duberstein

This is a clear example of a unit test. I tested this using: $ tools/testing/kunit/kunit.py run --arch arm64 --make_options LLVM=1 math-prime_numbers On success: ; [08:51:41] ============== math-prime_numbers (1 subtest) ============== ; [08:51:41] [PASSED] prime_numbers_test ; [08:51:41] =============== [PASSED] math-prime_numbers ================ ; [08:51:41] ============================================================ ; [08:51:41] Testing complete. Ran 1 tests: passed: 1 On failure: ; [08:50:19] ============== math-prime_numbers (1 subtest) ============== ; [08:50:19] # prime_numbers_test: ASSERTION FAILED at lib/math/tests/prime_numbers_kunit.c:28 ; [08:50:19] Expected slow == fast, but ; [08:50:19] slow == 0 (0x0) ; [08:50:19] fast == 1 (0x1) ; [08:50:19] is-prime(2) ; [08:50:19] [FAILED] prime_numbers_test ; [08:50:19] # module: prime_numbers_kunit ; [08:50:19] # math-prime_numbers: primes.{last=61, .sz=64, .primes[]=...x28208a20a08a28ac} = 2-3,5,7,11,13,17,19,23,29,31,37,41,43,47,53,59,61 ; [08:50:19] =============== [FAILED] math-prime_numbers ================ ; [08:50:19] ============================================================ ; [08:50:19] Testing complete. Ran 1 tests: failed: 1 Signed-off-by: Tamir Duberstein <tamird(a)gmail.com> --- Changes in v2: - Keep all the details hidden in prime_numbers.c; expose `with_primes` for debug logging in the test. (David Gow) - Link to v1: https://lore.kernel.org/r/20250207-prime_numbers-kunit-convert-v1-0-6067f2b… --- Tamir Duberstein (2): lib/math: Hook up tests/Makefile lib/prime_numbers: convert self-test to KUnit lib/Kconfig.debug | 14 +++++ lib/math/Makefile | 4 +- lib/math/prime_numbers.c | 82 ++++------------------------ lib/math/prime_numbers_private.h | 17 ++++++ lib/math/tests/Makefile | 1 + lib/math/tests/prime_numbers_kunit.c | 59 ++++++++++++++++++++ tools/testing/selftests/lib/config | 1 - tools/testing/selftests/lib/prime_numbers.sh | 4 -- 8 files changed, 104 insertions(+), 78 deletions(-) --- base-commit: 2014c95afecee3e76ca4a56956a936e23283f05b change-id: 20250207-prime_numbers-kunit-convert-71c9b3c1d1d4 Best regards, -- Tamir Duberstein <tamird(a)gmail.com>

4 months, 2 weeks

2
6
0 0

Re: The business loan-

by David Song

Hello, My name is David Song, at AA4 FS, we are a consultancy and brokerage Firm specializing in Growth Financial Loan and joint partnership venture. We specialize in investments in all Private and public sectors in a broad range of areas within our Financial Investment Services. We are experts in financial and operational management, due diligence and capital planning in all markets and industries. Our Investors wish to invest in any viable Project presented by your Management after reviews on your Business Project Presentation Plan. We look forward to your Swift response. We also offer commission to consultants and brokers for any partnership referrals. Regards, David Song Senior Broker AA4 Financial Services 13 Wonersh Way, Cheam, Sutton, Surrey, SM2 7LX Email: dsong(a)aa4financialservice.com

4 months, 2 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror February 2025