linux-kernel - Re: [tip:x86/urgent] x86/mm/KASLR: Compute the size of the vmemmap section properly

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:   Sat, 8 Jun 2019 10:14:04 +0800
From:   Baoquan He <bhe@...hat.com>
To:     tglx@...utronix.de, stable@...r.kernel.org, mingo@...nel.org,
        x86@...nel.org, linux-kernel@...r.kernel.org, peterz@...radead.org,
        keescook@...omium.org, bp@...e.de, luto@...nel.org, hpa@...or.com,
        kirill@...ux.intel.com, dave.hansen@...ux.intel.com
Cc:     linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/urgent] x86/mm/KASLR: Compute the size of the vmemmap
 section properly

On 06/07/19 at 02:16pm, tip-bot for Baoquan He wrote:
> Commit-ID:  00e5a2bbcc31d5fea853f8daeba0f06c1c88c3ff
> Gitweb:     https://git.kernel.org/tip/00e5a2bbcc31d5fea853f8daeba0f06c1c88c3ff
> Author:     Baoquan He <bhe@...hat.com>
> AuthorDate: Thu, 23 May 2019 10:57:44 +0800
> Committer:  Borislav Petkov <bp@...e.de>
> CommitDate: Fri, 7 Jun 2019 23:12:13 +0200
> 
> x86/mm/KASLR: Compute the size of the vmemmap section properly
> 
> The size of the vmemmap section is hardcoded to 1 TB to support the
> maximum amount of system RAM in 4-level paging mode - 64 TB.
> 
> However, 1 TB is not enough for vmemmap in 5-level paging mode. Assuming
> the size of struct page is 64 Bytes, to support 4 PB system RAM in 5-level,
> 64 TB of vmemmap area is needed:
> 
>   4 * 1000^5 PB / 4096 bytes page size * 64 bytes per page struct / 1000^4 TB = 62.5 TB.

Thanks for picking this, Boris.

Here, 4PB = 4*2^50 = 4*1024^5, the vmemmap should be 64 TB, am I right?

> 
> This hardcoding may cause vmemmap to corrupt the following
> cpu_entry_area section, if KASLR puts vmemmap very close to it and the
> actual vmemmap size is bigger than 1 TB.