linux-kernel - Re: [PATCH 2/2] x86/mm/KASLR: Adjust the vmemmap size according to paging mode

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: <20180903074718.GD1740@192.168.1.3>
Date:   Mon, 3 Sep 2018 15:47:18 +0800
From:   Baoquan He <bhe@...hat.com>
To:     "Kirill A. Shutemov" <kirill@...temov.name>
Cc:     tglx@...utronix.de, mingo@...nel.org, hpa@...or.com,
        thgarnie@...gle.com, kirill.shutemov@...ux.intel.com,
        x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] x86/mm/KASLR: Adjust the vmemmap size according to
 paging mode

On 09/02/18 at 11:52pm, Kirill A. Shutemov wrote:
> On Thu, Aug 30, 2018 at 11:25:12PM +0800, Baoquan He wrote:
> > Hi Kirill,
> > 
> > I made a new version according to your suggestion, just a little
> > different, I didn't make 1TB as default, just calculate with the actual
> > size, then align up to 1TB boundary.  Just found kcore is printing more
> > entries than before, I thought it's caused by my code, later got it was
> > touchde by other people.
> > 
> > Any comment about this? I can change accordingly.
> 
> Looks good to me.
> 
> But there's corner case when struct page is unreasonably large and
> vmemmap_size will be way to large. We probably have to report an error if
> we cannot fit vmemmap properly into virtual memory layout.

Hmm, sizeof(struct page) can't exceed one whole page surely, otherwise
system bootup can't go over vmemmap initlization. Except of this, we may
need think about the virtual memory layout which vmemmap can be allowed
to occupy.

If KASAN enabled, KASLR disabled,
4-level 1TB + 1TB hole (2TB)
5-level 512TB + 2034TB hole (2.5PB)

If KASAN disabled, KASLR enabled,
4-level 1TB + 1TB hole + 16TB  (18TB)
5-level 512TB + 2034TB hole + 8PB (10.5PB)

So, as you can see, if add check in memory KASLR code, we should only
consider KASLR enabled case. We possibly don't need to worry about
5-level case since the size 10.5PB is even bigger than the maximum
physical RAM mapping size. For 4-level, 18TB align to multiples of 2, it
will be 32 times of the current 1TB, then we usually assume 64 as the
default value of sizeof(struct page), then 64*32 == 1024. So we can add
check like this, what do you think? Or any other idea?

diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
index 1db8e166455e..776ec759a87c 100644
--- a/arch/x86/mm/kaslr.c
+++ b/arch/x86/mm/kaslr.c
@@ -90,6 +90,7 @@ void __init kernel_randomize_memory(void)
        BUILD_BUG_ON(vaddr_start >= vaddr_end);
        BUILD_BUG_ON(vaddr_end != CPU_ENTRY_AREA_BASE);
        BUILD_BUG_ON(vaddr_end > __START_KERNEL_map);
+       BUILD_BUG_ON(sizeof(struct page ) > PAGE_SIZE/4);
 
        if (!kaslr_memory_enabled())
                return;


For 5-level paging mode, we
may not need to worry about that. Since KASAN 

***4-level***
ffffea0000000000 - ffffeaffffffffff (=40 bits) virtual memory map (1TB)
... unused hole ...
ffffec0000000000 - fffffbffffffffff (=44 bits) kasan shadow memory (16TB)
... unused hole ...



***5-level***
ffd4000000000000 - ffd5ffffffffffff (=49 bits) virtual memory map (512TB)
... unused hole ...
ffdf000000000000 - fffffc0000000000 (=53 bits) kasan shadow memory (8PB) 

> 
> -- 
>  Kirill A. Shutemov