Commits
ca0e22d4f011 ("x86/boot/compressed/64: Always switch to own page table")
8570978ea030 ("x86/boot/compressed/64: Don't pre-map memory in KASLR code")
set up a new page table in the decompressor stub, but without explicit
mappings for boot_params and the kernel command line, relying on the #PF
handler instead.
This is fragile, as boot_params and the command line mappings are
required for the main kernel. If EARLY_PRINTK and RANDOMIZE_BASE are
disabled, a QEMU/OVMF boot never accesses the command line in the
decompressor stub, and so it never gets mapped. The main kernel accesses
it from the identity mapping if AMD_MEM_ENCRYPT is enabled, and will
crash.
Fix this by adding back the explicit mapping of boot_params and the
command line.
Note: the changes also removed the explicit mapping of the main kernel,
with the result that .bss and .brk may not be in the identity mapping,
but those don't get accessed by the main kernel before it switches to
its own page tables.
Signed-off-by: Arvind Sankar <[email protected]>
---
arch/x86/boot/compressed/ident_map_64.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/x86/boot/compressed/ident_map_64.c b/arch/x86/boot/compressed/ident_map_64.c
index 070cda70aef3..8edeff0d9324 100644
--- a/arch/x86/boot/compressed/ident_map_64.c
+++ b/arch/x86/boot/compressed/ident_map_64.c
@@ -150,10 +150,13 @@ void initialize_identity_maps(void)
}
/*
- * New page-table is set up - map the kernel image and load it
- * into cr3.
+ * New page-table is set up - map the kernel image, boot_params and the
+ * command line, and load the new page-table into cr3.
*/
add_identity_map((unsigned long)_head, (unsigned long)_end - (unsigned long)_head);
+ add_identity_map((unsigned long)boot_params, sizeof(*boot_params));
+ add_identity_map(get_cmd_line_ptr(), COMMAND_LINE_SIZE);
+
write_cr3(top_level_pgt);
}
--
2.26.2
On Wed, Oct 07, 2020 at 03:53:50PM -0400, Arvind Sankar wrote:
> This is fragile, as boot_params and the command line mappings are
> required for the main kernel. If EARLY_PRINTK and RANDOMIZE_BASE are
> disabled, a QEMU/OVMF boot never accesses the command line in the
> decompressor stub, and so it never gets mapped. The main kernel accesses
> it from the identity mapping if AMD_MEM_ENCRYPT is enabled, and will
> crash.
Looked again, and I think that is wrong for boot_params, which are
touched unconditionally at the beginning of extract_kernel().
For the cmdline you are right, but one of CONFIG_ACPI,
CONFIG_RANDOMIZE_BASE, CONFIG_X86_5LEVEL or CONFIG_EARLY_PRINTK is
sufficient to have it touched during this boot stage.
Regards,
Joerg
On Wed, Oct 07, 2020 at 03:53:50PM -0400, Arvind Sankar wrote:
> Commits
>
> ca0e22d4f011 ("x86/boot/compressed/64: Always switch to own page table")
> 8570978ea030 ("x86/boot/compressed/64: Don't pre-map memory in KASLR code")
>
> set up a new page table in the decompressor stub, but without explicit
> mappings for boot_params and the kernel command line, relying on the #PF
> handler instead.
>
> This is fragile, as boot_params and the command line mappings are
> required for the main kernel. If EARLY_PRINTK and RANDOMIZE_BASE are
> disabled, a QEMU/OVMF boot never accesses the command line in the
> decompressor stub, and so it never gets mapped. The main kernel accesses
> it from the identity mapping if AMD_MEM_ENCRYPT is enabled, and will
> crash.
>
> Fix this by adding back the explicit mapping of boot_params and the
> command line.
>
> Note: the changes also removed the explicit mapping of the main kernel,
> with the result that .bss and .brk may not be in the identity mapping,
> but those don't get accessed by the main kernel before it switches to
> its own page tables.
>
> Signed-off-by: Arvind Sankar <[email protected]>
> ---
> arch/x86/boot/compressed/ident_map_64.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/boot/compressed/ident_map_64.c b/arch/x86/boot/compressed/ident_map_64.c
> index 070cda70aef3..8edeff0d9324 100644
> --- a/arch/x86/boot/compressed/ident_map_64.c
> +++ b/arch/x86/boot/compressed/ident_map_64.c
> @@ -150,10 +150,13 @@ void initialize_identity_maps(void)
> }
>
> /*
> - * New page-table is set up - map the kernel image and load it
> - * into cr3.
> + * New page-table is set up - map the kernel image, boot_params and the
> + * command line, and load the new page-table into cr3.
> */
Please extend this comment to state that boot_params and command-line
need to be mapped here because they might not be touched (and thus
mapped) before jumping to the uncompressed kernel image. Otherwise no
one will remember why those need to be pre-mapped in a couple of years.
With that change and the add_identity_map() call adjusted:
Reviewed-by: Joerg Roedel <[email protected]>
On Thu, Oct 08, 2020 at 11:48:36AM +0200, Joerg Roedel wrote:
> On Wed, Oct 07, 2020 at 03:53:50PM -0400, Arvind Sankar wrote:
> > This is fragile, as boot_params and the command line mappings are
> > required for the main kernel. If EARLY_PRINTK and RANDOMIZE_BASE are
> > disabled, a QEMU/OVMF boot never accesses the command line in the
> > decompressor stub, and so it never gets mapped. The main kernel accesses
> > it from the identity mapping if AMD_MEM_ENCRYPT is enabled, and will
> > crash.
>
> Looked again, and I think that is wrong for boot_params, which are
> touched unconditionally at the beginning of extract_kernel().
Yes, command line is the only thing that actually breaks, but it is more
robust to explicitly make sure boot_params is mapped as well. There's no
specific alignment requirement for boot_params AFAICT, so at least in
theory it's possible that it would be split across a PMD boundary and
only get half-mapped in the decompressor. It's easier not to have to
worry about it.
>
> For the cmdline you are right, but one of CONFIG_ACPI,
> CONFIG_RANDOMIZE_BASE, CONFIG_X86_5LEVEL or CONFIG_EARLY_PRINTK is
> sufficient to have it touched during this boot stage.
>
X86_5LEVEL accesses it before the switch to the new page tables, so that
doesn't help in getting it mapped. ACPI only accesses it if KASLR is
enabled (as well as MEMORY_HOTREMOVE).
Thanks.