linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
To: linux-kernel@vger.kernel.org
Cc: Borislav Petkov <bp@alien8.de>, H Peter Anvin <hpa@zytor.com>
Subject: [PATCH 5/8] x86, microcode, intel: don't check extsig entry checksum
Date: Mon,  8 Sep 2014 14:37:51 -0300	[thread overview]
Message-ID: <1410197875-19252-6-git-send-email-hmh@hmh.eng.br> (raw)
In-Reply-To: <1410197875-19252-1-git-send-email-hmh@hmh.eng.br>

The contents of the extended signature entries are already covered by
the extended table checksum, and the microcode driver should not be
attempting to check their internal checksum field.

Unlike the main microcode checksum field and the extended signature
table checksum field, the checksum fields inside the extended signature
entries are not meant to be processed by a microcode update loader.  The
extended signature entry checksum field's description in the Intel SDM,
vol 3A, table 9-6, page 9-30, reads in the first paragraph:

   "Used by utility software to decompose a microcode update into
    multiple microcode updates where each of the new updates is
    constructed without the optional Extended Processor Signature
    Table."

And the Linux microcode driver is not processing them correctly anyway.
The second paragraph of the signature entry checksum field's description
in the Intel SDM, vol 3A, table 9-6, page 9-30, reads:

   "To calculate the Checksum, substitute the Primary Processor
    Signature entry and the Processor Flags entry with the corresponding
    Extended Patch entry. Delete the Extended Processor Signature Table
    entries. The Checksum is correct when the summation of all DWORDs
    that comprise the created Extended Processor Patch results in
    00000000H."

Deleting the extended signature table changes the Total Size field, and
the Intel SDM paragraph above makes it very clear that such a change must
be accounted for by the checksum.  The current extended signature entry
checksum code in the Linux microcode driver, which has been in place
since 2003, will be thrown off by this and reject a valid microcode
update.

The microcode driver is better off by doing what the Intel SDM suggests,
and staying well clear of that checksum field.  It has already checked
the whole extended signature table's checksum, anyway.

Signed-off-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
---
 arch/x86/kernel/cpu/microcode/intel_lib.c |   20 ++------------------
 1 file changed, 2 insertions(+), 18 deletions(-)

diff --git a/arch/x86/kernel/cpu/microcode/intel_lib.c b/arch/x86/kernel/cpu/microcode/intel_lib.c
index 1cc6494..9200b83 100644
--- a/arch/x86/kernel/cpu/microcode/intel_lib.c
+++ b/arch/x86/kernel/cpu/microcode/intel_lib.c
@@ -49,8 +49,7 @@ int microcode_sanity_check(void *mc, int print_err)
 	unsigned long total_size, data_size, ext_table_size;
 	struct microcode_header_intel *mc_header = mc;
 	struct extended_sigtable *ext_header = NULL;
-	int sum, orig_sum, ext_sigcount = 0, i;
-	struct extended_signature *ext_sig;
+	int orig_sum, i;
 
 	total_size = get_totalsize(mc_header);
 	data_size = get_datasize(mc_header);
@@ -81,7 +80,6 @@ int microcode_sanity_check(void *mc, int print_err)
 				pr_err("error: bad exttable size in microcode data file\n");
 			return -EFAULT;
 		}
-		ext_sigcount = ext_header->count;
 	}
 
 	/*
@@ -129,21 +127,7 @@ int microcode_sanity_check(void *mc, int print_err)
 			pr_err("error: bad microcode update checksum\n");
 		return -EINVAL;
 	}
-	if (!ext_table_size)
-		return 0;
-	/* check extended signature checksum */
-	for (i = 0; i < ext_sigcount; i++) {
-		ext_sig = (void *)ext_header + EXT_HEADER_SIZE +
-			  EXT_SIGNATURE_SIZE * i;
-		sum = orig_sum
-			- (mc_header->sig + mc_header->pf + mc_header->cksum)
-			+ (ext_sig->sig + ext_sig->pf + ext_sig->cksum);
-		if (sum) {
-			if (print_err)
-				pr_err("error: bad extended signature checksum\n");
-			return -EINVAL;
-		}
-	}
+
 	return 0;
 }
 EXPORT_SYMBOL_GPL(microcode_sanity_check);
