wireguard-openbsd/libexec/ld.so/Makefile, branch jd/histogram WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/libexec/ld.so/Makefile?h=jd%2Fhistogram 2019-12-02T17:19:25Z It is not always clear what ld.so was backed up to ld.so.backup, and 2019-12-02T17:19:25Z deraadt deraadt@openbsd.org 2019-12-02T17:19:25Z urn:sha1:93a664f21378b90da9c7200b1020553be1df08d4 better that folk doing development in here use their own cp tooling. As additional paranoia, make a copy of system ld.so into obj/ld.so.backup 2019-11-29T19:30:56Z deraadt deraadt@openbsd.org 2019-11-29T19:30:56Z urn:sha1:29ab13eb17d9e2d6e30c1ca48e4fee1f71c2a2fc We don't want to CLEANFILES this one. On occasion this comes in useful. Repurpose the "syscalls must be on a writeable page" mechanism to 2019-11-29T06:34:44Z deraadt deraadt@openbsd.org 2019-11-29T06:34:44Z urn:sha1:e50417250fb1d11dd90538c8f1a10723b2e4b3af enforce a new policy: system calls must be in pre-registered regions. We have discussed more strict checks than this, but none satisfy the cost/benefit based upon our understanding of attack methods, anyways let's see what the next iteration looks like. This is intended to harden (translation: attackers must put extra effort into attacking) against a mixture of W^X failures and JIT bugs which allow syscall misinterpretation, especially in environments with polymorphic-instruction/variable-sized instructions. It fits in a bit with libc/libcrypto/ld.so random relink on boot and no-restart-at-crash behaviour, particularily for remote problems. Less effective once on-host since someone the libraries can be read. For static-executables the kernel registers the main program's PIE-mapped exec section valid, as well as the randomly-placed sigtramp page. For dynamic executables ELF ld.so's exec segment is also labelled valid; ld.so then has enough information to register libc's exec section as valid via call-once msyscall(2) For dynamic binaries, we continue to to permit the main program exec segment because "go" (and potentially a few other applications) have embedded system calls in the main program. Hopefully at least go gets fixed soon. We declare the concept of embedded syscalls a bad idea for numerous reasons, as we notice the ecosystem has many of static-syscall-in-base-binary which are dynamically linked against libraries which in turn use libc, which contains another set of syscall stubs. We've been concerned about adding even one additional syscall entry point... but go's approach tends to double the entry-point attack surface. This was started at a nano-hackathon in Bob Beck's basement 2 weeks ago during a long discussion with mortimer trying to hide from the SSL scream-conversations, and finished in more comfortable circumstances next to a wood-stove at Elk Lakes cabin with UVM scream-conversations. ok guenther kettenis mortimer, lots of feedback from others conversations about go with jsing tb sthen For more archs, ld.so itself only needs/uses the arch's "just add load offset" 2019-10-20T03:44:49Z guenther guenther@openbsd.org 2019-10-20T03:44:49Z urn:sha1:17fa88719dad59793b58356460b07659ff5d59db 'relative' relocation. Take advantage of that to simplify ld.so's self-reloc code: * give the exceptional archs (hppa and mips64) copies of the current boot.c as boot_md.c * teach the Makefile to use boot_md.c when present * reduce boot.c down to the minimum necessary to handle just relative reloc * teach the Makefile to fail if the built ld.so has other types of relocs ok visa@ kettenis@ Suppress DWARF2 warnings on clang archs by building with -gdwarf-4 2019-08-03T19:36:55Z guenther guenther@openbsd.org 2019-08-03T19:36:55Z urn:sha1:8f3b0808dbeea07d6b28e21f0f947ced6b8eca98 ok deraadt@, kettenis@ ld.so's $ORIGIN handling when argv[0] is a relative path was broken by 2019-07-14T03:23:12Z guenther guenther@openbsd.org 2019-07-14T03:23:12Z urn:sha1:6eb4f976a0f7775de1d6294cab149fddd37b7a5b the change in __getcwd(2)'s return value. Fix it by switching to the __realpath(2) syscall, eliminating the ld.so copy of realpath(). problem caught by regress and noted by bluhm@ ok deraadt@ ld.so boot cleanup support: 2019-05-10T13:29:21Z guenther guenther@openbsd.org 2019-05-10T13:29:21Z urn:sha1:c0197e40dd4094880fe205f9c12d3e12e14e7ff3 - put functions and data which are only used before calling the executable's start function into their own page-aligned segments for unmapping (only done on amd64, arm64, armv7, powerpc, and sparc64 so far) - pass .init_array and .preinit_array functions an addition argument which is a callback to get a structure which includes a function that frees the boot text and data - sometimes delay doing RELRO processing: for a shared-object marked DF_1_INITFIRST do it after the object's .init_array, for the executable do it after the .preinit_array - improve test-ld.so to link against libpthread and trigger its initialization late libc changes to use this will come later ok kettenis@ make ld.so build reproducible by including a FILE symbol and by removing 2018-08-29T15:56:46Z robert robert@openbsd.org 2018-08-29T15:56:46Z urn:sha1:92ffaf13ffd174051475dab79f500436b1aeb294 -x from ld; this is only used for syspatch creation so builds are still randomized just as before ok guenther@ provide ffs, gcc generates calls to it, even when __builtin_ffs() is used. 2018-01-30T20:15:25Z otto otto@openbsd.org 2018-01-30T20:15:25Z urn:sha1:544a27041b454910782e3cf3b3673938dffaa3b6 ok deraadt@ also cleanout ld.so.a 2017-12-08T05:30:16Z deraadt deraadt@openbsd.org 2017-12-08T05:30:16Z urn:sha1:4bb83bacbcdac4b7d90409410727ef942dbedce3