linux-kernel - Re: [PATCH] x86/tsc: Add debugfs entry to mark TSC as unstable after boot

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: <cfee20d6-881d-32a2-96f8-2bcac87864a7@igalia.com>
Date: Mon, 17 Mar 2025 12:24:15 -0300
From: "Guilherme G. Piccoli" <gpiccoli@...lia.com>
To: Borislav Petkov <bp@...en8.de>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org, tglx@...utronix.de,
 mingo@...hat.com, dave.hansen@...ux.intel.com, hpa@...or.com,
 kernel@...ccoli.net, kernel-dev@...lia.com
Subject: Re: [PATCH] x86/tsc: Add debugfs entry to mark TSC as unstable after
 boot

On 17/03/2025 12:14, Borislav Petkov wrote:
> [...]
>> The same that happens if today someone marks it as unstable via
>> command-line, right? You will see that on logs, and could simply reply
>> that the user marked as unstable themselves, so..no bug at all!!
>>
>> But let's think the other way around: what if some user marks TSC
>> unstable via debugfs, later on runtime, and with that, unveils a real
> 
> I don't understand what you mean here.
> 

Oh, I meant that: since the behavior of other components (like tracing
clock) is different if TSC is marked as unstable (a) on boot time,
through command-line, (b) some time after boot, like on watchdog skews
(or using this debugfs approach), we may as well have some user marking
it unstable through debugfs and due to that, finding a real bug
somewhere, that we can fix it!

>> bug as [1] and then, we can then fix it? That would be a win heheh
> 
> No, marking the most important clocksource on x86 deliberately as unstable
> better scream bloody hell in dmesg. But regardless, I'm not convinced this is
> nearly as needed to have upstream. Just use it locally or cmdline.
> 
> Thx.
> 

OK Boris, thanks for the feedback - if you don't see much value in this
one, let's forget about that - can always change locally as you said.
Cheers,

Guilherme