WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/sys/kern/init_main.c?h=jd%2Fqueueboosts 2020-06-16T05:09:28Z 2020-06-16T05:09:28Z dlg dlg@openbsd.org 2020-06-16T05:09:28Z urn:sha1:31aecb516e65b13579b7e57d1c38ad0f1da2f8a5 2020-05-29T04:42:23Z deraadt deraadt@openbsd.org 2020-05-29T04:42:23Z urn:sha1:c8f27247b9f5f282483daaddbfd1267ad73569c5 conversion steps). it only contains kernel prototypes for 4 interfaces, all of which legitimately belong in sys/systm.h, which are already included by all enqueue_randomness() users. 2020-05-25T15:24:30Z deraadt deraadt@openbsd.org 2020-05-25T15:24:30Z urn:sha1:14fbdcd427565d3fe1b1651072e26ead237d2c4f will frantically compensate. ok kettenis 2020-03-13T09:25:21Z mpi mpi@openbsd.org 2020-03-13T09:25:21Z urn:sha1:c74ff8cf4d71e98b8a7101b467101ad72cbe6604 This shows that atomic_* operations should not be necessery to write to this field unlike with the process one. The advantage of using a somewhat-unique prefix for struct member is moot when multiple definitions use the same prefix :o) From Amit Kulkarni, ok claudio@ 2020-02-25T16:55:33Z visa visa@openbsd.org 2020-02-25T16:55:33Z urn:sha1:1ab6845c7fa458f2367d6012c7c943bea84ab9dd prevents the appearance of a "smr: dispatch took N seconds" message during boot when there is an early smr_call(). Such a call can happen with mfii(4). The initial dispatch cannot make progress until smr_grace_wait() can visit all CPUs. This fix is essentially a hack. It makes use of the fact that there is no hard guarantee on how quickly the callback of smr_call() gets invoked. It is assumed that the SMR call backlog does not grow large during boot. An alternative fix is to make smr_grace_wait() skip secondary CPUs until they have been started. However, this could break if the spinup logic of secondary CPUs was changed. Delayed SMR dispatch reported and fix tested by Hrvoje Popovski Discussed with and OK kettenis@, claudio@ 2020-01-01T07:06:35Z jsg jsg@openbsd.org 2020-01-01T07:06:35Z urn:sha1:093ca88dbb2f21a2eb4de8acbe3c18401c2587bb 2019-12-30T15:48:12Z mpi mpi@openbsd.org 2019-12-30T15:48:12Z urn:sha1:eb48f06bbd46bbd3a811013fabf44df88b2a47de ok bluhm@ 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-04T17:51:22Z anton anton@openbsd.org 2019-11-04T17:51:22Z urn:sha1:c01f5a043bd9de42dff8a9324c4076b5ba324a07 instead of task(9). Undefined behavior can potentially be present in any context and calling task_add() isn't always safe. ok visa@ 2019-10-22T21:19:22Z cheloha cheloha@openbsd.org 2019-10-22T21:19:22Z urn:sha1:fe57de6bf86372f8c8b447012d1d082826b5f1c4 Allows us to determine how long a process has been running, even if the UTC clock jumps. With help from bluhm@ and millert@, who squashed several bugs. ok bluhm@ millert@