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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2024072611-unrelated-aflame-bf41@gregkh>
Date: Fri, 26 Jul 2024 10:15:14 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: linux-kernel@...r.kernel.org, Masami Hiramatsu <mhiramat@...nel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Subject: Re: [PATCH] tracing: remove tracing_is_on export

On Thu, Jul 25, 2024 at 12:17:45PM -0400, Steven Rostedt wrote:
> On Thu, 25 Jul 2024 16:41:11 +0200
> Greg Kroah-Hartman <gregkh@...uxfoundation.org> wrote:
> 
>  This workflow is used by many developers.  
> > 
> > Is it documented anywhere?  I've never heard of it before, and nothing
> > really describes this in Documentation/ that I can find.
> 
> It is mentioned, but I could expand on it more:
> 
> Documentation/trace/ftrace.rst:
> 
>   tracing_on:
> 
>         This sets or displays whether writing to the trace
>         ring buffer is enabled. Echo 0 into this file to disable
>         the tracer or 1 to enable it. Note, this only disables
>         writing to the ring buffer, the tracing overhead may
>         still be occurring.
> 
>         The kernel function tracing_off() can be used within the
>         kernel to disable writing to the ring buffer, which will
>         set this file to "0". User space can re-enable tracing by
>         echoing "1" into the file.

Seems "dangerous" that any random driver can control all of the tracing
system like this, but you do you :)

> > But as you only want these to be exported to developer kernels, why not
> > say that and put that behind a debugging Kconfig option or something?
> 
> Why add the burden of having to compile the core kernel to enable it? I use
> this all the time.
> 
> > That way "vendor kernels" can properly disable this as they don't want
> > to give this type of functionality to random 3rd-party kernel modules.
> 
> This has been exported since 2008. Has it ever been a problem in the last
> 16 years?

As I am finding out, yes, external modules are "abusing" this to do
different types of logic depending on if tracing is enabled or not for
various unknown reasons.  As there was no in-kernel user of this symbol,
I assumed it was just an oversight and should be removed.

I'll go ask the distro involved to just remove the symbol from their
kernels instead, but that feels like the wrong thing to do to me.

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