RISC-V User-Space Pointer Masking Appears Ready For Linux 6.13
([RISC-V] 6 Hours Ago
RISC-V Pointer Masking)
- Reference: 0001502359
- News link: https://www.phoronix.com/news/RISC-V-Pointer-Masking-Linux
- Source link:
It looks like the upcoming [1]Linux 6.13 cycle will be adding RISC-V support for user-space pointer masking and tagged address ABI.
RISC-V pointer masking can be used for implementing memory tagging akin to the Arm Memory Tagging Extension (MTE) by way of ignoring various bits of the effective address on RISC-V platforms. Memory tagging can help with the memory safety state of user-space applications.
Samuel Holland of SiFive explains in [2]this merge adding RISC-V user-space pointer masking:
"RISC-V defines three extensions for pointer masking:
- Smmpm: configured in M-mode, affects M-mode
- Smnpm: configured in M-mode, affects the next lower mode (S or U-mode)
- Ssnpm: configured in S-mode, affects the next lower mode (VS, VU, or U-mode)
This series adds support for configuring Smnpm or Ssnpm (depending on which privilege mode the kernel is running in) to allow pointer masking in userspace (VU or U-mode), extending the PR_SET_TAGGED_ADDR_CTRL API from arm64. Unlike arm64 TBI, userspace pointer masking is not enabled by default on RISC-V. Additionally, the tag width (referred to as PMLEN) is variable, so userspace needs to ask the kernel for a specific tag width, which is interpreted as a lower bound on the number of tag bits.
This series also adds support for a tagged address ABI similar to arm64 and x86. Since accesses from the kernel to user memory use the kernel's pointer masking configuration, not the user's, the kernel must untag user pointers in software before dereferencing them. And since the tag width is variable, as with LAM on x86, it must be kept the same across all threads in a process so untagged_addr_remote() can work."
As noted though, the user-space pointer masking isn't enabled by default on RISC-V, besides needing the new RISC-V ISA extensions. The new RISC-V pointer masking documentation goes on to describe its enabling:
"Support for pointer masking in userspace (the Supm extension) is provided via the PR_SET_TAGGED_ADDR_CTRL and PR_GET_TAGGED_ADDR_CTRL prctl() operations. Pointer masking is disabled by default. To enable it, userspace must call PR_SET_TAGGED_ADDR_CTRL with the PR_PMLEN field set to the number of mask/tag bits needed by the application. PR_PMLEN is interpreted as a lower bound; if the kernel is unable to satisfy the request, the PR_SET_TAGGED_ADDR_CTRL operation will fail. The actual number of tag bits is returned in PR_PMLEN by the PR_GET_TAGGED_ADDR_CTRL operation."
This RISC-V user-space pointer masking support was queued last week into [3]riscv's "for-next" Git branch . With that milestone achieved, this functionality should be merged for the upcoming Linux 6.13 merge window barring any objections from Linus Torvalds or other last minute reservations/issues by any of the involved stakeholders.
[1] https://www.phoronix.com/search/Linux+6.13
[2] https://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git/commit/?h=for-next&id=075fde581896bde171d43a994df8617b9728eae7
[3] https://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git/log/?h=for-next
RISC-V pointer masking can be used for implementing memory tagging akin to the Arm Memory Tagging Extension (MTE) by way of ignoring various bits of the effective address on RISC-V platforms. Memory tagging can help with the memory safety state of user-space applications.
Samuel Holland of SiFive explains in [2]this merge adding RISC-V user-space pointer masking:
"RISC-V defines three extensions for pointer masking:
- Smmpm: configured in M-mode, affects M-mode
- Smnpm: configured in M-mode, affects the next lower mode (S or U-mode)
- Ssnpm: configured in S-mode, affects the next lower mode (VS, VU, or U-mode)
This series adds support for configuring Smnpm or Ssnpm (depending on which privilege mode the kernel is running in) to allow pointer masking in userspace (VU or U-mode), extending the PR_SET_TAGGED_ADDR_CTRL API from arm64. Unlike arm64 TBI, userspace pointer masking is not enabled by default on RISC-V. Additionally, the tag width (referred to as PMLEN) is variable, so userspace needs to ask the kernel for a specific tag width, which is interpreted as a lower bound on the number of tag bits.
This series also adds support for a tagged address ABI similar to arm64 and x86. Since accesses from the kernel to user memory use the kernel's pointer masking configuration, not the user's, the kernel must untag user pointers in software before dereferencing them. And since the tag width is variable, as with LAM on x86, it must be kept the same across all threads in a process so untagged_addr_remote() can work."
As noted though, the user-space pointer masking isn't enabled by default on RISC-V, besides needing the new RISC-V ISA extensions. The new RISC-V pointer masking documentation goes on to describe its enabling:
"Support for pointer masking in userspace (the Supm extension) is provided via the PR_SET_TAGGED_ADDR_CTRL and PR_GET_TAGGED_ADDR_CTRL prctl() operations. Pointer masking is disabled by default. To enable it, userspace must call PR_SET_TAGGED_ADDR_CTRL with the PR_PMLEN field set to the number of mask/tag bits needed by the application. PR_PMLEN is interpreted as a lower bound; if the kernel is unable to satisfy the request, the PR_SET_TAGGED_ADDR_CTRL operation will fail. The actual number of tag bits is returned in PR_PMLEN by the PR_GET_TAGGED_ADDR_CTRL operation."
This RISC-V user-space pointer masking support was queued last week into [3]riscv's "for-next" Git branch . With that milestone achieved, this functionality should be merged for the upcoming Linux 6.13 merge window barring any objections from Linus Torvalds or other last minute reservations/issues by any of the involved stakeholders.
[1] https://www.phoronix.com/search/Linux+6.13
[2] https://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git/commit/?h=for-next&id=075fde581896bde171d43a994df8617b9728eae7
[3] https://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git/log/?h=for-next
phoronix