From: deraadt Date: Sat, 28 Jan 2023 17:58:58 +0000 (+0000) Subject: Permit the --exec-only option on i386 also. This does not make it the default. X-Git-Url: http://artulab.com/gitweb/?a=commitdiff_plain;h=6c48c7163af37c99878ea8e586177651d6ef2689;p=openbsd 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. --- diff --git a/gnu/llvm/lld/ELF/Driver.cpp b/gnu/llvm/lld/ELF/Driver.cpp index 55efade2462..45d378b8c36 100644 --- a/gnu/llvm/lld/ELF/Driver.cpp +++ b/gnu/llvm/lld/ELF/Driver.cpp @@ -359,6 +359,7 @@ static void checkOptions() { if (config->executeOnly) { switch (config->emachine) { + case EM_386: case EM_AARCH64: case EM_MIPS: case EM_PPC64: