From: Florian Weimer <fweimer@redhat.com>
To: kernel-hardening@lists.openwall.com
Subject: [kernel-hardening] System call interface changes
Date: Fri, 20 Nov 2015 11:30:39 +0100 [thread overview]
Message-ID: <564EF64F.1060903@redhat.com> (raw)
Not sure if this in scope for this list. If not, please say so.
Currently, the system call interface to user space expects the system
call number in a register (on i386 and x86_64, and probably most other
architectures). This means that once you have a system call instruction
in the process image, it can be theoretically used to run *any* system
call, including ones that are not actually referenced in the binary. As
a result, you need seccomp or a Linux security module to interdict
certain system calls.
This would have to be an opt-in feature, obviously, and applications
would have to opt in explicitly via some ELF flag (similar to what we
did for non-executable stacks).
Do you think it would be feasible to encode the system call number in
the instruction stream instead, next to the instruction? I think this
would have to set the system call MSR (LSTAR) on some context switches
at least (to avoid a conditional branch in the system call handler,
depending on whether the process has opted in to the new interface), and
add a few instructions (two loads and an add, so that the system call
number can be encoded in multiple ways, to avoid creating otherwise
useful bit patterns). On the other hand, it would avoid the need to
load the sixth argument from the stack on i386.
Florian
next reply other threads:[~2015-11-20 10:30 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-20 10:30 Florian Weimer [this message]
2015-11-20 19:16 ` [kernel-hardening] System call interface changes Rich Felker
2015-11-24 19:54 ` Florian Weimer
2015-11-24 20:29 ` Rich Felker
2015-11-24 20:10 ` Kees Cook
2015-11-24 20:54 ` Florian Weimer
2015-11-24 21:43 ` Kees Cook
2015-12-07 15:44 ` Florian Weimer
2015-12-07 16:26 ` lazytyped
2015-11-24 22:33 ` Rich Felker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=564EF64F.1060903@redhat.com \
--to=fweimer@redhat.com \
--cc=kernel-hardening@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.