lkml.org 
[lkml]   [2020]   [Oct]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRFC x86/boot/64: BOOT_PGT_SIZE definition for compressed kernel
Hi, I think the definition of BOOT_PGT_SIZE in
arch/x86/include/asm/boot.h is insufficient, especially after
ca0e22d4f011 ("x86/boot/compressed/64: Always switch to own page table")

Currently, it allocates 6 pages if KASLR is disabled, and either 17 or
19 pages depending on X86_VERBOSE_BOOTUP if KASLR is enabled.

- The X86_VERBOSE_BOOTUP test shouldn't be done: that only disables
debug messages, but warnings/errors are always output to VGA memory,
so the two extra pages for mapping video RAM are always needed.

- The calculation wasn't updated for X86_5LEVEL, which requires at least
one more page for the P4D level, and in theory could require two extra
pages for each of the 4 mappings (compressed kernel, output kernel,
boot_params and command line), though that would require a system with
truly ginormous amounts of RAM.

- If KASLR is disabled, there are only 6 pages, but now that we're
always setting up our own page table, we need 1+(2+2)*3 (one PGD, and
two PUD and two PMD pages for kernel, boot_params and command line),
and 2 more pages for the video RAM, and more for 5-level. Even for
!RELOCATABLE, 13 pages might be needed.

- SEV-ES needs one more page because it needs to do a PTE-level mapping
for the GHCB page.

- The static calculation is also busted because
boot/compressed/{kaslr.c,acpi.c} can scan the setup data, EFI
configuration tables and the EFI memmap, and none of these are
accounted for. They used to be scanned while still on the
firmware/bootloader page tables, but now our page tables have to cover
them as well. Trying to add up the worst case for all of these, and
anything else the compressed kernel might potentially access seems
like a lost cause.

We could do something similar to what the main kernel does with
early_dynamic_pgts: map the compressed kernel at a fixed virtual
address (in negative address space, say); recycle all the other mappings
until we're done with decompression, and then map the output,
boot_params and command line. The number of pages needed for this can be
statically calculated, for 4-level paging we'd need 2 pages for the
fixed mapping, 12 pages for the other three, and one PGD page.

Thoughts?

\
 
 \ /
  Last update: 2020-10-25 02:43    [W:0.067 / U:0.760 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site