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

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: David Vrabel [mailto:david.vrabel@xxxxxxxxxx]
> Sent: 04 January 2016 11:29
> 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: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.

Ok. That's a good enough reason. I'll come up with a new prototype.

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

There is no 'standard' here though. There's convention, but that's a different 
thing. If we're going to have a 'no more variable size message protocols' 
policy than that needs writing down somewhere.

  Paul

> David

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