On 2025-07-22 20:25, Steven Rostedt wrote:

On Thu, 10 Jul 2025 15:31:38 +0800
WangYuli [off-list ref] wrote:

quoted

diff --git a/include/trace/events/input.h b/include/trace/events/input.h
new file mode 100644
index 000000000000..3c5ffcfb7c8d
--- /dev/null
+++ b/include/trace/events/input.h

@@ -0,0 +1,251 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/* input tracepoints
+ *
+ * Copyright (C) 2025 WangYuli <wangyuli@uniontech.com>
+ */
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM input
+
+#if !defined(_TRACE_INPUT_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_INPUT_H
+
+#include <linux/tracepoint.h>
+#include <linux/input.h>
+
+/**
+ * input_event - called when an input event is processed
+ * @dev: input device that generated the event
+ * @type: event type (EV_KEY, EV_REL, EV_ABS, etc.)
+ * @code: event code within the type
+ * @value: event value
+ *
+ * This tracepoint fires for every input event processed by the input core.
+ * It can be used to monitor input device activity and debug input issues.
+ */

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.

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.

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

Thoughts ?

Thanks,

Mathieu

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