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 ea617dd..1ec8326 100644 (file)
--- 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);
 }