netdev - Re: AF_NETDEV - device specific sockets

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]

Date:	Sat, 31 Jan 2015 20:41:05 -0800
From:	John Fastabend <john.fastabend@...il.com>
To:	"Zayats, Michael" <michael.zayats@...com>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: AF_NETDEV - device specific sockets

On 01/31/2015 08:20 PM, Zayats, Michael wrote:
> 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?

It might help to come up with specific examples but an alternate
proposal would be to use skb->priority field and then mqprio to
steer the traffic to a specific queue and then bind attributes to
the queue.

For example the NIC offloaded QOS can be mapped on to queues and
then sockets mapped to the queues.

Another example would be to forward all traffic from one queue
to a virtual fuction in SR-IOV use case. We don't have an interface
to do this but I have been working on an API that could be used
for this.

In this case you don't need to modify AF_PACKET interface but
configure the device correctly. If you need per-packet control
you could use 'tc' or 'nftables' to do the steering.

.John

-- 
John Fastabend         Intel Corporation
--
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