-- 
1.7.10.4


  parent reply	other threads:[~2014-09-08 17:49 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-08 17:37 [PATCH 0/8] x86, microcode, intel: fixes and enhancements Henrique de Moraes Holschuh
2014-09-08 17:37 ` [PATCH 1/8] x86, microcode, intel: forbid some incorrect metadata Henrique de Moraes Holschuh
2014-10-05 17:34   ` Borislav Petkov
2014-10-05 19:37     ` Henrique de Moraes Holschuh
2014-10-05 21:13       ` Borislav Petkov
2014-10-05 21:49         ` Henrique de Moraes Holschuh
2014-10-06  5:15           ` Borislav Petkov
2014-09-08 17:37 ` [PATCH 2/8] x86, microcode, intel: don't update each HT core twice Henrique de Moraes Holschuh
2014-10-20 13:32   ` Borislav Petkov
2014-10-20 18:24     ` Henrique de Moraes Holschuh
2014-10-28 17:31       ` Borislav Petkov
2014-10-31 18:43         ` Henrique de Moraes Holschuh
2014-11-01 11:06           ` Borislav Petkov
2014-11-01 19:20             ` Henrique de Moraes Holschuh
2014-11-04 15:53               ` Borislav Petkov
2014-09-08 17:37 ` [PATCH 3/8] x86, microcode, intel: clarify log messages Henrique de Moraes Holschuh
2014-10-20 13:52   ` Borislav Petkov
2014-10-21 14:13     ` Henrique de Moraes Holschuh
2014-10-29  9:54       ` Borislav Petkov
2014-10-31 20:08         ` Henrique de Moraes Holschuh
2014-11-07 17:37           ` Borislav Petkov
2014-09-08 17:37 ` [PATCH 4/8] x86, microcode, intel: add error logging to early update driver Henrique de Moraes Holschuh
2014-10-20 15:08   ` Borislav Petkov
2014-10-21 14:10     ` Henrique de Moraes Holschuh
2014-10-30 17:41       ` Borislav Petkov
2014-10-30 18:15         ` Joe Perches
2014-10-31 20:10         ` Henrique de Moraes Holschuh
2014-09-08 17:37 ` Henrique de Moraes Holschuh [this message]
2014-10-30 20:25   ` [PATCH 5/8] x86, microcode, intel: don't check extsig entry checksum Borislav Petkov
2014-10-31 17:14     ` Henrique de Moraes Holschuh
2014-11-07 17:49       ` Borislav Petkov
2014-09-08 17:37 ` [PATCH 6/8] x86, microcode, intel: use cpuid explicitly instead of sync_core Henrique de Moraes Holschuh
2014-11-07 17:56   ` Borislav Petkov
2014-11-07 18:40     ` Henrique de Moraes Holschuh
2014-11-07 19:48       ` Borislav Petkov
2014-09-08 17:37 ` [PATCH 7/8] x86, microcode, intel: guard against misaligned microcode data Henrique de Moraes Holschuh
2014-09-18  0:48   ` Henrique de Moraes Holschuh
2014-11-07 19:59   ` Borislav Petkov
2014-11-07 22:54     ` Henrique de Moraes Holschuh
2014-11-07 23:48       ` Borislav Petkov
2014-11-08 21:57         ` Henrique de Moraes Holschuh
2014-11-11 10:47           ` Borislav Petkov
2014-11-11 16:57             ` Henrique de Moraes Holschuh
2014-11-11 17:13               ` Borislav Petkov
2014-11-11 19:54                 ` Henrique de Moraes Holschuh
2014-11-12 12:31                   ` Borislav Petkov
2014-11-13  0:18                     ` Henrique de Moraes Holschuh
2014-11-13 11:53                       ` Borislav Petkov
2014-11-15 23:10                         ` Henrique de Moraes Holschuh
2014-11-24 17:35                           ` Borislav Petkov
2014-11-25 13:29                             ` Henrique de Moraes Holschuh
2014-09-08 17:37 ` [PATCH 8/8] x86, microcode, intel: defend apply_microcode_intel with BUG_ON Henrique de Moraes Holschuh
2014-11-07 20:05   ` Borislav Petkov
2014-11-07 22:56     ` Henrique de Moraes Holschuh
2014-11-07 23:48       ` Borislav Petkov

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=1410197875-19252-6-git-send-email-hmh@hmh.eng.br \
    --to=hmh@hmh.eng.br \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.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;
as well as URLs for NNTP newsgroup(s).