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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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.

~Andrew