All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shubham Bansal <illusionist.neo@gmail.com>
To: Kees Cook <keescook@chromium.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Mircea Gherzan <mgherzan@gmail.com>
Cc: netdev@vger.kernel.org, kernel-hardening@lists.openwall.com,
	linux@armlinux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
Date: Mon, 30 Jan 2017 16:08:54 +0530	[thread overview]
Message-ID: <20170130103853.GA34633@in3o.xyz> (raw)

Hi all,

Please ignore last copy of this mail. Kernel mailing lists bounced my
last mail back because of HTML content.

Just starting a new thread with proper heading on the main kernel
hardening and net-dev mailing list so that other people can be involved
in this. Please don't take this as a personal mail.

I am working on conversion of arm32 cBPF into eBPF JIT. I wanted some
help, regarding understanding of kernel code, from the dev available on
the mailing list. If you look at the ./arch/arm/net/bpf_jit_32.c code,
you will see jit_ctx structure. If anybody could help me understand what
each fields of this structure represent then it would be great.

Also, currently I am mapping the eBPF registers to arm 32 bit registers
in the following way.

> static const int bpf2a32[] = {
>
>         /* return value from in-kernel function, and exit value from
>         eBPF
> */
>         [BPF_REG_0] = ARM_R0,
>
>         /* arguments from eBPF program to in-kernel function */
>
>         [BPF_REG_1] = ARM_R1,
>
>         [BPF_REG_2] = ARM_R2,
>
>         [BPF_REG_3] = ARM_R3,
>
>         [BPF_REG_4] = ARM_R4,
>
>         [BPF_REG_5] = ARM_R5,
>
>         /* callee saved registers that in-kernel function will
>         preserve */
>
>         [BPF_REG_6] = ARM_R6,
>
>         [BPF_REG_7] = ARM_R7,
>
>         [BPF_REG_8] = ARM_R8,
>
>         [BPF_REG_9] = ARM_R9,
>
>         /* Read only Frame Pointer to access Stack */
>
>         [BPF_REG_FP] = ARM_FP,
>
>         /* Temperory Register for internal BPF JIT */
>
>         [TMP_REG_1] = ARM_R11,
>
>         /* temporary register for blinding constants */
>
>         [BPF_REG_AX] = ARM_R10,
>
> };

But I have some question if anybody could help with those.

1.) Currently, as eBPF uses 64 bit registers, I am mapping 64 bit eBPF
registers with 32 bit arm registers which looks wrong to me. Do anybody
have some idea about how to map eBPF->arm 32 bit registers ?
2.) Also, is my current mapping good enough to make the JIT fast enough ?
because as you might know, eBPF JIT mostly depends on 1-to-1 mapping of
its instructions with native instructions.

Appreciate the help from anybody from the mailing list.

Best,
Shubham Bansal

WARNING: multiple messages have this Message-ID (diff)
From: illusionist.neo@gmail.com (Shubham Bansal)
To: linux-arm-kernel@lists.infradead.org
Subject: arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
Date: Mon, 30 Jan 2017 16:08:54 +0530	[thread overview]
Message-ID: <20170130103853.GA34633@in3o.xyz> (raw)

Hi all,

Please ignore last copy of this mail. Kernel mailing lists bounced my
last mail back because of HTML content.

Just starting a new thread with proper heading on the main kernel
hardening and net-dev mailing list so that other people can be involved
in this. Please don't take this as a personal mail.

I am working on conversion of arm32 cBPF into eBPF JIT. I wanted some
help, regarding understanding of kernel code, from the dev available on
the mailing list. If you look at the ./arch/arm/net/bpf_jit_32.c code,
you will see jit_ctx structure. If anybody could help me understand what
each fields of this structure represent then it would be great.

Also, currently I am mapping the eBPF registers to arm 32 bit registers
in the following way.

