netdev - TX time stamping

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-next>] [day] [month] [year] [list]

Date:	Tue, 03 Mar 2009 10:31:21 -0800
From:	Patrick Ohly <patrick.ohly@...el.com>
To:	David Miller <davem@...emloft.net>,
	Herbert Xu <herbert@...dor.apana.org.au>
Cc:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"Kirsher, Jeffrey T" <jeffrey.t.kirsher@...el.com>
Subject: TX time stamping

Hello!

Based on previous discussions, there are some areas of time stamping
which could be improved or needing a fix.

The first being, using skb->sk to send back TX information. The goal is
to notify the sender, and just the sender of the packet about the time
when the packet got transmitted.

I cannot think of how this can be done without skb->sk, but I am open to
suggestions. Without it, one would have to fall back to some kind of
broadcasting scheme were all TX stamped packets are received by all processes
potentially interested in them. This has security issues (packet data
needs to be included to identify packets -> data sent by one user would
be visible to other users; TX stamping feature would have to be
restricted to root, which is not the case now), and potentially impacts
performance (every process has to analyze every packet) and might not be
reliable (depending on the packet payload, processes might not be able
to identify their own packets when they get mixed with those of other
processes).

When an early call to skb_orphan() gets implemented, would it be
acceptable to only do that if no TX time stamping is requested for the
packet? This can be tested relatively fast (check one field in shinfo)?

Second, loopback. I cannot see any issues with loopback, but please let
me know if I have missed something. If I remember (and understand)
correctly, loopback is implemented as writing to a special network
device. Once the TX software fallback is implemented again (see third
point below), then this case can be tested with the timestamping test
program by selecting "lo" as device and asking for TX software time
stamps.

Third, TX software time stamping. I believe a clean solution could work
like this:
      * if TX time stamping is requested, then clone the skb and get a
        reference to the socket
      * ask driver to send packet
      * check status of cloned skb: if TX software fallback is
        necessary, do it using the socket reference
      * drop the references to the cloned skb and the socket

In this scenario the extra work is only done for those packets which
need it. It will work for drivers which call skb_orphan().

As an extra refinement one can later add a driver flag which tells the
kernel that the driver will do the software TX fallback itself. In that
case no extra work needs to be done before calling the driver.

Of course, this all depends on still having the socket before calling
the driver - see above  :-/

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html