From: "Markus Gutschke (顧孟勤)" <markus@google.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: linux-mips@linux-mips.org, x86@kernel.org,
linux-kernel@vger.kernel.org, linuxppc-dev@ozlabs.org,
sparclinux@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
stable@kernel.org, Roland McGrath <roland@redhat.com>
Subject: Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
Date: Wed, 6 May 2009 15:08:40 -0700 [thread overview]
Message-ID: <904b25810905061508n6d9cb8dbg71de5b1e0332ede7@mail.gmail.com> (raw)
In-Reply-To: <20090506215450.GA9537@elte.hu>
On Wed, May 6, 2009 at 14:54, Ingo Molnar <mingo@elte.hu> wrote:
> Which other system calls would you like to use? Futexes might be
> one, for fast synchronization primitives?
There are a large number of system calls that "normal" C/C++ code uses
quite frequently, and that are not security sensitive. A typical
example would be gettimeofday(). But there are other system calls,
where the sandbox would not really need to inspect arguments as the
call does not expose any exploitable interface.
It is currently awkward that in order to use seccomp we have to
intercept all system calls and provide alternative implementations for
them; whereas we really only care about a comparatively small number
of security critical operations that we need to restrict.
Also, any redirected system call ends up incurring at least two
context switches, which is needlessly expensive for the large number
of trivial system calls. We are quite happy that read() and write(),
which are quite important to us, do not incur this penalty.
Markus
next prev parent reply other threads:[~2009-05-06 22:08 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20090228030226.C0D34FC3DA@magilla.sf.frob.com>
[not found] ` <20090228030413.5B915FC3DA@magilla.sf.frob.com>
[not found] ` <alpine.LFD.2.00.0902271932520.3111@localhost.localdomain>
[not found] ` <alpine.LFD.2.00.0902271948570.3111@localhost.localdomain>
2009-02-28 7:25 ` [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole Roland McGrath
2009-02-28 7:31 ` Ingo Molnar
2009-02-28 7:36 ` Roland McGrath
2009-02-28 17:23 ` Linus Torvalds
2009-02-28 17:46 ` [stable] " Greg KH
2009-02-28 17:54 ` Arjan van de Ven
2009-02-28 18:23 ` Greg KH
2009-02-28 20:27 ` Greg KH
2009-02-28 21:09 ` Benjamin Herrenschmidt
2009-03-02 1:44 ` Roland McGrath
2009-05-06 18:42 ` Markus Gutschke
2009-05-06 18:46 ` Markus Gutschke (顧孟勤)
2009-05-06 21:29 ` Ingo Molnar
2009-05-06 21:46 ` Markus Gutschke (顧孟勤)
2009-05-06 21:54 ` Ingo Molnar
2009-05-06 22:08 ` Markus Gutschke (顧孟勤) [this message]
2009-05-06 22:13 ` Ingo Molnar
2009-05-06 22:21 ` Markus Gutschke (顧孟勤)
2009-05-07 4:23 ` Nicholas Miell
2009-05-07 10:11 ` Ingo Molnar
2009-05-10 5:37 ` Pavel Machek
2009-05-08 19:18 ` Andi Kleen
2009-05-07 7:03 ` Roland McGrath
2009-05-07 8:01 ` Markus Gutschke (顧孟勤)
2009-05-07 7:30 ` Roland McGrath
2009-05-07 7:31 ` Roland McGrath
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=904b25810905061508n6d9cb8dbg71de5b1e0332ede7@mail.gmail.com \
--to=markus@google.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=mingo@elte.hu \
--cc=roland@redhat.com \
--cc=sparclinux@vger.kernel.org \
--cc=stable@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).