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]

Message-Id: <200811281455.32744.opurdila@ixiacom.com>
Date:	Fri, 28 Nov 2008 14:55:32 +0200
From:	Octavian Purdila <opurdila@...acom.com>
To:	Oliver Hartkopp <oliver@...tkopp.net>
Cc:	Patrick Ohly <patrick.ohly@...el.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: hardware time stamping with extra skb->hwtstamp

From: Oliver Hartkopp <oliver@...tkopp.net>
Date: Thu, 27 Nov 2008 23:13:08 +0100

> > 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.
>
> Ugh.
>
> Not every protocol that uses skbuffs, has a mac header (e.g. the CAN
> protocol doesn't have mac addresses). 

OK, then what about this: we use a device ioctl to get the number of bytes to 
copy from skb->head. We then pass this to the socket level option.

This is more complicated than option 3 or 4, but it should address the 
concerns raised here - no performance impact when not using this feature. The 
trade-off is moving work from core kernel into userspace and device driver. 

> This twist does not look very maintainable to me ...

Could you elaborate on the maintainability issues, they are not clear to me.


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