netdev - Re: [RFC PATCH net-next 2/2] net: Reset forwarded skb->tstamp before delivering to user space

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: <1ef23d3b-fe49-213b-6b60-127393b24e84@iogearbox.net>
Date:   Wed, 8 Dec 2021 20:27:45 +0100
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Martin KaFai Lau <kafai@...com>
Cc:     Willem de Bruijn <willemdebruijn.kernel@...il.com>,
        netdev@...r.kernel.org, Alexei Starovoitov <ast@...nel.org>,
        David Miller <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>, kernel-team@...com
Subject: Re: [RFC PATCH net-next 2/2] net: Reset forwarded skb->tstamp before
 delivering to user space

On 12/8/21 9:30 AM, Martin KaFai Lau wrote:
> On Wed, Dec 08, 2021 at 12:18:46AM -0800, Martin KaFai Lau wrote:
>> On Tue, Dec 07, 2021 at 10:48:53PM +0100, Daniel Borkmann wrote:
[...]
>>> One other thing I wonder, BPF progs at host-facing veth's tc ingress which
>>> are not aware of skb->tstamp will then see a tstamp from future given we
>>> intentionally bypass the net_timestamp_check() and might get confused (or
>>> would confuse higher-layer application logic)? Not quite sure yet if they
>>> would be the only affected user.
>> Considering the variety of clock used in skb->tstamp (real/mono, and also
>> tai in SO_TXTIME),  in general I am not sure if the tc-bpf can assume anything
>> in the skb->tstamp now.

But today that's either only 0 or real via __net_timestamp() if skb->tstamp is
read at bpf@...ress@...h@...t, no?

>> Also, there is only mono clock bpf_ktime_get helper, the most reasonable usage
>> now for tc-bpf is to set the EDT which is in mono.  This seems to be the
>> intention when the __sk_buff->tstamp was added.

Yep, fwiw, that's also how we only use it in our code base today.

>> For ingress, it is real clock now.  Other than simply printing it out,
>> it is hard to think of a good way to use the value.  Also, although
>> it is unlikely, net_timestamp_check() does not always stamp the skb.
> For non bpf ingress, hmmm.... yeah, not sure if it is indeed an issue :/
> may be save the tx tstamp first and then temporarily restamp with __net_timestamp()