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 for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 24 Apr 2013 11:17:50 -0700
From:	Alexander Duyck <alexander.h.duyck@...el.com>
To:	netdev <netdev@...r.kernel.org>,
	David Miller <davem@...emloft.net>,
	Eric Dumazet <eric.dumazet@...il.com>,
	Ben Hutchings <bhutchings@...arflare.com>,
	Stephen Hemminger <shemminger@...tta.com>
Subject: Question on the use of ETH_P_CONTROL

I have a wired Ethernet driver that will need to support a user space
application with UIO access and a network device.  The network device
will need a way to send raw frames with some descriptor data to and from
the user space application.  The frames are not meant to be routed and
are not meant for this host, only for the user space application.  After
doing some digging I came across the definition for ETH_P_CONTROL, which
seems to be a good solution for my current issue.

My thought is to do something like this for Rx control frames:
	eth_type_trans(skb);
	skb->protocol = htons(ETH_P_CONTROL);
	skb->mac_header -= sizeof(struct desc_hdr);
	desc_hdr = (struct desc_hdr *)skb_mac_header(skb);
	desc_hdr->val = val;

For frames received from the user space application I would essentially
just leave the descriptor header on and notify the hardware that it is
present for any frames received that have ETH_P_CONTROL as their protocol.

Then all that is left is for the user space to allocate a raw packet
socket and bind it to our interface specifying the control protocol so
that it can send and receive just the control frames.

I'm looking for any thoughts, issues, or concerns with this approach.

Thanks,

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