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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
