On 28.10.2024 10:18, Andrew Cooper wrote:
> The comment highlights just how bogus this really is. Being an initcall, the
> boot allocator is long gone, and bootstrap_unmap() is a no-op.
How's the boot allocator coming into the picture here? This is all about
(un)mapping, not allocating.
> The fact there is nothing to do should be a giant red flag about the validity
> of the mappings "being freed". Indeed, they both constitute use-after-frees.
I can't spot any use-after-free; the pointers in question ...
> --- a/xen/arch/x86/cpu/microcode/core.c
> +++ b/xen/arch/x86/cpu/microcode/core.c
> @@ -758,28 +758,6 @@ int microcode_update(XEN_GUEST_HANDLE(const_void) buf,
> return continue_hypercall_on_cpu(0, microcode_update_helper, buffer);
> }
>
> -static int __init cf_check microcode_init(void)
> -{
> - /*
> - * At this point, all CPUs should have updated their microcode
> - * via the early_microcode_* paths so free the microcode blob.
> - */
> - if ( ucode_blob.size )
> - {
> - bootstrap_unmap();
> - ucode_blob.size = 0;
> - ucode_blob.data = NULL;
> - }
> - else if ( ucode_mod.mod_end )
> - {
> - bootstrap_unmap();
> - ucode_mod.mod_end = 0;
> - }
> -
> - return 0;
> -}
> -__initcall(microcode_init);
... aren't used anywhere. bootstrap_unmap() is "just in case" (perhaps indeed
a no-op at least nowadays), and the rest is field clobbering. I'm okay with the
code change, so
Acked-by: Jan Beulich <[email protected]>
yet I'd like to ask for the description to be "softened" some.
Jan
