linux-kernel - Re: [PATCH 1/2] input: Add tracepoint support

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: <921F8D487468018A+141227fc-070d-4ed9-8828-d446236eccd2@uniontech.com>
Date: Mon, 28 Jul 2025 15:07:42 +0800
From: WangYuli <wangyuli@...ontech.com>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
 Steven Rostedt <rostedt@...dmis.org>
Cc: dmitry.torokhov@...il.com, guanwentao@...ontech.com,
 linux-input@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-trace-kernel@...r.kernel.org, mhiramat@...nel.org,
 niecheng1@...ontech.com, wangyuli@...pin.org, zhanjun@...ontech.com,
 Winston Wen <wentao@...ontech.com>
Subject: Re: [PATCH 1/2] input: Add tracepoint support

Hi Mathieu,

On 2025/7/23 09:24, Mathieu Desnoyers wrote:
> I've always been worried about adding tracepoint instrumentation of the
> input subsystem that includes the actual keystrokes into the event
> payload. What I'm trying to avoid here is people leaking their password
> by mistake just because they happened to record a trace while
> typing on their keyboard.
>
The evtest tool can also do this.

However, it doesn't fully report all events from the input subsystem.

 From a debugging perspective, adding tracepoints to the input subsystem 
is still more convenient for debugging.

> I don't mind if this gets enabled with a new kernel command line
> options "tracing_leak_my_credentials=yes" or such, but I'd try to
> avoid making it easy to enable by mistake unless this information
> is specifically needed.
>
I'm not sure if this is over-engineering...

I feel that adding too many command-line parameters will increase the 
user's cognitive load.

However, the leakage of keyboard input records is indeed a very, very 
significant risk.

As a compromise, would it be better if we added a separate Kconfig 
option specifically for the input subsystem's tracepoints to decide 
whether to enable them at compile time, and then documented the 
potential risks within that Kconfig's description?
> But maybe I'm being too careful and people should really learn not
> to share kernel traces with others.
>
> Thoughts ?
>
Thanks,
-- 
WangYuli

Download attachment "OpenPGP_0xC5DA1F3046F40BEE.asc" of type "application/pgp-keys" (633 bytes)

Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (237 bytes)