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  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 <>
To:	Borislav Petkov <>
Cc:	Chuck Ebbert <>,
	Henrique de Moraes Holschuh <>,
	"H. Peter Anvin" <>,
	"" <>
Subject: Re: x86, microcode: BUG: microcode update that changes x86_capability

On Fri, Sep 19, 2014 at 8:00 AM, Borislav Petkov <> 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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists