Re: [kernel-hardening] Re: x86: PIE support and option to extend KASLR randomization

From: Boris Lukashev <blukashev@sempervictus.com>
To: Christopher Lameter <cl@linux.com>
Cc: "Nicolas Pitre" <nicolas.pitre@linaro.org>,
	"Peter Zijlstra" <a.p.zijlstra@chello.nl>,
	"Michal Hocko" <mhocko@suse.com>,
	"Len Brown" <len.brown@intel.com>,
	"Radim Krčmář" <rkrcmar@redhat.com>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Christopher Li" <sparse@chrisli.org>,
	"Alexei Starovoitov" <ast@kernel.org>,
	"David Howells" <dhowells@redhat.com>,
	"Paul Gortmaker" <paul.gortmaker@windriver.com>,
	"Pavel Machek" <pavel@ucw.cz>, "H . Peter Anvin" <hpa@zytor.com>,
	"Kernel Hardening" <kernel-hardening@lists.openwall.com>,
	"Ingo Molnar" <mingo@kernel.org>,
	"Kees Cook" <keescook@chromium.org>,
	"the arch/x86 maintainers" <x86@kernel.org>,
	"Herbert Xu" <herbert@gondor.apana.org.au>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Matthew Wilcox" <mawilcox@microsoft.com>,
	"Peter Foley" <pefoley2@pefoley.com>,
	"Joerg Roedel" <joro@8bytes.org>
Subject: Re: [kernel-hardening] Re: x86: PIE support and option to extend KASLR randomization
Date: Sun, 27 Aug 2017 18:39:51 -0400	[thread overview]
Message-ID: <CAFUG7CekAa-CBEo=t0KRMRe0T8ZkRyg4c_stO8Bt4njwQeAH4Q__34126.5968316749$1503873695$gmane$org@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.20.1708251036150.5830@nuc-kabylake>

On Fri, Aug 25, 2017 at 11:38 AM, Christopher Lameter <cl@linux.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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel