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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 23 Nov 2014 19:38:02 +0100 From: Richard Cochran <richardcochran@...il.com> To: Ben Hutchings <ben@...adent.org.uk> Cc: netdev@...r.kernel.org, David Miller <davem@...emloft.net>, Stefan Sørensen <stefan.sorensen@...ctralink.com> Subject: Re: [PATCH net-next] vlan: Pass ethtool get_ts_info queries to real device. On Sun, Nov 23, 2014 at 05:19:59PM +0000, Ben Hutchings wrote: > > Unsafe? How? > > I mean that the assumption is wrong in general. So these changes will > result in silent failure to enable RX timestamps, on some devices. Silent failure is dissapointing, yes, but not unsafe. Nothing breaks. > > The whole filter list with every last combination (at least, the ones > > at the time) came directly from a early, limited HW design. Sane, > > modern PTP hardware provides time stamps regardless of whether a frame > > is VLAN tagged or not. > > I would hope so. However, this is non-standard - IEEE802.1AS > *explicitly forbids* the use of VLAN tags. Yes, but still people are using them. People fail to understand that VLAN tags are not meant for end stations. The power industry has created IEEE 61850 which actually requires end stations to send and receive VLAN tagged frames with VID!=0, in violation of 802.1. Then they published a PTP profile running on VLAN tagged Layer2. (For this reason alone, most hardware does handle tagged frames, and that is also why the linuxptp stack accepts vlan tags when using Layer2 transport.) Setting up vlan interfaces on an end station is already somewhat fishy. People who do that can surely take care that their cards do correctly handle vlan tagged frames. Concerning this patch, I needed get_ts_info to work on a VLAN interface in order to implement a grand master clock on a managed switch. I think that is valid use case, and implementing a Linux based Transparent Clock will also need this. > Linux's software PTP > classifier also doesn't yet handle 802.1ad VLAN tags. As soon as someone wants this, I don't see why it cannot be added. > > I don't see any reason not to make our stack even more ugly just to cater > > to broken hardware. > > So failure to implement a non-standard extension is now 'broken'? If your PTP traffic flows through a managed, transparent switch with VLANs enabled, then the device will have to provide time stamps. This is really a standard use case. Also the power profile mandates vlan. > This is progress for some devices, false advertising for others. And where do we draw the line with describing the limitations of poorly made hardware classifiers? What if a card can time stamp IPv4 packets, but not in the presence of IPv4 options? Again, I don't mind if someone wants to add a bunch more combinations to the rx_filters. But they are useless in the end. In practice, user space software will ignore them anyhow, unless the software somehow caters to hardware limitations. Really, look at the list in rx_filters, and think about this. What is the stack supposed to do if SIOCGHWTSTAMP returns HWTSTAMP_FILTER_PTP_V2_DELAY_REQ? It is madness, really. Thanks, Richard -- 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
Powered by blists - more mailing lists