netdev - Re: [RFC v3 net-next 14/18] net/sched: Add HW offloading capability to TBS

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:   Wed, 21 Mar 2018 17:18:07 +0100 (CET)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Richard Cochran <richardcochran@...il.com>
cc:     Jesus Sanchez-Palencia <jesus.sanchez-palencia@...el.com>,
        netdev@...r.kernel.org, jhs@...atatu.com, xiyou.wangcong@...il.com,
        jiri@...nulli.us, vinicius.gomes@...el.com,
        anna-maria@...utronix.de, henrik@...tad.us,
        John Stultz <john.stultz@...aro.org>, levi.pearson@...man.com,
        edumazet@...gle.com, willemb@...gle.com, mlichvar@...hat.com
Subject: Re: [RFC v3 net-next 14/18] net/sched: Add HW offloading capability
 to TBS

On Wed, 21 Mar 2018, Richard Cochran wrote:

> On Wed, Mar 21, 2018 at 03:22:11PM +0100, Thomas Gleixner wrote:
> > Which clockid will be handed in from the application? The network adapter
> > time has no fixed clockid. The only way you can get to it is via a fd based
> > posix clock and that does not work at all because the qdisc setup might
> > have a different FD than the application which queues packets.
> 
> Duh.  That explains it.  Please ignore my "why not?" Q in the other thread...

:)

So in that case you are either bound to rely on the application to use the
proper dynamic clock or if we need a sanity check, then you need a cookie
of some form which can be retrieved from the posix clock file descriptor
and handed in as 'clockid' together with clock_adapter = true.

That's doable, but that needs a bit more trickery. A simple unique ID per
dynamic posix-clock would be trivial to add, but that would not give you
any form of verification whether this ID actually belongs to the network
adapter or not.

So either you ignore the clockid and rely on the application not being
stupid when it says "clock_adpater = true" or you need some extra
complexity to build an association of a "clockid" to a network adapter.

There is a connection already, via

     adapter->ptp_clock->devid

which is MKDEV(major, index) which is accessible at least at the network
driver level, but probably not from networking core. So you'd need to drill
a few more holes by adding yet another callback to net_device_ops.

I'm not sure if its worth the trouble. If the application hands in bogus
timestamps, packets go out at the wrong time or are dropped. That's true
whether it uses the proper clock or not. So nothing the kernel should
really worry about.

For clock_system - REAL/MONO/TAI(sigh) - you surely need a sanity check,
but that is independent of the underlying network adapater even in the
qdisc assisted HW offload case.

Thanks,

	tglx