Re: x86, microcode: BUG: microcode update that changes x86_capability

[Henrique de Moraes Holschuh]

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
> already).

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.

Indeed.

-- 
  "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
--
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/