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: <20241119174546.5ehj6yjiqk3baxhh@desk>
Date: Tue, 19 Nov 2024 09:45:46 -0800
From: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
To: Dave Hansen <dave.hansen@...ux.intel.com>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org, tglx@...utronix.de,
	bp@...en8.de
Subject: Re: [RFC][PATCH] x86/cpu/bugs: Consider having old Intel microcode
 to be a vulnerability

On Thu, Nov 07, 2024 at 09:06:30AM -0800, Dave Hansen wrote:
> 
> From: Dave Hansen <dave.hansen@...ux.intel.com>
> 
> You can't practically run old microcode and consider a system secure
> these days.  So, let's call old microcode what it is: a vulnerability.

> Expose that vulnerability in a place that folks can find it:
> 
> 	/sys/devices/system/cpu/vulnerabilities/old_microcode

Sorry for playing the devil's advocate. I am wondering who is the prime
beneficiary of this change?

Roughly dividing the user base into:

1. People who get their updates from distro. As distros also provide the
   microcode, most likely, their kernel will be patched to agree that the
   microcode that they provide has latest security fixes. Effectively
   distros have the control over what the kernel reports.

2. People who get their updates from distro, but build their own kernel
   could benefit from this change. Broadly these would be CSPs/embedded
   vendors/developers etc.

   - I am assuming CSPs are well versed with the microcode updates and
     hand-pick the microcode that they want to apply. So, they may not be
     care too much about microcode being old. And majority of their users
     that run workload in a guest VM won't see the microcode version.

   - In my experience, embedded vendors generally take a very long time to
     provide updates. They could benefit from this change when they
     eventually update their kernel.

   - Expert users/developers who submit bug reports to mailing lists can
     now know that they are running old microcode, and should update their
     microcode before submitting a bug report. To me they would benefit
     the most from this change.

For this to be help category 1. users, we need blessing from distro
providers. It would be great if more and more distros provide their
agreement/feedback on this change, as they are the ones who would enforce
this change.