linux-sparse.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Garnier <thgarnie@google.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: "Herbert Xu" <herbert@gondor.apana.org.au>,
	"David S . Miller" <davem@davemloft.net>,
	"Thomas Gleixner" <tglx@linutronix.de>,
	"Ingo Molnar" <mingo@redhat.com>,
	"H . Peter Anvin" <hpa@zytor.com>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Josh Poimboeuf" <jpoimboe@redhat.com>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Matthias Kaehlcke" <mka@chromium.org>,
	"Boris Ostrovsky" <boris.ostrovsky@oracle.com>,
	"Juergen Gross" <jgross@suse.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Radim Krčmář" <rkrcmar@redhat.com>,
	"Joerg Roedel" <joro@8bytes.org>,
	"Tom Lendacky" <thomas.lendacky@amd.com>,
	"Andy Lutomirski" <luto@kernel.org>,
	"Borislav Petkov" <bp@suse.de>, "Brian Gerst" <brgerst@gmail.com>,
	"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
	"Rafael J . Wysocki" <rjw@rjwysocki.net>,
	"Len Brown" <len.brown@intel.com>, "Pavel Machek" <pavel@ucw.cz>,
	"Tejun Heo" <tj@kernel.org>
Subject: Re: x86: PIE support and option to extend KASLR randomization
Date: Wed, 16 Aug 2017 09:57:58 -0700	[thread overview]
Message-ID: <CAJcbSZFM_zpL1av1JVaow8NdsGeH+6oZKeDnMPdXR0PGfynzsg@mail.gmail.com> (raw)
In-Reply-To: <20170816151235.oamkdva6cwpc4cex@gmail.com>

On Wed, Aug 16, 2017 at 8:12 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
>
> * Thomas Garnier <thgarnie@google.com> wrote:
>
> > On Tue, Aug 15, 2017 at 12:56 AM, Ingo Molnar <mingo@kernel.org> wrote:
> > >
> > > * Thomas Garnier <thgarnie@google.com> wrote:
> > >
> > >> > Do these changes get us closer to being able to build the kernel as truly
> > >> > position independent, i.e. to place it anywhere in the valid x86-64 address
> > >> > space? Or any other advantages?
> > >>
> > >> Yes, PIE allows us to put the kernel anywhere in memory. It will allow us to
> > >> have a full randomized address space where position and order of sections are
> > >> completely random. There is still some work to get there but being able to build
> > >> a PIE kernel is a significant step.
> > >
> > > So I _really_ dislike the whole PIE approach, because of the huge slowdown:
> > >
> > > +config RANDOMIZE_BASE_LARGE
> > > +       bool "Increase the randomization range of the kernel image"
> > > +       depends on X86_64 && RANDOMIZE_BASE
> > > +       select X86_PIE
> > > +       select X86_MODULE_PLTS if MODULES
> > > +       default n
> > > +       ---help---
> > > +         Build the kernel as a Position Independent Executable (PIE) and
> > > +         increase the available randomization range from 1GB to 3GB.
> > > +
> > > +         This option impacts performance on kernel CPU intensive workloads up
> > > +         to 10% due to PIE generated code. Impact on user-mode processes and
> > > +         typical usage would be significantly less (0.50% when you build the
> > > +         kernel).
> > > +
> > > +         The kernel and modules will generate slightly more assembly (1 to 2%
> > > +         increase on the .text sections). The vmlinux binary will be
> > > +         significantly smaller due to less relocations.
> > >
> > > To put 10% kernel overhead into perspective: enabling this option wipes out about
> > > 5-10 years worth of painstaking optimizations we've done to keep the kernel fast
> > > ... (!!)
> >
> > Note that 10% is the high-bound of a CPU intensive workload.
>
> Note that the 8-10% hackbench or even a 2%-4% range would be 'huge' in terms of
> modern kernel performance. In many cases we are literally applying cycle level
> optimizations that are barely measurable. A 0.1% speedup in linear execution speed
> is already a big success.
>
> > I am going to start doing performance testing on -mcmodel=large to see if it is
> > faster than -fPIE.
>
> Unfortunately mcmodel=large looks pretty heavy too AFAICS, at the machine
> instruction level.
>
> Function calls look like this:
>
>  -mcmodel=medium:
>
>    757:   e8 98 ff ff ff          callq  6f4 <test_code>
>
>  -mcmodel=large
>
>    77b:   48 b8 10 f7 df ff ff    movabs $0xffffffffffdff710,%rax
>    782:   ff ff ff
>    785:   48 8d 04 03             lea    (%rbx,%rax,1),%rax
>    789:   ff d0                   callq  *%rax
>
> And we'd do this for _EVERY_ function call in the kernel. That kind of crap is
> totally unacceptable.
>

