All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicholas Miell <nmiell@comcast.net>
To: "Markus Gutschke (顧孟勤)" <markus@google.com>
Cc: Ingo Molnar <mingo@elte.hu>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Roland McGrath <roland@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	x86@kernel.org, linux-kernel@vger.kernel.org, stable@kernel.org,
	linux-mips@linux-mips.org, sparclinux@vger.kernel.org,
	linuxppc-dev@ozlabs.org
Subject: Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
Date: Wed, 06 May 2009 21:23:57 -0700	[thread overview]
Message-ID: <1241670237.11500.7.camel@entropy> (raw)
In-Reply-To: <904b25810905061521v62b3ddd6l14deb614d203385a@mail.gmail.com>

On Wed, 2009-05-06 at 15:21 -0700, Markus Gutschke (顧孟勤) wrote:
> On Wed, May 6, 2009 at 15:13, Ingo Molnar <mingo@elte.hu> wrote:
> > doing a (per arch) bitmap of harmless syscalls and replacing the
> > mode1_syscalls[] check with that in kernel/seccomp.c would be a
> > pretty reasonable extension. (.config controllable perhaps, for
> > old-style-seccomp)
> >
> > It would probably be faster than the current loop over
> > mode1_syscalls[] as well.
> 
> This would be a great option to improve performance of our sandbox. I
> can detect the availability of the new kernel API dynamically, and
> then not intercept the bulk of the system calls. This would allow the
> sandbox to work both with existing and with newer kernels.
> 
> We'll post a kernel patch for discussion in the next few days,
> 

I suspect the correct thing to do would be to leave seccomp mode 1 alone
and introduce a mode 2 with a less restricted set of system calls -- the
interface was designed to be extended in this way, after all.

-- 
Nicholas Miell <nmiell@comcast.net>

WARNING: multiple messages have this Message-ID (diff)
From: Nicholas Miell <nmiell@comcast.net>
To: "Markus Gutschke (顧孟勤)" <markus@google.com>
Cc: linux-mips@linux-mips.org, x86@kernel.org,
	linux-kernel@vger.kernel.org, stable@kernel.org,
	linuxppc-dev@ozlabs.org, sparclinux@vger.kernel.org,
	Ingo Molnar <mingo@elte.hu>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Roland McGrath <roland@redhat.com>
Subject: Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
Date: Wed, 06 May 2009 21:23:57 -0700	[thread overview]
Message-ID: <1241670237.11500.7.camel@entropy> (raw)
In-Reply-To: <904b25810905061521v62b3ddd6l14deb614d203385a@mail.gmail.com>

On Wed, 2009-05-06 at 15:21 -0700, Markus Gutschke (顧孟勤) wrote:
> On Wed, May 6, 2009 at 15:13, Ingo Molnar <mingo@elte.hu> wrote:
> > doing a (per arch) bitmap of harmless syscalls and replacing the
> > mode1_syscalls[] check with that in kernel/seccomp.c would be a
> > pretty reasonable extension. (.config controllable perhaps, for
> > old-style-seccomp)
> >
> > It would probably be faster than the current loop over
> > mode1_syscalls[] as well.
> 
> This would be a great option to improve performance of our sandbox. I
> can detect the availability of the new kernel API dynamically, and
> then not intercept the bulk of the system calls. This would allow the
> sandbox to work both with existing and with newer kernels.
> 
> We'll post a kernel patch for discussion in the next few days,
> 

I suspect the correct thing to do would be to leave seccomp mode 1 alone
and introduce a mode 2 with a less restricted set of system calls -- the
interface was designed to be extended in this way, after all.

-- 
Nicholas Miell <nmiell@comcast.net>

WARNING: multiple messages have this Message-ID (diff)
From: Nicholas Miell <nmiell@comcast.net>
To: "Markus Gutschke (顧孟勤)" <markus@google.com>
Cc: Ingo Molnar <mingo@elte.hu>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Roland McGrath <roland@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	x86@kernel.org, linux-kernel@vger.kernel.org, stable@kernel.org,
	linux-mips@linux-mips.org, sparclinux@vger.kernel.org,
	linuxppc-dev@ozlabs.org
Subject: Re: [PATCH 2/2] x86-64: seccomp: fix 32/64 syscall hole
Date: Thu, 07 May 2009 04:23:57 +0000	[thread overview]
Message-ID: <1241670237.11500.7.camel@entropy> (raw)
In-Reply-To: <904b25810905061521v62b3ddd6l14deb614d203385a@mail.gmail.com>

On Wed, 2009-05-06 at 15:21 -0700, Markus Gutschke (顧孟勤) wrote:
> On Wed, May 6, 2009 at 15:13, Ingo Molnar <mingo@elte.hu> wrote:
> > doing a (per arch) bitmap of harmless syscalls and replacing the
> > mode1_syscalls[] check with that in kernel/seccomp.c would be a
> > pretty reasonable extension. (.config controllable perhaps, for
> > old-style-seccomp)
> >
> > It would probably be faster than the current loop over
> > mode1_syscalls[] as well.
> 
> This would be a great option to improve performance of our sandbox. I
> can detect the availability of the new kernel API dynamically, and
> then not intercept the bulk of the system calls. This would allow the
> sandbox to work both with existing and with newer kernels.
> 
> We'll post a kernel patch for discussion in the next few days,
> 

