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: <4d8e4f98-4736-4a46-b759-eff7e33cbca3@intel.com>
Date: Mon, 18 Nov 2024 12:02:55 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Andrew Cooper <andrew.cooper3@...rix.com>, alex.murray@...onical.com
Cc: bp@...en8.de, dave.hansen@...ux.intel.com, 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

On 11/13/24 18:09, Andrew Cooper wrote:
> Note how it's admitting to have fixed security issues silently in prior
> drops.  If I were you, I wouldn't make assumptions based on what's not
> said in the release notes.

I've gotten two pieces of feedback. Paraphrasing, one bit of feedback
from Andrew says:

	Don't explicitly trust the release notes. Here's an active,
	super recent example of when you can't trust them.

and Alex (elsewhere in the thread) says:

	The kernel should explicitly trust the release notes (for
	security vulnerability statements at least)

I'm partial to Andrew's position here because of the real-world recent
evidence.

It also occurs to me that Intel could have done this for two reasons:
First, it could be an attempt to do coordinated disclosure when the
microcode to fix the issue is ready well in advance of an issue being
disclosed.  The second is that a human made an error and neglected to
mention the security issues in the release notes.

We can fix the first issue by asking my Intel colleagues to not do that
in  the future.  I'd be happy to do that if folks want.

But we can't fix the second issue until we have either infallible humans
(or AI).  I'm not sure either one is on the horizon. ;)