On 19.11.2024 22:57, Andrew Cooper wrote:
> Following commit cd7cc5320bb2 ("x86/boot: add start and size fields to struct
> boot_module"), bootstrap_map*() works as soon as boot_info is populated.
I'm struggling with following where this connection is coming from. Before
Daniel's work (e.g. in 4.19) we have
if ( pvh_boot )
{
ASSERT(mbi_p == 0);
pvh_init(&mbi, &mod);
}
else
{
mbi = __va(mbi_p);
mod = __va(mbi->mods_addr);
}
Leaving aside the issue with the PVH side, what would have stood in the way
of accessing any of the modules (e.g. ucode) right afterwards?
The question is also relevant when considering the potential need for
backporting this functionality (even if not directly this change, as the
dependency on Daniel's work would then need stripping off): There might
conceivably be a point where for security needs way may need to have this
as early as you now put it.
> Resolve the todo, and move microcode loading to be the eariest action after
> establishing a console.
So yes, this is merely strengthening a dependency we already have:
bootstrap_map_addr() arranging to avoid allocating any page table memory.
Yet don't we rather need to move away from this? We don't know what's in
the excess space we map, and hence we better wouldn't have any (cachable)
mappings thereof.
Jan
