IABSD.fr/src/libexec/ld.so
Branch :
Log
| Author | Commit | Date | CI | Message |
|---|---|---|---|---|
 |
c1b303c8 | 2026-05-10 09:10:02 | While technically allowed, shared libraries without PT_LOAD segments don't really make any sense. Bail out early to avoid the bits of code that assume that we have a PT_LOAD sagment. This avoids a NULL pointer dereference on i386 (which uses library_mquery.c) or bogus mmap calls on other architectures (which use library.c). The potential NULL pointer dereference in library_mquery.c was found by Frank Denis. ok guenther@ | |
 |
f7b67fbe | 2026-05-06 13:30:26 | Add missing bounds check for the relocation flags table. ok kettenis@ | |
|
e2945eec | 2026-05-06 09:05:48 | Add checks to make sure that the ELF header and program header fit into the data we read from the on-disk shared library. These checks should only fail for malformed shared libraries, but failing to load a shared library is better than crashing the program because of an out-of-bounds access. Issue found by Frank Denis using the Swival Security Scanner. ok guenther@ | |
|
57704f4f | 2026-05-06 08:07:05 | Add missing bounds check for the relocation flags table. Found by Frank Denis using the Swival Security Scanner. ok guenther@, jsg@ | |
 |
74811a55 | 2026-02-18 08:54:46 | These programs are using pledge "tmppath" with "rpath wpath cpath". The "tmppath" is not needed. ok semarie and others | |
|
4ae131ef | 2025-12-03 14:43:25 | Use the correct start address for the initial immutable address range for a shared library. The code used the load offset of the shared library instead of the start address of the mapped memory. In most case that works because the first segment of a shared library typically starts at virtual address zero. But on sparc64 (and possibly other architectures that still use ld.bfd) libicudata.so from ports has a non-zero virtual address (possibly because it is a data-only library). So this fixes the bug reported by claudio@ ok deraadt@, jca@, claudio@ | |
 |
da52d6dd | 2025-09-09 08:41:48 | Fix relocation handling for PLT entries with a r_addend On sparc64 the first 32768 PLT entries use a direct form of relocation while all other entires afterwards use a PC relative pointer that initally points at PLT0 and is then fixed up to point at the function. These entries use the r_addend. This relocation mode was broken in two ways: - kbind only modified 32bit of the 64bit pointer - the offset calculation used the wrong base pointer. It used the address of the PLT0 entry instead of the object base address. Introduce a simple _dl_reloc_addend() wrapper which does the calculation in both the _dl_bind and _dl_md_reloc_all_plt case. Adjust the kbind calls to update two Elf_Word values so the pointer is swapped by the kernel. There is still an issue that kbind(2) does not update this 64bit value in an atomic operation. This fixes the stage1 gcc15 cc1 and cc1plus binaries that have over 60'000 PLT entries. With and OK miod@ jca@ | |
 |
