OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [virtio-dev] Propose to report the offset addr back from vhost to virtio



> -----Original Message-----
> From: Stefan Hajnoczi [mailto:stefanha@redhat.com]
> Sent: Friday, November 10, 2017 5:31 PM
> To: Tan, Jianfeng
> Cc: virtio-dev@lists.oasis-open.org; Michael S. Tsirkin; Liang, Cunming;
> Gasparakis, Joseph; 'Jason Wang'
> Subject: Re: [virtio-dev] Propose to report the offset addr back from vhost to
> virtio
> 
> On Thu, Nov 09, 2017 at 01:33:11PM +0800, Tan, Jianfeng wrote:
> > This proposal will be from virtio-net perspective, not sure if it helps for
> > other device types.
> >
> > Current status:
> > VIRTIO-net "rx" path will rearm buffers for packets receiving, put the start
> > addr and len on the descriptor table (or the single ring for virtio 1.1
> > draft spec), vhost backend will put the packet exactly on the start addr,
> > and report the real packet len back. This way does not allow the vhost
> > backend to put the packet somewhere offset to the start addr.
> >
> > Use case:
> > When we look at vhost rx zero copy problem, we would like the NIC to put
> the
> > packets directly onto VM memory, but this raw packet (tunnel packet)
> always
> > contains a outer header which should be decap before VM starts receiving
> the
> > packet. And unfortunately, not all NICs support decap. After the whole
> > tunnel packet be put on the VM buffer (starting with the start addr), and
> > after the vswitch's decap, we can report an "offset" back to VIRTIO
> > frontend, and of course, the frontend shall honor this offset and adjust
> > accordingly.
> >
> > The proposal:
> > We can add a new feature like, VIRTIO_NET_F_OFFSET and add a new filed
> in
> > virtio_net_header; if this feature is negotiated, the vhost side can report
> > the "offset" in virtio_net_header, and the frontend side will recognize this
> > value and adjust the packet buffer accordingly.
> >
> > Any comments?
> 
> Does exposing the encapsulation header to guest memory pose a security
> problem?

We could memset it to zero before returning it back to virtio; but that cannot protect from a malicious VM which keep snooping on the memory. What's worse, the malicious can still write that buffer.

Hmm, indeed, it's an unsecure solution.

> 
> In a simple VLAN scenario it tells the guest about the VLAN ID used on
> the host.  If fancier encapsulation protocols are used there might be
> additional info that the guest shouldn't see?
> 
> Besides this concern it seems like a useful virtio-net feature.

Thank you for your insight here.

Thanks,
Jianfeng

> 
> Stefan


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]