[Oneiric][pull request] SECCOMP syscall filtering

[Leann Ogasawara]

On Mon, 2011-08-08 at 18:29 +0100, Andy Whitcroft wrote:
> On Wed, Aug 03, 2011 at 11:53:27PM -0700, Kees Cook wrote:
> > The following changes since commit 12bf0a5416335a051be56978f8f87a2eaec143b2:
> > 
> >   UBUNTU: Ubuntu-3.0.0-7.9 (2011-07-29 08:51:10 -0700)
> > 
> > are available in the git repository at:
> >   git://kernel.ubuntu.com/kees/ubuntu-oneiric.git master
> > 
> > Kees Cook (1):
> >       UBUNTU: [Config] enable SECCOMP_FILTER for x86 and arm
> > 
> > Will Drewry (5):
> >       UBUNTU: SAUCE: CHROMIUM: seccomp_filter: new mode with configurable syscall filters
> >       UBUNTU: SAUCE: CHROMIUM: seccomp_filter: add process state reporting
> >       UBUNTU: SAUCE: CHROMIUM: seccomp_filter: Document what seccomp_filter is and how it works.
> >       UBUNTU: SAUCE: CHROMIUM: x86: add HAVE_SECCOMP_FILTER and seccomp_execve
> >       UBUNTU: SAUCE: CHROMIUM: arm: select HAVE_SECCOMP_FILTER
> 
> This branch looks ok in principle.  The effect is only enabled for
> processes for which specific enabling action is taken.  The cost for
> a non-enabled case is unchanged, leveraging the same check used for the
> SECCOMP mode 1.  The patches do make some pretty large controls structures
> for processes for which they are enabled.
> 
> Overall my biggest concern is that these are pretty large, and we do not
> yet know if they are going to make it upstream as they are (I believe).

I have to share Andy's concern here.  Kees, Will, what's the outlook for
these hitting v3.1?  It seems like it might be best to queue these in
the early stages of the P-cycle to allow more time for these to firm up
with upstream.

Also, Kees, have you done any specific testing of these patches?

Thanks,
Leann