netdev - Re: [RFC PATCH 02/13] extended semantic of sk_buff::tstamp: lowest bit marks hardware time stamps

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

Message-Id: <1227099006.16263.46.camel@ecld0pohly>
Date:	Wed, 19 Nov 2008 13:50:06 +0100
From:	Patrick Ohly <patrick.ohly@...el.com>
To:	David Miller <davem@...emloft.net>
Cc:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [RFC PATCH 02/13] extended semantic of sk_buff::tstamp: lowest
	bit marks hardware time stamps

On Wed, 2008-11-12 at 09:58 +0000, David Miller wrote:
> From: Patrick Ohly <patrick.ohly@...el.com>
> Date: Wed, 22 Oct 2008 10:17:24 +0200
> 
> > +int skb_hwtstamp_raw(const struct sk_buff *skb, struct timespec *stamp)
> > +{
> > +	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_raw) {
> > +		return netdev->hwtstamp_raw(skb, stamp);
> > +	} else {
> > +		return 0;
> > +	}
> > +}
> > +
> > +EXPORT_SYMBOL_GPL(skb_hwtstamp_raw);
> 
> You can't be accessing the generic destination cache entry attached to
> the SKB, here in generic SKB code, as a pointer to an ipv4 specific
> route object.  What if this is an IPV6 or DECNET packet?

Yes, this is problematic. The revised patch still depends on this
pointer chain, now to convert the raw hardware time stamp to system
time. I don't see any clean solution right now except adding both raw
and transformed value to the skb (16 additional bytes instead of just 8,
or zero as in the original patch).

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