Re: [PATCH] x86/microcode: Prevent attempting updates known to fail

[Alejandro Vallejo <alejandro.vallejo@cloud.com>]

On Fri, Jun 02, 2023 at 09:35:56PM +0100, Andrew Cooper wrote:
> For this MCU_CONTROL_DIS_MCU_LOAD case, we don't want to be trying to
> load new microcode because that's a waste of time, but we absolutely
> should query the current microcode revision.  It is frequently relevant
> for security reasons.
> 
> So I think we want to fine-grain things a little, and separate the
> concepts of "ucode info available" and "ucode loading available".  Per
> the current mechanism, that would involve supporting a case where
> ucode_ops.collect_cpu_info() is available but
> ucode_ops.apply_microcode() is not.
I was going after something to that effect, yes.

> 
> ~Andrew
> 
> P.S. also in our copious free time, we need to start supporting the
> Intel min_rev field, which is more complicated than it sounds.
> 
> min_rev is vaguely defined as being relevant to block updates "after
> you've evaluated CPUID and made decisions based on it", but here in Xen
> we do also do livepatching and late loading to explicitly make use of
> newly enumerated features.
> 
> So we need a way of xen-ucode saying "please really do load this,
> because I as the admin think it will be fine in combination with the
> livepatch I'm about to apply".
> 
> My best idea for this is to have a `--force` option to pass to Xen to
> skip the revision checks, which will require either a new hypercall, or
> perhaps borrowing a high bit from the size field in the current hypercall.
> 
> With a force option in place, the boot time ucode=allow-same can go
> away.  It has become distinctly less useful now that we were forced do
> this unilaterally on AMD CPUs, and separating "allow same because of HW
> bugs" from "the Admin promised they knew what they were doing" would be
> better for testing.
I've created a GitLab issue to keep track of that:

  https://gitlab.com/xen-project/xen/-/issues/164

There's also the case of downgrades. We probably want to at least avoid
going back to a microcode revision with different min_rev field.

Alejandro