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  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:	Thu, 14 Aug 2014 23:08:10 -0700
From:	Alexei Starovoitov <>
To:	Brendan Gregg <>
Cc:	"David S. Miller" <>,
	Ingo Molnar <>,
	Linus Torvalds <>,
	Andy Lutomirski <>,
	Steven Rostedt <>,
	Daniel Borkmann <>,
	Chema Gonzalez <>,
	Eric Dumazet <>,
	Peter Zijlstra <>,
	"H. Peter Anvin" <>,
	Andrew Morton <>,
	Kees Cook <>,
	Linux API <>,
	Network Development <>,
	LKML <>
Subject: Re: [PATCH RFC v4 net-next 17/26] tracing: allow eBPF programs to be
 attached to events

On Thu, Aug 14, 2014 at 2:20 PM, Brendan Gregg
<> wrote:
> On Wed, Aug 13, 2014 at 12:57 AM, Alexei Starovoitov <> wrote:
> [...]
>> +/* For tracing filters save first six arguments of tracepoint events.
>> + * On 64-bit architectures argN fields will match one to one to arguments passed
>> + * to tracepoint events.
>> + * On 32-bit architectures u64 arguments to events will be seen into two
>> + * consecutive argN, argN+1 fields. Pointers, u32, u16, u8, bool types will
>> + * match one to one
>> + */
>> +struct bpf_context {
>> +       unsigned long arg1;
>> +       unsigned long arg2;
>> +       unsigned long arg3;
>> +       unsigned long arg4;
>> +       unsigned long arg5;
>> +       unsigned long arg6;
>> +       unsigned long ret;
>> +};
> While this works, the argN+1 shift for 32-bit is a gotcha to learn.
> Lets say arg1 was 64-bit, and my program only examined arg2. I'd need
> two programs, one for 64-bit (using arg2) and 32-bit (arg3). If there

I've picked 'long' type for these tracepoint 'arguments' to match
what is going on at assembler level.
32-bit archs are passing 64-bit values in two consecutive registers
or two stack slots. So it's partially exposing architectural details.
I've tried to use u64 here, but it complicated tracepoint+ebpf patch
a lot, since I need per-architecture support for moving C arguments
into u64 variables and hacking tracepoint event definitions in a nasty
ways. This 'long' type approach is the least intrusive I could find.
Also out of 1842 total tracepoint fields, only 144 fields are 64-bit,
so rarely one would need to deal with u64. Most of the tracepoint
arguments are either longs, ints or pointers, which fits this approach
the best.
In general the eBPF design approach is to keep kernel bits as simple
as possible and move complexity to user space.
In this case some higher language than C for writing scripts can
hide this oddity.
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists