Messages in this thread | | | From | Arvind Sankar <> | Date | Sat, 24 Oct 2020 22:20:03 -0400 | Subject | Re: RFC x86/boot/64: BOOT_PGT_SIZE definition for compressed kernel |
| |
On Sat, Oct 24, 2020 at 08:41:58PM -0400, Arvind Sankar wrote: > 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?
Or just bump BOOT_PGT_SIZE to some largeish number?
| |