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

0 files changed, 0 insertions, 0 deletions