On Tue, Jul 1, 2014 at 1:18 PM, Andy Lutomirski <[email protected]> wrote: > This is a question about tradeoffs. I'm playing with a couple of > approaches for an x86 seccomp fast path. > > It looks like populating struct seccomp_data in the syscall entry asm > code saves 4-5ns (83ns vs 87.7ns or so for getpid with seccomp > enabled). Presumably this is because it avoids a branch and replaces > seven two-instruction memory copies with 6 register pushes and one > memory push. It also keeps the code shorter, with corresponding > icache benefits. > > OTOH, populating struct seccomp_data in C keeps the asm code shorter > and simpler. In fast, it ends up being a net deletion of asm code. > > Thoughts? What's a line of assembly code worth? Keep in mind that > someone will probably want to port this to the x86_32 and compat > entries.
My feeling is that keeping it maintainable/readable should probably take precedence over 5ns. The syscall entry points are already complex, and already very security-sensitive, so my (security-conservative) instincts are for robustness over speed. > To keep this in perspective, this is down from >200ns in 3.16-rc3. > > My current code is here: > > https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=x86/seccomp-fastpath > > I think it's in pretty good shape, but I still want to play with it a > bit before sending it out. This version uses the C approach. This looks really great! -Kees -- Kees Cook Chrome OS Security -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
