Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

* Ingo Molnar wrote: > > * Thomas Garnier wrote: > > > arch/x86/include/asm/kaslr.h| 12 +++ > > Hm, what tree is this patch against? asm/kaslr.h does not exist upstream or > in the > x86 tree. So the problem is that this file gets

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

* Ingo Molnar wrote: > > * Thomas Garnier wrote: > > > arch/x86/include/asm/kaslr.h| 12 +++ > > Hm, what tree is this patch against? asm/kaslr.h does not exist upstream or > in the > x86 tree. So the problem is that this file gets introduced by: [PATCH v5 1/4] x86, boot:

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

* Ingo Molnar wrote: > > * Thomas Garnier wrote: > > > arch/x86/include/asm/kaslr.h| 12 +++ > > Hm, what tree is this patch against? asm/kaslr.h does not exist upstream or > in the > x86 tree. Ah, never mind, introduced by the first

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

* Ingo Molnar wrote: > > * Thomas Garnier wrote: > > > arch/x86/include/asm/kaslr.h| 12 +++ > > Hm, what tree is this patch against? asm/kaslr.h does not exist upstream or > in the > x86 tree. Ah, never mind, introduced by the first patch. Thanks, Ingo

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

* Thomas Garnier wrote: > arch/x86/include/asm/kaslr.h| 12 +++ Hm, what tree is this patch against? asm/kaslr.h does not exist upstream or in the x86 tree. Thanks, Ingo

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

* Thomas Garnier wrote: > arch/x86/include/asm/kaslr.h| 12 +++ Hm, what tree is this patch against? asm/kaslr.h does not exist upstream or in the x86 tree. Thanks, Ingo

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

Make sense, thanks for the details. On Thu, Apr 21, 2016 at 1:15 PM, H. Peter Anvin wrote: > On April 21, 2016 8:52:01 AM PDT, Thomas Garnier wrote: >>On Thu, Apr 21, 2016 at 8:46 AM, H. Peter Anvin wrote: >>> On April 21, 2016 6:30:24 AM

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

Make sense, thanks for the details. On Thu, Apr 21, 2016 at 1:15 PM, H. Peter Anvin wrote: > On April 21, 2016 8:52:01 AM PDT, Thomas Garnier wrote: >>On Thu, Apr 21, 2016 at 8:46 AM, H. Peter Anvin wrote: >>> On April 21, 2016 6:30:24 AM PDT, Boris Ostrovsky >> wrote: On

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

On April 21, 2016 8:52:01 AM PDT, Thomas Garnier wrote: >On Thu, Apr 21, 2016 at 8:46 AM, H. Peter Anvin wrote: >> On April 21, 2016 6:30:24 AM PDT, Boris Ostrovsky > wrote: >>> >>> >>>On 04/15/2016 06:03 PM, Thomas Garnier wrote:

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

