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