Patchwork [Oneiric,pull,request] SECCOMP syscall filtering

login
register
mail settings
Submitter Kees Cook
Date Aug. 4, 2011, 6:53 a.m.
Message ID <20110804065327.GW5255@outflux.net>
Download mbox
Permalink /patch/108350/
State New
Headers show

Pull-request

git://kernel.ubuntu.com/kees/ubuntu-oneiric.git master

Comments

Kees Cook - Aug. 4, 2011, 6:53 a.m.
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

 Documentation/prctl/seccomp_filter.txt    |  189 +++++
 arch/arm/Kconfig                          |    1 +
 arch/x86/Kconfig                          |    1 +
 arch/x86/include/asm/ia32_unistd.h        |    1 +
 arch/x86/include/asm/seccomp_64.h         |    2 +
 debian.master/config/config.common.ubuntu |    2 +
 fs/proc/base.c                            |   31 +
 include/linux/init_task.h                 |   12 +
 include/linux/prctl.h                     |    7 +
 include/linux/sched.h                     |    2 +-
 include/linux/seccomp.h                   |  119 ++++-
 kernel/Makefile                           |    1 +
 kernel/fork.c                             |    4 +
 kernel/seccomp.c                          |   38 +-
 kernel/seccomp_filter.c                   | 1058 +++++++++++++++++++++++++++++
 kernel/sys.c                              |   12 +
 security/Kconfig                          |   17 +
 17 files changed, 1484 insertions(+), 13 deletions(-)
 create mode 100644 Documentation/prctl/seccomp_filter.txt
 create mode 100644 kernel/seccomp_filter.c

This is the "seccomp syscall filtering" subsystem that is expected to
be used by Chromium, vsftpd, openssh, qemu, lxc, and others[1]. It has
been stalled getting into mainline, but is a welcome new programmatic
opt-in security hardening feature.

Note, I have not build tested this myself yet, as tangerine's host key has
changed and I'm travelling for a conference. I wanted to get eyes on it
ASAP since feature freeze is next week.

Thanks!

-Kees

[1] http://lwn.net/Articles/450291/
Andy Whitcroft - Aug. 8, 2011, 5:29 p.m.
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).

-apw
Leann Ogasawara - Aug. 11, 2011, 6:04 p.m.
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
Kees Cook - Aug. 11, 2011, 7:08 p.m.
Hi Leann,

On Thu, Aug 11, 2011 at 11:04:02AM -0700, Leann Ogasawara wrote:
> 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.

Upstream gave Will a multi-month run-around, so while this functionality
may go upstream eventually, it probably won't be soon. I'm hoping to
break a chicken-and-egg problem by having this interface available in
Ubuntu (matching ChromeOS) so that all the folks that wanted to use it
will have a stable Ubuntu release soon to play with it in.

Since the feature doesn't change default process behavior, and is really
just a container "enhancement", I feel like the risk of carrying it is
low and the disruption level of suddenly tearing it out is low, it's only
a win to have it.

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

I have not done testing of it yet. I know Will has done a fair bit though.

-Kees
Will Drewry - Aug. 12, 2011, 9:09 p.m.
On Thu, Aug 11, 2011 at 2:08 PM, Kees Cook <kees.cook@canonical.com> wrote:
> Hi Leann,
>
> On Thu, Aug 11, 2011 at 11:04:02AM -0700, Leann Ogasawara wrote:
>> 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.
>
> Upstream gave Will a multi-month run-around, so while this functionality
> may go upstream eventually, it probably won't be soon. I'm hoping to
> break a chicken-and-egg problem by having this interface available in
> Ubuntu (matching ChromeOS) so that all the folks that wanted to use it
> will have a stable Ubuntu release soon to play with it in.
>
> Since the feature doesn't change default process behavior, and is really
> just a container "enhancement", I feel like the risk of carrying it is
> low and the disruption level of suddenly tearing it out is low, it's only
> a win to have it.

Thanks - this is how we're looking at it with CrOS too.  I've tried to
centralize as much as possible in seccomp_filter.c to minimize some of
the future management and porting pain.  In theory, this interface
will lay quite easily on a future (next year at best, I suspect)
ftrace-based active, per-process event mechanism.

If there is interest in carrying it, I will certainly ensure that any
Chromium patches provide support detection such that ubuntu users also
get a better kernel-supported sandbox for their renderers than is
possible today.

>> Also, Kees, have you done any specific testing of these patches?
>
> I have not done testing of it yet. I know Will has done a fair bit though.

Yes, and it seems robust on x86, but I'm running into a few challenges
on ARM that will require a few small-ish tweaks (as I start to send
patches to enable CONFIG_FTRACE_SYSCALLS on arm).