I started looking into mcmodel=large and ran into multiple issues. In
the meantime, i thought I would
try difference configurations and compilers.

I did 10 hackbench runs accross 10 reboots with and without pie (same
commit) with gcc 4.9. I copied
the result below and based on the hackbench configuration we are
between -0.29% and 1.92% (average
across is 0.8%) which seems more aligned with what people discussed in
this thread.

I don't know how I got 10% maximum on hackbench, I am still
investigating. It could be the configuration
I used or my base compiler being too old.

> > > I think the fundamental flaw is the assumption that we need a PIE executable
> > > to have a freely relocatable kernel on 64-bit CPUs.
> > >
> > > Have you considered a kernel with -mcmodel=small (or medium) instead of -fpie
> > > -mcmodel=large? We can pick a random 2GB window in the (non-kernel) canonical
> > > x86-64 address space to randomize the location of kernel text. The location of
> > > modules can be further randomized within that 2GB window.
> >
> > -model=small/medium assume you are on the low 32-bit. It generates instructions
> > where the virtual addresses have the high 32-bit to be zero.
>
> How are these assumptions hardcoded by GCC? Most of the instructions should be
> relocatable straight away, as most call/jump/branch instructions are RIP-relative.

I think PIE is capable to use relative instructions well.
mcmodel=large assumes symbols can be anywhere.

>
> I.e. is there no GCC code generation mode where code can be placed anywhere in the
> canonical address space, yet call and jump distance is within 31 bits so that the
> generated code is fast?

I think that's basically PIE. With PIE, you have the assumption
everything is close, the main issue is any assembly referencing
absolute addresses.

>
> Thanks,
>
>         Ingo

process-pipe-1600 ------
         baseline_samecommit     pie  % diff
0                     16.985  16.999   0.082
1                     17.065  17.071   0.033
2                     17.188  17.130  -0.342
3                     17.148  17.107  -0.240
4                     17.217  17.170  -0.275
5                     17.216  17.145  -0.415
6                     17.161  17.109  -0.304
7                     17.202  17.122  -0.465
8                     17.169  17.173   0.024
9                     17.217  17.178  -0.227
average               17.157  17.120  -0.213
median                17.169  17.122  -0.271
min                   16.985  16.999   0.082
max                   17.217  17.178  -0.228

[14 rows x 3 columns]
threads-pipe-1600 ------
         baseline_samecommit     pie  % diff
0                     17.914  18.041   0.707
1                     18.337  18.352   0.083
2                     18.233  18.457   1.225
3                     18.334  18.402   0.366
4                     18.381  18.369  -0.066
5                     18.370  18.408   0.207
6                     18.337  18.400   0.345
7                     18.368  18.372   0.020
8                     18.328  18.588   1.421
9                     18.369  18.344  -0.138
average               18.297  18.373   0.415
median                18.337  18.373   0.200
min                   17.914  18.041   0.707
max                   18.381  18.588   1.126

[14 rows x 3 columns]
threads-pipe-50 ------
         baseline_samecommit     pie  % diff
0                     23.491  22.794  -2.965
1                     23.219  23.542   1.387
2                     22.886  23.638   3.286
3                     23.233  23.778   2.343
4                     23.228  23.703   2.046
5                     23.000  23.376   1.636
6                     23.589  23.335  -1.079
7                     23.043  23.543   2.169
8                     23.117  23.350   1.007
9                     23.059  23.420   1.564
average               23.187  23.448   1.127
median                23.187  23.448   1.127
min                   22.886  22.794  -0.399
max                   23.589  23.778   0.800

[14 rows x 3 columns]
process-socket-50 ------
         baseline_samecommit     pie  % diff
0                     20.333  20.430   0.479
1                     20.198  20.371   0.856
2                     20.494  20.737   1.185
3                     20.445  21.264   4.008
4                     20.530  20.911   1.854
5                     20.281  20.487   1.015
6                     20.311  20.871   2.757
7                     20.472  20.890   2.044
8                     20.568  20.422  -0.710
9                     20.415  20.647   1.134
average               20.405  20.703   1.462
median                20.415  20.703   1.410
min                   20.198  20.371   0.856
max                   20.568  21.264   3.385

[14 rows x 3 columns]
process-pipe-50 ------
         baseline_samecommit     pie  % diff
0                     20.131  20.643   2.541
1                     20.184  20.658   2.349
2                     20.359  20.907   2.693
3                     20.365  21.284   4.514
4                     20.506  20.578   0.352
5                     20.393  20.599   1.010
6                     20.245  20.515   1.331
7                     20.627  20.964   1.636
8                     20.519  20.862   1.670
9                     20.505  20.741   1.150
average               20.383  20.775   1.922
median                20.383  20.741   1.753
min                   20.131  20.515   1.907
max                   20.627  21.284   3.186

