netdev - [PATCH net-next 0/9] nfp: bpf: stack support in offload

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20171023185814.4797-1-jakub.kicinski@netronome.com>
Date:   Mon, 23 Oct 2017 11:58:05 -0700
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     netdev@...r.kernel.org
Cc:     oss-drivers@...ronome.com,
        Jakub Kicinski <jakub.kicinski@...ronome.com>
Subject: [PATCH net-next 0/9] nfp: bpf: stack support in offload

Hi!

This series brings stack support for offload.

We use the LMEM (Local memory) register file as memory to store
the stack.  Since this is a register file we need to do appropriate
shifts on unaligned accesses.  Verifier's state tracking helps us
with that.

LMEM can't be accessed directly, so we add support for setting
pointer registers through which one can read/write LMEM.

This set does not support accessing the stack when the alignment 
is not known.  This can be added later (most likely using the byte_align 
instructions).  There is also a number of optimizations which have been
left out:
 - in more complex non aligned accesses, double shift and rotation
   can save us a cycle.  This, however, leads to code explosion 
   since all access sizes have to be coded separately;
 - since setting LM pointers costs around 5 cycles, we should be
   tracking their values to make sure we don't move them when
   they're already set correctly for earlier access;
 - in case of 8 byte access aligned to 4 bytes and crossing 
   32 byte boundary but not crossing a 64 byte boundary we don't
   have to increment the pointer, but this seems like a pretty
   rare case to justify the added complexity.


Jakub Kicinski (9):
  nfp: bpf: add helper for emitting nops
  nfp: bpf: refactor nfp_bpf_check_ptr()
  nfp: bpf: add stack write support
  nfp: bpf: add stack read support
  nfp: bpf: optimize the RMW for stack accesses
  nfp: bpf: allow stack accesses via modified stack registers
  nfp: bpf: support accessing the stack beyond 64 bytes
  nfp: bpf: support stack accesses via non-constant pointers
  nfp: bpf: optimize mov64 a little

 drivers/net/ethernet/netronome/nfp/bpf/jit.c      | 357 +++++++++++++++++++++-
 drivers/net/ethernet/netronome/nfp/bpf/main.h     |   8 +
 drivers/net/ethernet/netronome/nfp/bpf/offload.c  |   8 +
 drivers/net/ethernet/netronome/nfp/bpf/verifier.c |  64 +++-
 drivers/net/ethernet/netronome/nfp/nfp_asm.h      |   5 +
 5 files changed, 420 insertions(+), 22 deletions(-)

-- 
2.14.1