mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Borislav Petkov <bp@alien8.de>
Cc: X86 ML <x86@kernel.org>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 06/13] x86/microcode/AMD: Rework container parsing
Date: Tue, 17 Jan 2017 21:29:05 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.20.1701172105180.3645@nanos> (raw)
In-Reply-To: <20170117173734.14251-7-bp@alien8.de>

On Tue, 17 Jan 2017, Borislav Petkov wrote:
> +	/* Find the equivalence ID of our CPU in this table: */
> +	eq_id = find_equiv_id(eq, eax);

So here we figure out whether the blob claims to have a patch for that cpu.

> +	/*
> +	 * Scan through the rest of the container to find where it ends. We do
> +	 * some basic sanity-checking too.
> +	 */

Stupid question. Why do we need to walk through that blob if we already
know that it does not contain a patch for this cpu, i.e. eq_id == 0 ?

I assume it has to do with the multiple containers glued together in the
blob, but that should be mentioned in the comment.

> +	while (size > 0) {
> +		struct microcode_amd *mc;
> +		u32 patch_size;
>  
> -		eq_id = find_equiv_id(eq, eax);
> -		if (eq_id) {
> -			ret.size = compute_container_size(ret.data, left + offset);
> +		hdr = (u32 *)buf;
>  
> -			/*
> -			 * truncate how much we need to iterate over in the
> -			 * ucode update loop below
> -			 */
> -			left = ret.size - offset;
> +		if (hdr[0] != UCODE_UCODE_TYPE)
> +			break;
>  
> -			*desc = ret;
> -			return eq_id;
> +		/* Sanity-check patch size. */
> +		patch_size = hdr[1];
> +		if (patch_size > PATCH_MAX_SIZE) {
> +			/* Something corrupted the container, invalidate it. */
> +			eq_id = 0;
> +			break;
>  		}
>  
> -		/*
> -		 * support multiple container files appended together. if this
> -		 * one does not have a matching equivalent cpu entry, we fast
> -		 * forward to the next container file.
> -		 */
> -		while (left > 0) {
> -			header = (u32 *)data;
> +		/* Skip patch section header: */
> +		buf  += SECTION_HDR_SIZE;
> +		size -= SECTION_HDR_SIZE;
>  
> -			if (header[0] == UCODE_MAGIC &&
> -			    header[1] == UCODE_EQUIV_CPU_TABLE_TYPE)
> -				break;
> -
> -			offset = header[1] + SECTION_HDR_SIZE;
> -			data  += offset;
> -			left  -= offset;
> +		mc = (struct microcode_amd *)buf;
> +		if (eq_id == mc->hdr.processor_rev_id) {
> +			desc->psize = patch_size;
> +			desc->mc = mc;

So here you set patch_size and mc when the eq_id is matching. I assume we
continue the scan for the same reason as we do the scan for eq_id = 0, right?

>  		}
>  
> -		/* mark where the next microcode container file starts */
> -		offset    = data - (u8 *)ucode;
> -		ucode     = data;
> +		buf  += patch_size;
> +		size -= patch_size;
> +	}
> +
> +	/*
> +	 * If we have found an eq_id, it means we're looking at the container
> +	 * which has a patch for this CPU so return 0 to mean, @ucode already
> +	 * points to it and it will be parsed later. Otherwise, we return the
> +	 * size we scanned so that we can advance to the next container in the
> +	 * buffer.
> +	 */
> +	if (eq_id) {

Now this one is dangerous. If the blob is corrupted we might have exited
the loop above due to

> +		if (hdr[0] != UCODE_UCODE_TYPE)
> +			break;

before the eq_id matching happened. In that case we return success, but
desc->psize and desc->mc are not set. Not what you want, right?

> +		desc->eq_id = eq_id;
> +		desc->data  = ucode;
> +		desc->size  = orig_size - size;
> +
> +		return 0;
  
> @@ -241,49 +232,33 @@ static bool apply_microcode_early_amd(void *ucode, size_t size, bool save_patch,
>  #endif
>  
>  	if (check_current_patch_level(&rev, true))
> -		return false;

So this becomes
> +		return ret;

which is not really better than the original code. I think we really should
only use the variable when there is something which can change between two
points, but that's my personal preference and up to you :)

> +	if (!desc.eq_id)
> +		return ret;
>  
> -		mc = (struct microcode_amd *)(data + SECTION_HDR_SIZE);
> +	this_equiv_id = desc.eq_id;

Why are you storing the id when you don't have an idea whether the patch is
actually available and useable? There might be a proper reason, but w/o a
comment or access to the microcode crystalball it's hard to tell.

>  static bool get_builtin_microcode(struct cpio_data *cp, unsigned int family)
> @@ -402,6 +377,7 @@ void load_ucode_amd_ap(unsigned int family)
>  		}
>  
>  		if (!apply_microcode_early_amd(cp.data, cp.size, false, &cont)) {
> +			cont.data = NULL;
>  			cont.size = -1;

What's the point of fiddling with the local variable at all if we return
right away?

>  			return;
>  		}
> @@ -440,7 +416,6 @@ int __init save_microcode_in_initrd_amd(unsigned int fam)
>  {
>  	enum ucode_state ret;
>  	int retval = 0;
> -	u16 eq_id;
>  
>  	if (!cont.data) {
>  		if (IS_ENABLED(CONFIG_X86_32) && (cont.size != -1)) {
> @@ -456,8 +431,8 @@ int __init save_microcode_in_initrd_amd(unsigned int fam)
>  				return -EINVAL;
>  			}
>  
> -			eq_id = find_proper_container(cp.data, cp.size, &cont);
> -			if (!eq_id) {
> +			scan_containers(cp.data, cp.size, &cont);
> +			if (!cont.eq_id) {
>  				cont.size = -1;

Ditto. That might be fixed in a seperate patch because thats existing code.

>  				return -EINVAL;

Thanks,

	tglx

  reply	other threads:[~2017-01-17 20:29 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-17 17:37 [PATCH 00/13] x86/microcode: 4.11 queue Borislav Petkov
2017-01-17 17:37 ` [PATCH 01/13] x86/microcode/intel: Drop stashed AP patch pointer optimization Borislav Petkov
2017-01-17 19:59   ` Thomas Gleixner
2017-01-17 17:37 ` [PATCH 02/13] x86/microcode: Use own MSR accessors Borislav Petkov
2017-01-17 17:51   ` Thomas Gleixner
2017-01-17 18:11     ` Borislav Petkov
2017-01-17 19:12       ` Thomas Gleixner
2017-01-17 22:33         ` Borislav Petkov
2017-01-18  9:46           ` Thomas Gleixner
2017-01-17 17:37 ` [PATCH 03/13] x86/microcode/AMD: Clean up find_equiv_id() Borislav Petkov
2017-01-17 17:54   ` Thomas Gleixner
2017-01-17 18:49     ` Borislav Petkov
2017-01-17 19:02       ` Thomas Gleixner
2017-01-17 23:12         ` Borislav Petkov
2017-01-17 17:37 ` [PATCH 04/13] x86/microcode/AMD: Shorten function parameter's name Borislav Petkov
2017-01-17 19:59   ` Thomas Gleixner
2017-01-17 17:37 ` [PATCH 05/13] x86/microcode/AMD: Extend the container struct Borislav Petkov
2017-01-17 20:02   ` Thomas Gleixner
2017-01-17 17:37 ` [PATCH 06/13] x86/microcode/AMD: Rework container parsing Borislav Petkov
2017-01-17 20:29   ` Thomas Gleixner [this message]
2017-01-17 23:31     ` Borislav Petkov
2017-01-18 14:44       ` Borislav Petkov
2017-01-18 14:58         ` Borislav Petkov
2017-01-17 17:37 ` [PATCH 07/13] x86/microcode: Decrease CPUID use Borislav Petkov
2017-01-17 20:34   ` Thomas Gleixner
2017-01-17 17:37 ` [PATCH 08/13] x86/microcode/AMD: Get rid of global this_equiv_id Borislav Petkov
2017-01-17 20:36   ` Thomas Gleixner
2017-01-17 17:37 ` [PATCH 09/13] x86/microcode/AMD: Use find_microcode_in_initrd() Borislav Petkov
2017-01-17 20:36   ` Thomas Gleixner
2017-01-17 17:37 ` [PATCH 10/13] x86/microcode/AMD: Check patch level only on the BSP Borislav Petkov
2017-01-17 20:43   ` Thomas Gleixner
2017-01-17 17:37 ` [PATCH 11/13] x86/microcode/AMD: Unify load_ucode_amd_ap() Borislav Petkov
2017-01-17 20:58   ` Thomas Gleixner
2017-01-17 21:18     ` Thomas Gleixner
2017-01-17 17:37 ` [PATCH 12/13] x86/microcode/AMD: Simplify saving from initrd Borislav Petkov
2017-01-17 21:19   ` Thomas Gleixner
2017-01-17 17:37 ` [PATCH 13/13] x86/microcode/AMD: Remove AP scanning optimization Borislav Petkov
2017-01-17 21:24   ` Thomas Gleixner

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=alpine.DEB.2.20.1701172105180.3645@nanos \
    --to=tglx@linutronix.de \
    --cc=bp@alien8.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=x86@kernel.org \
    /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

all inboxes | Powered by JetHome®