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

Date:	Tue, 2 Dec 2014 16:02:13 -0800
From:	Alexei Starovoitov <ast@...mgrid.com>
To:	"Theodore Ts'o" <tytso@....edu>,
	Alexei Starovoitov <ast@...mgrid.com>,
	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 Tue, Dec 2, 2014 at 4:14 AM, Theodore Ts'o <tytso@....edu> wrote:
>
> 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.  :-)

eBPF is just an engine. Anyone can develop a userspace bits that
will use debug info and/or their favorite language (stap, ktap, dtrace
or any other) when right hooks are in place on the kernel side.
I'm focusing on restricted C as a way to program it and
environments without debug info.

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

Understood. i386 is difficult, since arg passing is using
combination of registers(eax,edx,ecx) and stack in
non-obvious way, so some trick is needed to get it right
without debug info. I'm still trying to solve this one.
That's for programs attached to kprobes.
Programs that attach to tracepoints will see arguments
in a normal way on all archs.
Anyway, one step at a time. Easy things first.

As one of the crazy things for the future I was thinking
about mini-tracepoints. Instead of generating full
ftrace_raw_* bodies, generate minimal stubs
to collect tracepoint arguments only and invoke programs.
In other words move responsibility of TP_STRUCT__entry,
TP_fast_assign and TP_printk into the bpf program.
On x64 all we need is single stub for all mini-tracepoints.
For 32-bit archs all mini-tracepoint stubs will be different
to accomodate 32/64-bit argument passing.
That will save quite a bit from .text and hopefully more
people will enable such tracepoints in production.
--
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/