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]

Message-ID: <20160108120812.GF14673@pd.tnic>
Date:	Fri, 8 Jan 2016 13:08:12 +0100
From:	Borislav Petkov <bp@...e.de>
To:	Måns Rullgård <mans@...sr.com>
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

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.

I hope that makes it more clear.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--