linux-kernel - Re: [PATCH 07/14] x86/microcode/intel: Expose microcode_sanity

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a4107510-add4-3d85-ed2f-2f5e8c32a350@intel.com>
Date:   Thu, 3 Nov 2022 23:15:12 -0700
From:   "Joseph, Jithu" <jithu.joseph@...el.com>
To:     Borislav Petkov <bp@...en8.de>
CC:     <hdegoede@...hat.com>, <markgross@...nel.org>,
        <tglx@...utronix.de>, <mingo@...hat.com>,
        <dave.hansen@...ux.intel.com>, <x86@...nel.org>, <hpa@...or.com>,
        <gregkh@...uxfoundation.org>, <ashok.raj@...el.com>,
        <tony.luck@...el.com>, <linux-kernel@...r.kernel.org>,
        <platform-driver-x86@...r.kernel.org>, <patches@...ts.linux.dev>,
        <ravi.v.shankar@...el.com>, <thiago.macieira@...el.com>,
        <athenas.jimenez.gonzalez@...el.com>
Subject: Re: [PATCH 07/14] x86/microcode/intel: Expose
 microcode_sanity_check()



On 11/3/2022 4:33 AM, Borislav Petkov wrote:
> The moment we decide to change something in the microcode loader, we're
> going to have to
> 
> * test the IFS driver too
> 
> * and I suspect we won't even be able to because we'd probably need
> special hardware and those special blobs which you probably don't
> distribute freely.

We hear your concern that IFS test images are not yet publicly available for testing.
We are working on it and it should be available in the near future.

> 
> And yes, right now that function should be doing the SDM-sanctioned
> dance about verifying the table and thus should also be generic but
> judging from past experience, things do get different in time and
> implementations do get changed so even if it is a trivial change to
> microcode_sanity_check(), we would still need to test the IFS driver
> too.
> 
> So I'm wondering if it wouldn't be simply easier on everyone involved if
> you just copy the bits you need into your driver and use them there as
> you wish.
> 
> Then the testing burden won't be an issue and there won't be any
> potential cross-breakages.
> 

We further hear your concern of potential cross-breakages due to IFS and
Intel Microcode update driver sharing common functionality (like find_matching_signature()
and microcode_sanity_check()). Within Intel, microcode and IFS folks do work closely,
limiting the chances of this being introduced from Intel side.

If these doesn’t alleviate your concern, I will post v2 without exporting
the aforementioned functions and implementing them separately in IFS driver as you suggested.

Jithu