ARM audit, seccomp, etc are broken wrt OABI syscalls

ARM audit, seccomp, etc are broken wrt OABI syscalls

[Andy Lutomirski]

[cc: some ARM people]

After a bit of an adventure, I got QEMU working.  (Linux 3.12's smc91x
driver and qemu 1.6 don't get along.  It would be great if some
kernel.org page described a standard way to boot a modern Linux image
on a modern QEMU version, but I digress.)

The current state of affairs is unhealthy.  I wrote a program
(attached) that does 'svc $0x90002f' (silly GNU syntax for "Issue the
getgid syscall in OABI").  The registers I program are:

r0: 1
r1: 2
r2: 3
r3: 4
r4: 5
r5: 6

(i.e. the arguments are 1,2,3,4,5,6, although getgid ignores them)

r7: 1

(r7 is the EABI syscall register.  On a kernel without OABI support,
the immediate svc argument is ignored and syscall 1, i.e. _exit, will
be invoked).

Seccomp sees the registers as I set them (unsurprisingly) and it sees
nr == 0x2f.  It passes those values on to a SIGSYS handler, if one
exists.  This is, IMO, bad.  The OABI and EABI argument passing
conventions are *not* the same, and seccomp filters that check syscall
argument values may be spoofable by using OABI calls.

I suspect that audit, perf, ftrace, and maybe even ptrace are broken
as well for exactly the same reason.

I would argue that there are two reasonable fixes:

1. Set a different audit arch for OABI syscalls (e.g.
AUDIT_ARCH_ARMOABI).  That is, treat OABI syscall entries the same way
that x86_64 treats int 80.

2. Leave the 0x900000 bits set in the syscall nr.  That way OABI
syscalls would look like a different set of syscalls on the same
architecture.  That is, treat OABI syscall entries kind of like x86_64
treats x32 syscalls.  (There's probably no reason to accept 0x900000 +
N as an r7 value to cause 'svc 0' to invoke OABI syscall N, though.)

3. Unconditionally kill any process that makes an OABI syscall with
seccomp enabled (because there should be no such programs).  Eww.

Options 1 and 2 are both break ABI, but I doubt that anythink cares.
OABI is, AFAICT, mostly dead.  That being said, even if nothing
legitimate uses OABI, exploits against seccomp-using programs can
certainly use OABI, so I think that this needs to be fixed somehow.

Thoughts?  I think I prefer option 1.  I don't really want to make the
change because my ARM assembly skills are lacking.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: seccomp_oabi.c
Type: text/x-csrc
Size: 2375 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131105/5e363192/attachment.bin>

ARM audit, seccomp, etc are broken wrt OABI syscalls

[Kees Cook]

On Tue, Nov 5, 2013 at 2:36 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> [cc: some ARM people]
>
> After a bit of an adventure, I got QEMU working.  (Linux 3.12's smc91x
> driver and qemu 1.6 don't get along.  It would be great if some
> kernel.org page described a standard way to boot a modern Linux image
> on a modern QEMU version, but I digress.)

Yeah, I kept losing this battle too, and most recently switch to using
mmc emulation instead of the SCSI emulation (CONFIG_MMC=y, and qemu's
"sd" disk driver).

> The current state of affairs is unhealthy.  I wrote a program
> (attached) that does 'svc $0x90002f' (silly GNU syntax for "Issue the
> getgid syscall in OABI").  The registers I program are:
>
> r0: 1
> r1: 2
> r2: 3
> r3: 4
> r4: 5
> r5: 6
>
> (i.e. the arguments are 1,2,3,4,5,6, although getgid ignores them)
>
> r7: 1
>
> (r7 is the EABI syscall register.  On a kernel without OABI support,
> the immediate svc argument is ignored and syscall 1, i.e. _exit, will
> be invoked).

Just to clarify: without CONFIG_OABI_COMPAT, all OABI syscalls turn into _exit?

> Seccomp sees the registers as I set them (unsurprisingly) and it sees
> nr == 0x2f.  It passes those values on to a SIGSYS handler, if one
> exists.  This is, IMO, bad.  The OABI and EABI argument passing
> conventions are *not* the same, and seccomp filters that check syscall
> argument values may be spoofable by using OABI calls.
>
> I suspect that audit, perf, ftrace, and maybe even ptrace are broken
> as well for exactly the same reason.
>
> I would argue that there are two reasonable fixes:
>
> 1. Set a different audit arch for OABI syscalls (e.g.
> AUDIT_ARCH_ARMOABI).  That is, treat OABI syscall entries the same way
> that x86_64 treats int 80.
>
> 2. Leave the 0x900000 bits set in the syscall nr.  That way OABI
> syscalls would look like a different set of syscalls on the same
> architecture.  That is, treat OABI syscall entries kind of like x86_64
> treats x32 syscalls.  (There's probably no reason to accept 0x900000 +
> N as an r7 value to cause 'svc 0' to invoke OABI syscall N, though.)
>
> 3. Unconditionally kill any process that makes an OABI syscall with
> seccomp enabled (because there should be no such programs).  Eww.
>
> Options 1 and 2 are both break ABI, but I doubt that anythink cares.
> OABI is, AFAICT, mostly dead.  That being said, even if nothing
> legitimate uses OABI, exploits against seccomp-using programs can
> certainly use OABI, so I think that this needs to be fixed somehow.
>
> Thoughts?  I think I prefer option 1.  I don't really want to make the
> change because my ARM assembly skills are lacking.

I would agree: option 1 seems cleanest of the 3. 3 is sort of like a
built-in automatic check for a mismatched arch, so maybe that works
better?

Alternatively, CONFIG_SECCOMP_FILTER could depend on
!CONFIG_OABI_COMPAT. That seems like the least work, given the desire
to kill OABI in the real world. (Though I would note that at least
Ubuntu's ARM kernels build with CONFIG_OABI_COMPAT; Chrome OS does
not.)

-Kees

-- 
Kees Cook
Chrome OS Security

ARM audit, seccomp, etc are broken wrt OABI syscalls

[Russell King - ARM Linux]

On Tue, Nov 05, 2013 at 04:14:49PM -0800, Kees Cook wrote:
> I would agree: option 1 seems cleanest of the 3. 3 is sort of like a
> built-in automatic check for a mismatched arch, so maybe that works
> better?
> 
> Alternatively, CONFIG_SECCOMP_FILTER could depend on
> !CONFIG_OABI_COMPAT. That seems like the least work, given the desire
> to kill OABI in the real world. (Though I would note that at least
> Ubuntu's ARM kernels build with CONFIG_OABI_COMPAT; Chrome OS does
> not.)

OABI compat is really only something you want to deal with if you have
a reason to run OABI programs on the kernel; it is in no way guaranteed
that the OABI programs will run properly (many ALSA programs will not
because of different layouts with ioctls).

OABI compat was meant to allow a transition from OABI to EABI.  While
a lot of effort went in to the kernel side of that, which does allow
OABI based userspace to boot with an EABI kernel, and allows OABI built
test programs to run under an EABI kernel, actually being able to
migrate userland is far from trivial - and something that I've never
been able to do.  Hence, virtually all my long-running ARM machines
here are stuck with OABI, and I don't see that situation ever changing.

As a rule, distros should not be enabling OABI compat.  OABI compat
is more something that a developer (like me) who has a reason to enable
it turns it on.

ARM audit, seccomp, etc are broken wrt OABI syscalls

[Andy Lutomirski]

On Tue, Nov 5, 2013 at 4:40 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Nov 05, 2013 at 04:14:49PM -0800, Kees Cook wrote:
>> I would agree: option 1 seems cleanest of the 3. 3 is sort of like a
>> built-in automatic check for a mismatched arch, so maybe that works
>> better?
>>
>> Alternatively, CONFIG_SECCOMP_FILTER could depend on
>> !CONFIG_OABI_COMPAT. That seems like the least work, given the desire
>> to kill OABI in the real world. (Though I would note that at least
>> Ubuntu's ARM kernels build with CONFIG_OABI_COMPAT; Chrome OS does
>> not.)
>
> OABI compat is really only something you want to deal with if you have
> a reason to run OABI programs on the kernel; it is in no way guaranteed
> that the OABI programs will run properly (many ALSA programs will not
> because of different layouts with ioctls).
>
> OABI compat was meant to allow a transition from OABI to EABI.  While
> a lot of effort went in to the kernel side of that, which does allow
> OABI based userspace to boot with an EABI kernel, and allows OABI built
> test programs to run under an EABI kernel, actually being able to
> migrate userland is far from trivial - and something that I've never
> been able to do.  Hence, virtually all my long-running ARM machines
> here are stuck with OABI, and I don't see that situation ever changing.
>
> As a rule, distros should not be enabling OABI compat.  OABI compat
> is more something that a developer (like me) who has a reason to enable
> it turns it on.

So I guess that audit, ptrace, etc. work on OABI because the userspace
tools expect the OABI syscall conventions and they work on EABI for
the same reason, everything is subtly broken on OABI compat.  Adding a
new AUDIT_ARCH_ARMOABI is probably bad, then, unless it only applies
to OABI compat kernels.  Similarly, bumping the syscall numbers is
probably also bad.  (Arguably the audit arch should have been
AUDIT_ARCH_ARMEABI from the beginning -- too late now.)

Maybe the thing to do is to put a warning in the config text for
CONFIG_OABI_COMPAT that describes the problems (malicious userspace
can confuse syscall auditors, strace, etc.), change the "if in doubt"
part to N, and disable seccomp filters if CONFIG_OABI_COMPAT.  That
might even get Debian to change their default.

--Andy

ARM audit, seccomp, etc are broken wrt OABI syscalls

[Henrique de Moraes Holschuh]

On Tue, 05 Nov 2013, Andy Lutomirski wrote:
> Maybe the thing to do is to put a warning in the config text for
> CONFIG_OABI_COMPAT that describes the problems (malicious userspace
> can confuse syscall auditors, strace, etc.), change the "if in doubt"
> part to N, and disable seccomp filters if CONFIG_OABI_COMPAT.  That
> might even get Debian to change their default.

Bug reported to the Debian BTS: #728975
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728975

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

ARM audit, seccomp, etc are broken wrt OABI syscalls

[Kees Cook]

On Thu, Nov 7, 2013 at 4:55 AM, Henrique de Moraes Holschuh
<hmh@hmh.eng.br> wrote:
> On Tue, 05 Nov 2013, Andy Lutomirski wrote:
>> Maybe the thing to do is to put a warning in the config text for
>> CONFIG_OABI_COMPAT that describes the problems (malicious userspace
>> can confuse syscall auditors, strace, etc.), change the "if in doubt"
>> part to N, and disable seccomp filters if CONFIG_OABI_COMPAT.  That
>> might even get Debian to change their default.
>
> Bug reported to the Debian BTS: #728975
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728975

FWIW, Ubuntu has also now disabled OABI_COMPAT going forward:
https://lists.ubuntu.com/archives/kernel-team/2013-November/034242.html

-Kees

-- 
Kees Cook
Chrome OS Security

ARM audit, seccomp, etc are broken wrt OABI syscalls

[Henrique de Moraes Holschuh]

On Thu, 07 Nov 2013, Kees Cook wrote:
> On Thu, Nov 7, 2013 at 4:55 AM, Henrique de Moraes Holschuh
> <hmh@hmh.eng.br> wrote:
> > On Tue, 05 Nov 2013, Andy Lutomirski wrote:
> >> Maybe the thing to do is to put a warning in the config text for
> >> CONFIG_OABI_COMPAT that describes the problems (malicious userspace
> >> can confuse syscall auditors, strace, etc.), change the "if in doubt"
> >> part to N, and disable seccomp filters if CONFIG_OABI_COMPAT.  That
> >> might even get Debian to change their default.
> >
> > Bug reported to the Debian BTS: #728975
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728975
> 
> FWIW, Ubuntu has also now disabled OABI_COMPAT going forward:
> https://lists.ubuntu.com/archives/kernel-team/2013-November/034242.html

Unless something very weird happens, it looks like that's also what Debian
will do.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

ARM audit, seccomp, etc are broken wrt OABI syscalls

[Mikael Pettersson]

Russell King - ARM Linux writes:
 > OABI compat was meant to allow a transition from OABI to EABI.  While
 > a lot of effort went in to the kernel side of that, which does allow
 > OABI based userspace to boot with an EABI kernel, and allows OABI built
 > test programs to run under an EABI kernel, actually being able to
 > migrate userland is far from trivial - and something that I've never
 > been able to do.  Hence, virtually all my long-running ARM machines
 > here are stuck with OABI, and I don't see that situation ever changing.

I did a live incremental upgrade from OABI to EABI on my systems years
ago.  What I did was to first patch my OABI glibc to look for .so files
in oabi/ subdirectories.  Then I moved all OABI .so files to oabi/
subdirectories, and deleted all OABI static .a libraries.  After that
it was "simply" a matter of rebuilding everything as EABI, in the right
order.  The main advantage over this compared to a bootstrap-from-scratch
(which I've done 4 times on different architectures) was that I had access
to fully functional utilities and build tools from the start.

I _might_ be able to locate the glibc patch I used; do you want it?

/Mikael

ARM audit, seccomp, etc are broken wrt OABI syscalls

[Matt Sealey]

On Tue, Nov 5, 2013 at 6:14 PM, Kees Cook <keescook@chromium.org> wrote:
>
> Alternatively, CONFIG_SECCOMP_FILTER could depend on
> !CONFIG_OABI_COMPAT. That seems like the least work, given the desire
> to kill OABI in the real world. (Though I would note that at least
> Ubuntu's ARM kernels build with CONFIG_OABI_COMPAT; Chrome OS does
> not.)

I think CONFIG_OABI_COMPAT probably leaked in from the original
configurations of the kernel taken from Debian.

There were several big decisions they made (build for ARMv5 soft
float, then switch to ARMv7 softfp, then switch to ARMv7 hardfp, then
switch to using THUMB2 kernels) which would have just broken OABI
binaries at every step of the way since they had some subtle
implications in kernel configuration (note: Ubuntu have never, ever
enabled FPA emulation in the kernel, and all Debian's OABI userspace
is built for FPA, for example. A good chunk of the original Debian arm
port probably would just pitch a SIGILL if you ran it under an Ubuntu
kernel).

I would ignore anyone who enables it in a distribution, since they
probably weren't intending to enable it in the first place, and never
noticed the.. what.. 3-4KiB it adds to the kernel?

Matt Sealey <neko@bakuhatsu.net>

ARM audit, seccomp, etc are broken wrt OABI syscalls

[Andy Lutomirski]

On Wed, Nov 6, 2013 at 2:30 PM, Matt Sealey <neko@bakuhatsu.net> wrote:
> On Tue, Nov 5, 2013 at 6:14 PM, Kees Cook <keescook@chromium.org> wrote:
>>
>> Alternatively, CONFIG_SECCOMP_FILTER could depend on
>> !CONFIG_OABI_COMPAT. That seems like the least work, given the desire
>> to kill OABI in the real world. (Though I would note that at least
>> Ubuntu's ARM kernels build with CONFIG_OABI_COMPAT; Chrome OS does
>> not.)
>
> I think CONFIG_OABI_COMPAT probably leaked in from the original
> configurations of the kernel taken from Debian.
>
> There were several big decisions they made (build for ARMv5 soft
> float, then switch to ARMv7 softfp, then switch to ARMv7 hardfp, then
> switch to using THUMB2 kernels) which would have just broken OABI
> binaries at every step of the way since they had some subtle
> implications in kernel configuration (note: Ubuntu have never, ever
> enabled FPA emulation in the kernel, and all Debian's OABI userspace
> is built for FPA, for example. A good chunk of the original Debian arm
> port probably would just pitch a SIGILL if you ran it under an Ubuntu
> kernel).
>
> I would ignore anyone who enables it in a distribution, since they
> probably weren't intending to enable it in the first place, and never
> noticed the.. what.. 3-4KiB it adds to the kernel?
>

Forget the size -- it adds a fair amount of complexity and a D-cache
miss on every syscall.

--Andy

[libseccomp-discuss] ARM audit, seccomp, etc are broken wrt OABI syscalls

[Eric Paris]

On Tue, 2013-11-05 at 14:36 -0800, Andy Lutomirski wrote:
> [cc: some ARM people]
> 
> After a bit of an adventure, I got QEMU working.  (Linux 3.12's smc91x
> driver and qemu 1.6 don't get along.  It would be great if some
> kernel.org page described a standard way to boot a modern Linux image
> on a modern QEMU version, but I digress.)
> 
> The current state of affairs is unhealthy.  I wrote a program
> (attached) that does 'svc $0x90002f' (silly GNU syntax for "Issue the
> getgid syscall in OABI").  The registers I program are:
> 
> r0: 1
> r1: 2
> r2: 3
> r3: 4
> r4: 5
> r5: 6
> 
> (i.e. the arguments are 1,2,3,4,5,6, although getgid ignores them)
> 
> r7: 1
> 
> (r7 is the EABI syscall register.  On a kernel without OABI support,
> the immediate svc argument is ignored and syscall 1, i.e. _exit, will
> be invoked).
> 
> Seccomp sees the registers as I set them (unsurprisingly) and it sees
> nr == 0x2f.  It passes those values on to a SIGSYS handler, if one
> exists.  This is, IMO, bad.  The OABI and EABI argument passing
> conventions are *not* the same, and seccomp filters that check syscall
> argument values may be spoofable by using OABI calls.
> 
> I suspect that audit, perf, ftrace, and maybe even ptrace are broken
> as well for exactly the same reason.
> 
> I would argue that there are two reasonable fixes:
> 
> 1. Set a different audit arch for OABI syscalls (e.g.
> AUDIT_ARCH_ARMOABI).  That is, treat OABI syscall entries the same way
> that x86_64 treats int 80.

As the audit maintainer, I like #1.  It might break ABI, but the ABI is
flat wrong now and not maintainable...

> 
> 2. Leave the 0x900000 bits set in the syscall nr.  That way OABI
> syscalls would look like a different set of syscalls on the same
> architecture.  That is, treat OABI syscall entries kind of like x86_64
> treats x32 syscalls.  (There's probably no reason to accept 0x900000 +
> N as an r7 value to cause 'svc 0' to invoke OABI syscall N, though.)
> 
> 3. Unconditionally kill any process that makes an OABI syscall with
> seccomp enabled (because there should be no such programs).  Eww.
> 
> Options 1 and 2 are both break ABI, but I doubt that anythink cares.
> OABI is, AFAICT, mostly dead.  That being said, even if nothing
> legitimate uses OABI, exploits against seccomp-using programs can
> certainly use OABI, so I think that this needs to be fixed somehow.
> 
> Thoughts?  I think I prefer option 1.  I don't really want to make the
> change because my ARM assembly skills are lacking.
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. Explore
> techniques for threading, error checking, porting, and tuning. Get the most 
> from the latest Intel processors and coprocessors. See abstracts and register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> libseccomp-discuss mailing list
> libseccomp-discuss at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/libseccomp-discuss

[libseccomp-discuss] ARM audit, seccomp, etc are broken wrt OABI syscalls

[Russell King - ARM Linux]

On Wed, Nov 06, 2013 at 10:32:31AM -0500, Eric Paris wrote:
> On Tue, 2013-11-05 at 14:36 -0800, Andy Lutomirski wrote:
> > 1. Set a different audit arch for OABI syscalls (e.g.
> > AUDIT_ARCH_ARMOABI).  That is, treat OABI syscall entries the same way
> > that x86_64 treats int 80.
> 
> As the audit maintainer, I like #1.  It might break ABI, but the ABI is
> flat wrong now and not maintainable...

If you read the whole thread, you will see that this corner case is just
not worth the effort to support.  Audit may as well be disabled by
kernel config if any OABI support is enabled.

[libseccomp-discuss] ARM audit, seccomp, etc are broken wrt OABI syscalls

[Will Drewry]

On Wed, Nov 6, 2013 at 9:51 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Nov 06, 2013 at 10:32:31AM -0500, Eric Paris wrote:
>> On Tue, 2013-11-05 at 14:36 -0800, Andy Lutomirski wrote:
>> > 1. Set a different audit arch for OABI syscalls (e.g.
>> > AUDIT_ARCH_ARMOABI).  That is, treat OABI syscall entries the same way
>> > that x86_64 treats int 80.
>>
>> As the audit maintainer, I like #1.  It might break ABI, but the ABI is
>> flat wrong now and not maintainable...
>
> If you read the whole thread, you will see that this corner case is just
> not worth the effort to support.  Audit may as well be disabled by
> kernel config if any OABI support is enabled.

This might be the best move for seccomp too (as Kees suggested).  I'd
love to have audit arch visibility, but it's not clear that it's worth
any sort of larger changes ...

... like adding a task_thread_info.compat flag that bubbles up to
syscall_get_arch(), or if we assume consumers of syscall_get_nr() are
broken today (I haven't checked), then it would be possible to at
least re-add the 0x900000 bits, if compat, before handing back the
system call number but leave the audit arch pieces alone.

[libseccomp-discuss] ARM audit, seccomp, etc are broken wrt OABI syscalls

[Kees Cook]

On Wed, Nov 6, 2013 at 1:20 PM, Will Drewry <wad@chromium.org> wrote:
> On Wed, Nov 6, 2013 at 9:51 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> On Wed, Nov 06, 2013 at 10:32:31AM -0500, Eric Paris wrote:
>>> On Tue, 2013-11-05 at 14:36 -0800, Andy Lutomirski wrote:
>>> > 1. Set a different audit arch for OABI syscalls (e.g.
>>> > AUDIT_ARCH_ARMOABI).  That is, treat OABI syscall entries the same way
>>> > that x86_64 treats int 80.
>>>
>>> As the audit maintainer, I like #1.  It might break ABI, but the ABI is
>>> flat wrong now and not maintainable...
>>
>> If you read the whole thread, you will see that this corner case is just
>> not worth the effort to support.  Audit may as well be disabled by
>> kernel config if any OABI support is enabled.
>
> This might be the best move for seccomp too (as Kees suggested).  I'd
> love to have audit arch visibility, but it's not clear that it's worth
> any sort of larger changes ...
>
> ... like adding a task_thread_info.compat flag that bubbles up to
> syscall_get_arch(), or if we assume consumers of syscall_get_nr() are
> broken today (I haven't checked), then it would be possible to at
> least re-add the 0x900000 bits, if compat, before handing back the
> system call number but leave the audit arch pieces alone.

How does this look, for the seccomp part?

-Kees

diff --git a/arch/Kconfig b/arch/Kconfig
index af2cc6eabcc7..3610c2d9910f 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -331,7 +331,7 @@ config HAVE_ARCH_SECCOMP_FILTER

 config SECCOMP_FILTER
        def_bool y
-       depends on HAVE_ARCH_SECCOMP_FILTER && SECCOMP && NET
+       depends on HAVE_ARCH_SECCOMP_FILTER && SECCOMP && NET && !OABI_COMPAT
        help
          Enable tasks to build secure computing environments defined
          in terms of Berkeley Packet Filter programs which implement


-- 
Kees Cook
Chrome OS Security

[libseccomp-discuss] ARM audit, seccomp, etc are broken wrt OABI syscalls

[Andy Lutomirski]

On Wed, Nov 6, 2013 at 1:26 PM, Kees Cook <keescook@chromium.org> wrote:
> On Wed, Nov 6, 2013 at 1:20 PM, Will Drewry <wad@chromium.org> wrote:
>> On Wed, Nov 6, 2013 at 9:51 AM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>> On Wed, Nov 06, 2013 at 10:32:31AM -0500, Eric Paris wrote:
>>>> On Tue, 2013-11-05 at 14:36 -0800, Andy Lutomirski wrote:
>>>> > 1. Set a different audit arch for OABI syscalls (e.g.
>>>> > AUDIT_ARCH_ARMOABI).  That is, treat OABI syscall entries the same way
>>>> > that x86_64 treats int 80.
>>>>
>>>> As the audit maintainer, I like #1.  It might break ABI, but the ABI is
>>>> flat wrong now and not maintainable...
>>>
>>> If you read the whole thread, you will see that this corner case is just
>>> not worth the effort to support.  Audit may as well be disabled by
>>> kernel config if any OABI support is enabled.
>>
>> This might be the best move for seccomp too (as Kees suggested).  I'd
>> love to have audit arch visibility, but it's not clear that it's worth
>> any sort of larger changes ...
>>
>> ... like adding a task_thread_info.compat flag that bubbles up to
>> syscall_get_arch(), or if we assume consumers of syscall_get_nr() are
>> broken today (I haven't checked), then it would be possible to at
>> least re-add the 0x900000 bits, if compat, before handing back the
>> system call number but leave the audit arch pieces alone.

That would fix the main issue, but I bet that no one will ever do
anything on the userspace side other than treating those syscalls like
any other unknown syscall.

>
> How does this look, for the seccomp part?
>
> -Kees
>
> diff --git a/arch/Kconfig b/arch/Kconfig
> index af2cc6eabcc7..3610c2d9910f 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -331,7 +331,7 @@ config HAVE_ARCH_SECCOMP_FILTER
>
>  config SECCOMP_FILTER
>         def_bool y
> -       depends on HAVE_ARCH_SECCOMP_FILTER && SECCOMP && NET
> +       depends on HAVE_ARCH_SECCOMP_FILTER && SECCOMP && NET && !OABI_COMPAT
>         help
>           Enable tasks to build secure computing environments defined
>           in terms of Berkeley Packet Filter programs which implement
>

Works for me.  Of course, I don't maintain any of this stuff, so I
don't have to deal with it :)

It's probably work adding some text either in CONFIG_SECCOMP_FILTER or
CONFIG_OABI_COMPAT explaining what the problem is.


FWIW, does syscall restart work with OABI_COMPAT?  I've never
understood the syscall restart mechanism, but x86 had an issue awhile
back when with sysenter vs. syscall that was kind of similar.

--Andy

[libseccomp-discuss] ARM audit, seccomp, etc are broken wrt OABI syscalls

[Russell King - ARM Linux]

On Wed, Nov 06, 2013 at 01:26:52PM -0800, Kees Cook wrote:
> On Wed, Nov 6, 2013 at 1:20 PM, Will Drewry <wad@chromium.org> wrote:
> > On Wed, Nov 6, 2013 at 9:51 AM, Russell King - ARM Linux
> > <linux@arm.linux.org.uk> wrote:
> >> On Wed, Nov 06, 2013 at 10:32:31AM -0500, Eric Paris wrote:
> >>> On Tue, 2013-11-05 at 14:36 -0800, Andy Lutomirski wrote:
> >>> > 1. Set a different audit arch for OABI syscalls (e.g.
> >>> > AUDIT_ARCH_ARMOABI).  That is, treat OABI syscall entries the same way
> >>> > that x86_64 treats int 80.
> >>>
> >>> As the audit maintainer, I like #1.  It might break ABI, but the ABI is
> >>> flat wrong now and not maintainable...
> >>
> >> If you read the whole thread, you will see that this corner case is just
> >> not worth the effort to support.  Audit may as well be disabled by
> >> kernel config if any OABI support is enabled.
> >
> > This might be the best move for seccomp too (as Kees suggested).  I'd
> > love to have audit arch visibility, but it's not clear that it's worth
> > any sort of larger changes ...
> >
> > ... like adding a task_thread_info.compat flag that bubbles up to
> > syscall_get_arch(), or if we assume consumers of syscall_get_nr() are
> > broken today (I haven't checked), then it would be possible to at
> > least re-add the 0x900000 bits, if compat, before handing back the
> > system call number but leave the audit arch pieces alone.
> 
> How does this look, for the seccomp part?

Looks correct, thanks.