I'm not 100% aware of your kernel release cycle, so I can't provide
any helpful commentary there.

Thanks for the consideration!
will
Andy Whitcroft - Aug. 12, 2011, 10 p.m.
On Fri, Aug 12, 2011 at 04:09:31PM -0500, Will Drewry wrote:
> On Thu, Aug 11, 2011 at 2:08 PM, Kees Cook <kees.cook@canonical.com> wrote:

> > Upstream gave Will a multi-month run-around, so while this functionality
> > may go upstream eventually, it probably won't be soon. I'm hoping to
> > break a chicken-and-egg problem by having this interface available in
> > Ubuntu (matching ChromeOS) so that all the folks that wanted to use it
> > will have a stable Ubuntu release soon to play with it in.
> >
> > Since the feature doesn't change default process behavior, and is really
> > just a container "enhancement", I feel like the risk of carrying it is
> > low and the disruption level of suddenly tearing it out is low, it's only
> > a win to have it.
[...]
> If there is interest in carrying it, I will certainly ensure that any
> Chromium patches provide support detection such that ubuntu users also
> get a better kernel-supported sandbox for their renderers than is
> possible today.

If we are going to get get better security in chromium on Ubuntu that is
probabally something that is worth the pain of carrying these patches.
There was no performance hit for the regular case.

-apw
Leann Ogasawara - Aug. 17, 2011, 8:28 p.m.
On Fri, 2011-08-12 at 16:09 -0500, Will Drewry wrote:
> On Thu, Aug 11, 2011 at 2:08 PM, Kees Cook <kees.cook@canonical.com> wrote:
> > Hi Leann,
> >
> > On Thu, Aug 11, 2011 at 11:04:02AM -0700, Leann Ogasawara wrote:
> >> 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.
> >
> > Upstream gave Will a multi-month run-around, so while this functionality
> > may go upstream eventually, it probably won't be soon. I'm hoping to
> > break a chicken-and-egg problem by having this interface available in
> > Ubuntu (matching ChromeOS) so that all the folks that wanted to use it
> > will have a stable Ubuntu release soon to play with it in.
> >
> > Since the feature doesn't change default process behavior, and is really
> > just a container "enhancement", I feel like the risk of carrying it is
> > low and the disruption level of suddenly tearing it out is low, it's only
> > a win to have it.
> 
> Thanks - this is how we're looking at it with CrOS too.  I've tried to
> centralize as much as possible in seccomp_filter.c to minimize some of
> the future management and porting pain.  In theory, this interface
> will lay quite easily on a future (next year at best, I suspect)
> ftrace-based active, per-process event mechanism.
> 
> If there is interest in carrying it, I will certainly ensure that any
> Chromium patches provide support detection such that ubuntu users also
> get a better kernel-supported sandbox for their renderers than is
> possible today.
> 
> >> Also, Kees, have you done any specific testing of these patches?
> >
> > I have not done testing of it yet. I know Will has done a fair bit though.
> 
> Yes, and it seems robust on x86, but I'm running into a few challenges
> on ARM that will require a few small-ish tweaks (as I start to send
> patches to enable CONFIG_FTRACE_SYSCALLS on arm).

Kees, I'm seeing some build failures doing a quick test build on ARM
[1].  Did you want to disable on ARM for now or did you want to try and
fix up these failures?  Either way, care to send an updated pull request
to either fix up the build failures or disable for ARM.

Thanks,
Leann

