Date: Sun, 27 Aug 2017 18:39:51 -0400 From: Boris Lukashev <blukashev@...pervictus.com> To: Christopher Lameter <cl@...ux.com> Cc: Ingo Molnar <mingo@...nel.org>, Thomas Garnier <thgarnie@...gle.com>, Herbert Xu <herbert@...dor.apana.org.au>, "David S . Miller" <davem@...emloft.net>, Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, "H . Peter Anvin" <hpa@...or.com>, Peter Zijlstra <peterz@...radead.org>, Josh Poimboeuf <jpoimboe@...hat.com>, Arnd Bergmann <arnd@...db.de>, Matthias Kaehlcke <mka@...omium.org>, Boris Ostrovsky <boris.ostrovsky@...cle.com>, Juergen Gross <jgross@...e.com>, Paolo Bonzini <pbonzini@...hat.com>, Radim Krčmář <rkrcmar@...hat.com>, Joerg Roedel <joro@...tes.org>, Tom Lendacky <thomas.lendacky@....com>, Andy Lutomirski <luto@...nel.org>, Borislav Petkov <bp@...e.de>, Brian Gerst <brgerst@...il.com>, "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>, "Rafael J . Wysocki" <rjw@...ysocki.net>, Len Brown <len.brown@...el.com>, Pavel Machek <pavel@....cz>, Tejun Heo <tj@...nel.org>, Paul Gortmaker <paul.gortmaker@...driver.com>, Chris Metcalf <cmetcalf@...lanox.com>, Andrew Morton <akpm@...ux-foundation.org>, "Paul E . McKenney" <paulmck@...ux.vnet.ibm.com>, Nicolas Pitre <nicolas.pitre@...aro.org>, Christopher Li <sparse@...isli.org>, "Rafael J . Wysocki" <rafael.j.wysocki@...el.com>, Lukas Wunner <lukas@...ner.de>, Mika Westerberg <mika.westerberg@...ux.intel.com>, Dou Liyang <douly.fnst@...fujitsu.com>, Daniel Borkmann <daniel@...earbox.net>, Alexei Starovoitov <ast@...nel.org>, Masahiro Yamada <yamada.masahiro@...ionext.com>, Markus Trippelsdorf <markus@...ppelsdorf.de>, Steven Rostedt <rostedt@...dmis.org>, Kees Cook <keescook@...omium.org>, Rik van Riel <riel@...hat.com>, David Howells <dhowells@...hat.com>, Waiman Long <longman@...hat.com>, Kyle Huey <me@...ehuey.com>, Peter Foley <pefoley2@...oley.com>, Tim Chen <tim.c.chen@...ux.intel.com>, Catalin Marinas <catalin.marinas@....com>, Ard Biesheuvel <ard.biesheuvel@...aro.org>, Michal Hocko <mhocko@...e.com>, Matthew Wilcox <mawilcox@...rosoft.com>, "H . J . Lu" <hjl.tools@...il.com>, Paul Bolle <pebolle@...cali.nl>, Rob Landley <rob@...dley.net>, Baoquan He <bhe@...hat.com>, Daniel Micay <danielmicay@...il.com>, "the arch/x86 maintainers" <x86@...nel.org>, Linux Crypto Mailing List <linux-crypto@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, xen-devel@...ts.xenproject.org, kvm list <kvm@...r.kernel.org>, Linux PM list <linux-pm@...r.kernel.org>, linux-arch <linux-arch@...r.kernel.org>, linux-sparse@...r.kernel.org, Kernel Hardening <kernel-hardening@...ts.openwall.com>, Linus Torvalds <torvalds@...ux-foundation.org>, Peter Zijlstra <a.p.zijlstra@...llo.nl>, Borislav Petkov <bp@...en8.de> Subject: Re: Re: x86: PIE support and option to extend KASLR randomization On Fri, Aug 25, 2017 at 11:38 AM, Christopher Lameter <cl@...ux.com> wrote: > > > On Thu, 17 Aug 2017, Boris Lukashev wrote: > >> Is the expectation then to have security functions also decrease size >> and operational latency? Seems a bit unrealistic if so. >> 1-2% performance hit on systems which have become at least several >> hundred % faster over recent years is not a significant performance >> regression compared to the baseline before. > > Where do you get these fantastic numbers? Where can I buy a system like > that? Commonly we see regressions with single threaded integer > performance on most newer processor generations. > > These hundreds of percent improvement can only come from floating point > performance using specialized instructions. There are only a very limited > number of applications that can make use of it. > An example of these fantastic numbers can be seen in https://www.cpubenchmark.net/cpu.php?cpu=Intel+Pentium+4+3.00GHz which shows a 9 year old P4 compared to today's desktop chips. Point taken on the specific types of maths being performed though. I personally can't make an educated guess at how much of the "modern" functionality compilers could leverage to optimize these code paths. I am by no means a chip or compiler architect, but have built a fair number of systems and service oriented architectures; and in the business-end of planning and design, a deficit of security function doesn't just slow down execution by several percent - it can halt the project or scuttle it altogether as stakeholders do not wish to put their posteriors on the line. The intent of my original email was to point out that the balance between performance and security isn't as clear-cut as "all bugs are created equal and hackbench outputs tell the whole story," since aspects of performance and security are often evaluated by separate parties in different segments of the decision making process. Providing as many avenues as possible to enhance security posture with clearly labeled performance penalties may be the difference between adoption/execution and another cycle of "wait and see." While decisions around future development agility based on changes in these optional configurations are definitely a major point to consider, the decision between a performance penalty and an exposed attack surface is likely a useful option to leave for the people building the final systems. -Boris
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.