BPF List
 help / color / mirror / Atom feed
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