Re: x86, microcode: BUG: microcode update that changes x86_capability
From: Henrique de Moraes Holschuh
Date: Thu Sep 25 2014 - 11:30:27 EST
On Thu, 25 Sep 2014, Borislav Petkov wrote:
> On Thu, Sep 25, 2014 at 11:40:25AM -0300, Henrique de Moraes Holschuh wrote:
> > At this point, what alternatives are left?
> Here's what we could do:
> * Install microcode to /lib/firmware/...
> * Refuse to update the microcode and tell the user that she needs to reboot.
> * Reboot and load the microcode
> For that to work though, we'd need to detect the that we're freshly
> booting and only then load the microcode (if we're coming in later,
> we should refuse because something linking to libpthread might've run
Userspace can install the microcode only inside the initramfs, if it wants
to avoid it being loaded later. It is not even too difficult to do so.
But the kernel currently doesn't have a away to know that happened.
We could just add the blacklist _and_ support for x86_capability changes
that don't touch something the kernel uses, and bypass the blacklist the
first time userspace writes 2 to the sysfs update trigger.
So, it would be an one-use trapdoor that the initramfs can use to update the
Haswells at boot. If someone really wants to use it again, he can rmmod +
modprobe (no way to do it if the microcode driver is built-in, though).
> The other thing we could do is backport early ucode loading...
> Hmm, I'm not crazy about both possibilities though, TBH.
"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
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/