linux-kernel - Re: [PATCH 3/3] trace-cmd: Making stat to report when the stack tracer is ON

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]

Date:   Wed, 29 Nov 2017 07:57:38 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Vladislav Valtchev <vladislav.valtchev@...il.com>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] trace-cmd: Making stat to report when the stack
 tracer is ON

On Thu, 23 Nov 2017 14:32:32 +0200
Vladislav Valtchev <vladislav.valtchev@...il.com> wrote:

> Agree.
> We might also add an if (!isdigit(buf)) die() before return, but I understand
> that, on the other side, we might not need to check the kernel's behavior
> this way. We might ultimately trust the kernel [every part of it] and save
> trace-cmd's code from having a ton of verbose sanity checks like this one.
> 
> It's all about trade-offs, clearly.
> Therefore, I'm fine with whatever trade-off you believe is better for trace-cmd.

Let's think about what the user wants.

If you do a "trace-cmd stat" what are you looking for? You want to see
what ftrace operations are available. Now let's say we do something
weird, or someone has some weird modified kernel, and the stack tracer
shows something that trace-cmd doesn't expect. With a die, it kills the
tool.

Would you like it if you ran "trace-cmd stat" and got it crashed with
an error message saying the kernel is doing something it doesn't
understand? To me, I'd be pissed. I would be cursing at trace-cmd
saying "I don't give a frick about that, show me what you do know!"

Now, do you think having a "die" is good there?

The only "die"s I have in trace-cmd stat is failure to allocate. That's
because the tool itself is then corrupted. In no case should trace-cmd
stat die because it doesn't understand something. And really, that
should be the entire case for trace-cmd. The only reason to call die is
if there's a failure in the tool itself where it can't continue (failed
memory allocations are usually severe).

-- Steve