netdev - Re: [RFC bpf-next 1/4] net: xdp: introduce flags field in xdp_buff and xdp

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: <20210528215654.31619c97@kicinski-fedora-PC1C0HJN.hsd1.ca.comcast.net>
Date:   Fri, 28 May 2021 21:56:54 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Tom Herbert <tom@...bertland.com>
Cc:     Lorenzo Bianconi <lorenzo@...nel.org>, bpf@...r.kernel.org,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Daniel Borkmann <daniel@...earbox.net>,
        Alexei Starovoitov <ast@...nel.org>,
        Eelco Chaudron <echaudro@...hat.com>,
        David Ahern <dsahern@...il.com>, magnus.karlsson@...el.com,
        Toke Høiland-Jørgensen 
        <toke@...hat.com>, Jesper Dangaard Brouer <brouer@...hat.com>,
        bjorn@...nel.org,
        "Maciej Fijałkowski (Intel)" 
        <maciej.fijalkowski@...el.com>,
        john fastabend <john.fastabend@...il.com>
Subject: Re: [RFC bpf-next 1/4] net: xdp: introduce flags field in xdp_buff
 and xdp_frame

On Fri, 28 May 2021 14:18:33 -0700 Tom Herbert wrote:
> On Fri, May 28, 2021 at 10:44 AM Lorenzo Bianconi <lorenzo@...nel.org> wrote:
> > Introduce flag field in xdp_buff and xdp_frame data structure in order
> > to report xdp_buffer metadata. For the moment just hw checksum hints
> > are defined but flags field will be reused for xdp multi-buffer
> > For the moment just CHECKSUM_UNNECESSARY is supported.
> > CHECKSUM_COMPLETE will need to set csum value in metada space.
> >  
> Lorenzo,
> 
> This isn't sufficient for the checksum-unnecessary interface, we'd
> also need ability to set csum_level for cases the device validated
> more than one checksum.
> 
> IMO, we shouldn't support CHECKSUM_UNNECESSARY for new uses like this.
> For years now, the Linux community has been pleading with vendors to
> provide CHECKSUM_COMPLETE which is far more useful and robust than
> CHECSUM_UNNECESSARY, and yet some still haven't got with the program
> even though we see more and more instances where CHECKSUM_UNNECESSARY
> doesn't even work at all (e.g. cases with SRv6, new encaps device
> doesn't understand). I believe it's time to take a stand! :-)

I must agree. Not supporting CHECKSUM_COMPLETE seems like a step back.