[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v3 03/46] ivhsmem: read do not accept more than
From: |
Marc-André Lureau |
Subject: |
Re: [Qemu-devel] [PATCH v3 03/46] ivhsmem: read do not accept more than sizeof(long) |
Date: |
Wed, 16 Sep 2015 08:03:33 -0400 (EDT) |
----- Original Message -----
> On 16.09.2015 11:33, Marc-André Lureau wrote:
> > ----- Original Message -----
> >> On 15.09.2015 18:07, address@hidden wrote:
> >>> From: Marc-André Lureau <address@hidden>
> >>>
> >>> 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 <address@hidden>
> >>> ---
> >>> 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
[Qemu-devel] [PATCH v3 04/46] ivshmem: fix number of bytes to push to fifo, marcandre . lureau, 2015/09/15
[Qemu-devel] [PATCH v3 05/46] ivshmem: factor out the incoming fifo handling, marcandre . lureau, 2015/09/15
[Qemu-devel] [PATCH v3 07/46] ivshmem: remove superflous ivshmem_attr field, marcandre . lureau, 2015/09/15