Re: x86/microcode update on systems without INITRD

[Markus Trippelsdorf <markus@trippelsdorf.de>]

On 2016.01.08 at 13:08 +0100, Borislav Petkov wrote:
> On Fri, Jan 08, 2016 at 11:46:28AM +0000, Måns Rullgård wrote:
> > How is an initrd different from a real filesystem as seen by the
> > microcode update driver?
> 
> For starters, initrd is available much earlier, even before paging is
> enabled on 32-bit, for example. See find_cpio_data().
> 
> > The objection against removing the dependency was that updating
> > microcode "late" isn't safe.  I don't see how turning on BLK_DEV_INITRD
> > stops anyone doing those allegedly unsafe updates anyway.
> 
> No one is stopping anyone from doing late updates. It is a valid use
> case, and we have to support it. And late updates are not necessarily
> unsafe, per se.
> 
> Lemme put it this way: it is a lot less unproblematic to do early
> updates. Mind you, there's no 100% guarantee that early updates would
> always work either. It all depends on what the microcode patch does. But
> they do work 99,9999999...% of the time. :)
> 
> IOW, I haven't heard of an early update breaking the machine. But it is
> possible.
> 
> So the *general* flow should be that people enable BLK_DEV_INITRD,
> put the microcode in there and it gets updated as early as possible.
> This is what the distros do and it is the most tested path. The other
> possibilities are there too, but only for cases where initrd is out of
> the question.

But you take the choice away from people like me, who don't need initrd
at all. BLK_DEV_INITRD is a superfluous dependency in this case, because
microcode update works perfectly well without it.

-- 
Markus