On Wed, Nov 6, 2013 at 2:30 PM, Matt Sealey <[email protected]> wrote: > On Tue, Nov 5, 2013 at 6:14 PM, Kees Cook <[email protected]> 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 ------------------------------------------------------------------------------ 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