[1]
kernel/seccomp.c: In function '__secure_computing':
kernel/seccomp.c:55:23: error: 'NR_syscalls' undeclared (first use in this function)
kernel/seccomp.c:55:23: note: each undeclared identifier is reported only once for each function it appears in
make[3]: *** [kernel/seccomp.o] Error 1
make[3]: *** Waiting for unfinished jobs....
...
kernel/seccomp_filter.c:34:25: fatal error: asm/syscall.h: No such file or directory
compilation terminated.
make[3]: *** [kernel/seccomp_filter.o] Error 1
Will Drewry - Aug. 17, 2011, 8:49 p.m.
On Wed, Aug 17, 2011 at 3:28 PM, Leann Ogasawara
<leann.ogasawara@canonical.com> wrote:
> On Fri, 2011-08-12 at 16:09 -0500, Will Drewry wrote:
>> On Thu, Aug 11, 2011 at 2:08 PM, Kees Cook <kees.cook@canonical.com> wrote:
>> > Hi Leann,
>> >
>> > On Thu, Aug 11, 2011 at 11:04:02AM -0700, Leann Ogasawara wrote:
>> >> 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.
>> >
>> > Upstream gave Will a multi-month run-around, so while this functionality
>> > may go upstream eventually, it probably won't be soon. I'm hoping to
>> > break a chicken-and-egg problem by having this interface available in
>> > Ubuntu (matching ChromeOS) so that all the folks that wanted to use it
>> > will have a stable Ubuntu release soon to play with it in.
>> >
>> > Since the feature doesn't change default process behavior, and is really
>> > just a container "enhancement", I feel like the risk of carrying it is
>> > low and the disruption level of suddenly tearing it out is low, it's only
>> > a win to have it.
>>
>> Thanks - this is how we're looking at it with CrOS too.  I've tried to
>> centralize as much as possible in seccomp_filter.c to minimize some of
>> the future management and porting pain.  In theory, this interface
>> will lay quite easily on a future (next year at best, I suspect)
>> ftrace-based active, per-process event mechanism.
>>
>> If there is interest in carrying it, I will certainly ensure that any
>> Chromium patches provide support detection such that ubuntu users also
>> get a better kernel-supported sandbox for their renderers than is
>> possible today.
>>
>> >> Also, Kees, have you done any specific testing of these patches?
>> >
>> > I have not done testing of it yet. I know Will has done a fair bit though.
>>
>> Yes, and it seems robust on x86, but I'm running into a few challenges
>> on ARM that will require a few small-ish tweaks (as I start to send
>> patches to enable CONFIG_FTRACE_SYSCALLS on arm).
>
> Kees, I'm seeing some build failures doing a quick test build on ARM
> [1].  Did you want to disable on ARM for now or did you want to try and
> fix up these failures?  Either way, care to send an updated pull request
> to either fix up the build failures or disable for ARM.
>
> Thanks,
> Leann
>
> [1]
> kernel/seccomp.c: In function '__secure_computing':
> kernel/seccomp.c:55:23: error: 'NR_syscalls' undeclared (first use in this function)
> kernel/seccomp.c:55:23: note: each undeclared identifier is reported only once for each function it appears in
> make[3]: *** [kernel/seccomp.o] Error 1
> make[3]: *** Waiting for unfinished jobs....
> ...
> kernel/seccomp_filter.c:34:25: fatal error: asm/syscall.h: No such file or directory
> compilation terminated.
> make[3]: *** [kernel/seccomp_filter.o] Error 1

Yup - it's broken on ARM.  My apologies!

While I proposed wiring up NR_syscalls upstream yesterday,  it uses
syscall numbers as indices like ftrace_syscalls does which is not ARM
friendly.  I am testing out a larger change to the patch to remove all
references to NR_syscalls unless CONFIG_FTRACE_SYSCALLS is enabled.  I
hope to have a better version available quite shortly.  I had failed
to notice that I broke all these other platforms during the patchset
churn on LKML.

Sorry for the breakage!
will
Kees Cook - Aug. 18, 2011, 5:46 p.m.
Hi,

On Wed, Aug 17, 2011 at 03:49:20PM -0500, Will Drewry wrote:
> On Wed, Aug 17, 2011 at 3:28 PM, Leann Ogasawara
> <leann.ogasawara@canonical.com> wrote:
> > Kees, I'm seeing some build failures doing a quick test build on ARM
> > [1].  Did you want to disable on ARM for now or did you want to try and
> > fix up these failures?  Either way, care to send an updated pull request
> > to either fix up the build failures or disable for ARM.
> >
> > Thanks,
> > Leann
> >
> > [1]
> > kernel/seccomp.c: In function '__secure_computing':
> > kernel/seccomp.c:55:23: error: 'NR_syscalls' undeclared (first use in this function)
> > kernel/seccomp.c:55:23: note: each undeclared identifier is reported only once for each function it appears in
> > make[3]: *** [kernel/seccomp.o] Error 1
> > make[3]: *** Waiting for unfinished jobs....
> > ...
> > kernel/seccomp_filter.c:34:25: fatal error: asm/syscall.h: No such file or directory
> > compilation terminated.
> > make[3]: *** [kernel/seccomp_filter.o] Error 1
> 
> Yup - it's broken on ARM.  My apologies!
> 
> While I proposed wiring up NR_syscalls upstream yesterday,  it uses
> syscall numbers as indices like ftrace_syscalls does which is not ARM
> friendly.  I am testing out a larger change to the patch to remove all
> references to NR_syscalls unless CONFIG_FTRACE_SYSCALLS is enabled.  I
> hope to have a better version available quite shortly.  I had failed
> to notice that I broke all these other platforms during the patchset
> churn on LKML.

For Oneiric, since we're pretty late, let's disable ARM. The new
syscall numbering will happen later, and we can update the patch then
(in Oneiric+1). The interface is the same, it'll just include
additional architecture support.

I'll prepare an updated pull.

Thanks!

-Kees