lkml.org 
[lkml]   [2014]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: Seccomp performance vs. asm complexity
From
On Tue, Jul 1, 2014 at 1:18 PM, Andy Lutomirski <luto@amacapital.net> 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


\
 
 \ /
  Last update: 2014-07-02 01:01    [W:0.049 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site