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 <b...@redhat.com> > AuthorDate: Thu, 23 May 2019 10:57:44 +0800 > Committer: Borislav Petkov <b...@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.
