Re: [Xen-devel] [PATCH 2/3] public/io/netif.h: document control ring and toeplitz hashing

[David Vrabel <david.vrabel@xxxxxxxxxx>]

On 04/01/16 11:21, Paul Durrant wrote:
>> -----Original Message-----
>> From: David Vrabel [mailto:david.vrabel@xxxxxxxxxx]
>> Sent: 04 January 2016 11:18
>> To: Paul Durrant; xen-devel@xxxxxxxxxxxxxxxxxxxx
>> Cc: Tim (Xen.org); Keir (Xen.org); Ian Campbell; Jan Beulich; Ian Jackson
>> Subject: Re: [Xen-devel] [PATCH 2/3] public/io/netif.h: document control
>> ring and toeplitz hashing
>>
>> On 04/01/16 11:14, Paul Durrant wrote:
>>>>>> You should use the standard ring format and infrastructure.
>>>>>
>>>>> Is there one for variable message size rings? I didn't find one. I
>>>>> don't want to use the fixed size balanced ring macros for control
>>>>> messages as fixed size messages really aren't appropriate in this case.
>>>>
>>>> Perhaps union the request/response message types with a uint8_t
>>>> pad[1024] and use this as the request/response type?
>>>>
>>>
>>> The problem is that this places a 1k limit on the message size,
>>> which
>>> is not there in the scheme I'm proposing. I'd rather not bake that limit
>>> in if I don't have to.
>>
>>>>>>> + * |                      req[1024]                |
>>                                  ^^^^^^^^^
>> Surely this limits your size to 1024 bytes?
> 
> No, I've already got prototype code that can pass 4k messages. Nothing in the 
> protocol says the whole message has to fit in the buffer. In fact I've 
> explicitly documented how to handle partial messages.

Then the standard ring infrastructure will work just fine.

>> Also if you need bigger messages you can grant those areas separately
>> and pass a grant ref through the ring, or you can chunk the message to
>> fit in several requests/responses.
> 
> Why go to that trouble to wedge a square peg into a round hole? What is the 
> fundamental problem with what I've proposed that you want to avoid?

You've put the consumer values into the shared page. I'd rather not have
to scrutinize your shared ring implementation for other security bugs.
Similarly, if there's another security issues like XSA-155 I'd rather
not have to look at another non-standard shared ring implementation.

IMO, it's you who should be presenting compelling reasons for /not/
using the standard infrastructure, not the other way around.

David

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel