From: Alexei Starovoitov <ast@fb.com>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>,
Alexei Starovoitov <ast@kernel.org>
Cc: "David S. Miller" <davem@davemloft.net>,
Daniel Borkmann <daniel@iogearbox.net>,
"x86@kernel.org" <x86@kernel.org>,
Networking <netdev@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
Kernel Team <Kernel-team@fb.com>
Subject: Re: [PATCH bpf-next 07/10] bpf: add support for BTF pointers to x86 JIT
Date: Wed, 9 Oct 2019 17:46:16 +0000 [thread overview]
Message-ID: <c08a5ce5-cc82-97ae-40cd-8f8bdd8a5668@fb.com> (raw)
In-Reply-To: <CAEf4Bza0FP9EgXVuHsQFy4-bedn3uypuwznpu2fPDTYLaMAQpA@mail.gmail.com>
On 10/9/19 10:38 AM, Andrii Nakryiko wrote:
> On Fri, Oct 4, 2019 at 10:04 PM Alexei Starovoitov <ast@kernel.org> wrote:
>>
>> Pointer to BTF object is a pointer to kernel object or NULL.
>> Such pointers can only be used by BPF_LDX instructions.
>> The verifier changed their opcode from LDX|MEM|size
>> to LDX|PROBE_MEM|size to make JITing easier.
>> The number of entries in extable is the number of BPF_LDX insns
>> that access kernel memory via "pointer to BTF type".
>> Only these load instructions can fault.
>> Since x86 extable is relative it has to be allocated in the same
>> memory region as JITed code.
>> Allocate it prior to last pass of JITing and let the last pass populate it.
>> Pointer to extable in bpf_prog_aux is necessary to make page fault
>> handling fast.
>> Page fault handling is done in two steps:
>> 1. bpf_prog_kallsyms_find() finds BPF program that page faulted.
>> It's done by walking rb tree.
>> 2. then extable for given bpf program is binary searched.
>> This process is similar to how page faulting is done for kernel modules.
>> The exception handler skips over faulting x86 instruction and
>> initializes destination register with zero. This mimics exact
>> behavior of bpf_probe_read (when probe_kernel_read faults dest is zeroed).
>>
>> JITs for other architectures can add support in similar way.
>> Until then they will reject unknown opcode and fallback to interpreter.
>>
>> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
>> ---
>> arch/x86/net/bpf_jit_comp.c | 96 +++++++++++++++++++++++++++++++++++--
>> include/linux/bpf.h | 3 ++
>> include/linux/extable.h | 10 ++++
>> kernel/bpf/core.c | 20 +++++++-
>> kernel/bpf/verifier.c | 1 +
>> kernel/extable.c | 2 +
>> 6 files changed, 127 insertions(+), 5 deletions(-)
>>
>
> This is surprisingly easy to follow :) Looks good overall, just one
> concern about 32-bit distance between ex_handler_bpf and BPF jitted
> program below. And I agree with Eric, probably need to ensure proper
> alignment for exception_table_entry array.
already fixed.
> [...]
>
>> @@ -805,6 +835,48 @@ stx: if (is_imm8(insn->off))
>> else
>> EMIT1_off32(add_2reg(0x80, src_reg, dst_reg),
>> insn->off);
>> + if (BPF_MODE(insn->code) == BPF_PROBE_MEM) {
>> + struct exception_table_entry *ex;
>> + u8 *_insn = image + proglen;
>> + s64 delta;
>> +
>> + if (!bpf_prog->aux->extable)
>> + break;
>> +
>> + if (excnt >= bpf_prog->aux->num_exentries) {
>> + pr_err("ex gen bug\n");
>
> This should never happen, right? BUG()?
absolutely not. No BUGs in kernel for things like this.
If kernel can continue it should.
>> + return -EFAULT;
>> + }
>> + ex = &bpf_prog->aux->extable[excnt++];
>> +
>> + delta = _insn - (u8 *)&ex->insn;
>> + if (!is_simm32(delta)) {
>> + pr_err("extable->insn doesn't fit into 32-bit\n");
>> + return -EFAULT;
>> + }
>> + ex->insn = delta;
>> +
>> + delta = (u8 *)ex_handler_bpf - (u8 *)&ex->handler;
>
> how likely it is that global ex_handle_bpf will be close enough to
> dynamically allocated piece of exception_table_entry?
99.9% Since we rely on that in other places in the JIT.
See BPF_CALL, for example.
But I'd like to keep the check below. Just in case.
Same as in BPF_CALL.
next prev parent reply other threads:[~2019-10-09 17:46 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-05 5:03 [PATCH bpf-next 00/10] bpf: revolutionize bpf tracing Alexei Starovoitov
2019-10-05 5:03 ` [PATCH bpf-next 01/10] bpf: add typecast to raw_tracepoints to help BTF generation Alexei Starovoitov
2019-10-05 18:40 ` Andrii Nakryiko
2019-10-06 3:58 ` John Fastabend
2019-10-05 5:03 ` [PATCH bpf-next 02/10] bpf: add typecast to bpf helpers " Alexei Starovoitov
2019-10-05 18:41 ` Andrii Nakryiko
2019-10-06 4:00 ` John Fastabend
2019-10-05 5:03 ` [PATCH bpf-next 03/10] bpf: process in-kernel BTF Alexei Starovoitov
2019-10-06 6:36 ` Andrii Nakryiko
2019-10-06 23:49 ` Alexei Starovoitov
2019-10-07 0:20 ` Andrii Nakryiko
2019-10-09 20:51 ` Martin Lau
2019-10-10 3:43 ` Alexei Starovoitov
2019-10-05 5:03 ` [PATCH bpf-next 04/10] libbpf: auto-detect btf_id of raw_tracepoint Alexei Starovoitov
2019-10-07 23:41 ` Andrii Nakryiko
2019-10-09 2:26 ` Alexei Starovoitov
2019-10-05 5:03 ` [PATCH bpf-next 05/10] bpf: implement accurate raw_tp context access via BTF Alexei Starovoitov
2019-10-07 16:32 ` Alan Maguire
2019-10-09 3:59 ` Alexei Starovoitov
2019-10-08 0:35 ` Andrii Nakryiko
2019-10-09 3:30 ` Alexei Starovoitov
2019-10-09 4:01 ` Andrii Nakryiko
2019-10-09 5:10 ` Andrii Nakryiko
2019-10-10 3:54 ` Alexei Starovoitov
2019-10-05 5:03 ` [PATCH bpf-next 06/10] bpf: add support for BTF pointers to interpreter Alexei Starovoitov
2019-10-08 3:08 ` Andrii Nakryiko
2019-10-05 5:03 ` [PATCH bpf-next 07/10] bpf: add support for BTF pointers to x86 JIT Alexei Starovoitov
2019-10-05 6:03 ` Eric Dumazet
2019-10-09 17:38 ` Andrii Nakryiko
2019-10-09 17:46 ` Alexei Starovoitov [this message]
2019-10-05 5:03 ` [PATCH bpf-next 08/10] bpf: check types of arguments passed into helpers Alexei Starovoitov
2019-10-09 18:01 ` Andrii Nakryiko
2019-10-09 19:58 ` Alexei Starovoitov
2019-10-05 5:03 ` [PATCH bpf-next 09/10] bpf: disallow bpf_probe_read[_str] helpers Alexei Starovoitov
2019-10-09 5:29 ` Andrii Nakryiko
2019-10-09 19:38 ` Alexei Starovoitov
2019-10-05 5:03 ` [PATCH bpf-next 10/10] selftests/bpf: add kfree_skb raw_tp test Alexei Starovoitov
2019-10-09 5:36 ` Andrii Nakryiko
2019-10-09 17:37 ` 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=c08a5ce5-cc82-97ae-40cd-8f8bdd8a5668@fb.com \
--to=ast@fb.com \
--cc=Kernel-team@fb.com \
--cc=andrii.nakryiko@gmail.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=x86@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).