netdev - Re: [PATCH 00/11] XDP unaligned chunk placement support

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20190628130802.24a6f22b@cakuba.netronome.com>
Date:   Fri, 28 Jun 2019 13:08:02 -0700
From:   Jakub Kicinski <jakub.kicinski@...ronome.com>
To:     Björn Töpel <bjorn.topel@...el.com>
Cc:     "Laatz, Kevin" <kevin.laatz@...el.com>,
        Jonathan Lemon <jonathan.lemon@...il.com>,
        netdev@...r.kernel.org, ast@...nel.org, daniel@...earbox.net,
        magnus.karlsson@...el.com, bpf@...r.kernel.org,
        intel-wired-lan@...ts.osuosl.org, bruce.richardson@...el.com,
        ciara.loftus@...el.com
Subject: Re: [PATCH 00/11] XDP unaligned chunk placement support

On Fri, 28 Jun 2019 18:51:37 +0200, Björn Töpel wrote:
> In your example Jakub, how would this look in XDP? Wouldn't the
> timestamp be part of the metadata (xdp_md.data_meta)? Isn't
> data-data_meta (if valid) <= XDP_PACKET_HEADROOM? That was my assumption.

The driver parses the metadata and copies it outside of the prepend
before XDP runs.  Then XDP runs unaware of the prepend contents.  
That's the current situation.

XDP_PACKET_HEADROOM is before the entire frame.  Like this:

    buffer start
  /               DMA addr given to the device
 /              /
v              v
| XDP_HEADROOM | meta data | packet data |

Length of meta data comes in the standard fixed size descriptor.

The metadata prepend is in TV form ("TLV with no length field", length's
implied by type).

> There were some discussion on having meta data length in the struct
> xdp_desc, before AF_XDP was merged, but the conclusion was that this was
> *not* needed, because AF_XDP and the XDP program had an implicit
> contract. If you're running AF_XDP, you also have an XDP program running
> and you can determine the meta data length (and also getting back the
> original buffer).
> 
> So, today in AF_XDP if XDP metadata is added, the userland application
> can look it up before the xdp_desc.addr (just like regular XDP), and how
> the XDP/AF_XDP application determines length/layout of the metadata i
> out-of-band/not specified.
> 
> This is a bit messy/handwavy TBH, so maybe adding the length to the
> descriptor *is* a good idea (extending the options part of the
> xdp_desc)? Less clean though. OTOH the layout of the meta data still
> need to be determined.

Right, the device prepend is not exposed as metadata to XDP.