public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: Torsten Kaiser <just.for.lkml@googlemail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Jacob Shin <jacob.shin@amd.com>,
	Johannes Hirte <johannes.hirte@fem.tu-ilmenau.de>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH]Fix early microcode loading on AMD
Date: Wed, 24 Jul 2013 15:56:10 +0200	[thread overview]
Message-ID: <20130724135610.GG30777@pd.tnic> (raw)
In-Reply-To: <CAPVoSvR30mjRq8Kcp34akb6R1oTi4Y+z7CCO_8FWK5cGd-W61A@mail.gmail.com>

On Tue, Jul 23, 2013 at 06:57:12PM +0200, Torsten Kaiser wrote:
> >> * Save the amd_bsp_mpb on apply, not on load. Otherwise someone could
> >> later load an older microcode file that would overwrite amd_bsp_mpb,
> >> but would not be applied to the CPUs
> >
> > See the patch id check in apply_ucode_in_initrd()?
> >
> >         if (eq_id == mc->hdr.processor_rev_id && rev < mc->hdr.patch_id)
> 
> I meant with "load" load_microcode_amd() not the loading of the
> microcode into the CPU.
> 
> 1.: load microcode rev X into CPU (early or normal is not important)
> 2.: get older microcode file that only contains rev Y with Y<X
> 3.: trigger load_microcode_amd() with a corrupt file: This will call
> cleanup() and empty pcache.

Ok, that's actually a good catch. So I wonder: why in hell would we
flush the pcache if some of the blobs we're loading are corrupted. So
what?! Jacob, what were you thinking - I'd be very interested to know
what the idea behind this was.

So, just to refresh everybody: the idea of the pcache is to keep all
patches for the current family in memory so that we can support all
sorts of hotplug and cpu mixed stepping diddling.

> 4.: trigger load_microcode_amd() with the older file:
>  * this will now load rev Y into pcache
>  * rev Y will be returned by find_patch and copied into amd_bsp_mpb
>  * any try to apply rev Y will be skipped in apply_microcode_amd()
> 
> So now the CPU still correctly has rev X, but amd_bsp_mpb will contain
> the wrong rev Y.

Right, so this shouldn't happen - what should happen is, pcache would
hold both X and Y and find_patch would automatically give you the right
one.

And this is guaranteed since we keep the patches in a sorted linked list
by ->patch_id which is guaranteed to be increasing.

So actually load_microcode_amd() shouldn't be doing cleanup() but simply
return ret upwards.

> That copying already in load_microcode also is suspicious if someone
> would only load the microcode but not apply it. But I did not find
> a codepath in arch/x86/kernel/microcode_core.c to load it without a
> followup apply.

Yeah, we always load and apply.

So now back to the original problem - load_microcode_amd() shouldn't
clear the pcache and, in that case, a subsequent find_patch() would
always give the right patch.

Ok?

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

  parent reply	other threads:[~2013-07-24 13:56 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-23 11:58 [PATCH]Fix early microcode loading on AMD Torsten Kaiser
2013-07-23 12:02 ` H. Peter Anvin
2013-07-23 12:23   ` Borislav Petkov
2013-07-23 15:15 ` Borislav Petkov
2013-07-23 16:57   ` Torsten Kaiser
2013-07-24 13:41     ` Borislav Petkov
2013-07-24 14:20       ` Torsten Kaiser
2013-07-24 17:49         ` Borislav Petkov
2013-07-24 13:56     ` Borislav Petkov [this message]
2013-07-24 14:44       ` Torsten Kaiser
2013-07-24 18:06         ` Borislav Petkov
2013-07-24 14:14     ` Borislav Petkov
2013-07-24 14:19     ` Borislav Petkov
2013-07-24 15:01       ` Torsten Kaiser
2013-07-24 18:08         ` Borislav Petkov
2013-07-23 21:44   ` Torsten Kaiser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130724135610.GG30777@pd.tnic \
    --to=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=jacob.shin@amd.com \
    --cc=johannes.hirte@fem.tu-ilmenau.de \
    --cc=just.for.lkml@googlemail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox