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]
Message-ID: <20100402085556.75a8ff7c@nehalam>
Date:	Fri, 2 Apr 2010 08:55:56 -0700
From:	Stephen Hemminger <shemminger@...tta.com>
To:	xiaohui.xin@...el.com
Cc:	netdev@...r.kernel.org, kvm@...r.kernel.org,
	linux-kernel@...r.kernel.org, mingo@...e.hu, mst@...hat.com,
	jdike@...user-mode-linux.org, davem@...emloft.net
Subject: Re: [RFC] [PATCH v2 3/3] Let host NIC driver to DMA to guest user
 space.

On Fri,  2 Apr 2010 15:30:10 +0800
xiaohui.xin@...el.com wrote:

> From: Xin Xiaohui <xiaohui.xin@...el.com>
> 
> The patch let host NIC driver to receive user space skb,
> then the driver has chance to directly DMA to guest user
> space buffers thru single ethX interface.
> We want it to be more generic as a zero copy framework.
> 
> Signed-off-by: Xin Xiaohui <xiaohui.xin@...el.com>
> Signed-off-by: Zhao Yu <yzhao81@...il.com>
> Sigend-off-by: Jeff Dike <jdike@...user-mode-linux.org>
> ---
> 
> We consider 2 way to utilize the user buffres, but not sure which one
> is better. Please give any comments.
> 
> One:    Modify __alloc_skb() function a bit, it can only allocate a
>         structure of sk_buff, and the data pointer is pointing to a
>         user buffer which is coming from a page constructor API.
>         Then the shinfo of the skb is also from guest.
>         When packet is received from hardware, the skb->data is filled
>         directly by h/w. What we have done is in this way.
> 
>         Pros:   We can avoid any copy here.
>         Cons:   Guest virtio-net driver needs to allocate skb as almost
>                 the same method with the host NIC drivers, say the size
>                 of netdev_alloc_skb() and the same reserved space in the
>                 head of skb. Many NIC drivers are the same with guest and
>                 ok for this. But some lastest NIC drivers reserves special
>                 room in skb head. To deal with it, we suggest to provide
>                 a method in guest virtio-net driver to ask for parameter
>                 we interest from the NIC driver when we know which device
>                 we have bind to do zero-copy. Then we ask guest to do so.
>                 Is that reasonable?
> 
> Two:    Modify driver to get user buffer allocated from a page constructor
>         API(to substitute alloc_page()), the user buffer are used as payload
>         buffers and filled by h/w directly when packet is received. Driver
>         should associate the pages with skb (skb_shinfo(skb)->frags). For
>         the head buffer side, let host allocates skb, and h/w fills it.
>         After that, the data filled in host skb header will be copied into
>         guest header buffer which is submitted together with the payload buffer.
> 
>         Pros:   We could less care the way how guest or host allocates their
>                 buffers.
>         Cons:   We still need a bit copy here for the skb header.
> 
> We are not sure which way is the better here. This is the first thing we want
> to get comments from the community. We wish the modification to the network
> part will be generic which not used by vhost-net backend only, but a user
> application may use it as well when the zero-copy device may provides async
> read/write operations later.
> 
> 
> Thanks
> Xiaohui

How do you deal with the DoS problem of hostile user space app posting huge
number of receives and never getting anything. 
--
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