All of lore.kernel.org
 help / color / mirror / Atom feed
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: Mon, 19 Jun 2017 20:10:50 +0200	[thread overview]
Message-ID: <594813AA.5010001@iogearbox.net> (raw)
In-Reply-To: <CAHgaXdKMbFPgy-kKF0iDSAYo4CqLn9FRu9HwM+OfM-JWb9fNRQ@mail.gmail.com>

On 06/17/2017 02:23 PM, Shubham Bansal wrote:
> Hi Daniel,
>
>> Not all of the helpers have 4 or less byte arguments only, there are a
>> few with 8 byte arguments, so making that general assumption wouldn't
>> work. I guess what could be done is that helpers have a flag in struct
>> bpf_func_proto which indicates for JITs that all args are 4 byte on 32bit
>> so you could probably use convention similar to case2 for them. Presumably
>> for that information to process, the JIT might need to be reworked to
>> extract that via bpf_analyzer() that does a verifier run to re-analyze
>> the program like in nfp JIT case.
>
> Let me try a better solution which can be used to support both 4 byte
> and 8 byte arguments. I hope it would work out. Are you sure this
> patch can pass if it only supports 4 byte arguments though?
> Let me list out what I have to do, so that you can tell me if I am
> thinking in a wrong way :-
>
> * I will add a bit flag in bpf_func_proto to represent whether
> different arguments in a function call are 4 bytes or 8 bytes. If lsb
> of bit flag is set then first argument is 8 byte, otherwise its not. I
> think I can handle this flag properly in build_insn() in my code. Does
> this sound okay?
>
> I don't understand second part of your solution, i.e.
>
>> Presumably
>> for that information to process, the JIT might need to be reworked to
>> extract that via bpf_analyzer() that does a verifier run to re-analyze
>> the program like in nfp JIT case.
>
> Please explain what are you suggesting and how can I extract bit flag
> from bpf_func_proto().
>
> Please reply asap, as I would like to finish it over the weekend. Please.

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.

Otherwise you'd need some sort of reverse mapping since verifier
already converted BPF_CALL insns into relative helper addresses
in imm part.

> -Shubham
>

WARNING: multiple messages have this Message-ID (diff)
From: daniel@iogearbox.net (Daniel Borkmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] arm: eBPF JIT compiler
Date: Mon, 19 Jun 2017 20:10:50 +0200	[thread overview]
Message-ID: <594813AA.5010001@iogearbox.net> (raw)
In-Reply-To: <CAHgaXdKMbFPgy-kKF0iDSAYo4CqLn9FRu9HwM+OfM-JWb9fNRQ@mail.gmail.com>

On 06/17/2017 02:23 PM, Shubham Bansal wrote:
> Hi Daniel,
>
>> Not all of the helpers have 4 or less byte arguments only, there are a
>> few with 8 byte arguments, so making that general assumption wouldn't
>> work. I guess what could be done is that helpers have a flag in struct
>> bpf_func_proto which indicates for JITs that all args are 4 byte on 32bit
>> so you could probably use convention similar to case2 for them. Presumably
>> for that information to process, the JIT might need to be reworked to
>> extract that via bpf_analyzer() that does a verifier run to re-analyze
>> the program like in nfp JIT case.
>
> Let me try a better solution which can be used to support both 4 byte
> and 8 byte arguments. I hope it would work out. Are you sure this
> patch can pass if it only supports 4 byte arguments though?
> Let me list out what I have to do, so that you can tell me if I am
> thinking in a wrong way :-
>
> * I will add a bit flag in bpf_func_proto to represent whether
> different arguments in a function call are 4 bytes or 8 bytes. If lsb
> of bit flag is set then first argument is 8 byte, otherwise its not. I
> think I can handle this flag properly in build_insn() in my code. Does
> this sound okay?
>
> I don't understand second part of your solution, i.e.
>
>> Presumably
>> for that information to process, the JIT might need to be reworked to
>> extract that via bpf_analyzer() that does a verifier run to re-analyze
>> the program like in nfp JIT case.
>
> Please explain what are you suggesting and how can I extract bit flag
> from bpf_func_proto().
>
> Please reply asap, as I would like to finish it over the weekend. Please.

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.

Otherwise you'd need some sort of reverse mapping since verifier
already converted BPF_CALL insns into relative helper addresses
in imm part.

> -Shubham
>

  reply	other threads:[~2017-06-19 18:11 UTC|newest]

Thread overview: 87+ 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-05-30 19:19   ` Kees Cook
2017-06-06 19:47   ` Shubham Bansal
2017-06-06 19:47     ` Shubham Bansal
2017-06-12  2:00     ` Kees Cook
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 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 11:06       ` Russell King - ARM Linux
2017-06-12 15:41       ` Shubham Bansal
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 15:40       ` Shubham Bansal
2017-06-12 22:45       ` Alexander Alemayhu
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-12 23:17         ` Daniel Borkmann
2017-06-13  6:56       ` Shubham Bansal
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-14 20:31           ` Daniel Borkmann
2017-06-17 12:23           ` Shubham Bansal
2017-06-17 12:23             ` Shubham Bansal
2017-06-17 12:23             ` Shubham Bansal
2017-06-19 18:10             ` Daniel Borkmann [this message]
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  1:34                 ` Shubham Bansal
2017-06-20 16:55                 ` Daniel Borkmann
2017-06-20 16:55                   ` Daniel Borkmann
2017-06-20 16:55                   ` Daniel Borkmann
2017-06-21 14:26                   ` Shubham Bansal
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 16:32                       ` Daniel Borkmann
2017-06-21 19:37                       ` Shubham Bansal
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-21 19:53                           ` Daniel Borkmann
2017-06-23 22:39                       ` Shubham Bansal
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:11                           ` Kees Cook
2017-07-05 22:38                           ` 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-06  3:49                               ` Shubham Bansal
2017-07-07  4:42                               ` Kees Cook
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
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=594813AA.5010001@iogearbox.net \
    --to=daniel@iogearbox.net \
    --cc=andrew@lunn.ch \
    --cc=ast@kernel.org \
    --cc=davem@davemloft.net \
    --cc=illusionist.neo@gmail.com \
    --cc=keescook@chromium.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --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 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.