Re: [PATCH v3 4/4] x86/ucode: Add Kconfig option to remove microcode loading

[Jan Beulich <jbeulich@xxxxxxxx>]

On 13.01.2026 17:47, Andrew Cooper wrote:
> On 13/01/2026 4:12 pm, Alejandro Vallejo wrote:
>>>> --- a/xen/arch/x86/cpu/microcode/intel.c
>>>> +++ b/xen/arch/x86/cpu/microcode/intel.c
>>>> @@ -408,17 +408,20 @@ static const char __initconst intel_cpio_path[] =
>>>>      "kernel/x86/microcode/GenuineIntel.bin";
>>>>  
>>>>  static const struct microcode_ops __initconst_cf_clobber intel_ucode_ops 
>>>> = {
>>>> -    .cpu_request_microcode            = cpu_request_microcode,
>>>> +    .cpu_request_microcode            = 
>>>> MICROCODE_OP(cpu_request_microcode),
>>>>      .collect_cpu_info                 = collect_cpu_info,
>>>> -    .apply_microcode                  = apply_microcode,
>>>> -    .compare                          = intel_compare,
>>>> -    .cpio_path                        = intel_cpio_path,
>>>> +    .apply_microcode                  = MICROCODE_OP(apply_microcode),
>>>> +    .compare                          = MICROCODE_OP(intel_compare),
>>>> +    .cpio_path                        = MICROCODE_OP(intel_cpio_path),
>>>>  };
>>> While I appreciate the intention with MICROCODE_OP(), I'm not really happy
>>> with function pointer members left in place just for them to be NULL
>>> everywhere. What if a call site remains unguarded? With PV guests that
>>> would be a privilege escalation XSA.
>> I see where you're coming from, but these are already NULL if microcode
>> loading is not exposed by the underlying hypervisor (if any), or is blocked 
>> by
>> hardware in Intel, so arguably that worry is orthogonal to this.
> 
> Also because they're cf_clobber, the calls are turned into UDs.  We
> won't follow a function pointer to 0.

Hmm, yes, the alternative patching will guarantee that. That hasn't got
anything to do with cf_clobber though, I don't think.

Jan