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

Message-ID: <87tui9ydb6.fsf@toke.dk>
Date:   Fri, 24 Sep 2021 21:38:05 +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 Thu, 23 Sept 2021 at 13:59, Toke Høiland-Jørgensen <toke@...hat.com> wrote:
>>
>> I don't think it has to be quite that bleak :)
>>
>> Specifically, there is no reason to block mb-aware programs from loading
>> even when the multi-buffer mode is disabled. So a migration plan would
>> look something like:
>
> ...
>
>> 2. Start porting all your XDP programs to make them mb-aware, and switch
>>    their program type as you do. In many cases this is just a matter of
>>    checking that the programs don't care about packet length. [...]
>
> 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?

-Toke