netdev - Re: [net-next v2 2/2] tcp: Add receive timestamp support for receive zerocopy.

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: <CAOFY-A0fN20RdeLS+SXZ2-WC_3rtLEhgXkC8jJtX_431OrNy9Q@mail.gmail.com>
Date:   Thu, 4 Feb 2021 17:32:28 -0800
From:   Arjun Roy <arjunroy@...gle.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Leon Romanovsky <leon@...nel.org>, David Ahern <dsahern@...il.com>,
        Arjun Roy <arjunroy.kdev@...il.com>,
        David Miller <davem@...emloft.net>,
        netdev <netdev@...r.kernel.org>,
        Eric Dumazet <edumazet@...gle.com>,
        Soheil Hassas Yeganeh <soheil@...gle.com>
Subject: Re: [net-next v2 2/2] tcp: Add receive timestamp support for receive zerocopy.

On Thu, Feb 4, 2021 at 4:00 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Thu, 4 Feb 2021 15:03:40 -0800 Arjun Roy wrote:
> > But, if it's an IN or IN-OUT field, it seems like mandating that the
> > application set it to 0 could break the case where a future
> > application sets it to some non-zero value and runs on an older
> > kernel.
>
> That usually works fine in practice, 0 means "do what old kernels did /
> feature not requested", then if newer userspace sets the field to non-0
> that means it requires a feature the kernel doesn't support. So -EINVAL
> / -EOPNOTSUPP is right. BPF syscall has been successfully doing this
> since day 1, I'm not aware of any major snags.
>

Alright, sounds good.

> > And allowing it to be non-zero can maybe yield an unexpected
> > outcome if an old application that did not zero it runs on a newer
> > kernel.
>
> Could you refresh our memory as to why we can't require the application
> to pass zero-ed memory to TCP ZC? In practice is there are max
> reasonable length of the argument that such legacy application may pass
> so that we can start checking at a certain offset?
>

Actually I think that's fine. We have hitherto been just using length
checks to distinguish between feature capability for rx. zerocopy but
I think we can draw the line at this point (now that there's
ambiguity) and start requiring zero'd memory.

I will send out a patch soon; reserved u32 field, must be set to 0 for
the current kernel, can be non-zero and in/out in future kernels as
discussed.

Thanks,
-Arjun


> > So: maybe the right move is to mark it as reserved, not care what the
> > input value is, always set it to 0 before returning to the user, and
> > explicitly mandate that any future use of the field must be as an
> > OUT-only parameter?
>