From: Daniel Borkmann <daniel@iogearbox•net>
To: Shubham Bansal <illusionist.neo@gmail•com>
Cc: Kees Cook <keescook@chromium•org>,
Network Development <netdev@vger•kernel.org>,
"David S. Miller" <davem@davemloft•net>,
Alexei Starovoitov <ast@kernel•org>,
Russell King <linux@armlinux•org.uk>,
"linux-arm-kernel@lists•infradead.org"
<linux-arm-kernel@lists•infradead.org>,
LKML <linux-kernel@vger•kernel.org>, Andrew Lunn <andrew@lunn•ch>
Subject: Re: [PATCH v2] arm: eBPF JIT compiler
Date: Tue, 20 Jun 2017 18:55:03 +0200 [thread overview]
Message-ID: <59495367.3080402@iogearbox.net> (raw)
In-Reply-To: <CAHgaXdLtX6yLdU3bMvS=g8FZ79sM_BW_+hHTMH=Mfk4TZqUnpw@mail.gmail.com>
On 06/20/2017 03:34 AM, Shubham Bansal wrote:
> Hi Daniel,
>
>> Sorry, had a travel over the weekend, so didn't read it in time.
>>
>> What is the issue with imitating in JIT what the interpreter is
>> doing as a starting point? That should be generic enough to handle
>> any case.
Why not proceeding this way first?
>> Otherwise you'd need some sort of reverse mapping since verifier
>> already converted BPF_CALL insns into relative helper addresses
>> in imm part.
>>
> Sorry but I don't get what you are trying to say. Can you explain it
> with an example?
Ok, probably the best is to check fixup_bpf_calls() in the verifier,
see the fn = prog->aux->ops->get_func_proto(insn->imm). It fetches the
helper function specification based on the BPF_FUNC_* enum and converts
the imm field into a relative address for the function such that if
you look at ___bpf_prog_run(), JMP_CALL label, the call address can
be reconstructed again. So you'd need some reverse mapping to get back
to the struct bpf_func_proto, so you can check argX_type that needs to
be extended with whether its JITable on 32bit or not.
next prev parent reply other threads:[~2017-06-20 16:55 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1495754003-21099-1-git-send-email-illusionist.neo@gmail.com>
2017-05-30 19:19 ` [PATCH v2] arm: eBPF JIT compiler Kees Cook
2017-06-06 19:47 ` Shubham Bansal
2017-06-12 2:00 ` Kees Cook
2017-06-12 10:21 ` Daniel Borkmann
2017-06-12 11:06 ` Russell King - ARM Linux
2017-06-12 15:41 ` Shubham Bansal
2017-06-12 15:40 ` Shubham Bansal
2017-06-12 22:45 ` Alexander Alemayhu
2017-06-12 22:47 ` David Miller
2017-06-12 23:17 ` Daniel Borkmann
2017-06-13 6:56 ` Shubham Bansal
2017-06-14 20:31 ` Daniel Borkmann
2017-06-17 12:23 ` Shubham Bansal
2017-06-19 18:10 ` Daniel Borkmann
2017-06-20 1:34 ` Shubham Bansal
2017-06-20 16:55 ` Daniel Borkmann [this message]
2017-06-21 14:26 ` Shubham Bansal
2017-06-21 16:32 ` Daniel Borkmann
2017-06-21 19:37 ` Shubham Bansal
2017-06-21 19:53 ` Daniel Borkmann
2017-06-23 22:39 ` Shubham Bansal
2017-07-05 22:11 ` Kees Cook
2017-07-05 22:38 ` Kees Cook
2017-07-06 3:49 ` Shubham Bansal
2017-07-07 4:42 ` Kees Cook
2017-07-07 4:49 ` Shubham Bansal
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=59495367.3080402@iogearbox.net \
--to=daniel@iogearbox$(echo .)net \
--cc=andrew@lunn$(echo .)ch \
--cc=ast@kernel$(echo .)org \
--cc=davem@davemloft$(echo .)net \
--cc=illusionist.neo@gmail$(echo .)com \
--cc=keescook@chromium$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux@armlinux$(echo .)org.uk \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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