linux-kernel - Re: Checking to see if a bit is _not

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:	Tue, 2 Dec 2014 07:14:16 -0500
From:	Theodore Ts'o <tytso@....edu>
To:	Alexei Starovoitov <ast@...mgrid.com>
Cc:	Steven Rostedt <rostedt@...dmis.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: Checking to see if a bit is _not_ set in a ftrace event filter

On Mon, Dec 01, 2014 at 09:58:32PM -0800, Alexei Starovoitov wrote:
> well, dwarf is only needed if you have > 6 function
> arguments in x64, since x64 ABI promotes scalars
> to 64-bit and passes first six args in registers, so it's
> trivial to know where arguments are even without debug info.

Well, if eBPF can get more information without DWARF, that's great.
I'll use whatever I can get, so long as I can do it without DWARF.  :-)

So if eBPF can do a better job without the presence of debug info, and
even a better job with debug info (i.e., distro kernels where it's
worth the time to spend over an hour compiling a distro release rpm or
deb package), that would clearly be the best of both worlds.  I
suspect that developers like me will want to continue to add
tracepoints so we can do what we need to get done w/o debug info,
though.

(To me that was always the reason why I ignored systemtap; it focused
too much on the need of the release customer --- which makes sense,
since nearly all of the stap developers worked for Red Hat --- but it
ignored the needs of kernel developers.  So they shouldn't have been
surprised that most kernel developers returned the favor.  :-)

> Similar situation is on most 64-bit risc archs.
> dwarf is needed when one wants to see a value of
> local C variable somewhere in the middle of the function,
> but it's not common and rarely works in practice, since
> var-tracking is not easy for compilers.

Yes; fortunately, we can make that available via adding new
tracepoints --- which in general is why I'm in favor of not relying on
the ability to grab information via pure kprobe and kretprobe.  If we
can get the first six arguments on x86_64, then if I didn't think to
add a tracepoint, I can do some emergency debugging w/o needing to
recompile, which is a win.  (But since I also do a lot of debug runs
using 32-bit kernels, it would be nice to have things that worked
there as well, which is why in general I'll add tracepoints once I
find that it might be useful to trace a particular function.)

Cheers,

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/