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: <20140902063354.GA32105@nazgul.tnic>
Date:	Tue, 2 Sep 2014 08:33:54 +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 Mon, Sep 01, 2014 at 04:59:21PM -0300, Henrique de Moraes Holschuh wrote:
> On Mon, 01 Sep 2014, H. Peter Anvin wrote:
> > No, it is worse to rename it and have older kernels behave differently.
> > Kernel options are basically super obscure to most people anyway.
> 
> Ok, so rename is out, although as long as the rename was accepted for
> 3.16-stable, it would be just 3.16 and 3.16.1 (and maybe 3.16.2) that would
> not have the new name.
> 
> Options left are "keep it as is", or "add new and [optionally] deprecate
> old".  I can't really tell for sure which one you'd prefer from your
> previous answer.

Let me answer to all the concerns here:

* the parameter is not in kernel-parameters.txt for the simple reason
that we don't want people to disable ucode loaders left and right.
The absolutely normal, 99% situation should be loading works fine or
we don't load the ucode at all - this option is only for the very,
very, very! obscure and strange situation where we want to rule out any
microcode interference. Just in case.

This situation should almost never happen.

* The param naming could be argued about - maybe it is ugly and
unreadable for that same reason.

> This can be a very big deal when things go wrong: it is hard for the
> regular user to recover from an initramfs image that crashes the
> system, and the early initramfs has no "disable" trigger.

This maybe is a serious problem but disabling microcode loading is not
the proper solution. If the microcode in the initrd is corrupted, it
should simply not get loaded and system should continue as much as it
can - it *should* *not* be a requirement to disable the ucode loader in
order to workaround corrupted initrds.

And frankly, I'm trying to imagine how a corrupted microcode in an
initrd would ever fail the booting. So Henrique, if you have something
which is *not* hypothetical, please say so. It needs to be fixed
properly and not with disabling the ucode loader.

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