Message-ID: <c6ee2dfd-3d10-4fa6-943f-9d7b1ddc231e@efficios.com>
Date: Mon, 28 Jul 2025 09:53:05 -0400
From: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To: WangYuli <wangyuli@...ontech.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

On 2025-07-28 03:07, WangYuli wrote:
> 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?

In term of mechanism to select keylogger enabling/disabling, I can
think of the following options:

- Kconfig option,
- kernel command line parameter,
- sysctl

Here is a possibly incomplete list of desiderata for this:

- Keylogger should be disabled by default.
- System administrator should be able to enable keylogger at boot.
- Users should be able to query the state of keylogger
   (enabled/disabled) during kernel execution, and this should be
   invariant until reboot,
- Selecting whether this option is enabled or not should be decided
   by the system administrator, not by the distribution vendors who
   compile the distro kernels.
- Prevent use of a kernel tracer as a keylogger by mistake without
   having the system administrator explicitly enable keylogging.

The most flexible approach would be a sysctl, because it would allow
a system administrator to enable this while the system runs. But it
is somewhat redundant with the fact that the tracers allow disabling
specific events dynamically. Also I don't think we would want to allow
changing this configuration after system boots, so users interacting
with a production system can check whether this is enabled or not to
learn whether they can trust that this keylogger feature is disabled.

This leaves Kconfig option and kernel command line. The downside of the
Kconfig option is that it requires to choose the configuration up
front for a distro kernel, not allowing the system admin to select
the behavior at boot time without recompiling a custom kernel.

This leaves the kernel command line option, which I think is a
good tradeoff. It allows sysadmins to enable keylogging at boot
from a distro kernel without recompiling their own kernel. It
also prevents enabling keylogging in a production system by
mistake after bootup. It allows users to inspect the status of
this knob by looking at the kernel command line to know whether
they are interacting with a system that has this keylogging
enabled.

Thoughts ?

Thanks,

Mathieu

>> But maybe I'm being too careful and people should really learn not
>> to share kernel traces with others.
>>
>> Thoughts ?
>>
> Thanks,


-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com

Powered by blists - more mailing lists