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: <Y2QVrEGkfvpT/2KB@a4bf019067fa.jf.intel.com>
Date:   Thu, 3 Nov 2022 12:25:32 -0700
From:   Ashok Raj <ashok.raj@...el.com>
To:     Borislav Petkov <bp@...en8.de>
CC:     Jithu Joseph <jithu.joseph@...el.com>, <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>, <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>,
        Ashok Raj <ashok.raj@...el.com>
Subject: Re: [PATCH 07/14] x86/microcode/intel: Expose
 microcode_sanity_check()

On Thu, Nov 03, 2022 at 12:33:50PM +0100, Borislav Petkov wrote:
> On Fri, Oct 21, 2022 at 01:34:06PM -0700, Jithu Joseph wrote:
> > IFS test image carries the same microcode header as regular Intel
> > microcode blobs. Microcode blobs  use header version of 1,
> > whereas IFS test images will use header version of 2.
> > 
> > microcode_sanity_check() can be used by IFS driver to perform
> > sanity check of the IFS test images too.
> 
> So I'm very sceptical about such reuse.

The generic parts of the microcode is completely common between IFS and CPU
microcode. The parts that differ are in the meta-data. 

CPU microcode has stayed the same for over 15 years roughly. Changing
formats isn't something that's done lightly especially since there is cost
of enabling in all OS's. 

Both are in the same class of microcode, consumed by the CPU. Inside Intel
the format change is also pretty strict that they have several levels of
approval within the HW teams and also needs review and approval from SW
teams.

What probably is best is that we should document that the external formats
are shared in the header and probably in the shared routines. Changing
names as you suggested to be more generic is in the right track.

> Then the testing burden won't be an issue and there won't be any
> potential cross-breakages.

Even if its only a few hundred lines of code, it seems odd to simply
duplicate for the sake of fear of testing.