On Wed, Nov 6, 2013 at 1:26 PM, Kees Cook <[email protected]> wrote: > On Wed, Nov 6, 2013 at 1:20 PM, Will Drewry <[email protected]> wrote: >> On Wed, Nov 6, 2013 at 9:51 AM, Russell King - ARM Linux >> <[email protected]> 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 ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/libseccomp-discuss
