| 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
| ||
|
Date: Tue, 1 Jul 2014 13:18:38 -0700 From: Andy Lutomirski <luto@...capital.net> To: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "H. Peter Anvin" <hpa@...or.com>, Kees Cook <keescook@...omium.org>, Will Drewry <wad@...omium.org> Subject: Seccomp performance vs. asm complexity 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. 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. --Andy -- 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/
Powered by blists - more mailing lists