[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <8b2b0155-31a8-4470-c0ed-9747b21d66c9@intel.com>
Date: Thu, 18 Aug 2022 10:34:36 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Peter Zijlstra <peterz@...radead.org>,
Ashok Raj <ashok.raj@...el.com>
Cc: Borislav Petkov <bp@...en8.de>,
Thomas Gleixner <tglx@...utronix.de>,
Tony Luck <tony.luck@...el.com>,
LKML Mailing List <linux-kernel@...r.kernel.org>,
X86-kernel <x86@...nel.org>,
Andy Lutomirski <luto@...capital.net>,
Tom Lendacky <thomas.lendacky@....com>
Subject: Re: [PATCH 3/5] x86/microcode/intel: Allow a late-load only if a min
rev is specified
On 8/15/22 00:46, Peter Zijlstra wrote:
> What if any validation do you have to ensure min_rev does as promised?
> That is, ucode can very easily lie about the number and still remove an
> MSR or CPUID enumerated feature.
We can absolutely add sanity checks to this. It would not be hard at
all to, for instance, dump out all the CPUID leaves we can get our hands
on and diff them before and after a ucode update.
That said, min_rev is *architectural*. It includes an architectural
promise from Intel that the ucode won't lie. If Intel is breaking
architectural promises, it has bigger problems on its hands.
Bugs happen, of course -- even bugs in architectural features. If there
are enough bugs that we can't trust min_rev, late-loading will just get
disabled again, probably permanently. Our Intel colleagues should have
all the incentive in the world to be very, very careful with min_rev.
Powered by blists - more mailing lists