wireguard-openbsd/sys/kern/kern_exec.c, branch jd/queueboostsWireGuard implementation for the OpenBSD kernelhttps://git.zx2c4.com/wireguard-openbsd/atom/sys/kern/kern_exec.c?h=jd%2Fqueueboosts2020-02-15T09:35:48ZConsistently perform atomic writes to the ps_flags field of struct2020-02-15T09:35:48Zantonanton@openbsd.org2020-02-15T09:35:48Zurn:sha1:9648c32b5e7e65e0141b1dc6d1f8958e75832948
process.
ok bluhm@ claudio@ visa@
Replace p_xstat with ps_xexit and ps_xsig2019-12-11T07:30:09Zguentherguenther@openbsd.org2019-12-11T07:30:09Zurn:sha1:381e34d2ea89fee5668fcdf23ae079bf0d0c5f37
Convert those to a consolidated status when needed in wait4(), kevent(),
and sysctl()
Pass exit code and signal separately to exit1()
(This also serves as prep for adding waitid(2))
ok mpi@
comply with POSIX and make execve() return EACCES for directories2019-12-01T18:17:31Znaddynaddy@openbsd.org2019-12-01T18:17:31Zurn:sha1:11dfcec84175da73b57ac3a57ff06a8912b35576
ok millert@ deraadt@
Repurpose the "syscalls must be on a writeable page" mechanism to2019-11-29T06:34:44Zderaadtderaadt@openbsd.org2019-11-29T06:34:44Zurn: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
Kill uvm_deallocate(9) and use uvm_unmap() directly.2019-11-05T08:18:47Zmpimpi@openbsd.org2019-11-05T08:18:47Zurn:sha1:782069b16bde153d645fb4952ffca97be40e7f30
ok kettenis@, semarie@, deraadt@
per-process itimers: itimerval -> itimerspec2019-08-02T02:17:35Zchelohacheloha@openbsd.org2019-08-02T02:17:35Zurn:sha1:fcfbe7d9ad2cb0aec6d1e247491923311676b7b2
Loongson runs at 128hz. 128 doesn't divide evenly into a million,
but it does divide evenly into a billion. So if we do the per-process
itimer bookkeeping with itimerspec structs we can have error-free
virtual itimers on loongson just as we do on most other platforms.
This change doesn't fix the virtual itimer error alpha, as 1024 does not
divide evenly into a billion. But this doesn't make the situation any
worse, either.
ok deraadt@
Do not relock fdp in fdrelease(). This prevents unnecessary locking2019-07-15T04:11:03Zvisavisa@openbsd.org2019-07-15T04:11:03Zurn:sha1:8994f64af411fc832c7f1ee3934cc414321f1e81
in the common case.
OK mpi@
Make resource limit access MP-safe. So far, the copy-on-write sharing2019-06-21T09:39:48Zvisavisa@openbsd.org2019-06-21T09:39:48Zurn: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@
Revert to using the SCHED_LOCK() to protect time accounting.2019-06-01T14:11:17Zmpimpi@openbsd.org2019-06-01T14:11:17Zurn:sha1:17b25159f9636a4b303d8df3547b4d6c61a0117a
It currently creates a lock ordering problem because SCHED_LOCK() is taken
by hardclock(). That means the "priorities" of a thread should be moved
out of the SCHED_LOCK() first in order to make progress.
Reported-by: syzbot+8e4863b3dde88eb706dc@syzkaller.appspotmail.com
via anton@ as well as by kettenis@
Use a per-process mutex to protect time accounting instead of SCHED_LOCK().2019-05-31T19:51:09Zmpimpi@openbsd.org2019-05-31T19:51:09Zurn:sha1:4b91b74a18bc983f4cced5ae0e1d3b81f991786d
Note that hardclock(9) still increments p_{u,s,i}ticks without holding a
lock.
ok visa@, cheloha@