From: deraadt <deraadt@openbsd.org>
Date: Fri, 5 Apr 2024 12:58:49 +0000 (+0000)
Subject: On machines lacking xonly support hardware, we emulate xonly in the
X-Git-Url: http://artulab.com/gitweb/?a=commitdiff_plain;h=cd43dcb5b90fdb46896cd582869bd2c1381d8b99;p=openbsd

On machines lacking xonly support hardware, we emulate xonly in the
copyin(9) layer below system calls, using a 4-entry lookup; the 4th
entry is libc.so text. We were assuming, or rather insisting, that
on all our architectures libc.so text is treated as xonly, even if
the linker was behind in it's game.
Since msyscall(2) is gone, kernel no longer has information about the
start,len of libc.so text segment.  But we can instead use the (same)
start,len range of pinsyscalls() instead for this purpose.
ld.so is passing the same text-range to the kernel in this position.
regression tests run by anton discovered that libc.so text had become
copyin-readable.
ok kettenis
---

diff --git a/sys/uvm/uvm_mmap.c b/sys/uvm/uvm_mmap.c
index ea617dde6c5..1ec8326507c 100644
--- a/sys/uvm/uvm_mmap.c
+++ b/sys/uvm/uvm_mmap.c
@@ -1,4 +1,4 @@
-/*	$OpenBSD: uvm_mmap.c,v 1.189 2024/04/05 12:51:15 deraadt Exp $	*/
+/*	$OpenBSD: uvm_mmap.c,v 1.190 2024/04/05 12:58:49 deraadt Exp $	*/
 /*	$NetBSD: uvm_mmap.c,v 1.49 2001/02/18 21:19:08 chs Exp $	*/
 
 /*
@@ -657,6 +657,12 @@ err:
 	pr->ps_libcpin.pn_pins = pins;
 	pr->ps_libcpin.pn_npins = npins;
 	pr->ps_flags |= PS_LIBCPIN;
+
+#ifdef PMAP_CHECK_COPYIN
+	/* Assume (and insist) on libc.so text being execute-only */
+	if (PMAP_CHECK_COPYIN)
+		uvm_map_check_copyin_add(map, base, base+len);
+#endif
 	return (0);
 }