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, 8 Jan 2016 13:16:01 +0100
From:	Markus Trippelsdorf <markus@...ppelsdorf.de>
To:	Borislav Petkov <bp@...e.de>
Cc:	Måns Rullgård <mans@...sr.com>,
	Thomas Voegtle <tv@...96.de>, linux-kernel@...r.kernel.org
Subject: Re: x86/microcode update on systems without INITRD

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