Messages in this thread | | | From | Andy Lutomirski <> | Date | Wed, 24 Sep 2014 12:34:28 -0700 | 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@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
| |