diff options
author | Theo de Raadt <deraadt@cvs.openbsd.org> | 2019-11-29 06:34:47 +0000 |
---|---|---|
committer | Theo de Raadt <deraadt@cvs.openbsd.org> | 2019-11-29 06:34:47 +0000 |
commit | f67b268725d23fd3229f73b136ba575514edf1a1 (patch) | |
tree | 707fd46fa1309120b07da0ff3342c12297961096 /sys/sys/exec.h | |
parent | 6760a6095c934a222278e6d1c4e2209b9b96f736 (diff) |
Repurpose the "syscalls must be on a writeable page" mechanism to
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
Diffstat (limited to 'sys/sys/exec.h')
-rw-r--r-- | sys/sys/exec.h | 3 |
1 files changed, 2 insertions, 1 deletions
diff --git a/sys/sys/exec.h b/sys/sys/exec.h index 77e1066e136..ecaef3ef40b 100644 --- a/sys/sys/exec.h +++ b/sys/sys/exec.h @@ -1,4 +1,4 @@ -/* $OpenBSD: exec.h,v 1.39 2019/11/28 04:34:50 guenther Exp $ */ +/* $OpenBSD: exec.h,v 1.40 2019/11/29 06:34:46 deraadt Exp $ */ /* $NetBSD: exec.h,v 1.59 1996/02/09 18:25:09 christos Exp $ */ /*- @@ -98,6 +98,7 @@ struct exec_vmcmd { #define VMCMD_RELATIVE 0x0001 /* ev_addr is relative to base entry */ #define VMCMD_BASE 0x0002 /* marks a base entry */ #define VMCMD_STACK 0x0004 /* create with UVM_FLAG_STACK */ +#define VMCMD_SYSCALL 0x0008 /* create with UVM_FLAG_SYSCALL */ }; #define EXEC_DEFAULT_VMCMD_SETSIZE 8 /* # of cmds in set to start */ |