linux-kernel - Re: x86/microcode update on systems without INITRD

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 08 Jan 2016 12:18:15 +0000
From:	Måns Rullgård <mans@...sr.com>
To:	Borislav Petkov <bp@...e.de>
Cc:	Thomas Voegtle <tv@...96.de>,
	Markus Trippelsdorf <markus@...ppelsdorf.de>,
	linux-kernel@...r.kernel.org
Subject: Re: x86/microcode update on systems without INITRD

Borislav Petkov <bp@...e.de> 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