bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Borkmann <daniel@iogearbox.net>
To: ast@kernel.org
Cc: daniel@iogearbox.net, john.fastabend@gmail.com, kafai@fb.com,
	netdev@vger.kernel.org, bpf@vger.kernel.org,
	Andrii Nakryiko <andriin@fb.com>
Subject: [PATCH bpf-next v4 4/6] bpf, libbpf: add bpf_tail_call_static helper for bpf programs
Date: Wed, 30 Sep 2020 17:18:18 +0200	[thread overview]
Message-ID: <1656a082e077552eb46642d513b4a6bde9a7dd01.1601477936.git.daniel@iogearbox.net> (raw)
In-Reply-To: <cover.1601477936.git.daniel@iogearbox.net>

Port of tail_call_static() helper function from Cilium's BPF code base [0]
to libbpf, so others can easily consume it as well. We've been using this
in production code for some time now. The main idea is that we guarantee
that the kernel's BPF infrastructure and JIT (here: x86_64) can patch the
JITed BPF insns with direct jumps instead of having to fall back to using
expensive retpolines. By using inline asm, we guarantee that the compiler
won't merge the call from different paths with potentially different
content of r2/r3.

We're also using Cilium's __throw_build_bug() macro (here as: __bpf_unreachable())
in different places as a neat trick to trigger compilation errors when
compiler does not remove code at compilation time. This works for the BPF
back end as it does not implement the __builtin_trap().

  [0] https://github.com/cilium/cilium/commit/f5537c26020d5297b70936c6b7d03a1e412a1035

Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Andrii Nakryiko <andriin@fb.com>
---
 tools/lib/bpf/bpf_helpers.h | 46 +++++++++++++++++++++++++++++++++++++
 1 file changed, 46 insertions(+)

diff --git a/tools/lib/bpf/bpf_helpers.h b/tools/lib/bpf/bpf_helpers.h
index 1106777df00b..2bdb7d6dbad2 100644
--- a/tools/lib/bpf/bpf_helpers.h
+++ b/tools/lib/bpf/bpf_helpers.h
@@ -53,6 +53,52 @@
 	})
 #endif
 
+/*
+ * Helper macro to throw a compilation error if __bpf_unreachable() gets
+ * built into the resulting code. This works given BPF back end does not
+ * implement __builtin_trap(). This is useful to assert that certain paths
+ * of the program code are never used and hence eliminated by the compiler.
+ *
+ * For example, consider a switch statement that covers known cases used by
+ * the program. __bpf_unreachable() can then reside in the default case. If
+ * the program gets extended such that a case is not covered in the switch
+ * statement, then it will throw a build error due to the default case not
+ * being compiled out.
+ */
+#ifndef __bpf_unreachable
+# define __bpf_unreachable()	__builtin_trap()
+#endif
+
+/*
+ * Helper function to perform a tail call with a constant/immediate map slot.
+ */
+static __always_inline void
+bpf_tail_call_static(void *ctx, const void *map, const __u32 slot)
+{
+	if (!__builtin_constant_p(slot))
+		__bpf_unreachable();
+
+	/*
+	 * Provide a hard guarantee that LLVM won't optimize setting r2 (map
+	 * pointer) and r3 (constant map index) from _different paths_ ending
+	 * up at the _same_ call insn as otherwise we won't be able to use the
+	 * jmpq/nopl retpoline-free patching by the x86-64 JIT in the kernel
+	 * given they mismatch. See also d2e4c1e6c294 ("bpf: Constant map key
+	 * tracking for prog array pokes") for details on verifier tracking.
+	 *
+	 * Note on clobber list: we need to stay in-line with BPF calling
+	 * convention, so even if we don't end up using r0, r4, r5, we need
+	 * to mark them as clobber so that LLVM doesn't end up using them
+	 * before / after the call.
+	 */
+	asm volatile("r1 = %[ctx]\n\t"
+		     "r2 = %[map]\n\t"
+		     "r3 = %[slot]\n\t"
+		     "call 12"
+		     :: [ctx]"r"(ctx), [map]"r"(map), [slot]"i"(slot)
+		     : "r0", "r1", "r2", "r3", "r4", "r5");
+}
+
 /*
  * Helper structure used by eBPF C program
  * to describe BPF map attributes to libbpf loader
-- 
2.21.0


  parent reply	other threads:[~2020-09-30 15:18 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-30 15:18 [PATCH bpf-next v4 0/6] Various BPF helper improvements Daniel Borkmann
2020-09-30 15:18 ` [PATCH bpf-next v4 1/6] bpf: add classid helper only based on skb->sk Daniel Borkmann
2020-09-30 15:18 ` [PATCH bpf-next v4 2/6] bpf, net: rework cookie generator as per-cpu one Daniel Borkmann
2020-09-30 15:55   ` Eric Dumazet
2020-09-30 15:18 ` [PATCH bpf-next v4 3/6] bpf: add redirect_neigh helper as redirect drop-in Daniel Borkmann
2020-09-30 16:08   ` David Ahern
2020-09-30 20:56     ` Daniel Borkmann
2020-09-30 15:18 ` Daniel Borkmann [this message]
2020-09-30 15:18 ` [PATCH bpf-next v4 5/6] bpf, selftests: use bpf_tail_call_static where appropriate Daniel Borkmann
2020-09-30 17:23   ` Martin KaFai Lau
2020-09-30 15:18 ` [PATCH bpf-next v4 6/6] bpf, selftests: add redirect_neigh selftest Daniel Borkmann
2020-09-30 17:31   ` Martin KaFai Lau
2020-09-30 19:20   ` Alexei Starovoitov
2020-09-30 21:01     ` Daniel Borkmann
2020-09-30 21:12       ` Alexei Starovoitov
2020-09-30 19:10 ` [PATCH bpf-next v4 0/6] Various BPF helper improvements patchwork-bot+bpf

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=1656a082e077552eb46642d513b4a6bde9a7dd01.1601477936.git.daniel@iogearbox.net \
    --to=daniel@iogearbox.net \
    --cc=andriin@fb.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=john.fastabend@gmail.com \
    --cc=kafai@fb.com \
    --cc=netdev@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).