CVSROOT: /cvs
Module name: src
Changes by: dera...@cvs.openbsd.org 2023/01/28 10:58:58
Modified files:
gnu/llvm/lld/ELF: Driver.cpp
Log message:
Permit the --exec-only option on i386 also. This does not make it the default.
I wonder if we should allow --exec-only option on all architectures
(but not as default), because this pre-check list now covers all
architectures, and we haven't seen a ld.lld problem. We only switch
an architecture to --exec-only default when other aspects (mostly
compiler or .S files), that is a seperate switch block.
Even though i386 has no mmu means to enforce xonly, uvm will fail a
memcpy read of region which hasn't been previously faulted (by
executing code in the region). This definately blocks reads of
"contigious entire libc text", because very few programs "execute code
in all libc code pages", even with uvm_fault's behaviour of wide
faulting a 32K region. The random relinking also means an attacker
cannot know what subset of libc text can be read because pre-faulted
chunks are unknown, but now they can't copy it all (if they could find
the location and bounds). This neat behaviour applies to all
architectures. It seems we should try to always hint text segment
permission as PROT_EXEC-only to the kernel and be happy that blocks a
read, even if that blocking isn't 100% reliable.
note: unfortunately binutils --exec-only isn't bug-free yet on most
architectures, taking the same approach there will take longer.