I suspect the correct thing to do would be to leave seccomp mode 1 alone
and introduce a mode 2 with a less restricted set of system calls -- the
interface was designed to be extended in this way, after all.

-- 
Nicholas Miell <nmiell@comcast.net>


  reply	other threads:[~2009-05-07  4:24 UTC|newest]

Thread overview: 84+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-28  3:02 [PATCH 0/2] x86-64: 32/64 syscall arch holes Roland McGrath
2009-02-28  3:03 ` [PATCH 1/2] x86-64: syscall-audit: fix 32/64 syscall hole Roland McGrath
2009-02-28  3:04 ` [PATCH 2/2] x86-64: seccomp: " Roland McGrath
2009-02-28  3:36   ` Linus Torvalds
2009-02-28  3:52     ` Linus Torvalds
2009-02-28  4:46       ` Ingo Molnar
2009-02-28  7:25       ` Roland McGrath
2009-02-28  7:25         ` Roland McGrath
2009-02-28  7:25         ` Roland McGrath
2009-02-28  7:31         ` Ingo Molnar
2009-02-28  7:31           ` Ingo Molnar
2009-02-28  7:31           ` Ingo Molnar
2009-02-28  7:36           ` Roland McGrath
2009-02-28  7:36             ` Roland McGrath
2009-02-28  7:36             ` Roland McGrath
2009-02-28 17:23         ` Linus Torvalds
2009-02-28 17:23           ` Linus Torvalds
2009-02-28 17:23           ` Linus Torvalds
2009-02-28 17:46           ` [stable] " Greg KH
2009-02-28 17:46             ` Greg KH
2009-02-28 17:46             ` Greg KH
2009-02-28 17:54             ` Arjan van de Ven
2009-02-28 17:54               ` Arjan van de Ven
2009-02-28 17:54               ` Arjan van de Ven
2009-02-28 18:23               ` Greg KH
2009-02-28 18:23                 ` Greg KH
2009-02-28 18:23                 ` Greg KH
2009-02-28 20:27                 ` Greg KH
2009-02-28 20:27                   ` Greg KH
2009-02-28 21:09           ` Benjamin Herrenschmidt
2009-02-28 21:09             ` Benjamin Herrenschmidt
2009-02-28 21:09             ` Benjamin Herrenschmidt
2009-03-02  1:44           ` Roland McGrath
2009-03-02  1:44             ` Roland McGrath
2009-03-02  1:44             ` Roland McGrath
2009-05-06 18:42           ` Markus Gutschke
2009-05-06 18:42             ` Markus Gutschke
2009-05-06 18:46           ` Markus Gutschke (顧孟勤)
2009-05-06 18:46             ` 
2009-05-06 18:46             ` Markus Gutschke (顧孟勤)
2009-05-06 21:29             ` Ingo Molnar
2009-05-06 21:29               ` Ingo Molnar
2009-05-06 21:29               ` Ingo Molnar
2009-05-06 21:46               ` Markus Gutschke (顧孟勤)
2009-05-06 21:46                 ` 
2009-05-06 21:46                 ` Markus Gutschke (顧孟勤)
2009-05-06 21:54                 ` Ingo Molnar
2009-05-06 21:54                   ` Ingo Molnar
2009-05-06 21:54                   ` Ingo Molnar
2009-05-06 22:08                   ` Markus Gutschke (顧孟勤)
2009-05-06 22:08                     ` 
2009-05-06 22:08                     ` Markus Gutschke (顧孟勤)
2009-05-06 22:13                     ` Ingo Molnar
2009-05-06 22:13                       ` Ingo Molnar
2009-05-06 22:13                       ` Ingo Molnar
2009-05-06 22:21                       ` Markus Gutschke (顧孟勤)
2009-05-06 22:21                         ` 
2009-05-06 22:21                         ` Markus Gutschke (顧孟勤)
2009-05-07  4:23                         ` Nicholas Miell [this message]
2009-05-07  4:23                           ` Nicholas Miell
2009-05-07  4:23                           ` Nicholas Miell
2009-05-07 10:11                           ` Ingo Molnar
2009-05-07 10:11                             ` Ingo Molnar
2009-05-07 10:11                             ` Ingo Molnar
2009-05-10  5:37                             ` Pavel Machek
2009-05-10  5:37                               ` Pavel Machek
2009-05-10  5:37                               ` Pavel Machek
2009-05-08 19:18                     ` Andi Kleen
2009-05-08 19:18                       ` Andi Kleen
2009-05-08 19:18                       ` Andi Kleen
2009-05-07  7:03                 ` Roland McGrath
2009-05-07  7:03                   ` Roland McGrath
2009-05-07  8:01                   ` Markus Gutschke (顧孟勤)
2009-05-07  8:01                     ` 
2009-05-07  8:01                     ` Markus Gutschke (顧孟勤)
2009-05-07  7:30                 ` Roland McGrath
2009-05-07  7:30                   ` Roland McGrath
2009-05-07  7:30                   ` Roland McGrath
2009-05-07  7:31                 ` Roland McGrath
2009-05-07  7:31                   ` Roland McGrath
2009-05-07  7:31                   ` Roland McGrath
2009-05-07  7:31                   ` Roland McGrath
2009-05-08  1:59                   ` David Wagner
2009-05-10  5:36                     ` Pavel Machek

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=1241670237.11500.7.camel@entropy \
    --to=nmiell@comcast.net \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=markus@google.com \
    --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 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.