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 10:05:43 -0500 (EST)
From:   David Miller <davem@...emloft.net>
To:     arnd@...db.de
Cc:     mlichvar@...hat.com, willemb@...gle.com, bjorn.topel@...il.com,
        gregkh@...uxfoundation.org, francisyyan@...il.com,
        edumazet@...gle.com, keescook@...omium.org, rami.rosen@...el.com,
        andreyknvl@...gle.com, maloney@...gle.com,
        sowmini.varadhan@...cle.com, linux-kernel@...r.kernel.org,
        netdev@...r.kernel.org
Subject: Re: [PATCH] [RFC v2] packet: experimental support for 64-bit
 timestamps

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.