linux-kernel - [PATCH v2 3/3] Documentation: riscv: correct sv57 kernel behavior

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <tencent_6ADF31EB216F8DAA7C608268DA008EB6B808@qq.com>
Date: Sun, 21 Jan 2024 05:50:00 +0800
From: Yangyu Chen <cyy@...self.name>
To: linux-riscv@...ts.infradead.org
Cc: Charlie Jenkins <charlie@...osinc.com>,
	Paul Walmsley <paul.walmsley@...ive.com>,
	Palmer Dabbelt <palmer@...belt.com>,
	Guo Ren <guoren@...nel.org>,
	Andy Chiu <andy.chiu@...ive.com>,
	Conor Dooley <conor.dooley@...rochip.com>,
	Jisheng Zhang <jszhang@...nel.org>,
	Alexandre Ghiti <alexghiti@...osinc.com>,
	linux-mm@...ck.org,
	linux-kselftest@...r.kernel.org,
	linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Yangyu Chen <cyy@...self.name>
Subject: [PATCH v2 3/3] Documentation: riscv: correct sv57 kernel behavior

The original documentation from the previous patchset[1] treated the hint
address on mmap as the upper bound, since we have already removed this
behavior, this document should be updated. Most of the content is copied
from the corresponding feature in x86_64 with some modifications to align
with the current kernel's behavior on RISC-V.

[1]. https://lore.kernel.org/linux-riscv/20230809232218.849726-1-charlie@rivosinc.com/

Signed-off-by: Yangyu Chen <cyy@...self.name>
---
 Documentation/arch/riscv/vm-layout.rst | 54 ++++++++++++++++----------
 1 file changed, 34 insertions(+), 20 deletions(-)

diff --git a/Documentation/arch/riscv/vm-layout.rst b/Documentation/arch/riscv/vm-layout.rst
index 69ff6da1dbf8..9d84362b9f91 100644
--- a/Documentation/arch/riscv/vm-layout.rst
+++ b/Documentation/arch/riscv/vm-layout.rst
@@ -135,23 +135,37 @@ RISC-V Linux Kernel SV57
   __________________|____________|__________________|_________|____________________________________________________________
 
 
-Userspace VAs
---------------------
-To maintain compatibility with software that relies on the VA space with a
-maximum of 48 bits the kernel will, by default, return virtual addresses to
-userspace from a 48-bit range (sv48). This default behavior is achieved by
-passing 0 into the hint address parameter of mmap. On CPUs with an address space
-smaller than sv48, the CPU maximum supported address space will be the default.
-
-Software can "opt-in" to receiving VAs from another VA space by providing
-a hint address to mmap. A hint address passed to mmap will cause the largest
-address space that fits entirely into the hint to be used, unless there is no
-space left in the address space. If there is no space available in the requested
-address space, an address in the next smallest available address space will be
-returned.
-
-For example, in order to obtain 48-bit VA space, a hint address greater than
-:code:`1 << 47` must be provided. Note that this is 47 due to sv48 userspace
-ending at :code:`1 << 47` and the addresses beyond this are reserved for the
-kernel. Similarly, to obtain 57-bit VA space addresses, a hint address greater
-than or equal to :code:`1 << 56` must be provided.
+User-space and large virtual address space
+==========================================
+On RISC-V, Sv57 paging enables 56-bit userspace virtual address space.
+Not all user space is ready to handle wide addresses. It's known that
+at least some JIT compilers use higher bits in pointers to encode their
+information. It collides with valid pointers with Sv57 paging and leads
+to crashes.
+
+To mitigate this, we are not going to allocate virtual address space
+above 47-bit by default. And on kernel v6.6-v6.7, that is 38-bit by
+default.
+
+But userspace can ask for allocation from full address space by
+specifying hint address (with or without MAP_FIXED) above 47-bits, or
+hint address + size above 47-bits with MAP_FIXED.
+
+If hint address set above 47-bit, but MAP_FIXED is not specified, we try
+to look for unmapped area by specified address. If it's already
+occupied, we look for unmapped area in *full* address space, rather than
+from 47-bit window.
+
+A high hint address would only affect the allocation in question, but not
+any future mmap()s.
+
+Specifying high hint address without MAP_FIXED on older kernel or on
+machine without Sv57 paging support is safe. On kernel v6.6-v6.7, the
+hint will be treated as the upper bound of the address space to search,
+but this was removed in the future version of kernels. On kernel older
+than v6.6 or on machine without Sv57 paging support, the kernel will
+fall back to allocation from the supported address space.
+
+This approach helps to easily make application's memory allocator aware
+about large address space without manually tracking allocated virtual
+address space.
-- 
2.43.0