All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hector Marco <hecmargi@upv.es>
To: Borislav Petkov <bp@alien8.de>
Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, Alexander Viro <viro@zeniv.linux.org.uk>,
	Jan-Simon <dl9pf@gmx.de>,
	linux-fsdevel@vger.kernel.org,
	Ismael Ripoll <iripoll@disca.upv.es>,
	Kees Cook - ASLRv3 <keescook@chromium.org>
Subject: Re: [PATCH] mm/x86: AMD Bulldozer ASLR fix
Date: Wed, 25 Mar 2015 19:29:26 +0100	[thread overview]
Message-ID: <5512FE86.9070209@upv.es> (raw)
In-Reply-To: <20150324191556.GA11571@pd.tnic>



El 24/03/15 a las 20:15, Borislav Petkov escribió:
> On Tue, Mar 24, 2015 at 07:00:48PM +0100, Hector Marco-Gisbert wrote:
>> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
>> index 15c5df9..a693d54 100644
>> --- a/arch/x86/kernel/cpu/amd.c
>> +++ b/arch/x86/kernel/cpu/amd.c
>> @@ -5,6 +5,7 @@
>>
>>   #include <linux/io.h>
>>   #include <linux/sched.h>
>> +#include <linux/random.h>
>>   #include <asm/processor.h>
>>   #include <asm/apic.h>
>>   #include <asm/cpu.h>
>> @@ -18,6 +19,8 @@
>>
>>   #include "cpu.h"
>>
>> +unsigned long rnd_bulldozer_bits = 0;
>> +
>>   static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
>>   {
>>   	u32 gprs[8] = { 0 };
>> @@ -488,6 +491,8 @@ static void bsp_init_amd(struct cpuinfo_x86 *c)
>>
>>   		va_align.mask	  = (upperbit - 1) & PAGE_MASK;
>>   		va_align.flags    = ALIGN_VA_32 | ALIGN_VA_64;
>> +		/* A random value per boot for bits 12,13 and 14 */
>> +		rnd_bulldozer_bits = get_random_int() & va_align.mask;
>
> Hmm, this should be done differently:
>
> va_align should have a ->bits member which gets ORed in into the hole
> made my va_align.mask...
>

Yes, It looks better using va_align.

>>   	}
>>   }
>>
>> diff --git a/arch/x86/kernel/sys_x86_64.c b/arch/x86/kernel/sys_x86_64.c
>> index 30277e2..5b8ad01 100644
>> --- a/arch/x86/kernel/sys_x86_64.c
>> +++ b/arch/x86/kernel/sys_x86_64.c
>> @@ -18,6 +18,7 @@
>>
>>   #include <asm/ia32.h>
>>   #include <asm/syscalls.h>
>> +#include <asm/amd_15h.h>
>>
>>   /*
>>    * Align a virtual address to avoid aliasing in the I$ on AMD F15h.
>> @@ -34,10 +35,16 @@ static unsigned long get_align_mask(void)
>>   	return va_align.mask;
>>   }
>>
>> +static unsigned long get_bulldozer_bits(void){
>> +
>> +	return rnd_bulldozer_bits & get_align_mask();
>> +}
>> +
>>   unsigned long align_vdso_addr(unsigned long addr)
>>   {
>>   	unsigned long align_mask = get_align_mask();
>> -	return (addr + align_mask) & ~align_mask;
>> +	addr = (addr + align_mask) & ~align_mask;
>> +	return addr | get_bulldozer_bits();
>>   }
>>
>>   static int __init control_va_addr_alignment(char *str)
>> @@ -137,7 +144,10 @@ arch_get_unmapped_area(struct file *filp, unsigned long addr,
>>   	info.high_limit = end;
>>   	info.align_mask = filp ? get_align_mask() : 0;
>
> 	info.align_bits = get_align_bits() : 0;
>

I see your point. The drawback of adding a new field (align_bits) to the info 
struct is that all architectures need to initialize the info.align_bits. In 
addition, the generic functions unmapped_area()/unmapped_area_topdown() in file 
mm/mmap.c, need to be modified to set the bits [12..14] using the new field 
info.align_bits.

A possible alternative which does not add a new field, is to use the 
"align_offset" variable. By adding the "get_align_bits()" value to the 
"align_offset" the bits [12..14] are randomized per boot.

Patch coming.
Hector.

>>   	info.align_offset = pgoff << PAGE_SHIFT;
>> -	return vm_unmapped_area(&info);
>> +	addr = vm_unmapped_area(&info);
>> +	if (!(addr & ~PAGE_MASK))
>> +		return filp ? (addr|get_bulldozer_bits()) : addr;
>> +	return addr;
>>   }
>>
>>   unsigned long
>> @@ -178,7 +188,7 @@ arch_get_unmapped_area_topdown(struct file *filp, const unsigned long addr0,
>>   	info.align_offset = pgoff << PAGE_SHIFT;
>>   	addr = vm_unmapped_area(&info);
>>   	if (!(addr & ~PAGE_MASK))
>> -		return addr;
>> +		return filp ? (addr|get_bulldozer_bits()) : addr;
>
> Ditto.
>

  reply	other threads:[~2015-03-25 18:29 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-24 18:00 [PATCH] mm/x86: AMD Bulldozer ASLR fix Hector Marco-Gisbert
2015-03-24 19:15 ` Borislav Petkov
2015-03-25 18:29   ` Hector Marco [this message]
2015-03-25 18:36   ` Hector Marco-Gisbert
2015-03-26 19:08     ` Borislav Petkov
2015-03-27 11:38       ` Hector Marco-Gisbert
2015-03-27 12:14         ` Ingo Molnar
2015-03-27 12:35           ` Borislav Petkov
2015-03-27 14:44         ` Borislav Petkov
2015-03-27 15:06           ` Hector Marco-Gisbert
2015-03-28 13:10           ` Kees Cook
2015-03-29  8:51           ` Ingo Molnar
2015-03-29  9:53             ` Borislav Petkov
2015-03-31  7:59               ` Ingo Molnar
2015-03-31 12:37         ` [tip:x86/mm] x86/mm: Improve AMD Bulldozer ASLR workaround tip-bot for Hector Marco-Gisbert

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=5512FE86.9070209@upv.es \
    --to=hecmargi@upv.es \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=dl9pf@gmx.de \
    --cc=hpa@zytor.com \
    --cc=iripoll@disca.upv.es \
    --cc=keescook@chromium.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=viro@zeniv.linux.org.uk \
    --cc=x86@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.