Messages in this thread | | | From | Andy Lutomirski <> | Date | Fri, 19 Sep 2014 09:13:08 -0700 | Subject | Re: x86, microcode: BUG: microcode update that changes x86_capability |
| |
On Fri, Sep 19, 2014 at 8:00 AM, Borislav Petkov <bp@alien8.de> wrote: > On Fri, Sep 19, 2014 at 07:54:14AM -0500, Chuck Ebbert wrote: >> Assuming we can identify all the affected models and steppings, maybe >> something like this would work: >> >> 1) Refuse to finish booting if a microcode update that disables TSX >> isn't applied before userspace starts running on those CPUs. > > Well, I think when we're booting, we would have already applied the > early microcode, no? Because then it is a non-issue. > >> 2) Don't allow a late update if TSX is still enabled on those >> processors. > > Yeah, so the use case I have in mind is when a long-running machine > wants to apply microcode and this microcode disables CPUID bits and > instructions. And the machine cannot be rebooted. > > I guess in that case we would have to issue a warning only on the > affected processors that a rebooted is mandatory and fail the update... > Maybe something like that. > >> (1) could be overridden by a command line option for people who want >> to develop TSX code. > > The way I understand it, those people shouldn't apply the microcode > patch at all. >
One way or another, anyone who has a kernel without some kind of workaround, an old BIOS, and a new ucode file in /lib/firmware is going to have problems unless they're set up for early ucode updates.
Can we change the ucode blob format for these firmwares so that old kernels won't apply them? I have no other good ideas. The trouble is that distros *should* push out the new ucode, but only if there's some guarantee that they'll only be applied early, never late.
--Andy
| |