Re: x86/microcode update on systems without INITRD

[Måns Rullgård]

Borislav Petkov <bp@xxxxxxx> writes:

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

Yes, but the microcode driver doesn't care about this AFAICT.

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

So it's meant to be supported, good.

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

Yes, that's the common case, and those users will have BLK_DEV_INITRD
enabled anyway.  Now why should someone who, for whatever reasons, is
doing microcode updates late be forced to enable BLK_DEV_INITRD even
though he doesn't use it?

-- 
Måns Rullgård