Messages in this thread | | | From | Arvind Sankar <> | Date | Sat, 24 Oct 2020 20:41:58 -0400 | Subject | RFC 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?
| |