netdev - Re: [PATCH v3 bpf-next 0/2] bpf: fix use of trace

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] [day] [month] [year] [list]

Date:   Mon, 13 Jul 2020 17:01:53 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Alan Maguire <alan.maguire@...cle.com>
Cc:     Steven Rostedt <rostedt@...dmis.org>,
        Ingo Molnar <mingo@...hat.com>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        Andrii Nakryiko <andriin@...com>,
        John Fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...omium.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Network Development <netdev@...r.kernel.org>,
        bpf <bpf@...r.kernel.org>
Subject: Re: [PATCH v3 bpf-next 0/2] bpf: fix use of trace_printk() in BPF

On Mon, Jul 13, 2020 at 4:53 AM Alan Maguire <alan.maguire@...cle.com> wrote:
>
> Steven suggested a way to resolve the appearance of the warning banner
> that appears as a result of using trace_printk() in BPF [1].
> Applying the patch and testing reveals all works as expected; we
> can call bpf_trace_printk() and see the trace messages in
> /sys/kernel/debug/tracing/trace_pipe and no banner message appears.
>
> Also add a test prog to verify basic bpf_trace_printk() helper behaviour.
>
> Changes since v2:
>
> - fixed stray newline in bpf_trace_printk(), use sizeof(buf)
>   rather than #defined value in vsnprintf() (Daniel, patch 1)
> - Daniel also pointed out that vsnprintf() returns 0 on error rather
>   than a negative value; also turns out that a null byte is not
>   appended if the length of the string written is zero, so to fix
>   for cases where the string to be traced is zero length we set the
>   null byte explicitly (Daniel, patch 1)
> - switch to using getline() for retrieving lines from trace buffer
>   to ensure we don't read a portion of the search message in one
>   read() operation and then fail to find it (Andrii, patch 2)
>
> Changes since v1:
>
> - reorder header inclusion in bpf_trace.c (Steven, patch 1)
> - trace zero-length messages also (Andrii, patch 1)
> - use a raw spinlock to ensure there are no issues for PREMMPT_RT
>   kernels when using bpf_trace_printk() within other raw spinlocks
>   (Steven, patch 1)
> - always enable bpf_trace_printk() tracepoint when loading programs
>   using bpf_trace_printk() as this will ensure that a user disabling
>   that tracepoint will not prevent tracing output from being logged
>   (Steven, patch 1)
> - use "tp/raw_syscalls/sys_enter" and a usleep(1) to trigger events
>   in the selftest ensuring test runs faster (Andrii, patch 2)
>
> [1]  https://lore.kernel.org/r/20200628194334.6238b933@oasis.local.home

Applied. Thanks