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:31:57 +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 9:08 PM, David Miller <davem@...emloft.net> wrote:
> From: Arnd Bergmann <arnd@...db.de>
> Date: Tue, 28 Nov 2017 21:02:05 +0100
>
>> 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.
>
> If it can be done reasonably easy, which you patches seem to indicate
> is the case, I have no objections to extending packet socket for
> 64-bit timestamps.
>
> I hope that AF_CAPTURE will be designed in such a way that all apps
> can migrate to it, and I will be making sure it is implemented
> appropriately with that in mind.
>
> But I don't think AF_CAPTURE should block your work here.

To clarify where I'm coming from, my interest is mainly in the first
patch to remove all users of 'struct timespec' in order to weed out
the users that are actually broken in 2038. I added the comment
about it breaking in 2106 and how it could be fixed, and then
decided to try out how ugly that fix would get.

I'll follow up with v3 that should address the comments I got so far,
but a conclusion of 'nobody is asking for it' would be fine too, and
then the patch could get dropped.

I'll also look at the AF_CAPTURE patches to make sure that
the timestamping aspect is handled in a safe way there.

       Arnd