netdev - route and device for received packets

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

Message-Id: <1227013577.31699.198.camel@ecld0pohly>
Date:	Tue, 18 Nov 2008 14:06:17 +0100
From:	Patrick Ohly <patrick.ohly@...el.com>
To:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Cc:	Andi Kleen <ak@...ux.intel.com>
Subject: route and device for received packets

Hello!

As mentioned in the "hardware time stamping + igb example
implementation" I'm currently rewriting the patch so that it adds the
raw hardware time stamp to sk_buff. Conversion from hardware time stamp
to system time base is done at the socket level, if the owner of the
socket asked for it.

This conversion requires access to the net_device which generated the
hardware time stamp. Currently I am following this chain of pointers to
find the device and the new callback:

int skb_hwtstamp_transformed(const struct sk_buff *skb, struct timespec *ts)
{
	struct rtable *rt;
	struct in_device *idev;
	struct net_device *netdev;

        if (skb_hwtstamp_available(skb) &&
		(rt = skb->rtable) != NULL &&
		(idev = rt->idev) != NULL &&
		(netdev = idev->dev) != NULL  &&
		netdev->hwtstamp_raw2sys) {
		ktime_t hwtstamp_sys =
			netdev->hwtstamp_raw2sys(netdev,
						skb->hwtstamp.hwtstamp);

The problem is that incoming packets have a route pointer which leads to
the lo device instead of the real hardware which received the packet.
The rt->rt_iif however is correct.

For outgoing packets that were bounced via skb_clone() and
sock_queue_err_skb(sk, skb) the code above works.

Any suggestions how the right net_device could be found (perhaps via
rt->rt_iif)? How about locking?

-- 
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