Re: [PATCH] x86/microcode/intel: Ensure new microcode processor flags match with cpu's pf

From: Zhenzhong Duan
Date: Tue Jun 19 2018 - 00:50:08 EST


On 2018/6/19 3:56, Borislav Petkov wrote:
On Mon, Jun 04, 2018 at 08:16:51AM +0000, Zhenzhong Duan wrote:
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...
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.

I didn't see same issue in our system. When fixing another bug and reading upstream microcode code, I found this potential issue, feel free to correct me if it's never possible in reality.

Thanks
Zhenzhong