lkml.org 
[lkml]   [2019]   [Jun]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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@redhat.com>
> AuthorDate: Thu, 23 May 2019 10:57:44 +0800
> Committer: Borislav Petkov <bp@suse.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.

\
 
 \ /
  Last update: 2019-06-08 04:14    [W:0.150 / U:0.604 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site