[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <52E8168D.9060805@oracle.com>
Date: Tue, 28 Jan 2014 15:43:57 -0500
From: Boris Ostrovsky <boris.ostrovsky@...cle.com>
To: Borislav Petkov <bp@...en8.de>
CC: "H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
Ingo Molnar <mingo@...nel.org>
Subject: Re: AMD microcode loading broken on 32 bit
On 01/28/2014 11:24 AM, Borislav Petkov wrote:
> On Thu, Jan 23, 2014 at 02:41:59PM -0500, Boris Ostrovsky wrote:
>> 32-bit only.
> Ok, I think I know what happens. Can you try this one (I missed doing
> this on 32-bit and 64-bit does it, which would explain why it didn't
> explode there):
>
> ---
> diff --git a/arch/x86/kernel/cpu/microcode/amd_early.c b/arch/x86/kernel/cpu/microcode/amd_early.c
> index 8384c0fa206f..03b759401bc1 100644
> --- a/arch/x86/kernel/cpu/microcode/amd_early.c
> +++ b/arch/x86/kernel/cpu/microcode/amd_early.c
> @@ -359,7 +359,7 @@ int __init save_microcode_in_initrd_amd(void)
> pr_info("microcode: updated early to new patch_level=0x%08x\n",
> ucode_new_rev);
>
> - if (!container)
> + if (!container || !ucode_cpio.data)
> return -EINVAL;
>
> eax = cpuid_eax(0x00000001);
It fixes the case when there is no microcode in initrd but when
microcode is corrupted (as was the case when we were pointing to Intel
binary) we still die. Neither container nor ucode_cpio.data is NULL in
this case.
-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/
Powered by blists - more mailing lists