linux-kernel - Re: early microcode: how to disable at runtime?

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: <20140903064015.GA3941@nazgul.tnic>
Date:	Wed, 3 Sep 2014 08:40:15 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	Henrique de Moraes Holschuh <hmh@....eng.br>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Fenghua Yu <fenghua.yu@...el.com>, linux-kernel@...r.kernel.org
Subject: Re: early microcode: how to disable at runtime?

On Tue, Sep 02, 2014 at 10:16:51AM -0300, Henrique de Moraes Holschuh wrote:
> Things do go wrong in other ways, not just corrupt microcode data/initramfs
> images.
> 
> This stuff runs too early.  It is easy to break, and annoying to debug.

How is this stuff easy to break? Please stop with the conjectures and
give concrete issues, if any.

> Although, on the corrupted microcode topic, I have this very strong
> feeling that at least the Intel driver would benefit from a careful
> audit on the microcode container handling if we want to be sure it
> won't do stupid things when fed specially crafted hostile data.

If loading the microcode can disrupt the system (and not simply be
ignored if faulty) then we have to fix that. Disabling the loader is only
a stop-gap measure in such situation anyway - not a real solution.

-- 
Regards/Gruss,
    Boris.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/