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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 15 Aug 2014 10:20:25 -0700 From: Andy Lutomirski <luto@...capital.net> To: Alexei Starovoitov <ast@...mgrid.com> Cc: Brendan Gregg <brendan.d.gregg@...il.com>, "David S. Miller" <davem@...emloft.net>, Ingo Molnar <mingo@...nel.org>, Linus Torvalds <torvalds@...ux-foundation.org>, Steven Rostedt <rostedt@...dmis.org>, Daniel Borkmann <dborkman@...hat.com>, Chema Gonzalez <chema@...gle.com>, Eric Dumazet <edumazet@...gle.com>, Peter Zijlstra <a.p.zijlstra@...llo.nl>, "H. Peter Anvin" <hpa@...or.com>, Andrew Morton <akpm@...ux-foundation.org>, Kees Cook <keescook@...omium.org>, Linux API <linux-api@...r.kernel.org>, Network Development <netdev@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org> Subject: Re: [PATCH RFC v4 net-next 17/26] tracing: allow eBPF programs to be attached to events On Thu, Aug 14, 2014 at 11:08 PM, Alexei Starovoitov <ast@...mgrid.com> wrote: > On Thu, Aug 14, 2014 at 2:20 PM, Brendan Gregg > <brendan.d.gregg@...il.com> wrote: >> On Wed, Aug 13, 2014 at 12:57 AM, Alexei Starovoitov <ast@...mgrid.com> 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 > > correct. > 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. The downside of this approach is that compat support might be difficult or impossible. --Andy -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists