linux-kernel - Re: [PATCH] x86/msr: add CPU_OUT_OF_SPEC taint name to "unrecognized" pr

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: <m2bjll15q8.fsf@kvalverd-mobl1.amr.corp.intel.com>
Date: Sat, 01 Nov 2025 20:19:27 -0700
From: Marc Herbert <marc.herbert@...ux.intel.com>
To: Borislav Petkov <bp@...en8.de>
Cc: "H. Peter Anvin" <hpa@...or.com>,  Thomas Gleixner <tglx@...utronix.de>,
  Ingo Molnar <mingo@...hat.com>,  Dave Hansen
 <dave.hansen@...ux.intel.com>,  x86@...nel.org,
  linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86/msr: add CPU_OUT_OF_SPEC taint name to
 "unrecognized" pr_warn(msg)

Thanks Boris for looking at this!

Borislav Petkov <bp@...en8.de> writes:
> Taint flags are expensive and we don't have flag for everything. And when
> userspace is poking at MSRs, that's similar to putting the CPU in
> a out-of-specification mode of sorts. So I took what's closest.

I tried to be very thorough to justify the change but I did not mean
some alternative implementation was available, sorry if I gave that
impression. I just struggled to make sense of some unrelated crash logs
and that's really all from my point of view. I mean all for now at
least.

> What is not clear to me is why do you need to dump the fact that it tainted
> here and dump the taint flag too?

You mean the "%s", tainted_flags[OOSPEC].desc bit? Not sure I understand
your question. That was just a way to re-use the existing string. But as
found by the kernel test robot, that was a mistake because
tainted_flags[] is not exported to modules. I missed that msr.c could be
compiled as a module, apologies. I've removed that in v2, I want to make
this change even simpler and append this instead:

  pr_warn( "... (pid: %d), tainting CPU_OUT_OF_SPEC.\n",

> Also, why aren't you using print_tainted()... 

AFAIK print_tainted() shows all current flags, not just
CPU_OUT_OF_SPEC. So a full print_tainted() display would not make
unambiguous which specific flag is being set, even more so considering
writing MSRs can happen a very long time after boot. But, much worse:
the CPU_OUT_OF_SPEC taint loop has not even been set yet when this
pr_warn() is run...

> ...  if that is really necessary?

This patch is not "really necessary". Its purpose is only to save hours
or even days for people trying to make sense of crash logs. In my ideal
world, it should always be easy to tell "who tainted what when" from the
logs without an corresponding expert and/or searching the source code. I
admit this could harm job security ;-)

This is not unusual, for instance TAINT_OOT_MODULE is not printed
literally in the logs yet this other pr_warn() clearly points the finger
at mod->name(s) in the logs:

  pr_warn("%s: loading out-of-tree module taints kernel, mod->name);

Some other flags have a much narrower range which makes the lack of
finger pointing a non-issue.