linux-kernel - Re: Seccomp performance vs. asm complexity

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAGXu5jJAdr8mJttE_7XrV0Dj2UEQ-LgyEwNs5txA_mC66Qgm6Q@mail.gmail.com>
Date:	Tue, 1 Jul 2014 14:47:33 -0700
From:	Kees Cook <keescook@...omium.org>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>, Will Drewry <wad@...omium.org>
Subject: Re: Seccomp performance vs. asm complexity

On Tue, Jul 1, 2014 at 1:18 PM, Andy Lutomirski <luto@...capital.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/