linux-kernel - Re: [RFC][PATCH] x86/cpu/bugs: Consider having old Intel microcode to be a vulnerability

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: <87v7wtvty0.fsf@canonical.com>
Date: Tue, 12 Nov 2024 17:07:27 +1030
From: Alex Murray <alex.murray@...onical.com>
To: dave.hansen@...ux.intel.com
Cc: bp@...en8.de,linux-kernel@...r.kernel.org,tglx@...utronix.de,x86@...nel.org
Subject: Re: [RFC][PATCH] x86/cpu/bugs: Consider having old Intel microcode
 to be a vulnerability

> 
> == Microcode Revision Discussion ==
> 
> The microcode versions in the table were generated from the Intel
> microcode git repo:
>
>  	29f82f7429c ("microcode-20241029 Release")

This upstream microcode release only contained an update for a
functional issue[1] - not any fixes for security issues. So it would not
really be correct to say a machine running the previous microcode
revision is vulnerable. As such, should the table of microcode revisions
only be generated from the upstream microcode releases that contain
fixes for security issues? 

ie.

> +{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6,  .model = 0xb7, .steppings = 0x0002, .driver_data = 0x12b }

should ideally be:

> +{ .flags = X86_CPU_ID_FLAG_ENTRY_VALID, .vendor = X86_VENDOR_INTEL, .family = 0x6,  .model = 0xb7, .steppings = 0x0002, .driver_data = 0x129 }

to correspond with the previous microcode release that contained actual
security fixes. 

[1] https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases/tag/microcode-20241029