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 <[email protected]>
---
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;
}
--
1.7.3
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 <[email protected]>
> ---
> 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...
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
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 <[email protected]>
>> ---
>> 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
On Tue, Jun 19, 2018 at 12:49:40PM +0800, 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...
Do you see the
if (!microcode_matches(mc_header, uci->cpu_sig.sig)) {
call a couple of lines earlier?
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
On 2018/6/19 17:12, Borislav Petkov wrote:
> On Tue, Jun 19, 2018 at 12:49:40PM +0800, 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...
> Do you see the
>
> if (!microcode_matches(mc_header, uci->cpu_sig.sig)) {
>
> call a couple of lines earlier?
Sure, but it didn't ensure a match in stepping and pf, is that expected?
Thanks
Zhenzhong
On Tue, Jun 19, 2018 at 05:24:20PM +0800, Zhenzhong Duan wrote:
> On 2018/6/19 17:12, Borislav Petkov wrote:
> > On Tue, Jun 19, 2018 at 12:49:40PM +0800, 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...
> > Do you see the
> >
> > if (!microcode_matches(mc_header, uci->cpu_sig.sig)) {
> >
> > call a couple of lines earlier?
> Sure, but it didn't ensure a match in stepping and pf, is that expected?
Do you see the
if (!has_newer_microcode(data,
uci->cpu_sig.sig,
uci->cpu_sig.pf,
uci->cpu_sig.rev))
a couple lines later?
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.