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  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

Powered by blists - more mailing lists