[MODERATED] Re: [PATCH 3/9] TAA 3

[Borislav Petkov <bp@suse.de>]

On Fri, Oct 25, 2019 at 10:08:41AM +0100, speck for Andrew Cooper wrote:
> Its the perfect example here.  The answer is by requesting that Intel
> change bit 0's behaviour from causing #UD's to causing aborts.
> 
> The first version of this microcode was definitely not safe to late load.

Yap, exactly, and that is a problem: you can't always get the microcode
update to do what you want. IOW, we need some sort of communication
protocl between CPU vendors and OS which tells the OS what the microcode
provides and the OS can determine whether late loading would succeed.

tglx proposed a table of CPUID feature bits changing, for example, and
that is a first step in the right direction.

Changing the kernel to "reload" features is not trivial.

> Some userspace apparently gets confused when CPUID changes behind its
> back, which is why the CPUID control in bit 1 was split out from an
> otherwise monolithic bit 0.
> 
> At late load, choose (or not) to use bit 0 only.
> At boot, choose (or not) both bits 0 and 1 in unison.

Yes, and the fact that there are two bits is practically dictated by the
inability of the OS to handle late loading optimally. Otherwise, you
would've had only one bit.

All I'm saying is, late loading is such a problem that it even dictates
how microcode should look like.

> Noone has guaranteed that all microcode ever in the future is going to
> be safe to use on a running system.  If it really can't be made to be
> safe, then customers are really going to have to reboot.
> 
> However, there is a lot of effort going into trying to make sure that
> fixes such as this one are made safe for late loading.
> 
> To give a concrete example, we have customers who's elapsed time for a
> reboot, conforming to SLAs, is in excess of 9 months, and new microcode
> with critical fixes is coming out faster than that.  I bet that I'm not
> the only person on this list with this type of customer.

Oh I bet.

And I really think in the age of containers and live migration and all
that crap, what we should push for is freeing the host for proper kernel
and microcode update and then rebooting it. While the guests are moved
to another instance which has been rebooted already. I know, that is
hard and it has its warts too but the late loading is a PITA already.
And rebooting the host as part of maint downtime would give you a lot
more advantages.

But that's a whole another topic for another time and place.

-- 
Regards/Gruss,
    Boris.

SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG Nürnberg
--