WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/sys/kern/exec_subr.c?h=jd%2Fqueueboosts 2019-11-29T06:34:44Z 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-06-21T09:39:48Z visa visa@openbsd.org 2019-06-21T09:39:48Z urn:sha1:edc99bcd885f4004d6cffdbe82f15aa2eb27ee9c of resource limit structs has been done between processes. By applying copy-on-write also between threads, threads can read rlimits in a nearly lock-free manner. Inspired by code in DragonFly BSD and FreeBSD. OK mpi@, agreement from jmatthew@ and anton@ 2018-04-12T17:13:34Z deraadt deraadt@openbsd.org 2018-04-12T17:13:34Z urn:sha1:003f5e42bbc90263e30dbce6eb150fc5e31b56eb syscall) confirm the stack register points at MAP_STACK memory, otherwise SIGSEGV is delivered. sigaltstack() and pthread_attr_setstack() are modified to create a MAP_STACK sub-region which satisfies alignment requirements. Observe that MAP_STACK can only be set/cleared by mmap(), which zeroes the contents of the region -- there is no mprotect() equivalent operation, so there is no MAP_STACK-adding gadget. This opportunistic software-emulation of a stack protection bit makes stack-pivot operations during ROPchain fragile (kind of like removing a tool from the toolbox). original discussion with tedu, uvm work by stefan, testing by mortimer ok kettenis 2018-02-10T02:54:33Z mortimer mortimer@openbsd.org 2018-02-10T02:54:33Z urn:sha1:a4349a2ed0d3eaa37016558674c5ee8cae05a8a6 ok deraadt@ 2018-02-08T09:27:44Z mortimer mortimer@openbsd.org 2018-02-08T09:27:44Z urn:sha1:6d1ec4b9c689be385429cbe41b7d83e24e55d794 grabbing the rnglock repeatedly. ok deraadt@ djm@ 2017-05-18T18:50:32Z kettenis kettenis@openbsd.org 2017-05-18T18:50:32Z urn:sha1:4ed6bfeac112229466414b94cdbd983fb8017796 ok deraadt@, millert@, stefan@ 2015-08-29T05:40:01Z deraadt deraadt@openbsd.org 2015-08-29T05:40:01Z urn:sha1:c4deb1d23e5260b9d5b7e20251d2163a2a267346 2015-03-14T03:38:46Z jsg jsg@openbsd.org 2015-03-14T03:38:46Z urn:sha1:21dab745d772244ad59a415114e48be2888cfbc8 have any direct symbols used. Tested for indirect use by compiling amd64/i386/sparc64 kernels. ok tedu@ deraadt@ 2015-02-16T05:23:43Z miod miod@openbsd.org 2015-02-16T05:23:43Z urn:sha1:299d59e066c172422a5f1e0ef4a5b4314798132c MACHINE_STACK_GROWS_UP. 2015-02-09T11:52:47Z miod miod@openbsd.org 2015-02-09T11:52:47Z urn:sha1:2bda40dc64ded01f64f2729a3910b84c37f10acb fixed stack area of the exec'd image, and risking hitting process limits, should we want to increase stackgap_random, the randomness is applied to the stack region in the process' vmspace.