linux-kernel - Re: [PATCH v2 2/2] x86/mm/KASLR: Do not adapt size of the direct mapping section for SGI UV system

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 22 May 2017 07:14:37 +0800
From:   Baoquan He <bhe@...hat.com>
To:     Thomas Garnier <thgarnie@...gle.com>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        the arch/x86 maintainers <x86@...nel.org>,
        Kees Cook <keescook@...omium.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>
Subject: Re: [PATCH v2 2/2] x86/mm/KASLR: Do not adapt size of the direct
 mapping section for SGI UV system

On 05/21/17 at 01:38pm, Thomas Garnier wrote:
> On Sat, May 20, 2017 at 5:02 AM, Baoquan He <bhe@...hat.com> wrote:
> >  arch/x86/mm/kaslr.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
> > index aed2064..20b0456 100644
> > --- a/arch/x86/mm/kaslr.c
> > +++ b/arch/x86/mm/kaslr.c
> > @@ -27,6 +27,7 @@
> >  #include <asm/pgtable.h>
> >  #include <asm/setup.h>
> >  #include <asm/kaslr.h>
> > +#include <asm/uv/uv.h>
> >
> >  #include "mm_internal.h"
> >
> > @@ -123,7 +124,7 @@ void __init kernel_randomize_memory(void)
> >                 CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING;
> >
> >         /* Adapt phyiscal memory region size based on available memory */
> > -       if (memory_tb < kaslr_regions[0].size_tb)
> > +       if (memory_tb < kaslr_regions[0].size_tb && !is_early_uv_system())
> 
> Given your example, any way we could just restrict memory_tb to be
> 32TB? Or different configurations will result in different mappings?

Thanks for looking into this, Thomas!

For that machine where I used to reproduce the bug and test, 32TB memory
need be mapped to the direct mapping region. I am not sure if SGI UV
system has larger MMIOH region now or in the future in different machine.
If they have machine owning MMIOH region bigger than 64TB, then it's a
problem SGI UV need fix because that will break system whether kaslr
enabled or not.

Hi Mike, Russ and Frank,

About Thomas's question, could you help answer it? Could other SGI UV
system has MMIOH region bigger than 32TB?

Thanks
Baoquan

> 
> >                 kaslr_regions[0].size_tb = memory_tb;
> >
> >         /* Calculate entropy available between regions */