On 23/10/2024 8:10 am, Alan Robinson wrote: > Hi Andrew, > > A small suggestion for the commit log.. > > On Tue, Oct 22, 2024 at 12:41:14PM +0000, Andrew Cooper wrote: >> 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 > of the multiboot info data, and __start_xen() has been moved over to using > the
Thanks for noticing. Unfortunately this change was already taken to unblock other pending work. ~Andrew
