netdev - Re: Redux: Backwards compatibility for XDP multi-buff

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: <CACAyw9_grv4_c4gDntK7jT3hfBM+O0qSJZ7xFpaknd58e1PeQQ@mail.gmail.com>
Date:   Tue, 28 Sep 2021 09:47:43 +0100
From:   Lorenz Bauer <lmb@...udflare.com>
To:     Toke Høiland-Jørgensen <toke@...hat.com>
Cc:     Lorenzo Bianconi <lbianconi@...hat.com>,
        Daniel Borkmann <daniel@...earbox.net>,
        John Fastabend <john.fastabend@...il.com>,
        Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>
Subject: Re: Redux: Backwards compatibility for XDP multi-buff

On Fri, 24 Sept 2021 at 20:38, Toke Høiland-Jørgensen <toke@...hat.com> wrote:
> >
> > Porting is only easy if we are guaranteed that the first PAGE_SIZE
> > bytes (or whatever the current limit is) are available via ->data
> > without trickery. Otherwise we have to convert all direct packet
> > access to the new API, whatever that ends up being. It seemed to me
> > like you were saying there is no such guarantee, and it could be
> > driver dependent, which is the worst possible outcome imo. This is the
> > status quo for TC classifiers, which is a great source of hard to
> > diagnose bugs.
>
> Well, for the changes we're proposing now it will certainly be the case
> that the first PAGE_SIZE will always be present. But once we have the
> capability, I would expect people would want to do more with it, so we
> can't really guarantee this in the future. We could require that any
> other use be opt-in at the driver level, I suppose, but not sure if that
> would be enough?

I'm not sure what you mean by "opt-in at driver level"? Make smaller
initial fragments a feature on the driver? We shouldn't let drivers
dictate the semantics of a program type, it defeats the purpose of the
context abstraction. We're using XDP precisely because we don't want
to deal with vendor specific network stack bypass, etc. I would prefer
not specifying the first fragment size over the driver knob,
unfortunately it invalidates your assumption that porting is going to
be trivial.

Lorenz

-- 
Lorenz Bauer  |  Systems Engineer
6th Floor, County Hall/The Riverside Building, SE1 7PB, UK

www.cloudflare.com