linux-kernel - Re: [PATCH] x86/microcode/intel: Allow late loading only if a min rev is specified

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: <b519135c-2241-4172-747a-b1f2f492f48c@intel.com>
Date:   Mon, 29 Aug 2022 13:24:55 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Ashok Raj <ashok.raj@...el.com>
Cc:     Borislav Petkov <bp@...en8.de>,
        Thomas Gleixner <tglx@...utronix.de>,
        LKML Mailing List <linux-kernel@...r.kernel.org>,
        X86-kernel <x86@...nel.org>,
        Andy Lutomirski <luto@...capital.net>,
        Ingo Molnar <mingo@...nel.org>,
        Tom Lendacky <thomas.lendacky@....com>,
        Tony Luck <tony.luck@...el.com>
Subject: Re: [PATCH] x86/microcode/intel: Allow late loading only if a min rev
 is specified

On 8/29/22 11:52, Ashok Raj wrote:
> The enforcement is not in hardware and limited to kernel loader enforcing
> the requirement. It is not required for early loading of microcode to
> enforce this requirement, since the new features are only
> evaluated after early loading in the boot process.

That's _related_ to what I was asking, but it doesn't quite cover it.

Right now, the min_rev guarantee is something along the lines of:

	Intel will always set min-rev its its microcode releases when
	software-visible features change between microcode revisions.

That's subtly different from

	The microcode header will bump min-rev when software-
	visible features change between microcode revisions.

The kernel (and its developers) should at least be *aware* that features
can change even if there's no min-rev bump.  That could be because:

	1. A user is trying to do the microcode equivalent of "modprobe
	   --force", by hacking the header
	2. The user is applying microcode from the USB stick they found
	   in the parking lot.
	3. Intel isn't sticking to its end of the bargain (or we never
	   really agreed about what the bargain was in the first place).

I'm not saying that your patch can or should do this, but the min_rev
feature does *not* mean that we can just start to forego any sanity
checks about features being added or removed as the result of a late load.

I think those three ^ cases are even worth calling out in the changelog
because it's very easy to confuse what min_rev really *MEANS* in the
end.  It only has meaning when the ucode image is unmodified between
Intel and the kernel, *AND* if Intel keeps up its end of the contract.

BTW, about #3...  I fully trust Intel to be a good actor here.  But,
Intel employs actual humans and humans do make mistakes.  Let's make
sure the kernel is resilient in the face of any mistakes.