linux-kernel - Re: [PATCH] [RFC v2] packet: experimental support for 64-bit timestamps

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:   Tue, 28 Nov 2017 21:02:05 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     David Miller <davem@...emloft.net>
Cc:     Miroslav Lichvar <mlichvar@...hat.com>,
        Willem de Bruijn <willemb@...gle.com>,
        Björn Töpel <bjorn.topel@...il.com>,
        gregkh <gregkh@...uxfoundation.org>,
        Francis Yan <francisyyan@...il.com>,
        Eric Dumazet <edumazet@...gle.com>,
        Kees Cook <keescook@...omium.org>,
        "Rosen, Rami" <rami.rosen@...el.com>,
        Andrey Konovalov <andreyknvl@...gle.com>,
        Mike Maloney <maloney@...gle.com>,
        Sowmini Varadhan <sowmini.varadhan@...cle.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Networking <netdev@...r.kernel.org>
Subject: Re: [PATCH] [RFC v2] packet: experimental support for 64-bit timestamps

On Tue, Nov 28, 2017 at 4:05 PM, David Miller <davem@...emloft.net> wrote:
> From: Arnd Bergmann <arnd@...db.de>
> Date: Tue, 28 Nov 2017 14:14:05 +0100
>
>> The implementation is fairly straightforward, but I'm less sure about the
>> interface. Using SOF_TIMESTAMPING_* flags in PACKET_TIMESTAMP is a bit
>> odd already since most of the other flags make no sense here.  Adding two
>> more flags that only make sense for packet sockets but not the normal
>> SO_TIMESTAMPING option on other sockets makes this even more confusing.
>
> We unfortunately never enforced any checking whatsoever of the
> PACKET_TIMESTAMP mask the user gives us, we accept anything.
>
> That makes any changes in this area effectively a grenade ready to go
> off potentially at any moment.
>
> We can't add new checks without potentially making existing apps stop
> working.  And at least theoretically if we add new bits it is possible
> for an existing app passing those bits in by accident to start
> behaving improperly.
>
> I know it sounds like overkill for this, but maybe we can add a new
> socket option for the SKIP and 64-bit stuff.  That would be %100 safe.

Sure, it's easy enough to do, I'll cook something up.

Does this mean you think the general idea of an extended interface
for 64-bit timestamps is useful for traditional packet sockets? I think
that was still an open question, though we seem to be getting closer
to consensus on the implementation and the interface that it should
use if we want it.

       Arnd