linux-kernel - Re: [PATCH] kernel/trace: Add TRACING_ALLOW

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: <CANMq1KCAUfxy-njMJj0=+02Jew_1rJGwxLzp6BRTE=9CL2DZNA@mail.gmail.com>
Date:   Thu, 25 Jun 2020 10:00:09 +0800
From:   Nicolas Boichat <drinkcat@...omium.org>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     Steven Rostedt <rostedt@...dmis.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...hat.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Kees Cook <keescook@...omium.org>,
        Jason Gunthorpe <jgg@...pe.ca>,
        Daniel Vetter <daniel.vetter@...ll.ch>,
        Peter Zijlstra <peterz@...radead.org>,
        Vinod Koul <vkoul@...nel.org>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Alexey Dobriyan <adobriyan@...il.com>,
        Tiezhu Yang <yangtiezhu@...ngson.cn>,
        Thomas Gleixner <tglx@...utronix.de>,
        "Guilherme G . Piccoli" <gpiccoli@...onical.com>,
        Will Deacon <will@...nel.org>,
        Douglas Anderson <dianders@...omium.org>,
        Guenter Roeck <groeck@...omium.org>
Subject: Re: [PATCH] kernel/trace: Add TRACING_ALLOW_PRINTK config option

On Thu, Jun 25, 2020 at 1:25 AM Alexei Starovoitov
<alexei.starovoitov@...il.com> wrote:
>
> On Wed, Jun 24, 2020 at 9:07 AM Steven Rostedt <rostedt@...dmis.org> wrote:
> >
> > On Wed, 24 Jun 2020 16:45:24 +0800
> > Nicolas Boichat <drinkcat@...omium.org> wrote:
> >
> > > trace_printk is only meant as a debugging tool, and should never be
> > > compiled into production code without source code changes, as
> > > indicated by the warning that shows up on boot if any trace_printk
> > > is called:
> > >  **   NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE   **
> > >  **                                                      **
> > >  ** trace_printk() being used. Allocating extra memory.  **
> > >  **                                                      **
> > >  ** This means that this is a DEBUG kernel and it is     **
> > >  ** unsafe for production use.                           **
> > >
> > > If this option is set to n, the kernel will generate a build-time
> > > error if trace_printk is used.
> > >
> > > Signed-off-by: Nicolas Boichat <drinkcat@...omium.org>
> >
> > Interesting. Note, this will prevent modules with trace_printk from
> > being loaded as well.
>
> Nack.
> The message is bogus. It's used in production kernels.
> bpf_trace_printk() calls it.

Interesting. BTW, the same information (trace_printk is for debugging
only) is repeated all over the place, including where bpf_trace_printk
is documented:
https://elixir.bootlin.com/linux/latest/source/include/linux/kernel.h#L757
https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/bpf.h#L706
https://elixir.bootlin.com/linux/latest/source/kernel/trace/trace.c#L3157

Steven added that warning (2184db46e425c ("tracing: Print nasty banner
when trace_printk() is in use")), so maybe he can confirm if it's
still relevant.

Also, note that emitting the build error is behind a Kconfig option,
you don't have to select it if you don't want to (the default is =y
which allows trace_printk).

If the overhead is real, we (Chrome OS) would like to make sure
trace_printk does not slip into production kernels (we do want to
provide basic tracing support so we can't just remove CONFIG_TRACING
as a whole which would make trace_printk no-ops). I could also imagine
potential security issues if people print raw pointers/sensitive data
in trace_printk, assuming that the code is for debugging only.

Also, the fact that the kernel test robot already found a stray
trace_printk in drivers/usb/cdns3/gadget.c makes me think that this
change is working as intended ,-) (we're going to need to add a few
Kconfig deps though for other debugging options that intentionally use
trace_printk).