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
