Re: [PATCH] x86/microcode: Add an option to reload microcode even if revision is unchanged

[Borislav Petkov <bp@alien8.de>]

On Fri, Sep 06, 2019 at 07:40:39AM -0700, Johannes Erdfelt wrote:
> You say that switching of CPU feature bits is problematic, but adding
> new features should result only in a warning ("x86/CPU: CPU features
> have changed after loading microcode, but might not take effect.").

That's the only sane thing we can do ATM - warn the user to reboot.

> Removing a CPU feature bit could be problematic. Other than HLE being
> removed on Haswell (which the kernel shouldn't use anyway), have there
> been any other cases?

I hope there aren't. There are cases, however, where late loading cannot
fix an issue, like paging on some old Atoms. And then you *must* do
early loading or stick it in the BIOS. But we all know how the latter
works in practice.

> I ask because we have successfully used late microcode loading on tens
> of thousands of hosts.

How do you deal with all the mitigations microcode loaded late?

> I'm a bit worried to see that there is a push to remove a feature that
> we currently rely on.

I'd love to remove it. And the fact that people rely on it more instead
of fixing their infrastructure to reboot machines and do early microcode
updates is making it worse. Microcode update should be batched with
kernel updates and that's it. They happen normally once-twice per year -
except the last two years but the last two years are not normal anyway
- and done. No need to do some crazy CPUID features reloading dances in
the kernel and making sure cores will see the updated paths and so on.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette