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

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

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


Subject: Re: [PATCH] used ring: define the meaning and requirements of the len field.


"Michael S. Tsirkin" <mst@redhat.com> writes:
> On Fri, Mar 20, 2015 at 11:48:55AM +1030, Rusty Russell wrote:
>> We said what it was for, and noted why.  We didn't place any requirements
>> on it, nor clearly spell out the implications of its use.
>> 
>> This clarification comes particularly from noticing that QEMU didn't
>> set len correctly, and philosophising over the correct value when
>> an error has occurred.
>
> I'm having second thoughts about this philosophising here :)

That's what philosophising is all about, I think!

> Imagine this driver with untrusted buffers used by multiple
> applications. Assume application 1 uses the device.
> We get len value from device but with your change applied, we don't
> really know whether any bytes > len have been modified.
> Passing them to application 2 will thus leak some info from application
> 1 - thus driver must zero out the rest of buffer before reuse.

I don't see it.  Program1 and Program2 read from /dev/fubar.
Internally, /dev/fubar reuses a 4k buffer.

virtio says 1k was written to the buffer, so 1k is copied to Program1.
Buffer is reposted, and virtio says 2k was written to the buffer, so 2k
is copied to Program2.

If Program2 has some other way of accessing the left over buffer, that's
a problem.  But I think that will always require special driver
handling.

Cheers,
Rusty.



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