linux-kernel - Re: [GIT PULL] tracing: user

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]

Message-ID: <20230626020731.299d0b10@rorschach.local.home>
Date:   Mon, 26 Jun 2023 02:07:31 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     LKML <linux-kernel@...r.kernel.org>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Beau Belgrave <beaub@...ux.microsoft.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        sunliming <sunliming@...inos.cn>
Subject: Re: [GIT PULL] tracing: user_event fix for 6.4

On Sun, 25 Jun 2023 16:04:32 -0700
Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> The fact that your explanation is "we have that bug in other places"
> does *not* make me any happier.

Actually it's just the behavior inside the kernel. I just wrote a quick
program to see the behavior of /sys/kernel/tracing/trace_marker, and
yeah, it actually returns an error when writing if the ring buffer is
disabled.

I was trying to imitate the internal behavior in the kernel, but I
shouldn't have, as we control all the instances of that.

Now testing the other user space interface, it does behave the way you
described (something I implemented years ago!). So I will drop this
version of the patch.

>From the code for trace_marker:

        if (unlikely(!event))
                /* Ring buffer disabled, return as if not open for write */
                return -EBADF;

sunliming's original patch had it return an error. I'll have him redo
that one, because the current behavior is still wrong as it returns as
if it wrote something when it did not.

 https://lore.kernel.org/all/20230608011554.1181097-2-sunliming@kylinos.cn/

We were the ones to tell him not to return an error, so I take the
blame on that. But if we are going to return an error, I rather follow
what trace_marker does and return -EBADF and not -EFAULT.

sunliming,

Care to send a v3 that returns -EBADF instead?

Thanks,

-- Steve