Messages in this thread | | | Date | Tue, 2 Sep 2014 10:16:51 -0300 | From | Henrique de Moraes Holschuh <> | Subject | Re: early microcode: how to disable at runtime? |
| |
On Tue, 02 Sep 2014, Borislav Petkov wrote: > > This can be a very big deal when things go wrong: it is hard for the > > regular user to recover from an initramfs image that crashes the > > system, and the early initramfs has no "disable" trigger. > > This maybe is a serious problem but disabling microcode loading is not > the proper solution. If the microcode in the initrd is corrupted, it > should simply not get loaded and system should continue as much as it > can - it *should* *not* be a requirement to disable the ucode loader in > order to workaround corrupted initrds.
Things do go wrong in other ways, not just corrupt microcode data/initramfs images.
This stuff runs too early. It is easy to break, and annoying to debug.
> And frankly, I'm trying to imagine how a corrupted microcode in an > initrd would ever fail the booting. So Henrique, if you have something > which is *not* hypothetical, please say so. It needs to be fixed > properly and not with disabling the ucode loader.
I am not worried about corrupted microcode, or even corrupted initramfs images. I am just worried about regular bugs introduced by a kernel update causing systems to fail to reboot later.
I don't want to tell an user he has to use rescue media to get his system back into working order when a kernel parameter would have been enough to get it to boot.
Although, on the corrupted microcode topic, I have this very strong feeling that at least the Intel driver would benefit from a careful audit on the microcode container handling if we want to be sure it won't do stupid things when fed specially crafted hostile data.
-- "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
| |