All of lore.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Hector Marco-Gisbert <hecmargi@upv.es>
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, kees Cook <keescook@chromium.org>,
	Ismael Ripoll <iripoll@disca.upv.es>
Subject: Re: [PATCH] mm/x86: AMD Bulldozer ASLR fix
Date: Thu, 26 Mar 2015 20:08:00 +0100	[thread overview]
Message-ID: <20150326190800.GF27751@pd.tnic> (raw)
In-Reply-To: <1427308577-2590-1-git-send-email-hecmargi@upv.es>

On Wed, Mar 25, 2015 at 07:36:17PM +0100, Hector Marco-Gisbert wrote:
> A bug in Linux ASLR implementation which affects some AMD processors has been
> found. The issue affects to all Linux process even if they are not using
> shared libraries (statically compiled).
> 
> The problem appears because some mmapped objects (VDSO, libraries, etc.)
> are poorly randomized in an attempt to avoid cache aliasing penalties for
> AMD Bulldozer (Family 15h) processors.
> 
> Affected systems have reduced the mmapped files entropy by eight.
> 
> The following output is the run on an AMD Opteron 62xx class CPU processor
> under x86_64 Linux 4.0.0:
> 
> for i in `seq 1 10`; do cat /proc/self/maps | grep "r-xp.*libc" ; done
> b7588000-b7736000 r-xp 00000000 00:01 4924       /lib/i386-linux-gnu/libc.so.6
> b7570000-b771e000 r-xp 00000000 00:01 4924       /lib/i386-linux-gnu/libc.so.6
> b75d0000-b777e000 r-xp 00000000 00:01 4924       /lib/i386-linux-gnu/libc.so.6
> b75b0000-b775e000 r-xp 00000000 00:01 4924       /lib/i386-linux-gnu/libc.so.6
> b7578000-b7726000 r-xp 00000000 00:01 4924       /lib/i386-linux-gnu/libc.so.6
> 
> As shown in the previous output, the bits 12, 13 and 14 are always 0. The address
> always ends in 0x8000 or 0x0000.
> 
> The bug is caused by a hack to improve performance by avoiding cache aliasing
> penalties in the Family 15h of AMD Bulldozer processors (commit: dfb09f9b).
> 
> 32-bit systems are specially sensitive to this issue because the entropy for
> libraries is reduced from 2^8 to 2^5, which means that libraries only have 32
> different places where they can be loaded.
> 
> This patch randomizes per boot the three affected bits, rather than setting
> them to zero. Since all the shared pages have the same value at the bits
> [12..14], there is no cache aliasing problems (which is supposed to be the
> cause of performance loss). On the other hand, since the value is not
> known by a potential remote attacker, the ASLR preserves its effectiveness.
> 
> More details at:
> 
> http://hmarco.org/bugs/AMD-Bulldozer-linux-ASLR-weakness-reducing-mmaped-files-by-eight.html
> 
> 
> Signed-off-by: Hector Marco-Gisbert <hecmargi@upv.es>
> Signed-off-by: Ismael Ripoll <iripoll@disca.upv.es>
> ---
>  arch/x86/include/asm/elf.h   |  1 +
>  arch/x86/kernel/cpu/amd.c    |  3 +++
>  arch/x86/kernel/sys_x86_64.c | 20 +++++++++++++++++---
>  3 files changed, 21 insertions(+), 3 deletions(-)

Please run your patch through checkpatch to address minor coding style
issues.

> diff --git a/arch/x86/include/asm/elf.h b/arch/x86/include/asm/elf.h
> index ca3347a..bd292ce 100644
> --- a/arch/x86/include/asm/elf.h
> +++ b/arch/x86/include/asm/elf.h
> @@ -365,6 +365,7 @@ enum align_flags {
>  struct va_alignment {
>  	int flags;
>  	unsigned long mask;
> +	unsigned long bits;
>  } ____cacheline_aligned;
>  
>  extern struct va_alignment va_align;
> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> index 15c5df9..45a41be 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>
> @@ -488,6 +489,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;

Newline here.

> +		/* A random value per boot for bits 12,13 and 14 */

		"A random value for bit slice [12:upper_bit)"

the interval end is open.

> +		va_align.bits = get_random_int() & va_align.mask;
>  	}
>  }
>  
> diff --git a/arch/x86/kernel/sys_x86_64.c b/arch/x86/kernel/sys_x86_64.c
> index 30277e2..d38905d 100644
> --- a/arch/x86/kernel/sys_x86_64.c
> +++ b/arch/x86/kernel/sys_x86_64.c
> @@ -34,10 +34,16 @@ static unsigned long get_align_mask(void)
>  	return va_align.mask;
>  }

Please add a short comment here over this function explaining why we're
doing this and thus what the value that goes into ->align_offset below
represents.

> +static unsigned long get_align_bits(void){
> +
> +	return va_align.bits & get_align_mask();
> +}
> +

...

Thanks.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

  reply	other threads:[~2015-03-26 19:08 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
2015-03-25 18:36   ` Hector Marco-Gisbert
2015-03-26 19:08     ` Borislav Petkov [this message]
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=20150326190800.GF27751@pd.tnic \
    --to=bp@alien8.de \
    --cc=akpm@linux-foundation.org \
    --cc=dl9pf@gmx.de \
    --cc=hecmargi@upv.es \
    --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.