On Tue, Oct 20, 2015 at 5:54 AM, Borislav Petkov <[email protected]> wrote:
> From: Borislav Petkov <[email protected]>
>
> Merge the early loader functionality into the driver proper. The diff
> is huge but logically, it is simply moving code from the _early.c files
> into the main driver.
>
> Signed-off-by: Borislav Petkov <[email protected]>
> ---
> arch/x86/Kconfig | 19 +-
> arch/x86/include/asm/microcode.h | 19 +-
> arch/x86/include/asm/microcode_amd.h | 2 +-
> arch/x86/include/asm/microcode_intel.h | 10 +-
> arch/x86/kernel/cpu/microcode/Makefile | 3 -
> arch/x86/kernel/cpu/microcode/amd.c | 446 ++++++++++++++-
> arch/x86/kernel/cpu/microcode/amd_early.c | 444 ---------------
> arch/x86/kernel/cpu/microcode/core.c | 160 +++++-
> arch/x86/kernel/cpu/microcode/core_early.c | 170 ------
> arch/x86/kernel/cpu/microcode/intel.c | 788 ++++++++++++++++++++++++++-
> arch/x86/kernel/cpu/microcode/intel_early.c | 808 ----------------------------
> arch/x86/kernel/head_32.S | 5 +-
> arch/x86/mm/init.c | 2 -
> 13 files changed, 1399 insertions(+), 1477 deletions(-)
> delete mode 100644 arch/x86/kernel/cpu/microcode/amd_early.c
> delete mode 100644 arch/x86/kernel/cpu/microcode/core_early.c
> delete mode 100644 arch/x86/kernel/cpu/microcode/intel_early.c
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index fdf1f0cdf6b6..255ea22ccbec 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1126,6 +1126,7 @@ config MICROCODE
> bool "CPU microcode loading support"
> default y
> depends on CPU_SUP_AMD || CPU_SUP_INTEL
> + depends on BLK_DEV_INITRD
> select FW_LOADER
> ---help---
>
> @@ -1167,24 +1168,6 @@ config MICROCODE_OLD_INTERFACE
> def_bool y
> depends on MICROCODE
>
> -config MICROCODE_INTEL_EARLY
> - bool
> -
> -config MICROCODE_AMD_EARLY
> - bool
> -
> -config MICROCODE_EARLY
> - bool "Early load microcode"
> - depends on MICROCODE && BLK_DEV_INITRD
> - select MICROCODE_INTEL_EARLY if MICROCODE_INTEL
> - select MICROCODE_AMD_EARLY if MICROCODE_AMD
> - default y
> - help
> - This option provides functionality to read additional microcode data
> - at the beginning of initrd image. The data tells kernel to load
> - microcode to CPU's as early as possible. No functional change if no
> - microcode data is glued to the initrd, therefore it's safe to say Y.
> -
So this broke dracut. Dracut will look at the config file for the
INTEL or AMD early config options being set. If it does not find
them, it disables the creation of the early microcode part of the
initramfs. Now that the options don't even exist, it fails.
Do we have suggestions on how to work this out going forward? I
suppose we could assume the check should only be done on 4.3 or older
kernels, but I'm not sure making assumptions about newer kernels is a
great idea either.
josh
On Fri, Nov 06, 2015 at 02:22:42PM -0500, Josh Boyer wrote:
> So this broke dracut. Dracut will look at the config file for the
> INTEL or AMD early config options being set.
Nothing outside the kernel should depend on Kconfig symbols.
> Do we have suggestions on how to work this out going forward? I
> suppose we could assume the check should only be done on 4.3 or older
> kernels, but I'm not sure making assumptions about newer kernels is a
> great idea either.
How about always adding AMD and Intel microcode always? Maybe with a
switch to disable adding any microcode for testing purposes only...
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
Am 06.11.2015 um 20:31 schrieb Borislav Petkov:
> On Fri, Nov 06, 2015 at 02:22:42PM -0500, Josh Boyer wrote:
>> So this broke dracut. Dracut will look at the config file for the
>> INTEL or AMD early config options being set.
>
> Nothing outside the kernel should depend on Kconfig symbols.
>
>> Do we have suggestions on how to work this out going forward? I
>> suppose we could assume the check should only be done on 4.3 or older
>> kernels, but I'm not sure making assumptions about newer kernels is a
>> great idea either.
>
> How about always adding AMD and Intel microcode always? Maybe with a
> switch to disable adding any microcode for testing purposes only...
>
Will this work with kernels not supporting the microcode loading?
Theoretically the old kernels would just unpack all cpios one after the other,
right?
On Mon, Nov 09, 2015 at 10:42:13AM +0100, Harald Hoyer wrote:
> Will this work with kernels not supporting the microcode loading?
> Theoretically the old kernels would just unpack all cpios one after
> the other, right?
Well, what we should be doing is adding two paths to the initrd:
for AMD: kernel/x86/microcode/AuthenticAMD.bin
for Intel: kernel/x86/microcode/GenuineIntel.bin
I.e., the microcode blobs become part of the initrd, see
Documentation/x86/early-microcode.txt. The loader goes and opens the one
it needs at boot time.
You could also add a switch for convenience, something like
--no-microcode or so, so that dracut doesn't add it but if one wants to
not add microcode, one could also move it away from, say, /lib/firmware/
so that dracut simply doesn't find it. The --no-microcode might be more
convenient though.
Kernels which don't support microcode loading would simply not look for
that path.
Let me know if this doesn't make sense and if I need to test/look at
patches.
Thanks.
--
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.