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

[Dave Hansen <dave.hansen@intel.com>]

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. ;)