linux-kernel - Re: Edited draft of bpf(2) man page for review/enhancement

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]

Message-ID: <55AFD64E.9040105@plumgrid.com>
Date:	Wed, 22 Jul 2015 10:43:42 -0700
From:	Alexei Starovoitov <ast@...mgrid.com>
To:	"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
Cc:	Silvan Jegen <s.jegen@...il.com>, linux-man@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Daniel Borkmann <daniel@...earbox.net>,
	Walter Harms <wharms@....de>
Subject: Re: Edited draft of bpf(2) man page for review/enhancement

On 7/22/15 7:52 AM, Michael Kerrisk (man-pages) wrote:
>> As Daniel said there is no spec for this C. It's a normal C where
>> things like loops, global variables, vararg, floating point,
>> struct passing and bunch of other things are not supported.
>
> I assume we're talking about the LLVM front-end, right?

yes. clang.
There is a bpf backend for gcc, but it's bit rotting now.

> Am I correct that these kernel source files are examples of this restricted C:
>
> samples/bpf/tcbpf1_kern.c
> samples/bpf/tracex2_kern.c
> samples/bpf/tracex4_kern.c
> samples/bpf/tracex1_kern.c
> samples/bpf/tracex3_kern.c
> samples/bpf/sockex1_kern.c
> samples/bpf/sockex2_kern.c

yes.

> And samples/bpf/Makefile shows the necessary LLVM incantation
> to produce the BPF binaries, right?

yes.
Now with llvm 3.7 coming out soon it's even simpler. Just:
clang -O2 -target bpf -c file.c

> Anyway, I added the following text in NOTES:
>
>         eBPF objects (maps and programs) can  be  shared  between  pro‐
>         cesses.   For  example,  after fork(2), the child inherits file
>         descriptors referring to the same eBPF objects.   In  addition,
>         file  descriptors  referring to eBPF objects can be transferred
>         over UNIX domain sockets.  File descriptors referring  to  eBPF
>         objects  can  be  duplicated in the usual way, using dup(2) and
>         similar calls.  An eBPF object is deallocated  only  after  all
>         file descriptors referring to the object have been closed.
>
> Is the above all correct?

yes. all correct.

> This makes me curious: why was the BPF functionality not designed as
> a *set* of system calls (as per these wrappers), rather than the existing
> multiplexed call?

because new commands are much easier to add to existing syscall
instead of adding new syscall for every new command.

> [[
> If
> .I key
> is found, the operation returns zero and sets the
> .I next_key
> pointer to the key of the next element.
> ]]
>
> right?

yes.

>>>           BPF_MOV64_IMM(BPF_REG_1, 1),                /* r1 = 1 */
>>>           BPF_XADD(BPF_DW, BPF_REG_0, BPF_REG_1, 0, 0),
>>> .\" FIXME What does 'lock' in the line below mean?
>>>                                   /* lock *(u64 *) r0 += r1 */
>>
>> it means that it's 'lock xadd' equivalent.
>
> Sorry -- you've assumed I'm cleverer than I am... :-}
> I'm not wiser after that comment. What is 'lock xadd'?

I meant that it is == atomic64_add

> If you might have a chance to look at my questions above and
> let me know your thoughts, then I could further edit the page
> before sending out the next draft.

I think would be great to get some form of the man page out and
work on it incrementally. Quite a few folks have asked for it.

Thanks!

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