lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 19 Jun 2018 12:49:40 +0800 From: Zhenzhong Duan <zhenzhong.duan@...cle.com> To: Borislav Petkov <bp@...en8.de> Cc: Linux-Kernel <linux-kernel@...r.kernel.org>, mingo@...hat.com, tglx@...utronix.de, Srinivas REDDY Eeda <srinivas.eeda@...cle.com>, hpa@...or.com Subject: Re: [PATCH] x86/microcode/intel: Ensure new microcode processor flags match with cpu's pf 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@...cle.com> >> --- >> 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
Powered by blists - more mailing lists