> static const int bpf2a32[] = {
>
>         /* return value from in-kernel function, and exit value from
>         eBPF
> */
>         [BPF_REG_0] = ARM_R0,
>
>         /* arguments from eBPF program to in-kernel function */
>
>         [BPF_REG_1] = ARM_R1,
>
>         [BPF_REG_2] = ARM_R2,
>
>         [BPF_REG_3] = ARM_R3,
>
>         [BPF_REG_4] = ARM_R4,
>
>         [BPF_REG_5] = ARM_R5,
>
>         /* callee saved registers that in-kernel function will
>         preserve */
>
>         [BPF_REG_6] = ARM_R6,
>
>         [BPF_REG_7] = ARM_R7,
>
>         [BPF_REG_8] = ARM_R8,
>
>         [BPF_REG_9] = ARM_R9,
>
>         /* Read only Frame Pointer to access Stack */
>
>         [BPF_REG_FP] = ARM_FP,
>
>         /* Temperory Register for internal BPF JIT */
>
>         [TMP_REG_1] = ARM_R11,
>
>         /* temporary register for blinding constants */
>
>         [BPF_REG_AX] = ARM_R10,
>
> };

But I have some question if anybody could help with those.

1.) Currently, as eBPF uses 64 bit registers, I am mapping 64 bit eBPF
registers with 32 bit arm registers which looks wrong to me. Do anybody
have some idea about how to map eBPF->arm 32 bit registers ?
2.) Also, is my current mapping good enough to make the JIT fast enough ?
because as you might know, eBPF JIT mostly depends on 1-to-1 mapping of
its instructions with native instructions.

Appreciate the help from anybody from the mailing list.

Best,
Shubham Bansal

WARNING: multiple messages have this Message-ID (diff)
From: Shubham Bansal <illusionist.neo@gmail.com>
To: Kees Cook <keescook@chromium.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Mircea Gherzan <mgherzan@gmail.com>
Cc: netdev@vger.kernel.org, kernel-hardening@lists.openwall.com,
	linux@armlinux.org.uk, linux-arm-kernel@lists.infradead.org
Subject: [kernel-hardening] arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit
Date: Mon, 30 Jan 2017 16:08:54 +0530	[thread overview]
Message-ID: <20170130103853.GA34633@in3o.xyz> (raw)

Hi all,

Please ignore last copy of this mail. Kernel mailing lists bounced my
last mail back because of HTML content.

Just starting a new thread with proper heading on the main kernel
hardening and net-dev mailing list so that other people can be involved
in this. Please don't take this as a personal mail.

I am working on conversion of arm32 cBPF into eBPF JIT. I wanted some
help, regarding understanding of kernel code, from the dev available on
the mailing list. If you look at the ./arch/arm/net/bpf_jit_32.c code,
you will see jit_ctx structure. If anybody could help me understand what
each fields of this structure represent then it would be great.

Also, currently I am mapping the eBPF registers to arm 32 bit registers
in the following way.

> static const int bpf2a32[] = {
>
>         /* return value from in-kernel function, and exit value from
>         eBPF
> */
>         [BPF_REG_0] = ARM_R0,
>
>         /* arguments from eBPF program to in-kernel function */
>
>         [BPF_REG_1] = ARM_R1,
>
>         [BPF_REG_2] = ARM_R2,
>
>         [BPF_REG_3] = ARM_R3,
>
>         [BPF_REG_4] = ARM_R4,
>
>         [BPF_REG_5] = ARM_R5,
>
>         /* callee saved registers that in-kernel function will
>         preserve */
>
>         [BPF_REG_6] = ARM_R6,
>
>         [BPF_REG_7] = ARM_R7,
>
>         [BPF_REG_8] = ARM_R8,
>
>         [BPF_REG_9] = ARM_R9,
>
>         /* Read only Frame Pointer to access Stack */
>
>         [BPF_REG_FP] = ARM_FP,
>
>         /* Temperory Register for internal BPF JIT */
>
>         [TMP_REG_1] = ARM_R11,
>
>         /* temporary register for blinding constants */
>
>         [BPF_REG_AX] = ARM_R10,
>
> };

But I have some question if anybody could help with those.

1.) Currently, as eBPF uses 64 bit registers, I am mapping 64 bit eBPF
registers with 32 bit arm registers which looks wrong to me. Do anybody
have some idea about how to map eBPF->arm 32 bit registers ?
2.) Also, is my current mapping good enough to make the JIT fast enough ?
because as you might know, eBPF JIT mostly depends on 1-to-1 mapping of
its instructions with native instructions.

