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]

Message-ID: <20170521231737.GA4473@x1>
Date:   Mon, 22 May 2017 07:17:37 +0800
From:   Baoquan He <bhe@...hat.com>
To:     Thomas Garnier <thgarnie@...gle.com>, mike.travis@....com,
        rja@....com, frank.ramsay@....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

Sorry, forget 'To' Mike, Russ and Frank

On 05/22/17 at 07:14am, Baoquan He wrote:
> 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 */