[14 rows x 3 columns]
threads-socket-50 ------
         baseline_samecommit     pie  % diff
0                     23.197  23.728   2.286
1                     23.304  23.585   1.205
2                     23.098  23.379   1.217
3                     23.028  23.787   3.295
4                     23.242  23.122  -0.517
5                     23.036  23.512   2.068
6                     23.139  23.258   0.512
7                     22.801  23.458   2.881
8                     23.319  23.276  -0.187
9                     22.989  23.577   2.557
average               23.115  23.468   1.526
median                23.115  23.468   1.526
min                   22.801  23.122   1.407
max                   23.319  23.787   2.006

[14 rows x 3 columns]
process-socket-1600 ------
         baseline_samecommit     pie  % diff
0                     17.214  17.168  -0.262
1                     17.172  17.195   0.135
2                     17.278  17.137  -0.817
3                     17.173  17.102  -0.414
4                     17.211  17.153  -0.335
5                     17.220  17.160  -0.345
6                     17.224  17.161  -0.365
7                     17.224  17.224  -0.004
8                     17.176  17.135  -0.236
9                     17.242  17.188  -0.311
average               17.213  17.162  -0.296
median                17.214  17.161  -0.306
min                   17.172  17.102  -0.405
max                   17.278  17.224  -0.315

[14 rows x 3 columns]
threads-socket-1600 ------
         baseline_samecommit     pie  % diff
0                     18.395  18.389  -0.031
1                     18.459  18.404  -0.296
2                     18.427  18.445   0.096
3                     18.449  18.421  -0.150
4                     18.416  18.411  -0.026
5                     18.409  18.443   0.185
6                     18.325  18.308  -0.092
7                     18.491  18.317  -0.940
8                     18.496  18.375  -0.656
9                     18.436  18.385  -0.279
average               18.430  18.390  -0.219
median                18.430  18.390  -0.219
min                   18.325  18.308  -0.092
max                   18.496  18.445  -0.278

[14 rows x 3 columns]
Total stats ======
         baseline_samecommit     pie  % diff
average               19.773  19.930   0.791
median                19.773  19.930   0.791
min                   16.985  16.999   0.082
max                   23.589  23.787   0.839

[4 rows x 3 columns]

-- 
Thomas

  parent reply	other threads:[~2017-08-16 16:57 UTC|newest]

Thread overview: 81+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-10 17:25 x86: PIE support and option to extend KASLR randomization Thomas Garnier
2017-08-10 17:25 ` [RFC v2 01/23] x86/crypto: Adapt assembly for PIE support Thomas Garnier
2017-08-10 17:25 ` [RFC v2 02/23] x86: Use symbol name on bug table " Thomas Garnier
2017-08-10 17:25 ` [RFC v2 03/23] x86: Use symbol name in jump " Thomas Garnier
2017-08-10 17:25 ` [RFC v2 04/23] x86: Add macro to get symbol address " Thomas Garnier
2017-08-10 17:25 ` [RFC v2 05/23] xen: Adapt assembly " Thomas Garnier
2017-08-10 17:25 ` [RFC v2 06/23] kvm: " Thomas Garnier
2017-08-10 17:25 ` [RFC v2 07/23] x86: relocate_kernel - " Thomas Garnier
2017-08-10 17:26 ` [RFC v2 08/23] x86/entry/64: " Thomas Garnier
2017-08-10 17:26 ` [RFC v2 09/23] x86: pm-trace - " Thomas Garnier
2017-08-10 17:26 ` [RFC v2 10/23] x86/CPU: " Thomas Garnier
2017-08-10 17:26 ` [RFC v2 11/23] x86/acpi: " Thomas Garnier
2017-08-10 17:26 ` [RFC v2 12/23] x86/boot/64: " Thomas Garnier
2017-08-10 17:26 ` [RFC v2 13/23] x86/power/64: " Thomas Garnier
2017-08-11 12:36   ` Pavel Machek
2017-08-11 15:09     ` Thomas Garnier
2017-08-10 17:26 ` [RFC v2 14/23] x86/paravirt: " Thomas Garnier
2017-08-10 17:26 ` [RFC v2 15/23] x86/boot/64: Use _text in a global " Thomas Garnier
2017-08-10 17:26 ` [RFC v2 16/23] x86/percpu: Adapt percpu " Thomas Garnier
2017-08-10 17:26 ` [RFC v2 17/23] compiler: Option to default to hidden symbols Thomas Garnier
2017-08-10 17:26 ` [RFC v2 18/23] x86/relocs: Handle DYN relocations for PIE support Thomas Garnier
2017-08-10 17:26 ` [RFC v2 19/23] x86: Support global stack cookie Thomas Garnier
2017-08-10 17:26 ` [RFC v2 20/23] x86/pie: Add option to build the kernel as PIE for x86_64 Thomas Garnier
2017-08-10 17:26 ` [RFC v2 21/23] x86/relocs: Add option to generate 64-bit relocations Thomas Garnier
2017-08-10 17:26 ` [RFC v2 22/23] x86/module: Add support for mcmodel large and PLTs Thomas Garnier
2017-08-10 17:26 ` [RFC v2 23/23] x86/kaslr: Add option to extend KASLR range from 1GB to 3GB Thomas Garnier
2017-08-11 12:41 ` x86: PIE support and option to extend KASLR randomization Ingo Molnar
2017-08-11 15:09   ` Thomas Garnier
2017-08-15  7:56     ` Ingo Molnar
2017-08-15 14:20       ` Thomas Garnier
2017-08-15 14:47         ` Daniel Micay
2017-08-15 14:58           ` Thomas Garnier
2017-08-16 15:12         ` Ingo Molnar
2017-08-16 16:09           ` Christopher Lameter
2017-08-16 16:26           ` Daniel Micay
2017-08-16 16:32             ` Ard Biesheuvel
2017-08-16 16:57           ` Thomas Garnier [this message]
2017-08-17  8:09             ` Ingo Molnar
2017-08-17 14:10               ` Thomas Garnier
2017-08-24 21:13                 ` Thomas Garnier
2017-08-24 21:42                   ` Linus Torvalds
2017-08-25 15:35                     ` Thomas Garnier
2017-08-25  1:07                   ` Steven Rostedt
2017-08-25  8:04                   ` Ingo Molnar
2017-08-25 15:05                     ` Thomas Garnier
2017-08-29 19:34                       ` Thomas Garnier
2017-09-21 15:59                         ` Ingo Molnar
2017-09-21 16:10                           ` Ard Biesheuvel
2017-09-21 21:21                             ` Thomas Garnier
2017-09-22  4:24                               ` Markus Trippelsdorf
2017-09-22 14:38                                 ` Thomas Garnier
2017-09-22 23:55                               ` Thomas Garnier
2017-09-21 21:16                           ` Thomas Garnier
2017-09-22  0:06                             ` Thomas Garnier
2017-09-22 16:32                             ` Ingo Molnar
2017-09-22 18:08                               ` Thomas Garnier
2017-09-23  9:43                                 ` Ingo Molnar
2017-10-02 20:28                                   ` Thomas Garnier
2017-09-22 18:38                               ` H. Peter Anvin
2017-09-22 18:57                                 ` Kees Cook
2017-09-22 19:06                                   ` H. Peter Anvin
2017-09-22 18:59                                 ` Thomas Garnier
2017-09-23  9:49                                 ` Ingo Molnar
2017-08-17 14:12               ` Boris Lukashev
2017-08-25 15:38                 ` Christopher Lameter
2017-08-27 22:39                   ` Boris Lukashev
2017-08-28  9:59                 ` Pavel Machek
2017-08-21 13:32           ` Peter Zijlstra
2017-08-21 14:28             ` Peter Zijlstra
2017-09-22 18:27               ` H. Peter Anvin
2017-09-23 10:00                 ` Ingo Molnar
2017-09-24 22:37                   ` Pavel Machek
2017-09-25  7:33                     ` Ingo Molnar
2017-10-06 10:39                       ` Pavel Machek
2017-10-20  8:13                         ` Ingo Molnar
2017-08-21 14:31         ` Peter Zijlstra
2017-08-21 15:57           ` Thomas Garnier
2017-08-28  1:26           ` H. Peter Anvin
  -- strict thread matches above, loose matches on Subject: below --
2017-10-04 21:19 Thomas Garnier
2017-07-18 22:33 Thomas Garnier
2017-07-19 14:08 ` Christopher Lameter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJcbSZFM_zpL1av1JVaow8NdsGeH+6oZKeDnMPdXR0PGfynzsg@mail.gmail.com \
    --to=thgarnie@google.com \
    --cc=arnd@arndb.de \
    --cc=boris.ostrovsky@oracle.com \
    --cc=bp@suse.de \
    --cc=brgerst@gmail.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=hpa@zytor.com \
    --cc=jgross@suse.com \
    --cc=joro@8bytes.org \
    --cc=jpoimboe@redhat.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=len.brown@intel.com \
    --cc=luto@kernel.org \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=mka@chromium.org \
    --cc=pavel@ucw.cz \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rjw@rjwysocki.net \
    --cc=rkrcmar@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.lendacky@amd.com \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).