WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/libexec/ld.so/alpha?h=jd%2Fhistogram 2019-12-07T22:57:47Z 2019-12-07T22:57:47Z guenther guenther@openbsd.org 2019-12-07T22:57:47Z urn:sha1:d9337de30c60a295621aec3876b442e235b05c93 that was deletes the lazy relocation trampoline which ltrace currently depends on problem reported by tb@ directional feedback kettenis@ ok mpi@ 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 2019-10-23T19:55:08Z guenther guenther@openbsd.org 2019-10-23T19:55:08Z urn:sha1:e3b0f1d9f0b66ddbbaef7c091ed4b0707106a624 Strip superfluous parens from return statements while here. Done programatically with two perl invocations idea ok kettenis@ drahn@ ok visa@ 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@ 2019-10-05T00:08:50Z guenther guenther@openbsd.org 2019-10-05T00:08:50Z urn:sha1:d6b8755eabe45a0eb83f5f85c8d365d23653dbc9 ok mlarkin@, mpi@, krw@, deraadt@ 2019-08-06T04:01:41Z guenther guenther@openbsd.org 2019-08-06T04:01:41Z urn:sha1:90273bfb6a9670b47465d315bcdd9bfb5678fb5a hiding the actual grotty bits in inline functions ok mpi@ 2019-08-04T23:51:45Z guenther guenther@openbsd.org 2019-08-04T23:51:45Z urn:sha1:143e5accc158c0698519f1aed096f85b567edde3 - the symbol it found, returned via the second argument - the base offset of the the object it was found in, via the return value - optionally: the object it was found in, returned via the last argument Instead, return a struct with the symbol and object pointers and let the caller get the base offset from the object's obj_base member. On at least aarch64, amd64, mips64, powerpc, and sparc64, a two word struct like this is passed in registers. ok mpi@, kettenis@ 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@ 2019-02-03T02:20:36Z guenther guenther@openbsd.org 2019-02-03T02:20:36Z urn:sha1:d7a24b570c4e19ddff7ac1653e97326d8f619c8d the stubs noted by miod@ 2018-11-22T21:37:29Z guenther guenther@openbsd.org 2018-11-22T21:37:29Z urn:sha1:c9db2c6cc9c28bf8ff81d191ed1dd7b77a021120 relocation of ld.so's GOT without using it, so _reloc_alpha_got() merely made the call to _dl_boot_bind() from asm simpler...while itself being a call that required special handling. diff and muild baking by miod@ ok guenther@