On April 21, 2016 8:52:01 AM PDT, Thomas Garnier wrote: >On Thu, Apr 21, 2016 at 8:46 AM, H. Peter Anvin wrote: >> On April 21, 2016 6:30:24 AM PDT, Boris Ostrovsky > wrote: >>> >>> >>>On 04/15/2016 06:03 PM, Thomas Garnier wrote: +void __init kernel_randomize_memory(void) +{ +

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

On April 21, 2016 6:30:24 AM PDT, Boris Ostrovsky wrote: > > >On 04/15/2016 06:03 PM, Thomas Garnier wrote: >> +void __init kernel_randomize_memory(void) >> +{ >> +size_t i; >> +unsigned long addr = memory_rand_start; >> +unsigned long padding, rand,

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

On April 21, 2016 6:30:24 AM PDT, Boris Ostrovsky wrote: > > >On 04/15/2016 06:03 PM, Thomas Garnier wrote: >> +void __init kernel_randomize_memory(void) >> +{ >> +size_t i; >> +unsigned long addr = memory_rand_start; >> +unsigned long padding, rand, mem_tb; >> +struct rnd_state

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

On Thu, Apr 21, 2016 at 8:46 AM, H. Peter Anvin wrote: > On April 21, 2016 6:30:24 AM PDT, Boris Ostrovsky > wrote: >> >> >>On 04/15/2016 06:03 PM, Thomas Garnier wrote: >>> +void __init kernel_randomize_memory(void) >>> +{ >>> +size_t i; >>> +

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

On Thu, Apr 21, 2016 at 8:46 AM, H. Peter Anvin wrote: > On April 21, 2016 6:30:24 AM PDT, Boris Ostrovsky > wrote: >> >> >>On 04/15/2016 06:03 PM, Thomas Garnier wrote: >>> +void __init kernel_randomize_memory(void) >>> +{ >>> +size_t i; >>> +unsigned long addr = memory_rand_start; >>>

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

On Thu, Apr 21, 2016 at 6:30 AM, Boris Ostrovsky wrote: > > > On 04/15/2016 06:03 PM, Thomas Garnier wrote: >> >> +void __init kernel_randomize_memory(void) >> +{ >> + size_t i; >> + unsigned long addr = memory_rand_start; >> + unsigned long padding,

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

On Thu, Apr 21, 2016 at 6:30 AM, Boris Ostrovsky wrote: > > > On 04/15/2016 06:03 PM, Thomas Garnier wrote: >> >> +void __init kernel_randomize_memory(void) >> +{ >> + size_t i; >> + unsigned long addr = memory_rand_start; >> + unsigned long padding, rand, mem_tb; >> +

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

On 04/15/2016 06:03 PM, Thomas Garnier wrote: +void __init kernel_randomize_memory(void) +{ + size_t i; + unsigned long addr = memory_rand_start; + unsigned long padding, rand, mem_tb; + struct rnd_state rnd_st; + unsigned long remain_padding = memory_rand_end -

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

On 04/15/2016 06:03 PM, Thomas Garnier wrote: +void __init kernel_randomize_memory(void) +{ + size_t i; + unsigned long addr = memory_rand_start; + unsigned long padding, rand, mem_tb; + struct rnd_state rnd_st; + unsigned long remain_padding = memory_rand_end -

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

On Tue, Apr 19, 2016 at 7:27 AM, Joerg Roedel wrote: > Hi Thomas, > > On Fri, Apr 15, 2016 at 03:03:12PM -0700, Thomas Garnier wrote: >> +/* >> + * Create PGD aligned trampoline table to allow real mode initialization >> + * of additional CPUs. Consume only 1 additonal low memory

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

On Tue, Apr 19, 2016 at 7:27 AM, Joerg Roedel wrote: > Hi Thomas, > > On Fri, Apr 15, 2016 at 03:03:12PM -0700, Thomas Garnier wrote: >> +/* >> + * Create PGD aligned trampoline table to allow real mode initialization >> + * of additional CPUs. Consume only 1 additonal low memory page. >> + */ >>

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

Hi Thomas, On Fri, Apr 15, 2016 at 03:03:12PM -0700, Thomas Garnier wrote: > +/* > + * Create PGD aligned trampoline table to allow real mode initialization > + * of additional CPUs. Consume only 1 additonal low memory page. > + */ > +void __meminit kaslr_trampoline_init(unsigned long

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

Hi Thomas, On Fri, Apr 15, 2016 at 03:03:12PM -0700, Thomas Garnier wrote: > +/* > + * Create PGD aligned trampoline table to allow real mode initialization > + * of additional CPUs. Consume only 1 additonal low memory page. > + */ > +void __meminit kaslr_trampoline_init(unsigned long

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

On April 18, 2016 7:46:05 AM PDT, Joerg Roedel wrote: >On Fri, Apr 15, 2016 at 03:03:12PM -0700, Thomas Garnier wrote: >> +#if defined(CONFIG_KASAN) >> +static const unsigned long memory_rand_end = KASAN_SHADOW_START; >> +#elfif defined(CONFIG_X86_ESPFIX64) >> +static const

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

On April 18, 2016 7:46:05 AM PDT, Joerg Roedel wrote: >On Fri, Apr 15, 2016 at 03:03:12PM -0700, Thomas Garnier wrote: >> +#if defined(CONFIG_KASAN) >> +static const unsigned long memory_rand_end = KASAN_SHADOW_START; >> +#elfif defined(CONFIG_X86_ESPFIX64) >> +static const unsigned long

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

Yes, it is. Certainly happened while editing patches (sorry about that), will be fixed on next iteration once I get a bit more feedback. On Mon, Apr 18, 2016 at 7:46 AM, Joerg Roedel wrote: > On Fri, Apr 15, 2016 at 03:03:12PM -0700, Thomas Garnier wrote: >> +#if

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

Yes, it is. Certainly happened while editing patches (sorry about that), will be fixed on next iteration once I get a bit more feedback. On Mon, Apr 18, 2016 at 7:46 AM, Joerg Roedel wrote: > On Fri, Apr 15, 2016 at 03:03:12PM -0700, Thomas Garnier wrote: >> +#if defined(CONFIG_KASAN) >> +static

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

On Fri, Apr 15, 2016 at 03:03:12PM -0700, Thomas Garnier wrote: > +#if defined(CONFIG_KASAN) > +static const unsigned long memory_rand_end = KASAN_SHADOW_START; > +#elfif defined(CONFIG_X86_ESPFIX64) > +static const unsigned long memory_rand_end = ESPFIX_BASE_ADDR; > +#elfif defined(CONFIG_EFI) >

Re: [RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

On Fri, Apr 15, 2016 at 03:03:12PM -0700, Thomas Garnier wrote: > +#if defined(CONFIG_KASAN) > +static const unsigned long memory_rand_end = KASAN_SHADOW_START; > +#elfif defined(CONFIG_X86_ESPFIX64) > +static const unsigned long memory_rand_end = ESPFIX_BASE_ADDR; > +#elfif defined(CONFIG_EFI) >

[RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

Randomizes the virtual address space of kernel memory sections (physical memory mapping, vmalloc & vmemmap) for x86_64. This security feature mitigates exploits relying on predictable kernel addresses. These addresses can be used to disclose the kernel modules base addresses or corrupt specific

[RFC v1 3/4] x86, boot: Implement ASLR for kernel memory sections (x86_64)

Randomizes the virtual address space of kernel memory sections (physical memory mapping, vmalloc & vmemmap) for x86_64. This security feature mitigates exploits relying on predictable kernel addresses. These addresses can be used to disclose the kernel modules base addresses or corrupt specific