Try to read the microcode metadata file in order to see what features
are added or remove by the new microcode blob. If the metadata file
does not exists passthrough normal loading with a warning message.
Signed-off-by: Mihai Carabas <[email protected]>
---
arch/x86/kernel/cpu/microcode/intel.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/x86/kernel/cpu/microcode/intel.c b/arch/x86/kernel/cpu/microcode/intel.c
index 6a99535..a54d5e6 100644
--- a/arch/x86/kernel/cpu/microcode/intel.c
+++ b/arch/x86/kernel/cpu/microcode/intel.c
@@ -970,10 +970,12 @@ static enum ucode_state request_microcode_fw(int cpu, struct device *device,
bool refresh_fw)
{
struct cpuinfo_x86 *c = &cpu_data(cpu);
+ const struct firmware *meta_firmware;
const struct firmware *firmware;
struct iov_iter iter;
enum ucode_state ret;
struct kvec kvec;
+ char meta_name[40];
char name[30];
if (is_blacklisted(cpu))
@@ -982,11 +984,21 @@ static enum ucode_state request_microcode_fw(int cpu, struct device *device,
sprintf(name, "intel-ucode/%02x-%02x-%02x",
c->x86, c->x86_model, c->x86_stepping);
+ sprintf(meta_name, "intel-ucode/%02x-%02x-%02x.metadata",
+ c->x86, c->x86_model, c->x86_stepping);
+
if (request_firmware_direct(&firmware, name, device)) {
pr_debug("data file %s load failed\n", name);
return UCODE_NFOUND;
}
+ if (request_firmware_direct(&meta_firmware, meta_name, device)) {
+ pr_debug("metadata file %s load failed\n", name);
+ pr_debug("no feature check will be done pre-loading the microcode\n");
+ } else {
+ release_firmware(meta_firmware);
+ }
+
kvec.iov_base = (void *)firmware->data;
kvec.iov_len = firmware->size;
iov_iter_kvec(&iter, WRITE, &kvec, 1, firmware->size);
--
1.8.3.1
> Subject: Re: [PATCH RFC 1/3] x86: microcode: intel: read microcode metadata file
For the future, do:
git log <file I'm changing under arch/x86/>
to figure out what commit title prefix to use for the tip tree.
On Mon, Apr 27, 2020 at 10:27:57AM +0300, Mihai Carabas wrote:
> Try to read the microcode metadata file in order to see what features
> are added or remove by the new microcode blob. If the metadata file
> does not exists passthrough normal loading with a warning message.
So this file must be signed by the microcode vendors and that signature
then must be verified by the loader before we even look at the metadata.
We don't trust luserspace.
Also, I don't like it being a separate file - it could just as well be
appended to the microcode blob and parsed properly by the loader.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette