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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <877df0ke7p.fsf@toke.dk>
Date:   Tue, 28 Sep 2021 15:43:38 +0200
From:   Toke Høiland-Jørgensen <toke@...hat.com>
To:     Lorenz Bauer <lmb@...udflare.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

Lorenz Bauer <lmb@...udflare.com> writes:

> 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,

I didn't mean that every driver should get to just define their own
semantics; rather the opposite: If we do end up adding support for
anything other than "first page of data is in the first fragment", we
should define separate semantics for this and make it an explicit knob
to turn on such a mode.

> unfortunately it invalidates your assumption that porting is going to
> be trivial.

Well, I did say "for some programs" ;)

But OK, point taken. It would be great if you could chime in on the
helper discussion[0]. I.e., which helper API would make porting simplest
for you?

-Toke

[0] https://lore.kernel.org/r/20210920110216.4c54c9a3@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com