Re: ARM audit, seccomp, etc are broken wrt OABI syscalls
On Thu, 07 Nov 2013, Kees Cook wrote: > On Thu, Nov 7, 2013 at 4:55 AM, Henrique de Moraes Holschuh > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ARM audit, seccomp, etc are broken wrt OABI syscalls
On Thu, Nov 7, 2013 at 4:55 AM, Henrique de Moraes Holschuh 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ARM audit, seccomp, etc are broken wrt OABI syscalls
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ARM audit, seccomp, etc are broken wrt OABI syscalls
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ARM audit, seccomp, etc are broken wrt OABI syscalls
On Thu, Nov 7, 2013 at 4:55 AM, Henrique de Moraes Holschuh h...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ARM audit, seccomp, etc are broken wrt OABI syscalls
On Thu, 07 Nov 2013, Kees Cook wrote: On Thu, Nov 7, 2013 at 4:55 AM, Henrique de Moraes Holschuh h...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ARM audit, seccomp, etc are broken wrt OABI syscalls
On Wed, Nov 6, 2013 at 2:30 PM, Matt Sealey wrote: > On Tue, Nov 5, 2013 at 6:14 PM, Kees Cook 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ARM audit, seccomp, etc are broken wrt OABI syscalls
On Tue, Nov 5, 2013 at 6:14 PM, Kees Cook 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [libseccomp-discuss] ARM audit, seccomp, etc are broken wrt OABI syscalls
On Wed, Nov 06, 2013 at 01:26:52PM -0800, Kees Cook wrote: > On Wed, Nov 6, 2013 at 1:20 PM, Will Drewry wrote: > > On Wed, Nov 6, 2013 at 9:51 AM, Russell King - ARM Linux > > 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 0x90 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [libseccomp-discuss] ARM audit, seccomp, etc are broken wrt OABI syscalls
On Wed, Nov 6, 2013 at 1:26 PM, Kees Cook wrote: > On Wed, Nov 6, 2013 at 1:20 PM, Will Drewry wrote: >> On Wed, Nov 6, 2013 at 9:51 AM, Russell King - ARM Linux >> 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 0x90 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [libseccomp-discuss] ARM audit, seccomp, etc are broken wrt OABI syscalls
On Wed, Nov 6, 2013 at 1:20 PM, Will Drewry wrote: > On Wed, Nov 6, 2013 at 9:51 AM, Russell King - ARM Linux > 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 0x90 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [libseccomp-discuss] ARM audit, seccomp, etc are broken wrt OABI syscalls
On Wed, Nov 6, 2013 at 9:51 AM, Russell King - ARM Linux 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 0x90 bits, if compat, before handing back the system call number but leave the audit arch pieces alone. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [libseccomp-discuss] ARM audit, seccomp, etc are broken wrt OABI syscalls
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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [libseccomp-discuss] ARM audit, seccomp, etc are broken wrt OABI syscalls
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 0x90 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 0x90 + > 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=/4140/ostg.clktrk > ___ > libseccomp-discuss mailing list > libseccomp-disc...@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/libseccomp-discuss -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ARM audit, seccomp, etc are broken wrt OABI syscalls
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ARM audit, seccomp, etc are broken wrt OABI syscalls
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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [libseccomp-discuss] ARM audit, seccomp, etc are broken wrt OABI syscalls
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 0x90 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 0x90 + 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=60136231iu=/4140/ostg.clktrk ___ libseccomp-discuss mailing list libseccomp-disc...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libseccomp-discuss -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [libseccomp-discuss] ARM audit, seccomp, etc are broken wrt OABI syscalls
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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [libseccomp-discuss] ARM audit, seccomp, etc are broken wrt OABI syscalls
On Wed, Nov 6, 2013 at 9:51 AM, Russell King - ARM Linux li...@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 0x90 bits, if compat, before handing back the system call number but leave the audit arch pieces alone. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [libseccomp-discuss] ARM audit, seccomp, etc are broken wrt OABI syscalls
On Wed, Nov 6, 2013 at 1:20 PM, Will Drewry w...@chromium.org wrote: On Wed, Nov 6, 2013 at 9:51 AM, Russell King - ARM Linux li...@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 0x90 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [libseccomp-discuss] ARM audit, seccomp, etc are broken wrt OABI syscalls
On Wed, Nov 6, 2013 at 1:26 PM, Kees Cook keesc...@chromium.org wrote: On Wed, Nov 6, 2013 at 1:20 PM, Will Drewry w...@chromium.org wrote: On Wed, Nov 6, 2013 at 9:51 AM, Russell King - ARM Linux li...@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 0x90 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [libseccomp-discuss] ARM audit, seccomp, etc are broken wrt OABI syscalls
On Wed, Nov 06, 2013 at 01:26:52PM -0800, Kees Cook wrote: On Wed, Nov 6, 2013 at 1:20 PM, Will Drewry w...@chromium.org wrote: On Wed, Nov 6, 2013 at 9:51 AM, Russell King - ARM Linux li...@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 0x90 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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ARM audit, seccomp, etc are broken wrt OABI syscalls
On Tue, Nov 5, 2013 at 6:14 PM, Kees Cook keesc...@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 n...@bakuhatsu.net -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ARM audit, seccomp, etc are broken wrt OABI syscalls
On Wed, Nov 6, 2013 at 2:30 PM, Matt Sealey n...@bakuhatsu.net wrote: On Tue, Nov 5, 2013 at 6:14 PM, Kees Cook keesc...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ARM audit, seccomp, etc are broken wrt OABI syscalls
On Tue, Nov 5, 2013 at 4:40 PM, Russell King - ARM Linux 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ARM audit, seccomp, etc are broken wrt OABI syscalls
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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ARM audit, seccomp, etc are broken wrt OABI syscalls
On Tue, Nov 5, 2013 at 2:36 PM, 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.) 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 0x90 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 0x90 + > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
ARM audit, seccomp, etc are broken wrt OABI syscalls
[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 0x90 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 0x90 +
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.
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#include
#include
#include
#ifndef __ARM_EABI__
#error Must be compiled for ARM EABI
#endif
struct seccomp_data {
int nr;
__u32 arch;
__u64 instruction_pointer;
__u64 args[6];
};
#ifndef PR_SET_NO_NEW_PRIVS
#define PR_SET_NO_NEW_PRIVS 38
#endif
#define SECCOMP_RET_KILL 0xU
#define SECCOMP_RET_TRAP 0x0003U
#define SECCOMP_RET_ERRNO 0x0005U
#define SECCOMP_RET_TRACE 0x7ff0U
#define SECCOMP_RET_ALLOW 0x7fffU
struct sifields_sigsys {
void *_call_addr;
int _syscall;
unsigned int _arch;
};
#define SIGINFO_SIGSYS(si) ((struct sifields_sigsys *)&(si)->_sifields)
__attribute__((noinline,optimize("2"))) long call_getgid_oabi(void)
{
// If OABI compatibility is disabled, this will call exit instead
// (That's what r7==1 means.)
register long ret asm("r0");
asm volatile("mov r0, $1\n\tmov r1, $2\n\tmov r2, $3\n\t"
"mov r3, $4\n\tmov r4, $5\n\tmov r5, $6\n\t"
"mov r7, $1\n\tsvc $0x90002f\n\t" : : :
"r0", "r1", "r2", "r3", "r4", "r5", "r6", "r7", "memory");
return ret;
}
void handler(int signum, siginfo_t *si, void *uc_void)
{
const struct ucontext *uc = uc_void;
const struct sifields_sigsys *ss = SIGINFO_SIGSYS(si);
printf("SIGSYS\n\n");
printf("nr: 0x%X (__NR_getgid = 0x%X, OABI nr = 0x90002F)\n",
ss->_syscall, __NR_getgid);
#define DO_REG(i) printf("r" #i ": 0x%08X\n", uc->uc_mcontext.arm_r##i);
DO_REG(0);
DO_REG(1);
DO_REG(2);
DO_REG(3);
DO_REG(4);
DO_REG(5);
DO_REG(6);
DO_REG(7);
}
int main()
{
int rc;
struct sock_filter filter[] = {
BPF_STMT(BPF_LD+BPF_W+BPF_ABS,
(offsetof(struct seccomp_data, nr))),
BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, __NR_getgid, 0, 1),
BPF_STMT(BPF_RET+BPF_K, SECCOMP_RET_TRAP),
BPF_STMT(BPF_RET+BPF_K, SECCOMP_RET_ALLOW),
};
struct sock_fprog prog = {
.len = (unsigned short)(sizeof(filter)/sizeof(filter[0])),
.filter = filter,
};
struct sigaction sa = {};
sa.sa_sigaction = handler;
sa.sa_flags = SA_SIGINFO;
if (sigaction(SIGSYS, , NULL) != 0)
err(1, "sigaction");
if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0))
err(1, "PR_SET_NO_NEW_PRIVS");
if (prctl(PR_SET_SECCOMP, 2, ))
err(1, "PR_SET_SECCOMP");
call_getgid_oabi();
return 0;
}
ARM audit, seccomp, etc are broken wrt OABI syscalls
[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 0x90 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 0x90 +
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.
#define _GNU_SOURCE
#include stdio.h
#include unistd.h
#include linux/filter.h
#include sys/syscall.h
#include err.h
#include sys/prctl.h
#include stddef.h
#include sys/ucontext.h
#ifndef __ARM_EABI__
#error Must be compiled for ARM EABI
#endif
struct seccomp_data {
int nr;
__u32 arch;
__u64 instruction_pointer;
__u64 args[6];
};
#ifndef PR_SET_NO_NEW_PRIVS
#define PR_SET_NO_NEW_PRIVS 38
#endif
#define SECCOMP_RET_KILL 0xU
#define SECCOMP_RET_TRAP 0x0003U
#define SECCOMP_RET_ERRNO 0x0005U
#define SECCOMP_RET_TRACE 0x7ff0U
#define SECCOMP_RET_ALLOW 0x7fffU
struct sifields_sigsys {
void *_call_addr;
int _syscall;
unsigned int _arch;
};
#define SIGINFO_SIGSYS(si) ((struct sifields_sigsys *)(si)-_sifields)
__attribute__((noinline,optimize(2))) long call_getgid_oabi(void)
{
// If OABI compatibility is disabled, this will call exit instead
// (That's what r7==1 means.)
register long ret asm(r0);
asm volatile(mov r0, $1\n\tmov r1, $2\n\tmov r2, $3\n\t
mov r3, $4\n\tmov r4, $5\n\tmov r5, $6\n\t
mov r7, $1\n\tsvc $0x90002f\n\t : : :
r0, r1, r2, r3, r4, r5, r6, r7, memory);
return ret;
}
void handler(int signum, siginfo_t *si, void *uc_void)
{
const struct ucontext *uc = uc_void;
const struct sifields_sigsys *ss = SIGINFO_SIGSYS(si);
printf(SIGSYS\n\n);
printf(nr: 0x%X (__NR_getgid = 0x%X, OABI nr = 0x90002F)\n,
ss-_syscall, __NR_getgid);
#define DO_REG(i) printf(r #i : 0x%08X\n, uc-uc_mcontext.arm_r##i);
DO_REG(0);
DO_REG(1);
DO_REG(2);
DO_REG(3);
DO_REG(4);
DO_REG(5);
DO_REG(6);
DO_REG(7);
}
int main()
{
int rc;
struct sock_filter filter[] = {
BPF_STMT(BPF_LD+BPF_W+BPF_ABS,
(offsetof(struct seccomp_data, nr))),
BPF_JUMP(BPF_JMP+BPF_JEQ+BPF_K, __NR_getgid, 0, 1),
BPF_STMT(BPF_RET+BPF_K, SECCOMP_RET_TRAP),
BPF_STMT(BPF_RET+BPF_K, SECCOMP_RET_ALLOW),
};
struct sock_fprog prog = {
.len = (unsigned short)(sizeof(filter)/sizeof(filter[0])),
.filter = filter,
};
struct sigaction sa = {};
sa.sa_sigaction = handler;
sa.sa_flags = SA_SIGINFO;
if (sigaction(SIGSYS, sa, NULL) != 0)
err(1, sigaction);
if (prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0))
err(1, PR_SET_NO_NEW_PRIVS);
if (prctl(PR_SET_SECCOMP, 2, prog))
err(1, PR_SET_SECCOMP);
call_getgid_oabi();
return 0;
}
Re: ARM audit, seccomp, etc are broken wrt OABI syscalls
On Tue, Nov 5, 2013 at 2:36 PM, Andy Lutomirski l...@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 0x90 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 0x90 + 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ARM audit, seccomp, etc are broken wrt OABI syscalls
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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: ARM audit, seccomp, etc are broken wrt OABI syscalls
On Tue, Nov 5, 2013 at 4:40 PM, Russell King - ARM Linux li...@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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
