Re: [Qemu-devel] [PATCH v3 03/46] ivhsmem: read do not accept more than sizeof(long)

["Marc-André Lureau" <mlureau@redhat.com>]

----- Original Message -----
> On 16.09.2015 11:33, Marc-André Lureau wrote:
> > ----- Original Message -----
> >> On 15.09.2015 18:07, marcandre.lureau@redhat.com wrote:
> >>> From: Marc-André Lureau <marcandre.lureau@redhat.com>
> >>>
> >>> ivshmem_read() only reads sizeof(long) from the input buffer.  Accepting
> >>> more could lead to fifo8 abort() on 32bit systems if fifo is not empty.
> >>>
> >>> Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
> >>> ---
> >>>  hw/misc/ivshmem.c | 2 +-
> >>>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/hw/misc/ivshmem.c b/hw/misc/ivshmem.c
> >>> index cc76989..fb53b3f 100644
> >>> --- a/hw/misc/ivshmem.c
> >>> +++ b/hw/misc/ivshmem.c
> >>> @@ -272,7 +272,7 @@ static void ivshmem_receive(void *opaque, const
> >>> uint8_t
> >>> *buf, int size)
> >>>  
> >>>  static int ivshmem_can_receive(void * opaque)
> >>>  {
> >>> -    return 8;
> >>> +    return sizeof(long);
> >>>  }
> >>>  
> >>
> >> Is the right fix this one, or should ivshmem_read() not rely on
> >> sizeof(long)?
> > 
> > 
> > See my answer to Paolo:
> > http://lists.nongnu.org/archive/html/qemu-devel/2015-07/msg05341.html
> 
> Sorry for not noticing the previous discussion..
> 
> Still it would seem more sensible to say explicitly how big the field is I
> think,
> especially if we want to make it possible to have independent server
> implementations of this...
> 
> This field is used to communicate directly with another process on the host
> right?
> Should we not mandate the communication interface quite precisely, in order
> to allow independent server development?
> I'll push it further: do we need to consider endianness? It's the same host I
> know, but is the meaning of the field endian-independant, or fully
> expressed?

I am not aware of any specification, so following implementation it is 'long' integer in native endianness

I agree we could document and change the protocol, but this will likely break it and could be done in a different patch series.

thanks