On Mon, Jun 04, 2018 at 08:16:51AM +0000, Zhenzhong Duan wrote:Imagine kernel already found a microcode blob A with extended sig/pf matching current cpu, then another microcode B is checked which doesn't match current cpu but matches the sig/pf of microcode A, then microcode B will replaced A, but it's not suitable for current cpu.
Intel spec says: 'The processor flags in the 48-byte header and the
processor flags field associated with the extended processor signature
structures may have multiple bits set.'
Make sure processor flags of the new microcode intersect with current
cpu's. Comparing with old microcode's pf can't guarantee this.
Signed-off-by: Zhenzhong Duan <zhenzhong.duan@xxxxxxxxxx>
---
arch/x86/kernel/cpu/microcode/intel.c | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/cpu/microcode/intel.c b/arch/x86/kernel/cpu/microcode/intel.c
index 461e315..54f4014 100644
--- a/arch/x86/kernel/cpu/microcode/intel.c
+++ b/arch/x86/kernel/cpu/microcode/intel.c
@@ -371,12 +371,10 @@ static int microcode_sanity_check(void *mc, int print_err)
goto next;
} else {
- struct microcode_header_intel *phdr = &patch->hdr;
-
if (!has_newer_microcode(data,
- phdr->sig,
- phdr->pf,
- phdr->rev))
+ uci->cpu_sig.sig,
+ uci->cpu_sig.pf,
+ patch->hdr.rev))
goto next;
}
--
So I'm scratching my head over this and have no clue what you're trying
to achieve. Is this a fix for a bug you're seeing or what? You'd need to
be a lot more verbose when explaining what this patch is trying to do...