linux-kernel - Re: x86, microcode: BUG: microcode update that changes x86

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 19 Sep 2014 09:13:08 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Borislav Petkov <bp@...en8.de>
Cc:	Chuck Ebbert <cebbert.lkml@...il.com>,
	Henrique de Moraes Holschuh <hmh@....eng.br>,
	"H. Peter Anvin" <hpa@...or.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: x86, microcode: BUG: microcode update that changes x86_capability

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