WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/libexec/ld.so/amd64?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-11-28T16:54:29Z guenther guenther@openbsd.org 2019-11-28T16:54:29Z urn:sha1:c8754c30d3283e6adf940d4a92ad186365563e8d something's broken on at least i386. 2019-11-26T23:38:52Z guenther guenther@openbsd.org 2019-11-26T23:38:52Z urn:sha1:0e51d825b6636bf26a24a96932854edc7d03c322 that handle a dozen relocation types for each, just have a nice little switch for the four specific relocations that actually occur. Besides being smaller and easier to understand, this fixes the COPY relocation handling to only do one symbol lookup, instead of looking up the symbol and then immediately looking it up again (with the correct flags to find the instance it needs). ok kettenis@ 2019-11-26T02:50:11Z guenther guenther@openbsd.org 2019-11-26T02:50:11Z urn:sha1:51a0cd2b6f77d9fa444185389f9b0af8e7777f97 relocation from _dl_md_reloc() to _dl_md_reloc_all_plt() which has the minimal code to do it. Also, avoid division on PLTRELSZ; just use it to offset to the end. ok kettenis@ 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@