All of lore.kernel.org
 help / color / mirror / Atom feed
From: daniel@iogearbox.net (Daniel Borkmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [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.

WARNING: multiple messages have this Message-ID (diff)
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.

  reply	other threads:[~2017-06-20 16:55 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-25 23:13 [PATCH v2] arm: eBPF JIT compiler Shubham Bansal
2017-05-25 23:13 ` Shubham Bansal
2017-05-25 23:23 ` Andrew Lunn
2017-05-25 23:23   ` Andrew Lunn
2017-05-25 23:34   ` Shubham Bansal
2017-05-25 23:34     ` Shubham Bansal
2017-05-25 23:36     ` Shubham Bansal
2017-05-25 23:36       ` Shubham Bansal
2017-05-26 16:57       ` Shubham Bansal
2017-05-26 16:57         ` Shubham Bansal
2017-05-30 18:50         ` Shubham Bansal
2017-05-30 18:50           ` Shubham Bansal
2017-05-30 19:11 ` Kees Cook
2017-05-30 19:11   ` Kees Cook
2017-05-30 19:19 ` Kees Cook
2017-06-06 19:47   ` Shubham Bansal
2017-06-12  2:00     ` Kees Cook
2017-06-12  2:00       ` Kees Cook
2017-06-12 10:21   ` Daniel Borkmann
2017-06-12 10:21     ` Daniel Borkmann
2017-06-12 11:06     ` Russell King - ARM Linux
2017-06-12 11:06       ` Russell King - ARM Linux
2017-06-12 15:41       ` Shubham Bansal
2017-06-12 15:41         ` Shubham Bansal
2017-06-12 15:40     ` Shubham Bansal
2017-06-12 15:40       ` Shubham Bansal
2017-06-12 22:45       ` Alexander Alemayhu
2017-06-12 22:45         ` Alexander Alemayhu
2017-06-12 22:47         ` David Miller
2017-06-12 22:47           ` David Miller
2017-06-12 23:17       ` Daniel Borkmann
2017-06-12 23:17         ` Daniel Borkmann
2017-06-13  6:56       ` Shubham Bansal
2017-06-13  6:56         ` Shubham Bansal
2017-06-14 20:31         ` Daniel Borkmann
2017-06-14 20:31           ` Daniel Borkmann
2017-06-17 12:23           ` Shubham Bansal
2017-06-17 12:23             ` Shubham Bansal
2017-06-19 18:10             ` Daniel Borkmann
2017-06-19 18:10               ` Daniel Borkmann
2017-06-20  1:34               ` Shubham Bansal
2017-06-20  1:34                 ` Shubham Bansal
2017-06-20 16:55                 ` Daniel Borkmann [this message]
2017-06-20 16:55                   ` Daniel Borkmann
2017-06-21 14:26                   ` Shubham Bansal
2017-06-21 14:26                     ` Shubham Bansal
2017-06-21 16:32                     ` Daniel Borkmann
2017-06-21 16:32                       ` Daniel Borkmann
2017-06-21 19:37                       ` Shubham Bansal
2017-06-21 19:37                         ` Shubham Bansal
2017-06-21 19:53                         ` Daniel Borkmann
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:11                           ` Kees Cook
2017-07-05 22:38                           ` 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:42                                 ` Kees Cook
2017-07-07  4:49                                 ` Shubham Bansal
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.net \
    --cc=linux-arm-kernel@lists.infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.