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: Fri, 16 Oct 2020 09:04:38 +0200 From: Christian Eggers <ceggers@...i.de> To: Florian Fainelli <f.fainelli@...il.com> CC: Richard Cochran <richardcochran@...il.com>, "David S . Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, Krzysztof Halasa <khalasa@...p.pl>, Vishal Kulkarni <vishal@...lsio.com>, <netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org> Subject: Re: [PATCH net-next] net: ptp: get rid of IPV4_HLEN() and OFF_IHL macros On Thursday, 15 October 2020, 18:56:41 CEST, Florian Fainelli wrote: > Having recently helped someone with a bug that involved using > IPV4_HLEN() instead of ip_hdr() in a driver's transmit path (so with the > transport header correctly set), it would probably help if we could make > IPV4_HLEN()'s semantics clearer with converting it to a static inline > function and put asserts in there about what the transport and MAC > header positions should be. IPV4_HLEN() is only used for PTP. Is there any way to use "normal" infrastructure as in the rest of the network stack? It looks like PTP code typically has to look into multiple network layers (mac, network, transport) at places these layers may not be processed yet (at least in RX direction). > At the very least, creating a new function, like this maybe in > include/linux/ip.h might help: > > static inline u8 __ip_hdr_len(const struct sk_buff *skb) > { > const struct iphdr *ip_hdr = (const struct iphdr *)(skb->data); > > return ip_hdr->ihl << 2; > } Is there any reason using skb->data instead of skb_network_header()? Debugging through my DSA driver showed that ... - for TX (called by dsa_slave_xmit), skb->data is set to the MAC header (skb->head+0x02), whilst skb->network_header is correctly set to 0x10 (skb->mac_header+14). - for TX, skb->transport_header is 0xffff, so udp_hdr() cannot be used - for RX (called by dsa_switch_rcv), skb->data is set to skb->head+0x50, which is identical to skb->network_header - for RX, skb->transport_header ist set equal to skb->network_header, so udp_hdr() can also not be used. Best regards Christian
Powered by blists - more mailing lists