linux-kernel - Re: [PATCH] tracing: Add disable-filter-buf option

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: <368d36b2-e5ea-46d4-b214-6d04cf20685a@efficios.com>
Date: Fri, 15 Dec 2023 14:08:40 -0500
From: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
 Linux trace kernel <linux-trace-kernel@...r.kernel.org>,
 Masami Hiramatsu <mhiramat@...nel.org>, Mark Rutland <mark.rutland@....com>
Subject: Re: [PATCH] tracing: Add disable-filter-buf option

On 2023-12-15 13:43, Steven Rostedt wrote:
> On Fri, 15 Dec 2023 13:25:07 -0500
> Mathieu Desnoyers <mathieu.desnoyers@...icios.com> wrote:
>>
>> I am not against exposing an ABI that allows userspace to alter the
>> filter behavior. I disagree on the way you plan to expose the ABI.
> 
> These are no different than the knobs for sched_debug

These are very much different. The sched features are enabled at
build-time by modifying kernel/sched/features.h. There is no userspace
ABI involved.

> 
>>
>> Exposing this option as an ABI in this way exposes too much internal
>> ring buffer implementation details to userspace.
> 
> There's already lots of exposure using options. The options are just
> knobs, nothing more.
> 
>>
>> It exposes the following details which IMHO should be hidden or
>> configurable in a way that allows moving to a whole new mechanism
>> which will have significantly different characteristics in the
>> future:
>>
>> It exposes that:
>>
>> - filtering uses a copy to a temporary buffer, and
>> - that this copy is enabled by default.
>>
>> Once exposed, those design constraints become immutable due to ABI.
> 
> No it is not. There is no such thing as "immutable ABI". The rule is
> "don't break user space" If this functionality in the kernel goes away,
> the knob could become a nop, and I doubt any user space will break
> because of it.
> 
> That is, the only burden is keeping this option exposed. But it could
> be just like that light switch that has nothing connected to it. It's
> still there, but does nothing if you switch it. This knob can act the
> same way. This does not in anyway prevent future innovation.

I am not comfortable with exposing internal ring buffer implementation
details to userspace which may or may not be deprecated as no-ops
in the future. This will lead to useless clutter.

One approach that might be somewhat better would be to only expose
those files when a new CONFIG_TRACING_DEBUG option is enabled. This
way userspace cannot rely on having those files present as part
of the ABI, but you would still be free to use them for selftests
by skipping the specific selftests if the config option is not
enabled.

Thanks,

Mathieu

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