linux-kernel - Re: [PATCH v2 RESEND 2/2] x86/mm/KASLR: Do not adapt the 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 for Android: free password hash cracker in your pocket

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

Message-ID: <20170928090143.m6sog2am2ccz5dm4@gmail.com>
Date:   Thu, 28 Sep 2017 11:01:43 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Baoquan He <bhe@...hat.com>
Cc:     rja@....com, frank.ramsay@....com, linux-kernel@...r.kernel.org,
        x86@...nel.org, mingo@...hat.com, tglx@...utronix.de,
        hpa@...or.com, thgarnie@...gle.com, keescook@...omium.org,
        akpm@...ux-foundation.org, yamada.masahiro@...ionext.com
Subject: Re: [PATCH v2 RESEND 2/2] x86/mm/KASLR: Do not adapt the size of the
 direct mapping section for SGI UV system


* Baoquan He <bhe@...hat.com> wrote:

> Hi Ingo,
> 
> On 09/28/17 at 09:56am, Ingo Molnar wrote:
> > > diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
> > > index af599167fe3c..4d68c08df82d 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())
> > >  		kaslr_regions[0].size_tb = memory_tb;
> > This is really an ugly hack. Is kaslr_regions[] incorrect? If so then it should be 
> > corrected instead of uglifying the code that uses it...
> 
> Thanks for looking into this!
> 
> If on SGI UV system, the kaslr_regions[0].size_tb, namely the size of
> the direct mapping section, is incorrect. 
> 
> Its direct mapping size includes two parts:
> #1 RAM size of system
> #2 MMIOH region size which only SGI UV system has.
> 
> However, the #2 can only be got till uv_system_init() is called in
> native_smp_prepare_cpus(). That is too late for mm KASLR calculation.
> That's why I made this hack.
> 
> I checked uv_system_init() code, seems not easy to know the size of
> MMIOH region before or inside kernel_randomize_memory(). I have CCed UV
> devel experts, not sure if they have any idea about this. Otherwise,
> this patch could be the only way I can think of.
> 
> Hi Mike and Russ,
> 
> Is there any chance we can get the size of MMIOH region before mm KASLR
> code, namely before we call kernel_randomize_memory()?

I don't mind system specific quirks to hardware enumeration details, as long as 
they don't pollute generic code with such special hacks.

I.e. in this case it's wrong to allow kaslr_regions[0].size_tb to be wrong. Any 
other code that relies on it in the future will be wrong as well on UV systems.

The right quirk would be to fix that up where it gets introduced, or something 
like that.

Thanks,

	Ingo