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]

Message-ID: <CALCETrUUWHnRNvmXaQrjpRcGrBC_N2OFSyner_e-HEdAyk07rg@mail.gmail.com>
Date:	Wed, 24 Sep 2014 12:34:28 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Henrique de Moraes Holschuh <hmh@....eng.br>
Cc:	Borislav Petkov <bp@...en8.de>,
	Chuck Ebbert <cebbert.lkml@...il.com>,
	"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 Wed, Sep 24, 2014 at 11:59 AM, Henrique de Moraes Holschuh
<hmh@....eng.br> wrote:
> On Wed, 24 Sep 2014, Andy Lutomirski wrote:
>> We can sort of fudge it if whatever control BIOS uses is available to
>> us, too, and we can reprogram it to "enabled" after a microcode update
>> disables TSX.
>
> Only for the early initramfs microcode update driver, and that's going to be
> useful only as a way to honor the "keep Intel TSX enabled even if it is
> badly broken" switch that was added by Intel for developer usage.
>
> For the runtime microcode update (regular microcode driver), an
> "enabled->disabled->enabled" transition would still disrupt the system:
> triggering a microcode update in a cpu can update other cpus, which might be
> running Intel TSX instructions.  Boom! processes running on these other cpus
> can crash with SIGILL, and we have data loss.
>
> The microcode update has to preserve the entire [visible] processor state,
> otherwise we cannot safely apply it "late".  Intel TSX included.

Ugh, right.

If we knew the set of CPUs that would be affected by a given update,
we could freeze those CPUs first, though.  But yes, this sucks.

--Andy

>
> --
>   "One disk to rule them all, One disk to find them. One disk to bring
>   them all and in the darkness grind them. In the Land of Redmond
>   where the shadows lie." -- The Silicon Valley Tarot
>   Henrique Holschuh



-- 
Andy Lutomirski
AMA Capital Management, LLC
--
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/