Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

* Pavel Machek wrote: > On Mon 2017-09-25 09:33:42, Ingo Molnar wrote: > > > > * Pavel Machek wrote: > > > > > > For example, there would be collision with regular user-space mappings, > > > > right? > > > > Can local unprivileged users use mmap(MAP_FIXED)

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On Mon 2017-09-25 09:33:42, Ingo Molnar wrote: > > * Pavel Machek wrote: > > > > For example, there would be collision with regular user-space mappings, > > > right? > > > Can local unprivileged users use mmap(MAP_FIXED) probing to figure out > > > where > > > the kernel

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On Sat, Sep 23, 2017 at 2:43 AM, Ingo Molnar wrote: > > * Thomas Garnier wrote: > >> > 2) we first implement the additional entropy bits that Linus suggested. >> > >> > does this work for you? >> >> Sure, I can look at how feasible that is. If it is, can

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

* Pavel Machek wrote: > > For example, there would be collision with regular user-space mappings, > > right? > > Can local unprivileged users use mmap(MAP_FIXED) probing to figure out > > where > > the kernel lives? > > Local unpriviledged users can probably get your secret

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

Hi! > > We do need to consider how we want modules to fit into whatever model we > > choose, though. They can be adjacent, or we could go with a more > > traditional dynamic link model where the modules can be separate, and > > chained together with the main kernel via the GOT. > > So I believe

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

* H. Peter Anvin wrote: > We do need to consider how we want modules to fit into whatever model we > choose, though. They can be adjacent, or we could go with a more > traditional dynamic link model where the modules can be separate, and > chained together with the main kernel

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

* H. Peter Anvin wrote: > On 09/22/17 09:32, Ingo Molnar wrote: > > > > BTW., I think things improved with ORC because with ORC we have RBP as an > > extra > > register and with PIE we lose RBX - so register pressure in code generation > > is > > lower. > > > > We lose

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

* Thomas Garnier wrote: > > 2) we first implement the additional entropy bits that Linus suggested. > > > > does this work for you? > > Sure, I can look at how feasible that is. If it is, can I send > everything as part of the same patch set? The additional entropy would

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On September 23, 2017 3:06:16 AM GMT+08:00, "H. Peter Anvin" wrote: >On 09/22/17 11:57, Kees Cook wrote: >> On Fri, Sep 22, 2017 at 11:38 AM, H. Peter Anvin >wrote: >>> We lose EBX on 32 bits, but we don't lose RBX on 64 bits - since >x86-64 >>> has

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

,Andrew Morton ,"Paul E . McKenney" ,Nicolas Pitre ,Christopher Li ,"Rafael J . Wysocki" ,Lukas Wunner ,Mika Westerberg

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On Thu, Sep 21, 2017 at 2:21 PM, Thomas Garnier wrote: > On Thu, Sep 21, 2017 at 9:10 AM, Ard Biesheuvel > wrote: >> >> On 21 September 2017 at 08:59, Ingo Molnar wrote: >> > >> > ( Sorry about the delay in answering this. I

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On 09/22/17 11:57, Kees Cook wrote: > On Fri, Sep 22, 2017 at 11:38 AM, H. Peter Anvin wrote: >> We lose EBX on 32 bits, but we don't lose RBX on 64 bits - since x86-64 >> has RIP-relative addressing there is no need for a dedicated PIC register. > > FWIW, since gcc 5, the PIC

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On 09/22/17 09:32, Ingo Molnar wrote: > > BTW., I think things improved with ORC because with ORC we have RBP as an > extra > register and with PIE we lose RBX - so register pressure in code generation > is > lower. > We lose EBX on 32 bits, but we don't lose RBX on 64 bits - since x86-64

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On Fri, Sep 22, 2017 at 11:38 AM, H. Peter Anvin wrote: > On 09/22/17 09:32, Ingo Molnar wrote: >> >> BTW., I think things improved with ORC because with ORC we have RBP as an >> extra >> register and with PIE we lose RBX - so register pressure in code generation >> is >> lower.

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On Fri, Sep 22, 2017 at 11:38 AM, H. Peter Anvin wrote: > We lose EBX on 32 bits, but we don't lose RBX on 64 bits - since x86-64 > has RIP-relative addressing there is no need for a dedicated PIC register. FWIW, since gcc 5, the PIC register isn't totally lost. It is now

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On 08/21/17 07:28, Peter Zijlstra wrote: > > Ah, I see, this is large mode and that needs to use MOVABS to load 64bit > immediates. Still, small RIP relative should be able to live at any > point as long as everything lives inside the same 2G relative range, so > would still allow the goal of

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On Fri, Sep 22, 2017 at 9:32 AM, Ingo Molnar wrote: > > * Thomas Garnier wrote: > >> On Thu, Sep 21, 2017 at 8:59 AM, Ingo Molnar wrote: >> > >> > ( Sorry about the delay in answering this. I could blame the delay on the >> > merge >> >

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

* Thomas Garnier wrote: > On Thu, Sep 21, 2017 at 8:59 AM, Ingo Molnar wrote: > > > > ( Sorry about the delay in answering this. I could blame the delay on the > > merge > > window, but in reality I've been procrastinating this is due to the > >

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On Thu, Sep 21, 2017 at 9:24 PM, Markus Trippelsdorf wrote: > On 2017.09.21 at 14:21 -0700, Thomas Garnier wrote: >> On Thu, Sep 21, 2017 at 9:10 AM, Ard Biesheuvel >> wrote: >> > >> > On 21 September 2017 at 08:59, Ingo Molnar

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On 2017.09.21 at 14:21 -0700, Thomas Garnier wrote: > On Thu, Sep 21, 2017 at 9:10 AM, Ard Biesheuvel > wrote: > > > > On 21 September 2017 at 08:59, Ingo Molnar wrote: > > > > > > ( Sorry about the delay in answering this. I could blame the delay on

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On Thu, Sep 21, 2017 at 2:16 PM, Thomas Garnier wrote: > > On Thu, Sep 21, 2017 at 8:59 AM, Ingo Molnar wrote: > > > > ( Sorry about the delay in answering this. I could blame the delay on the > > merge > > window, but in reality I've been

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On Thu, Sep 21, 2017 at 9:10 AM, Ard Biesheuvel wrote: > > On 21 September 2017 at 08:59, Ingo Molnar wrote: > > > > ( Sorry about the delay in answering this. I could blame the delay on the > > merge > > window, but in reality I've been

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On Thu, Sep 21, 2017 at 8:59 AM, Ingo Molnar wrote: > > ( Sorry about the delay in answering this. I could blame the delay on the > merge > window, but in reality I've been procrastinating this is due to the > permanent, > non-trivial impact PIE has on generated C code. )

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On 21 September 2017 at 08:59, Ingo Molnar wrote: > > ( Sorry about the delay in answering this. I could blame the delay on the > merge > window, but in reality I've been procrastinating this is due to the > permanent, > non-trivial impact PIE has on generated C code. ) >

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

( Sorry about the delay in answering this. I could blame the delay on the merge window, but in reality I've been procrastinating this is due to the permanent, non-trivial impact PIE has on generated C code. ) * Thomas Garnier wrote: > 1) PIE sometime needs two

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On Fri, Aug 25, 2017 at 8:05 AM, Thomas Garnier wrote: > On Fri, Aug 25, 2017 at 1:04 AM, Ingo Molnar wrote: >> >> * Thomas Garnier wrote: >> >>> With the fix for function tracing, the hackbench results have an >>> average of +0.8 to

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On 08/21/17 07:31, Peter Zijlstra wrote: > On Tue, Aug 15, 2017 at 07:20:38AM -0700, Thomas Garnier wrote: >> On Tue, Aug 15, 2017 at 12:56 AM, Ingo Molnar wrote: > >>> Have you considered a kernel with -mcmodel=small (or medium) instead of >>> -fpie >>> -mcmodel=large? We can

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On Thu, Aug 24, 2017 at 2:42 PM, Linus Torvalds wrote: > > On Thu, Aug 24, 2017 at 2:13 PM, Thomas Garnier wrote: > > > > My original performance testing was done with an Ubuntu generic > > configuration. This configuration has the

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On Fri, Aug 25, 2017 at 1:04 AM, Ingo Molnar wrote: > > * Thomas Garnier wrote: > >> With the fix for function tracing, the hackbench results have an >> average of +0.8 to +1.4% (from +8% to +10% before). With a default >> configuration, the numbers are

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

* Thomas Garnier wrote: > With the fix for function tracing, the hackbench results have an > average of +0.8 to +1.4% (from +8% to +10% before). With a default > configuration, the numbers are closer to 0.8%. > > On the .text size, with gcc 4.9 I see +0.8% on default

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On Thu, 24 Aug 2017 14:13:38 -0700 Thomas Garnier wrote: > With the fix for function tracing, the hackbench results have an > average of +0.8 to +1.4% (from +8% to +10% before). With a default > configuration, the numbers are closer to 0.8%. Wow, an empty fentry function

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On Thu, Aug 24, 2017 at 2:13 PM, Thomas Garnier wrote: > > My original performance testing was done with an Ubuntu generic > configuration. This configuration has the CONFIG_FUNCTION_TRACER > option which was incompatible with PIE. The tracer failed to replace > the

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On Thu, Aug 17, 2017 at 7:10 AM, Thomas Garnier wrote: > > On Thu, Aug 17, 2017 at 1:09 AM, Ingo Molnar wrote: > > > > > > * Thomas Garnier wrote: > > > > > > > -model=small/medium assume you are on the low 32-bit. It generates > > > >

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On Mon, Aug 21, 2017 at 7:31 AM, Peter Zijlstra wrote: > On Tue, Aug 15, 2017 at 07:20:38AM -0700, Thomas Garnier wrote: >> On Tue, Aug 15, 2017 at 12:56 AM, Ingo Molnar wrote: > >> > Have you considered a kernel with -mcmodel=small (or medium) instead of

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On Tue, Aug 15, 2017 at 07:20:38AM -0700, Thomas Garnier wrote: > On Tue, Aug 15, 2017 at 12:56 AM, Ingo Molnar wrote: > > 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)

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On Mon, Aug 21, 2017 at 03:32:22PM +0200, Peter Zijlstra wrote: > On Wed, Aug 16, 2017 at 05:12:35PM +0200, Ingo Molnar wrote: > > Unfortunately mcmodel=large looks pretty heavy too AFAICS, at the machine > > instruction level. > > > > Function calls look like this: > > > > -mcmodel=medium: >

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On Wed, Aug 16, 2017 at 05:12:35PM +0200, Ingo Molnar wrote: > 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 > > -mcmodel=large > >

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On Thu, Aug 17, 2017 at 1:09 AM, Ingo Molnar wrote: > > > * Thomas Garnier wrote: > > > > > -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. > > > >

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

* Thomas Garnier wrote: > > > -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 > >

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On Wed, Aug 16, 2017 at 8:12 AM, Ingo Molnar wrote: > > > * Thomas Garnier wrote: > > > On Tue, Aug 15, 2017 at 12:56 AM, Ingo Molnar wrote: > > > > > > * Thomas Garnier wrote: > > > > > >> > Do these changes get us

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On 16 August 2017 at 17:26, Daniel Micay wrote: >> 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.e. is there no GCC code generation mode

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

> 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.e. is there no GCC code generation mode where code can be placed > anywhere in the > canonical address space, yet call

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On Wed, 16 Aug 2017, Ingo Molnar wrote: > And we'd do this for _EVERY_ function call in the kernel. That kind of crap is > totally unacceptable. Ahh finally a limit is in sight as to how much security hardening etc can reduce kernel performance. ___

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

* Thomas Garnier wrote: > On Tue, Aug 15, 2017 at 12:56 AM, Ingo Molnar wrote: > > > > * Thomas Garnier wrote: > > > >> > Do these changes get us closer to being able to build the kernel as truly > >> > position independent, i.e. to

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On Tue, Aug 15, 2017 at 7:47 AM, Daniel Micay wrote: > On 15 August 2017 at 10:20, Thomas Garnier wrote: >> On Tue, Aug 15, 2017 at 12:56 AM, Ingo Molnar wrote: >>> >>> * Thomas Garnier wrote: >>> > Do

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On 15 August 2017 at 10:20, Thomas Garnier wrote: > On Tue, Aug 15, 2017 at 12:56 AM, Ingo Molnar wrote: >> >> * Thomas Garnier wrote: >> >>> > Do these changes get us closer to being able to build the kernel as truly >>> > position

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On Tue, Aug 15, 2017 at 12:56 AM, Ingo Molnar wrote: > > * Thomas Garnier 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

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

* Thomas Garnier 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

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On Fri, Aug 11, 2017 at 5:41 AM, Ingo Molnar wrote: > > * Thomas Garnier wrote: > >> Changes: >> - v2: >>- Add support for global stack cookie while compiler default to fs without >> mcmodel=kernel >>- Change patch 7 to correctly jump out of

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

* Thomas Garnier wrote: > Changes: > - v2: >- Add support for global stack cookie while compiler default to fs without > mcmodel=kernel >- Change patch 7 to correctly jump out of the identity mapping on kexec > load > preserve. > > These patches make

Re: [Xen-devel] x86: PIE support and option to extend KASLR randomization

On Tue, 18 Jul 2017, Thomas Garnier wrote: > Performance/Size impact: > Hackbench (50% and 1600% loads): > - PIE enabled: 7% to 8% on half load, 10% on heavy load. > slab_test (average of 10 runs): > - PIE enabled: 3% to 4% > Kernbench (average of 10 Half and Optimal runs): > - PIE enabled: 5%