2834b6af | 2025-07-20 16:09:07 | The recent changes to expand_block_move in gcc causes assignment of 16-byte struct to no longer need to invoke memcpy(), and makes that code unnecessary. Should future changes to the MI code require the use of memcpy again, the commented out section added to the Makefile explains what to do to let ld.so build again. | |
|
278cc48c | 2025-05-08 13:57:20 | Some of architectures do not us the stack protector (for example, retguard or hppa with reverse stack). So they do not call __stack_smash_handler(), and do not call sendsyslog(2). On those architectures, we can onditionally remove the syscall stub (which also removes it from the pinsyscalls table), and the stack protector handler. ok miod | |
|
1457ca87 | 2024-06-04 15:14:44 | enable -fret-clean on amd64, for libc libcrypto ld.so kernel, and all the ssh tools. The dynamic objects are entirely ret-clean, static binaries will contain a blend of cleaning and non-cleaning callers. | |
|
ce7279d8 | 2024-05-21 05:00:47 | remove prototypes with no matching function and externs with no var partly checked by millert@ | |
|
c694ed72 | 2024-05-17 06:11:54 | use SIGKILL instead of 9; ok guenther | |
|
f7413c6a | 2024-04-05 13:51:47 | ld.so should stop calling msyscall(2), since it is fully neutered and about to be removed. Please be careful building through this, you need a kernel at least March 29th or so to build through it, otherwise use snapshots to cross over. ok various people | |
|
2584d4c0 | 2024-03-30 10:42:26 | Prefer illop1 rather than nop for text padding in the ld.so linker script. | |
|
e60a0123 | 2024-03-30 08:44:20 | Remove nonsensical comments. NFC | |
|
210cc31e | 2024-01-22 02:08:31 | ugly whitespaces | |
|
a09d28f1 | 2024-01-19 14:16:41 | Stop initializing pinsyscall(SYS_execve in dynamic binaries that contain a reference reaching the execve(2) stub. The new pinsyscalls(2) that applies to all system calls has made this redundant. | |
|
83447bbc | 2024-01-17 13:00:05 | very ugly whitespaces | |
|
4a066def | 2024-01-16 19:07:31 | Read PT_OPENBSD_SYSCALLS in libc.so, and convert it to a table for pinsyscalls(2). ok kettenis | |
|
5a40d3e0 | 2024-01-14 09:39:03 | Whenever we have a libc major bump, we run the risk that dependent shared libraries will request a different (major) libc version from the one requested by the binary itself. For various reasons loading multiple libc versions is not a good idea, and since the introduction of msyscall(2) support, system calls will only work when called from one of the two loaded libcs. This really means that when we have a libc major bump, users must update all dynamic executables and shared libraries in the system. However, to ease this transition, change ld.so to only load the first libc version that we encounter (in a breadth first sense) and substitute that libc version for all further loads of libc, even if different versions are requested. This is done silently since I can't come up with a good warning message. In practice this means the libc version requested by the executable itself will be loaded. This means that shared libraries may fail to load if they use a symbol that has been removed. But given the constraints, this is the best that we can do. Even when we bump the libc major, the set of changes is typically small and most binaries and shared libraries will continue to run and allow the user to run pkg_add -u without any fallout. ok deraadt@, gkoehler@ | |
|
a346a825 | 2023-12-20 14:54:29 | create a stub for pinsyscalls(2) | |
|
43ad5020 | 2023-12-20 14:52:07 | there is a super-alignment between btext and text, this creates a hole. Twice, I have seen the sigtramp mapping land inside that hole. This causes grief for the upcoming pinsyscalls() work which operates on address space ranges. But the micro-optimization is silly. ok kettenis | |
|
805b87ea | 2023-12-20 14:50:08 | For strange reasons which made sense at the time, the text segment was placed head of the btext (boot.text) segment. (the boot.text segment is "unmapped" after initization, as a self-protection mechanism). this meant the LOAD's virtual addresses were not in sequence, which clearly isn't what we intended. | |
|
434871b6 | 2023-12-19 16:13:22 | whitespaces | |
|
d20ca04b | 2023-12-19 06:27:45 | correct alignment placement | |
|
babd3ace | 2023-12-18 17:19:07 | correct section the SYS_kbind syscall pin record goes into noticed by gnezdo | |
 |
f73a2a97 | 2023-12-16 06:42:38 | Fix phdr name in ld.script. ok deraadt@ | |
|
2c98d8df | 2023-12-12 17:39:14 | repair type for 2nd arg of read(2) | |
|
876ab33d | 2023-12-12 15:44:00 | To avoid kbind(2) becoming a powerful gadget, it is called inline to a function. Therefore we cannot create a precise pinsyscall label. Instead create a duplicate entry (using inline asm) to force the kernel's pinsyscall code to skip validation, rather than labelling it illegal. kbind(2) remains safe because it self-protects by checking its calling address. ok kettenis | |
|
04459484 | 2023-12-11 22:29:23 | Make sure the syscall table entries are aligned on a 4-byte boundary. Required for strict-alignment architectures and a good idea on others. same as kettenis commit to libc | |
|
a0ef76c2 | 2023-12-11 03:05:15 | arm just had to be different and change the syntax for .pushsection arguments, so we have to cope. | |
|
83762a71 | 2023-12-10 16:45:50 | Populate the non-LOAD openbsd.syscalls section (and PT_OPENBSD_SYSCALL) with {uint offset, uint syscall#} entries in libc & ld.so. In libc a few syscall# entries (break, sigprocmask, _tfork, _threxit) are duplicated because additional or inline uses occur (that situation is handled elsewhere) ok kettenis | |
|
a4e0416e | 2023-12-08 12:58:27 | locally us MAXIMUM() rather than MAX() ok tb gnezdo | |
|
6750a6d9 | 2023-12-06 06:15:33 | Move CALLSYS_NOERROR macro from <machine/asm.h> to libc, and expand it for non-libc users. This is a two-liner macro anyway, and this will make deraadt@'s future changes in this area easier to make. NFC | |
|
1e43641e | 2023-11-18 16:26:15 | crt0 uses a helper function in a MD src/libexec/ld.so .h file (rather than reproducing the relevant defines and code in a different place) to perform minor relocations. If things go very wrong, it would call _dl_exit() -- a locally defined crt0 function which is syscall exit(2). We don't need to call exit(2) for this obscure case which doesn't happen and provides no debugging information. An 'abort' is going to provide better information. So let's change the function name to _dso_abort() and make it a single illegal instruction. ok guenther | |
|
b75a4ace | 2023-08-15 13:50:53 | ldd can pledge "stdio rpath proc exec prot_exec". We can later bifurbicate at the dlopen vs execve split, dropping either "proc" or "prot_exec". ok gnezdo | |
 |
ac42b3c8 | 2023-08-15 06:26:34 | Improve handling of dlopen(RTLD_TRACE) aka ldd, of a library that is already loaded: * add a 'trace' argument to _dl_show_objects() and exit the walk-the-objects loop if you hit that traced object * in dlopen(), pass the trace object to _dl_show_objects() * also, invoke _dl_show_objects() + exit if the object was already opened * pass NULL to _dl_show_objects() for all the other calls * oh hey, _dl_tracelib is now superfluous: _dl_show_objects() should do the walk-the-objects loop only if trace is not NULL. Problem noted by gnezdo@ ok millert@ | |
|
15fded63 | 2023-08-15 06:23:31 | Skip the _dl_msyscall() invocation if tracing library loading. Problem noted by gnezdo@ ok millert@ | |
 |
d4a5aacd | 2023-08-12 13:43:22 | Check for a full read, avoid warn when errno might be unmodified Promote size from int to size_t. From: lucas at sexy dot is Regress tests by gnezdo@ deraadt: yes | |
|
f61db8b9 | 2023-07-24 01:02:47 | I added the 2nd argument (execpromises) to pledge(2), and then hunted for more than a year code which could use it; but in all non-trivial circumstances (programs which would benefit), I was stopped by issues (in particular by environment variable behavious). But I never looked in ldd(1). This is the FIRST one which is completely obvious. spledge(NULL, "stdio rpath") ok guenther | |
 |
fbc42936 | 2023-07-13 19:04:50 | - use IS_ELF() to check the ELF magic bytes - reject non-sensical program header values which would result in a crash when accessing the 0 bytes sized buffer allocated due to it ok deraadt@ kettenis@ | |
|
4bd80098 | 2023-07-12 19:49:06 | validate alignment of ELF program headers | |
|
d198ddd1 | 2023-07-08 14:09:43 | turn an ifdef'd _dl_printf call into DL_DEB and various whitespace fixes sure deraadt@ | |
|
f81a9d33 | 2023-07-08 11:03:45 | zap stray backslash ok deraadt@ | |
|
2903f217 | 2023-05-18 16:33:39 | If you disable retpolineplt then _dl_bind_start is called with an indirect branch, so include an endbr64 Just In Case. ok deraadt@ | |
 |
ba367c05 | 2023-04-27 12:27:56 | revert cache lookup for full pathnames | |
|
12e285c6 | 2023-04-25 04:11:10 | endbr64 is potentially neccessary in the syscall stubs. | |
|
e00439cd | 2023-04-24 22:06:05 | Since ENTRY() already inserts a BTI instructions so don't add another one. ok patrick@ | |
|
34280c35 | 2023-04-24 08:59:09 | do a cache lookup as well in case a full pathname is passed to dlopen | |
 |
d82bde86 | 2023-04-13 19:57:30 | Avoid an overflow in the ELF SYSV ABI hash function. The hash function is supposed to return a value less than or equal to 0x0fffffff. Due to a bug in the sample code supplied with the ELF SYSV ABI documentation, the hash function can overflow on 64-bit systems. Apply the same fix used by GNU libc, MUSL libc and FreeBSD. Prompted by https://maskray.me/blog/2023-04-12-elf-hash-function OK tb@ miod@ | |
|
c51b9268 | 2023-04-09 23:41:47 | Treat symlinks better in $ORIGIN determination in ld.so Now symlinking an executable away from the rest of its installation tree no longer prevents it from finding the libraries. This matches the behavior of other OS linkers. Prompted by a behavior change in lang/ghc test suite. Swapped the order of dirname/realpath in _dl_origin_path. Added some regress tests that pass and then bin3 that fails without this change and reflects the behavior needd for lang/ghc. Suggestion by semarie@, OK deraadt@ | |
|
7dfdc4ec | 2023-03-31 18:45:05 | Call entry point of the executable through register x17. This allows it to be a normal C function that starts with "bti c" when BTI contro flow integretry enforcement is in place. Add "bti c" to _dl_bind_start(). Remove unused _rtld_tlsdesc() function to avoid having to add "bti c" to it. ok deraadt@ | |
|
8cef5497 | 2023-02-20 00:51:57 | Adjust inline !libc check to match the intent in ld.so right, deraadt@ | |
|
a4ba1e57 | 2023-02-18 01:22:50 | Lookup the start,len of the "execve" stub in libc.so, and tell the kernel where it is with pinsyscall(). In non-static binaries, kernel execve(2) will now insist upon being called from that small region. Arriving from a different region smells like ROP methodology, and the process is killed. | |
|
e148ff24 | 2023-02-10 03:22:12 | Explicitly mark the text LOAD as FLAGS(5), meaning RX, with a comment. This is the default value of the linker, but I really like placing the comment "architecturally required data islands". | |
|
92c11255 | 2023-02-02 00:44:08 | unify spacing for LOAD FLAGS lines | |
|
c284c86c | 2023-02-02 00:43:08 | i386 and alpha ld.so also work with X-only text LOAD. There is no hardware enforcement for this, but uvm can some of it's own tricks on occasion. | |
|
71410e9b | 2023-01-31 00:50:17 | powerpc xonly for G5 is coming. ld.so can have xonly text. ok gkoehler | |
|
4098e116 | 2023-01-29 20:30:56 | Accumulate intermediate imutables locally before applying OK deraadt | |
|
388165f5 | 2023-01-29 20:30:21 | Unite all nitems copies in ld.so/util.h OK deraadt | |
|
8e81a2e9 | 2023-01-29 07:37:34 | powerpc64 xonly works; ld.so can be switched over | |
|
79094096 | 2023-01-20 16:03:14 | amd64 now has xonly support via the PKU feature. Marking ld.so exec-only is no longer a NOP on those systems, let's do it. | |
|
55822a5e | 2023-01-12 07:25:29 | Use proper sparc64 illtrap instruction as text sections filler, rather than the x86 one. | |
|
f14117cf | 2023-01-11 17:16:33 | be very paranoid like other architectures and force no-jump-tables came up in two seperate conversations with miod and kettenis | |
|
7a839740 | 2023-01-11 16:33:36 | put LD_SCRIPT in the canonical location | |
|
c0a58aa7 | 2023-01-11 16:31:46 | Add ld.so linker scripts on the remaining platforms. | |
|
edb83f86 | 2023-01-11 16:21:32 | force-disable jump tables in ld.so building on sparc64, to ease the exonly transition for people building through an upcoming commit series | |
|
a291dbc8 | 2023-01-11 15:14:01 | the kernel on mips64 (octeon, loongson) is in good enough shape to run --execute-only ld.so (meaning FLAGS (1) on the LOAD line for the text segment, in the ld.script). the linker, when using built-in linker scripts, is not ready yet for other libraries / binaries.. | |
 |
39b8558c | 2023-01-11 01:55:17 | Add retguard to amd64 syscalls. Since we got rid of padded syscalls we have enough registers to do this. ok deraadt@ ok kettenis@ | |
|
7e81395c | 2023-01-10 21:22:39 | hppa ld.so works with executable-only text (non-readable) | |
|
571ef328 | 2023-01-09 15:05:49 | riscv64 ld.so is ready to be xonly ok kettenis | |
|
d857960c | 2023-01-09 13:52:42 | Rewrite the hppa assembly code to avoid reads from .text, by using the standard PIC magic. This makes the code similar to what we already use for rcrt0.o. This makes it ready for execute-only. Build C code using -fno-jump-tables to make it ready for execute-only. ok deraadt@, miod@ | |
|
4bd9ff11 | 2023-01-09 13:45:55 | In preparation for upcoming execute-only support, change the magic branch instruction used by __canonicalize_funcptr_for_compare() from "bl" into "b". This allows __canonicalize_funcptr_for_compare() to execute the branch instead of decoding the instruction to find the address of _dl_bind(). This is the first step in the transition to a new ABI. Once an updated ld.so has been installed, we can change __canonicalize_funcptr_for_compare() (which lives in libgcc) and rebuild everything with a new libgcc. Only then we can actually make ld.so executable-only. ok deraadt@, miod@ | |
 |
41b7dcd7 | 2022-12-25 09:39:37 | Re-enable DT_MIPS_RLD_MAP_REL tag in ld.so The linker now produces correct values for DT_MIPS_RLD_MAP_REL tags. The DT_MIPS_RLD_MAP_REL offset is relative to the entry of the original dynamic tags array. Therefore look up the tag from exe_obj->load_dyn instead of exe_obj->Dyn.info to get the correct base address. OK kettenis@ deraadt@ | |
|
40627327 | 2022-12-24 10:52:04 | Make .text (and .btext) execute-only on arm64. ok deraadt@ | |
|
61923635 | 2022-12-18 19:33:11 | cannot try the boot.data unmap until all the ld.script are commited, and fixed to identify the region correctly. | |
|
13f8c82f | 2022-12-16 03:14:52 | delete // debug comment chunks. If anyone wants to debug ld.so and runs into a mimmutable related concern, you want to undo this revision to get this debug back. I do not consider this suitable for hiding behind a cpp macro. | |
|
7e53a3c9 | 2022-12-05 07:49:07 | Add linker script for hppa. The crucial bit is that hppa needs an extra segment for .plt/.got which needs to be placed correctly. ok deraadt@ | |
|
9034200f | 2022-12-04 15:55:26 | ld.so: Disable DT_MIPS_RLD_MAP_REL The linker produces incorrect values for DT_MIPS_RLD_MAP_REL tags. Disable the handling of the tag in the dynamic loader. The linker will be fixed in a later commit when snapshots have the updated ld.so. Discussed with and OK kettenis@ deraadt@ | |
|
9ba2c65f | 2022-12-04 15:42:07 | The next step for mimmutable(). ld.so figures out what regions of memory of startup shared library mappings can be made immutable, and also does this for dlope() RTLD_NODELETE and subsidiary libraries. Complexity in this diff is due to the GNU_RELRO and OPENBSD_MUTABLE sections. Tested in snaps for about 3 weeks, with some bootstrap related pain felt in ports ok kettenis, much help from others. | |
|
fe251f38 | 2022-11-25 14:56:56 | Add ld.so linker script for mips64 Since the introduction of automatic immutable from the kernel, the munmap() of ld.so boot.text region is now (silently) failing because the region is contained within the text LOAD, which is immutable. So create a new btext LOAD with flags PF_X|PF_R|PF_OPENBSD_MUTABLE, and place all boot.text objects in there. This LOAD must also be page-aligned so it doesn't skip unmapping some of the object region, previously it was hilariously unaligned. OK deraadt@ | |
|
8fd2446c | 2022-11-14 13:21:50 | Since the introduction of automatic immutable from the kernel, the munmap() of ld.so boot.text region is now (silently) failing because the region is contained within the text LOAD, which is immutable. So create a new btext LOAD with flags PF_X|PF_R|PF_OPENBSD_MUTABLE, and place all boot.text objects in there. This LOAD must also be page-aligned so it doesn't skip unmapping some of the object region, previously it was hilariously unaligned. ok kettenis and guenther seemed to like it also This one is for powerpc64 and a modified version of the diff deraadt@ mailed out to make sure the LOADs are in increasing address order. this is the alpha version | |
|
b6feb2a9 | 2022-11-14 13:20:23 | Since the introduction of automatic immutable from the kernel, the munmap() of ld.so boot.text region is now (silently) failing because the region is contained within the text LOAD, which is immutable. So create a new btext LOAD with flags PF_X|PF_R|PF_OPENBSD_MUTABLE, and place all boot.text objects in there. This LOAD must also be page-aligned so it doesn't skip unmapping some of the object region, previously it was hilariously unaligned. ok kettenis and guenther seemed to like it also This one is for powerpc64 and a modified version of the diff deraadt@ mailed out to make sure the LOADs are in increasing address order. this is the i386 version | |
|
b3a51cd3 | 2022-11-14 13:13:19 | Since the introduction of automatic immutable from the kernel, the munmap() of ld.so boot.text region is now (silently) failing because the region is contained within the text LOAD, which is immutable. So create a new btext LOAD with flags PF_X|PF_R|PF_OPENBSD_MUTABLE, and place all boot.text objects in there. This LOAD must also be page-aligned so it doesn't skip unmapping some of the object region, previously it was hilariously unaligned. ok kettenis and guenther seemed to like it also This one is for powerpc64 and a modified version of the diff deraadt@ mailed out to make sure the LOADs are in increasing address order. this is the version for sparc64, tested by pascal also | |
|
e201c79b | 2022-11-14 13:12:59 | Since the introduction of automatic immutable from the kernel, the munmap() of ld.so boot.text region is now (silently) failing because the region is contained within the text LOAD, which is immutable. So create a new btext LOAD with flags PF_X|PF_R|PF_OPENBSD_MUTABLE, and place all boot.text objects in there. This LOAD must also be page-aligned so it doesn't skip unmapping some of the object region, previously it was hilariously unaligned. ok kettenis and guenther seemed to like it also This one is for powerpc64 and a modified version of the diff deraadt@ mailed out to make sure the LOADs are in increasing address order. this is the version for powerpc, tested by pascal | |
|
9044b3fc | 2022-11-10 16:14:50 | Since the introduction of automatic immutable from the kernel, the munmap() of ld.so boot.text region is now (silently) failing because the region is contained within the text LOAD, which is immutable. So create a new btext LOAD with flags PF_X|PF_R|PF_OPENBSD_MUTABLE, and place all boot.text objects in there. This LOAD must also be page-aligned so it doesn't skip unmapping some of the object region, previously it was hilariously unaligned. ok kettenis and guenther seemed to like it also This one is for powerpc64 and a modified version of the diff deraadt@ mailed out to make sure the LOADs are in increasing address order. | |
|
82e9b32a | 2022-11-09 19:50:25 | Now that dlopen() sets object->nodelete for RTLD_NODELETE, _dl_load_dep_libs() can consider this same as the "booting" case, and instruct lower layers to do immutability. With this change in place, the not-yet-commited library-immutable diff leaves 1 page of libc (malloc related) and 6 non-RTLD_NODELETE libraries mutable in chrome. Everything else is immutable, except for the program's transient memory allocations & file mappings. This is an unexpected result. | |
|
b75fe819 | 2022-11-09 18:44:11 | dlopen() with RTLD_NODELETE should also set the object nodelete flag, so the mapping layer will know it can use mimmutable() | |
|
7f8a129b | 2022-11-09 18:39:35 | Since the introduction of automatic immutable from the kernel, the munmap() of ld.so boot.text region is now (silently) failing because the region is contained within the text LOAD, which is immutable. So create a new btext LOAD with flags PF_X|PF_R|PF_OPENBSD_MUTABLE, and place all boot.text objects in there. This LOAD must also be page-aligned so it doesn't skip unmapping some of the object region, previously it was hilariously unaligned. ok kettenis and guenther seemed to like it also This one is for 32-bit arm, tested by phessler | |
|
b8b81751 | 2022-11-08 13:47:22 | In the new scheme, the main executable object needs to be marked nodelete, so that _dl_relro() will immutable it's relro. | |
|
59d66fc3 | 2022-11-08 06:55:53 | Since the introduction of automatic immutable from the kernel, the munmap() of ld.so boot.text region is now (silently) failing because the region is contained within the text LOAD, which is immutable. So create a new btext LOAD with flags PF_X|PF_R|PF_OPENBSD_MUTABLE, and place all boot.text objects in there. This LOAD must also be page-aligned so it doesn't skip unmapping some of the object region, previously it was hilariously unaligned. ok kettenis and guenther seemed to like it also This one is for riscv64, tested by jca | |
|
8e29f60a | 2022-11-08 06:47:31 | Instead of unmapping boot.text, and then a future allocation could land in the gap, mmap a fresh MAP_FIXED MAP_ANON PROT_NONE and make it immutable for good measure ok guenther kettenis | |
|
cd3e981d | 2022-11-07 21:12:57 | Missed an ALIGN (which I will admit I do not understand, this is voodoo) | |
|
a5c19628 | 2022-11-07 20:41:38 | Since the introduction of automatic immutable from the kernel, the munmap() of ld.so boot.text region is now (silently) failing because the region is contained within the text LOAD, which is immutable. So create a new btext LOAD with flags PF_X|PF_R|PF_OPENBSD_MUTABLE, and place all boot.text objects in there. This LOAD must also be page-aligned so it doesn't skip unmapping some of the object region, previously it was hilariously unaligned. Similar changes for other architectures coming after more testing. ok kettenis and guenther seemed to like it also | |
|
07cf23bb | 2022-11-07 10:35:26 | dtors were broken by trying to reuse DF_1_NODELETE to hint that this library would never unload, and could be immutable. Pass a seperate flag for our purposes Noticed from regress tests by anton, ok kettenis | |
|
d23cb5cd | 2022-11-06 12:00:20 | TEXTREL binaries are loaded without immutable on un-writeable sections. After text relocations are finished, these regions (in the binary) can become immutable. OPENBSD_MUTABLE section always overlaps writeable LOADs, so don't be afraid of that case, it's covered. | |
|
980da63b | 2022-11-06 11:43:19 | ld.so wants to make it's own RELRO immutable, which is obviously done right after it does mprotect PROT_READ. | |
|
118353ea | 2022-11-06 11:38:54 | Library RELRO sections are excluded from the immutable list, because ld.so tweaks them quite late. _dl_relro() is called when that work is done, and the final mprotect PROT_READ happens. Then we can make mark it immutable. ok kettenis | |
|
3349f56c | 2022-11-06 11:34:50 | When loading startup libraries, pass DF_1_NODELETE to indicate these are unloadable libraries. This allows us make consider making parts of those libraries immutable (in future commits) ok guenther kettenis | |
|
1916ec13 | 2022-11-05 18:48:31 | The /var/run/ld.so.hints file is mapped into memory. It is never replaced, so the mapping can be immutable. ok kettenis |