Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1647189

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

Show all headers | View raw

On Mon, May 22, 2017 at 9:30 AM, Mike Travis <mike.travis@hpe.com> wrote:
>
>
> On 5/21/2017 4:17 PM, Baoquan He wrote:
>
> 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@redhat.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?
>
>
> While the region is much smaller it can occupy address space > 32TB, up to
> 64TB - <MMIOH size>.
> On a system with 64TB, part of the address space is taken from RAM to
> accommodate this region.
> This has been true since UV1.

I see, it would be better to know the different places to tailor the
memory_tb accordingly. I understand that might be difficult to do and
I rather have KASLR memory randomization working for now.

Reviewed-by: thgarnie@google.com

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



-- 
Thomas

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

[PATCH v2 0/2] x86/mm/KASLR: Do not adapt size of the direct mapping section for SGI UV system Baoquan He <bhe@redhat.com> - 2017-05-20 14:10 +0200
  [PATCH v2 2/2] x86/mm/KASLR: Do not adapt size of the direct mapping section for SGI UV system Baoquan He <bhe@redhat.com> - 2017-05-20 14:10 +0200
    Re: [PATCH v2 2/2] x86/mm/KASLR: Do not adapt size of the direct  mapping section for SGI UV system Thomas Garnier <thgarnie@google.com> - 2017-05-21 22:40 +0200
      Re: [PATCH v2 2/2] x86/mm/KASLR: Do not adapt size of the direct  mapping section for SGI UV system Baoquan He <bhe@redhat.com> - 2017-05-22 01:20 +0200
        Re: [PATCH v2 2/2] x86/mm/KASLR: Do not adapt size of the direct  mapping section for SGI UV system Baoquan He <bhe@redhat.com> - 2017-05-22 01:20 +0200
          Re: [PATCH v2 2/2] x86/mm/KASLR: Do not adapt size of the direct  mapping section for SGI UV system Thomas Garnier <thgarnie@google.com> - 2017-05-22 19:10 +0200

csiph-web