From: Joanne Koong <joannekoong@fb.com>
To: <lsf-pc@lists.linux-foundation.org>, <bpf@vger.kernel.org>,
<andrii@kernel.org>, Alexei Starovoitov <ast@kernel.org>,
<daniel@iogearbox.net>
Subject: [LSF/MM/BPF TOPIC] BPF dynamic pointers
Date: Thu, 17 Feb 2022 16:36:19 -0800 [thread overview]
Message-ID: <4260958f-daf2-5399-c0db-9ccec39461ad@fb.com> (raw)
*
Hi all,
**
I’d like to discuss supporting dynamic pointers (“bpf_dynptr”) in bpf. A
dynamic pointer is a pointer that embeds extra metadata alongside the
address - this abstraction will allow bpf programs to interact with
memory dynamically in a safe way. The verifier and bpf helper functions
can use the metadata stored in the dynamic pointer to enforce safety
guarantees.
Some useful applications of dynamic pointers include
* Dynamically-sized ringbuf reservations
Currently, our only way of writing dynamically-sized data into a ring
buffer is through bpf_ringbuf_output, but this incurs an extra memcpy
cost. bpf_ringbuf_reserve + bpf_ringbuf_commit avoids this extra memcpy,
but it can only safely support reservation sizes that are
statically-known since the verifier cannot guarantee that the bpf
program won’t access memory outside the reserved space. bpf_dynptrs will
enable dynamically-sized ring buffer reservations without the extra memcpy.
* Dynamic memory allocations
Bpf programs currently do not support dynamic memory allocations, but
with the dynptr abstraction, the verifier can enforce that any memory
dynamically allocated will always be freed. One useful extension of this
is persisting dynamic memory allocations in a map to share between programs.
* Dynamically parsing packet data
Currently when we parse network packet data (eg xdp_md->data,
sk_buff->data) in a bpf program, there are two main inconveniences:
1.
We can only iterate through the packet data in statically-known sizes
2.
The verifier requires manual checks in the bpf program code to
ensure we are not accessing any memory beyond the end of the packet
data. Some of these checks can be broken by clang when it does
clever optimizations.
The bpf_dynptr abstraction handles both these cases. By embedding the
packet data behind a bpf_dynptr, the helper functions used to read/write
to the data* can check that no memory violations occur.*
*
reply other threads:[~2022-02-18 0:36 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4260958f-daf2-5399-c0db-9ccec39461ad@fb.com \
--to=joannekoong@fb.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=lsf-pc@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox