* 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) probing to figure out
> > > > whe
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 lives?
> >
> > Loca
These patches make the changes necessary to build the kernel as Position
Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below
the top 2G of the virtual address space. It allows to optionally extend the
KASLR randomization range from 1G to 3G.
Thanks a lot to Ard Biesheuvel &
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 I send
>> everything as part of the same
* 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 bits using cache
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
* 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 via the GOT.
So
* 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 EBX on 32 bits, but
* 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
> be enabled for all
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 RIP-relative addressing there is no need for
,Andrew Morton ,"Paul E .
McKenney" ,Nicolas Pitre
,Christopher Li ,"Rafael J .
Wysocki" ,Lukas Wunner ,Mika
Westerberg ,Dou Liyang
,Daniel Borkmann ,Alexei
Starovoitov ,Masahiro Yamada
,Markus Trippelsdorf
,Steven Rostedt ,Rik van Riel
,David Howells ,Waiman Long
,Kyle Huey ,Peter Foley
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 could blame the delay on the
>> > merge
>> > window, but in reality
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 register isn't tota
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
ha
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.
>>
>
> We lose E
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
reusable, and that seems
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 incr
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
>> > window, but in reality I've been procrastinating this is
* 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
> > permanent,
> > non-trivial impact PIE has o
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 wrote:
>> > >
>> > > ( Sorry about the delay in answering this. I co
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 the
> > > merge
> > > window, but in realit
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 procrastinating this is due to the
> > permanent,
> >
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 procrastinating this is due to the
> > permanent,
> >
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. )
>
> * Thomas Garnie
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. )
>
> * Thomas Garnier
( 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 instructions to represent a s
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 +1.4% (from +8% to +10% before). With a default
>>> configurat
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 pick a random 2GB
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 CONFIG_FUNCTION_TRACER
> > option which was incompatible with PIE
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 closer to 0.8%.
>>
>> On the .text size, wi
* 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 configuration
> and +1.180%
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 not "nop"ed out only add
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 __fentry__ call by a nop slide
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
> > > > > instructions where the virtual addresses have the high 32-
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
>> > -fpie
>> > -mcmodel=large? We can p
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)
> > canonical
> >
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:
> >
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
>
>7
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.
> > >
> > > How are these assumptions hardcoded
* 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
> > relocatable straight
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 closer to being able to build the kernel as
> > >> > truly
> > >> > position i
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 where code can be placed
>>
> 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 a
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.
___
X
* 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 place it anywhere in the valid x86-64
> >> > address
> >> >
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 these changes get us closer to being able to build the kernel as truly
> position i
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 independent, i.e. to place it anywhere in the valid x86-64
>>>
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 any other advantages?
>>
>> Yes, PIE al
* 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 memory. It will allow
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 the identity mapping on kexec
>> load
>>
* 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 the changes necessary to
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 the changes necessary to build the kernel as Position
Independent Exec
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%
These patches make the changes necessary to build the kernel as Position
Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below
the top 2G of the virtual address space. It allows to optionally extend the
KASLR randomization range from 1G to 3G.
Thanks a lot to Ard Biesheuvel &
54 matches
Mail list logo