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

Date:   Thu, 4 Feb 2021 16:00:06 -0800
From:   Jakub Kicinski <kuba@...nel.org>
To:     Arjun Roy <arjunroy@...gle.com>
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, 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.

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

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