Re: x86, microcode: BUG: microcode update that changes x86_capability

[Andy Lutomirski]

On Fri, Sep 19, 2014 at 8:00 AM, Borislav Petkov <bp@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/