netdev - Re: hardware time stamping with extra skb->hwtstamp

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:	Thu, 27 Nov 2008 20:53:09 +0200
From:	Octavian Purdila <opurdila@...acom.com>
To:	Patrick Ohly <patrick.ohly@...el.com>
Cc:	Oliver Hartkopp <oliver@...tkopp.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: hardware time stamping with extra skb->hwtstamp

From: Patrick Ohly <patrick.ohly@...el.com>
Date: Thu, 27 Nov 2008 16:31:07 +0100

> On Thu, 2008-11-27 at 14:02 +0000, Octavian Purdila wrote:
> > From: Patrick Ohly <patrick.ohly@...el.com>
> > Date: Thu, 27 Nov 2008 11:07:07 +0100
> >
> > > To summarize, I see the following options at this time:
> >
> > [snip]
> >
> > > My personal preference is, in this order: 3, 4, 2b (current patch,
> > > but needs clean way to find network device), 1a.
> >
> > I also vote for 3 (storing hw timestamps in the skb).
> >
> > Let me throw in another idea: when enabling hw timestamps could we
> > allocate a bigger skb and store the hw timestamp somewhere in the skb
> > data buffer?
>
> How does the socket layer detect that the HW timestamp is available in
> the larger skb data buffer, and where?
>

It doesn't know, thats why we need help from the device (the new netdev 
method).

> > We can then modify sock_recv_timestamp to call a new netdev method which
> > should return the hw timestamp. This should take care of RX hw
> > timestamps.
>
> Finding the netdev is non-trivial, see David's comment about the current
> hacky approach via the route. 
>

OK I see now, it seems that we can't get to the device in a generic way. 

How about this twist: we add a new option at the socket level, to get the 
whole skb->head - skb->end data into a user buffer. Then, we call an device 
ioctl and pass this buffer. The device will extract the hw timestamp and give 
it to the user. 

We might not need to get the whole skb->head - skb->end buffer, maybe just skb-
>head - skb->mac if we know that skb->mac is sane at the socket level and we 
use the convention that the device driver must put the timestamp below the mac 
header.

One potential problem I see with this approach is leaking sensitive 
information into userspace, which means we will have to restrict this to 
privileged processes only.

tavi

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