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-next>] [day] [month] [year] [list]
Message-ID: <FC8E8D0ECC753F45808079B18C3203FE1CCA0C@G4W3293.americas.hpqcorp.net>
Date:	Sun, 1 Feb 2015 04:20:10 +0000
From:	"Zayats, Michael" <michael.zayats@...com>
To:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: AF_NETDEV - device specific sockets

Hi,

I am looking for a generic mechanism that would allow network device drivers to provide socket interface to user and kernel space clients.

Such an interface might be used to provide access to important sub-streams of packets, alongside with device specific packet metadata, provided through msg_control fields of recv/sendmsg.

RX Metadata might include device specific information, such as queuing priorities applied, potential destination interface in case of switching hardware etc.

On the transmission, metadata might be used to indicate hardware specific required optimizations, as well as any other transformation or accounting required on the packet.

AF_PACKET based mechanism doesn't allow metadata to be exchanged between the client and the device driver.
Extending it would require extending of sk_buff and potentially additional per packet operations.
Generic Netlink is not intended to pass packets.

As I am trying to validate generic applicability of such a mechanism, I see that TUN driver is providing custom socket interface, in order to deal with user information through msg_control.
Only usable inside the kernel, through custom interface.

Proposed interface
------------------
Kernel side: 
(struct proto *) should be added to struct net_device.
Device driver that is interested to support socket interface would populate the pointer.

User space: 
After creating AF_NETDEV socket, the only successful operation would be setting SO_BINDTODEVICE option.
Once set, all socket operations would be implemented by calling functions, that are registered at struct proto on the appropriate net_device.

What do you think?
Would you see a better approach?
Some other mechanism that already exists for such a purpose?

Thanks,

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