Appreciate the help from anybody from the mailing list.

Best,
Shubham Bansal

             reply	other threads:[~2017-01-30 10:38 UTC|newest]

Thread overview: 105+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-30 10:38 Shubham Bansal [this message]
2017-01-30 10:38 ` [kernel-hardening] arch: arm: bpf: Converting cBPF to eBPF for arm 32 bit Shubham Bansal
2017-01-30 10:38 ` Shubham Bansal
2017-01-30 21:57 ` Kees Cook
2017-01-30 21:57   ` [kernel-hardening] " Kees Cook
2017-01-30 21:57   ` Kees Cook
     [not found]   ` <CAHgaXd+nj69n-Xf46N=4M-j-0hKHVrrLfsvRZCG=2CCAtVF6ZA@mail.gmail.com>
     [not found]     ` <CAGXu5j+NSLomuSgD40kys+pWc+J9aB6Bbk_gSP9Lp_ScimQn_w@mail.gmail.com>
2017-02-01 13:01       ` Shubham Bansal
2017-02-01 13:01         ` [kernel-hardening] " Shubham Bansal
2017-02-01 13:01         ` Shubham Bansal
2017-02-01 13:06         ` Fwd: " Shubham Bansal
2017-02-01 13:06           ` [kernel-hardening] " Shubham Bansal
2017-02-06 11:52           ` Shubham Bansal
2017-02-06 11:52             ` [kernel-hardening] " Shubham Bansal
     [not found]         ` <76621BFF-B30B-4417-AB2B-DB21CA6092D9@netronome.com>
2017-02-03  7:04           ` Shubham Bansal
2017-02-03  7:04             ` [kernel-hardening] " Shubham Bansal
2017-02-03  7:04             ` Shubham Bansal
2017-02-03  8:25             ` nick viljoen
2017-02-03  8:25               ` [kernel-hardening] " nick viljoen
2017-02-03  8:25               ` nick viljoen
2017-02-08  7:29         ` Shubham Bansal
2017-02-08  7:29           ` [kernel-hardening] " Shubham Bansal
2017-02-08  7:29           ` Shubham Bansal
2017-02-08 19:41         ` Kees Cook
2017-02-08 19:41           ` [kernel-hardening] " Kees Cook
2017-02-08 19:41           ` Kees Cook
2017-03-15 12:13           ` Shubham Bansal
2017-03-15 12:13             ` [kernel-hardening] " Shubham Bansal
2017-03-15 12:13             ` Shubham Bansal
2017-03-15 21:55             ` David Miller
2017-03-15 21:55               ` [kernel-hardening] " David Miller
2017-03-15 21:55               ` David Miller
2017-03-28 20:49               ` Shubham Bansal
2017-03-28 20:49                 ` [kernel-hardening] " Shubham Bansal
2017-03-28 20:49                 ` Shubham Bansal
2017-03-29  0:00                 ` Daniel Borkmann
2017-03-29  0:00                   ` [kernel-hardening] " Daniel Borkmann
2017-03-29  0:00                   ` Daniel Borkmann
2017-03-30 14:04                   ` Shubham Bansal
2017-03-30 14:04                     ` [kernel-hardening] " Shubham Bansal
2017-03-30 14:04                     ` Shubham Bansal
2017-04-06 11:05                     ` Shubham Bansal
2017-04-06 11:05                       ` [kernel-hardening] " Shubham Bansal
2017-04-06 11:05                       ` Shubham Bansal
2017-04-06 12:51                       ` Daniel Borkmann
2017-04-06 12:51                         ` [kernel-hardening] " Daniel Borkmann
2017-04-06 12:51                         ` Daniel Borkmann
2017-05-06 16:48                         ` Shubham Bansal
2017-05-06 16:48                           ` [kernel-hardening] " Shubham Bansal
2017-05-06 16:48                           ` Shubham Bansal
2017-05-06 18:38                           ` David Miller
2017-05-06 18:38                             ` [kernel-hardening] " David Miller
2017-05-06 18:38                             ` David Miller
2017-05-06 20:27                             ` Shubham Bansal
2017-05-06 20:27                               ` [kernel-hardening] " Shubham Bansal
2017-05-06 20:27                               ` Shubham Bansal
2017-05-06 22:17                               ` Shubham Bansal
2017-05-06 22:17                                 ` [kernel-hardening] " Shubham Bansal
2017-05-06 22:17                                 ` Shubham Bansal
2017-05-09 20:12                         ` Shubham Bansal
2017-05-09 20:12                           ` [kernel-hardening] " Shubham Bansal
2017-05-09 20:12                           ` Shubham Bansal
2017-05-09 20:19                           ` David Miller
2017-05-09 20:19                             ` [kernel-hardening] " David Miller
2017-05-09 20:19                             ` David Miller
2017-05-09 20:25                           ` Daniel Borkmann
2017-05-09 20:25                             ` [kernel-hardening] " Daniel Borkmann
2017-05-09 20:25                             ` Daniel Borkmann
     [not found] <CAHgaXdKsO2xoKYp7g91g+n+d_1KHSSByLjzBB-WjVXSjhB7qxw@mail.gmail.com>
     [not found] ` <20170510.212952.1440495072777358778.davem@davemloft.net>
     [not found]   ` <CAHgaXdK8LEEUPm4jTRRzCnjwdWAauHmmB=caZsSFY8MmStH89Q@mail.gmail.com>
     [not found]     ` <20170510.215218.2185526627014393313.davem@davemloft.net>
     [not found]       ` <CAHgaXdKZ_v+iO7uqEDx7PA7D+xcp1FngGvJ1SRSsGXNQ-iWWDQ@mail.gmail.com>
2017-05-11  9:32         ` Shubham Bansal
2017-05-11  9:32           ` Shubham Bansal
2017-05-11 15:30           ` Kees Cook
2017-05-11 15:30             ` Kees Cook
2017-05-13 21:38             ` Shubham Bansal
2017-05-13 21:38               ` Shubham Bansal
2017-05-15 17:44               ` Kees Cook
2017-05-15 17:44                 ` Kees Cook
2017-05-15 19:55               ` Daniel Borkmann
2017-05-15 19:55                 ` Daniel Borkmann
2017-05-20 20:01                 ` Shubham Bansal
2017-05-20 20:01                   ` Shubham Bansal
2017-05-22 13:01                   ` Daniel Borkmann
2017-05-22 13:01                     ` Daniel Borkmann
2017-05-22 17:04                     ` Shubham Bansal
2017-05-22 17:04                       ` Shubham Bansal
2017-05-22 20:05                       ` Kees Cook
2017-05-22 20:05                         ` Kees Cook
2017-05-23  2:58                         ` Shubham Bansal
2017-05-23  2:58                           ` Shubham Bansal
2017-05-23  4:27                           ` Kees Cook
2017-05-23  4:27                             ` Kees Cook
2017-05-22 18:58                   ` Kees Cook
2017-05-22 18:58                     ` Kees Cook
2017-05-22 19:08                     ` Florian Fainelli
2017-05-22 19:08                       ` Florian Fainelli
2017-05-23  3:34                       ` Shubham Bansal
2017-05-23  3:34                         ` Shubham Bansal
2017-05-23  4:22                         ` Kees Cook
2017-05-23  4:22                           ` Kees Cook
2017-05-23  5:03                           ` Shubham Bansal
2017-05-23  5:03                             ` Shubham Bansal
2017-05-23  5:35                             ` Kees Cook
2017-05-23  5:35                               ` Kees Cook
2017-05-23 18:39                               ` Shubham Bansal
2017-05-23 19:32                                 ` Kees Cook
2017-05-23 19:32                                   ` Kees Cook
  -- strict thread matches above, loose matches on Subject: below --
2017-01-30 10:16 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=20170130103853.GA34633@in3o.xyz \
    --to=illusionist.neo@gmail.com \
    --cc=daniel@iogearbox.net \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux@armlinux.org.uk \
    --cc=mgherzan@gmail.com \
    --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.