]> xenbits.xensource.com Git - people/royger/xen.git/commit
x86/boot: Fix PVH boot during boot_info transition period
authorAndrew Cooper <andrew.cooper3@citrix.com>
Tue, 22 Oct 2024 10:15:26 +0000 (11:15 +0100)
committerAndrew Cooper <andrew.cooper3@citrix.com>
Tue, 22 Oct 2024 15:16:43 +0000 (16:16 +0100)
commit0fe607b2a1440191b59cc6da83a3e717bf3ff7c0
tree5ff50da1dd7611d7c192212d388bc38bd3844912
parentb837d02163ff19e2440cae766e2bc50956da5410
x86/boot: Fix PVH boot during boot_info transition period

multiboot_fill_boot_info() taking the physical address of the multiboot_info
structure leads to a subtle use-after-free on the PVH path, with rather less
subtle fallout.

The pointers used by __start_xen(), mbi and mod, are either:

 - MB:  Directmap pointers into the trampoline, or
 - PVH: Xen pointers into .initdata, or
 - EFI: Directmap pointers into Xen.

Critically, these either remain valid across move_xen() (MB, PVH), or rely on
move_xen() being inhibited (EFI).

The conversion to multiboot_fill_boot_info(), taking only mbi_p, makes the PVH
path use directmap pointers into Xen, as well as move_xen() which invalidates
said pointers.

Switch multiboot_fill_boot_info() to consume the same virtual addresses that
__start_xen() currently uses.  This keeps all the pointers valid for the
duration of __start_xen(), for all boot protocols.

It can be safely untangled once multiboot_fill_boot_info() takes a full copy
the multiboot info data, and __start_xen() has been moved over to using the
new boot_info consistently.

Right now, bi->{loader,cmdline,mods} are problematic.  Nothing uses
bi->mods[], and nothing uses bi->cmdline after move_xen().

bi->loader is used after move_xen(), although only for cmdline_cook() of
dom0's cmdline, where it happens to be benign because PVH boot skips the
inspection of the bootloader name.

Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Roger Pau Monné <roger.pau@citrix.com>
xen/arch/x86/setup.c