netdev - Re: XDP multi-buffer design discussion

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20191217094635.7e4cac1c@carbon>
Date:   Tue, 17 Dec 2019 09:46:35 +0100
From:   Jesper Dangaard Brouer <brouer@...hat.com>
To:     Luigi Rizzo <rizzo@....unipi.it>
Cc:     "Jubran, Samih" <sameehj@...zon.com>,
        "Machulsky, Zorik" <zorik@...zon.com>,
        Daniel Borkmann <borkmann@...earbox.net>,
        David Miller <davem@...emloft.net>,
        "Tzalik, Guy" <gtzalik@...zon.com>,
        Ilias Apalodimas <ilias.apalodimas@...aro.org>,
        Toke Høiland-Jørgensen 
        <toke@...hat.com>, "Kiyanovski, Arthur" <akiyano@...zon.com>,
        Alexei Starovoitov <ast@...nel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        David Ahern <dsahern@...il.com>, brouer@...hat.com
Subject: Re: XDP multi-buffer design discussion

On Mon, 16 Dec 2019 20:15:12 -0800
Luigi Rizzo <rizzo@....unipi.it> wrote:

> On Mon, Dec 16, 2019 at 6:07 AM Jesper Dangaard Brouer
> <brouer@...hat.com> wrote:
> >
> >
> > See answers inlined below (please get an email client that support
> > inline replies... to interact with this community)
> >
> > On Sun, 15 Dec 2019 13:57:12 +0000
> > "Jubran, Samih" <sameehj@...zon.com> wrote:  
> ...
> > > * Why should we provide the fragments to the bpf program if the
> > > program doesn't access them? If validating the length is what
> > > matters, we can provide only the full length info to the user with no
> > > issues.  
> >
> > My Proposal#1 (in [base-doc]) is that XDP only get access to the
> > first-buffer.  People are welcome to challenge this choice.
> >
> > There are a several sub-questions and challenges hidden inside this
> > choice.
> >
> > As you hint, the total length... spawns some questions we should answer:
> >
> >  (1) is it relevant to the BPF program to know this, explain the use-case.
> >
> >  (2) if so, how does BPF prog access info (without slowdown baseline)  
> 
> For some use cases, the bpf program could deduct the total length
> looking at the L3 header. 

Yes, that actually good insight.  I guess the BPF-program could also
use this to detect that it doesn't have access to the full-lineary
packet this way(?)

> It won't work for XDP_TX response though.

The XDP_TX case also need to be discussed/handled. IMHO need to support
XDP_TX for multi-buffer frames.  XDP_TX *can* be driver specific, but
most drivers choose to convert xdp_buff to xdp_frame, which makes it
possible to use/share part of the XDP_REDIRECT code from ndo_xdp_xmit.

We also need to handle XDP_REDIRECT, which becomes challenging, as the
ndo_xdp_xmit functions of *all* drivers need to be updated (or
introduce a flag to handle this incrementally).


Sameeh, I know you have read the section[1] on "Storage space for
multi-buffer references/segments", and you updated the doc in git-tree.
So, you should understand that I want to keep this compatible with how
SKB stores segments, which will make XDP_PASS a lot easier/faster.
-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer

[1] https://github.com/xdp-project/xdp-project/blob/master/areas/core/xdp-multi-buffer01-design.org#storage-space-for-multi-buffer-referencessegments