WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/sys/kern/exec_elf.c?h=jd%2Fqueueboosts 2020-01-25T01:28:38Z 2020-01-25T01:28:38Z deraadt deraadt@openbsd.org 2020-01-25T01:28:38Z urn:sha1:61e8dc34fbacff47ccbb0c822dd93b968287fec4 Furthermore the parser was unaware a NOTE could contain multiple records. The scanner has been rewritten. Another bonus bug: if the binary was labelled as OPENBSD ABI, NOTE parsing was completely skipped so WXNEEDED wasn't learned either... Now that NOTEs are scanned correctly, search for the 'Go' NOTE. (During this work found the Go linker produces slightly broken NOTEs - Go team will probably fix that). Work is happening for our Go dynamic-binaries to use libc syscall stubs, but the change isn't ready. Go (and reportedly free-pascal also?) binaries are the only dynamic programs which require syscalls in the main-program. Since Go binaries are now identifiable, we can disable syscalls in all other regular dynamic-main-programs, gaining the strict enforcement we want. When the the Go-libc-stub change arrives we'll delete the Go NOTE scan and treat Go binaries same as regular binaries. This change probably breaks free-pascal, a lower priority item to repair. some discussion with jsing, ok kettenis 2019-12-09T18:19:09Z deraadt deraadt@openbsd.org 2019-12-09T18:19:09Z urn:sha1:aa9cdba38a933b956f780a29f6ccac36e4312aee 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-05-13T19:21:31Z bluhm bluhm@openbsd.org 2019-05-13T19:21:31Z urn:sha1:788422d65be41111bc05f25ec194535e3ae7eb6c does not block the signal. If all threads block the signal, we delivered it to the main thread. This does not conform to POSIX. If any thread unblocks the signal, it should be delivered immediately to this thread. Mark such signals pending at the process instead of a single thread. Then any thread can handle it later. OK kettenis@ guenther@ 2019-05-11T19:59:26Z deraadt deraadt@openbsd.org 2019-05-11T19:59:26Z urn:sha1:6cd8480a213100f64e0ddae7edb389a6bf42ac15 encountered a wxneeded binary that attempts correct operation when started on a nowxallowed filesystem (it tries mprotect with RWX, notices ENOTSUP and acts in a different way). So permit execution (but of course don't allow W^X violating mappings) ok sthen kettenis robert 2019-05-09T22:25:42Z guenther guenther@openbsd.org 2019-05-09T22:25:42Z urn:sha1:f0b7d25f7b90f0594dddc8db758a9ab5bc2c1941 instead of panicing ok deraadt@, tedu@, mpi@ 2019-04-20T23:11:20Z deraadt deraadt@openbsd.org 2019-04-20T23:11:20Z urn:sha1:81f2257f52bd0b86af580bf12b761a03608e53c6 Now that alpha is fixed, we can use sizeof(). 2018-12-06T18:59:31Z guenther guenther@openbsd.org 2018-12-06T18:59:31Z urn:sha1:8ad5423e8a742c92d5b406608f1de261576ca25b to pass the real count, with a minimal .shstrtab segment for consistency. Also, add support for PN_XNUM to readelf. problem reported and testing by claudio@ ok kettenis@ 2018-08-05T14:23:57Z beck beck@openbsd.org 2018-08-05T14:23:57Z urn:sha1:e1a6e22610ac903571d6f6d9b3fe485ff45b5a75 to the namei args. This fixes a bug where chmod would be allowed when with only READ. This also allows some further cleanup of some awkward things like PLEDGE_STAT that will follow Lots of assistence from semarie@ - thanks! ok semarie@ 2018-07-20T21:57:26Z deraadt deraadt@openbsd.org 2018-07-20T21:57:26Z urn:sha1:68a19ea97895289fd2dfeeeec2a14ca7c852b512 a bad/corrupt binary not returning ENOEXEC but some other error. ok guenther kettenis bluhm