From: Peter Zijlstra <peterz@infradead.org>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Jiri Olsa <olsajiri@gmail.com>, Song Liu <song@kernel.org>,
Song Liu <songliubraving@meta.com>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
X86 ML <x86@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
"David S. Miller" <davem@davemloft.net>,
David Ahern <dsahern@kernel.org>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
Yonghong Song <yonghong.song@linux.dev>,
John Fastabend <john.fastabend@gmail.com>,
KP Singh <kpsingh@kernel.org>,
Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
Arnd Bergmann <arnd@arndb.de>,
Sami Tolvanen <samitolvanen@google.com>,
Kees Cook <keescook@chromium.org>,
Nathan Chancellor <nathan@kernel.org>,
Nick Desaulniers <ndesaulniers@google.com>,
linux-riscv <linux-riscv@lists.infradead.org>,
LKML <linux-kernel@vger.kernel.org>,
Network Development <netdev@vger.kernel.org>,
bpf <bpf@vger.kernel.org>,
linux-arch <linux-arch@vger.kernel.org>,
clang-built-linux <llvm@lists.linux.dev>,
Josh Poimboeuf <jpoimboe@kernel.org>,
Joao Moreira <joao@overdrivepizza.com>,
Mark Rutland <mark.rutland@arm.com>
Subject: Re: [PATCH v2 2/2] x86/cfi,bpf: Fix BPF JIT call
Date: Fri, 8 Dec 2023 21:27:31 +0100 [thread overview]
Message-ID: <20231208202731.GF36716@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <CAADnVQKsnZfFomQ4wTZz=jMZW5QCV2XiXVsi64bghHkAjJtcmA@mail.gmail.com>
On Fri, Dec 08, 2023 at 11:40:27AM -0800, Alexei Starovoitov wrote:
> What is "sealing" by objtool?
Ah, LTO like pass that tries to determine if a function ever gets it's
address taken.
The basic problem is that the compiler (barring its own LTO pass) must
emit CFI for every non-local symbol in a translation unit. This means
that a ton of functions will have CFI on, even if they're never
indirectly called.
So objtool collects all functions that have CFI but do not get their
address taken, and sticks their address in a .discard section, then at
boot time we iterate this section and scribble the CFI state for all
these functions, making them invalid to be called indirectly.
For one this avoids malicious code from finding a function address in
the symbol table and indirectly calling it anyway as a means to
circumvent the EXPORT symbols.
So objtool does not think bpf_cgroup_release() gets its address taken,
specifically it does not find it's address in a section it knows about.
And hence it goes on the list and we scribble it and the indirect call
goes *boom*.
next prev parent reply other threads:[~2023-12-08 20:28 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-30 13:36 [PATCH v2 0/2] x86/bpf: Fix FineIBT vs eBPF Peter Zijlstra
2023-11-30 13:36 ` [PATCH v2 1/2] cfi: Flip headers Peter Zijlstra
2023-12-04 19:18 ` Sami Tolvanen
2023-11-30 13:36 ` [PATCH v2 2/2] x86/cfi,bpf: Fix BPF JIT call Peter Zijlstra
2023-12-03 22:56 ` Alexei Starovoitov
2023-12-04 9:13 ` Peter Zijlstra
2023-12-04 11:11 ` Peter Zijlstra
2023-12-04 12:52 ` Peter Zijlstra
2023-12-04 17:25 ` Jiri Olsa
2023-12-04 18:16 ` Peter Zijlstra
2023-12-04 18:33 ` Peter Zijlstra
2023-12-04 18:58 ` Sami Tolvanen
2023-12-05 1:18 ` Alexei Starovoitov
2023-12-06 15:35 ` Peter Zijlstra
2023-12-06 16:38 ` Peter Zijlstra
2023-12-06 18:37 ` Peter Zijlstra
2023-12-06 21:39 ` Alexei Starovoitov
2023-12-07 9:31 ` Peter Zijlstra
2023-12-07 22:32 ` Alexei Starovoitov
2023-12-08 10:29 ` Peter Zijlstra
2023-12-08 13:40 ` Peter Zijlstra
2023-12-08 17:21 ` Peter Zijlstra
2023-12-08 19:40 ` Alexei Starovoitov
2023-12-08 20:27 ` Peter Zijlstra [this message]
2023-12-08 20:35 ` Peter Zijlstra
2023-12-08 20:41 ` Alexei Starovoitov
2023-12-08 20:52 ` Peter Zijlstra
2023-12-08 20:58 ` Alexei Starovoitov
2023-12-08 22:45 ` Peter Zijlstra
2023-12-09 4:51 ` Alexei Starovoitov
2023-12-08 19:32 ` Alexei Starovoitov
2023-12-08 20:18 ` Peter Zijlstra
2023-12-08 20:45 ` Alexei Starovoitov
2023-12-08 20:56 ` Peter Zijlstra
2023-12-08 21:04 ` Alexei Starovoitov
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=20231208202731.GF36716@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=alexei.starovoitov@gmail.com \
--cc=andrii@kernel.org \
--cc=aou@eecs.berkeley.edu \
--cc=arnd@arndb.de \
--cc=ast@kernel.org \
--cc=bp@alien8.de \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=dsahern@kernel.org \
--cc=haoluo@google.com \
--cc=hpa@zytor.com \
--cc=joao@overdrivepizza.com \
--cc=john.fastabend@gmail.com \
--cc=jpoimboe@kernel.org \
--cc=keescook@chromium.org \
--cc=kpsingh@kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=llvm@lists.linux.dev \
--cc=mark.rutland@arm.com \
--cc=martin.lau@linux.dev \
--cc=mingo@redhat.com \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=netdev@vger.kernel.org \
--cc=olsajiri@gmail.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=samitolvanen@google.com \
--cc=sdf@google.com \
--cc=song@kernel.org \
--cc=songliubraving@meta.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=yonghong.song@linux.dev \
/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