Re: early microcode: how to disable at runtime?
From: Borislav Petkov
Date: Tue Sep 02 2014 - 02:34:12 EST
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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/