Commit Graph
6 Commits
Author SHA1 Message Date
Jason Andryuk 821096dd8a libvchan: Make raw_get_{data_ready, buffer_space} match
For writing into a vchan, raw_get_buffer_space used >, allowing the full
ring size to be written.  On the read side, raw_get_data_ready compared
the ring size with >=.  This mismatch means a completely filled buffer
cannot be read.  Fix this by making the size checks identical.

Signed-off-by: Jason Andryuk <andryuk@aero.org>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
2014-06-02 14:36:05 +01:00
Marek Marczykowski-Górecki 2efcb0193b libvchan: Fix handling of invalid ring buffer indices
The remote (hostile) process can set ring buffer indices to any value
at any time. If that happens, it is possible to get "buffer space"
(either for writing data, or ready for reading) negative or greater
than buffer size.  This will end up with buffer overflow in the second
memcpy inside of do_send/do_recv.

Fix this by introducing new available bytes accessor functions
raw_get_data_ready and raw_get_buffer_space which are robust against
mad ring states, and only return sanitised values.

Proof sketch of correctness:

Now {rd,wr}_{cons,prod} are only ever used in the raw available bytes
functions, and in do_send and do_recv.

The raw available bytes functions do unsigned arithmetic on the
returned values.  If the result is "negative" or too big it will be
>ring_size (since we used unsigned arithmetic).  Otherwise the result
is a positive in-range value representing a reasonable ring state, in
which case we can safely convert it to int (as the rest of the code
expects).

do_send and do_recv immediately mask the ring index value with the
ring size.  The result is always going to be plausible.  If the ring
state has become mad, the worst case is that our behaviour is
inconsistent with the peer's ring pointer.  I.e. we read or write to
arguably-incorrect parts of the ring - but always parts of the ring.
And of course if a peer misoperates the ring they can achieve this
effect anyway.

So the security problem is fixed.

This is XSA-86.

(The patch is essentially Ian Jackson's work, although parts of the
commit message are by Marek.)

Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
2014-02-06 16:44:41 +01:00
Matthew Daley f2f06a2f1b libvchan: handle libxc evtchn failures properly in init functions
The reasoning behind this patch is that ctrl->event_port is a uint32_t
(ie. unsigned), so the current checks on it for negative error results,
non-negative port presence etc. are incorrect.

Fix by using evtchn_port_or_error_t in the init functions instead,
adjusting the error handling, and removing the now-unnecessary check
from the close function.

Coverity-ID: 1055609
Coverity-ID: 1055610
Coverity-ID: 1055611
Signed-off-by: Matthew Daley <mattjd@gmail.com>
Reviewed-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
2013-10-31 21:55:53 +00:00
Olaf Hering 75f1b60ed0 tools/libvchan: Remove unwanted debugging code
-O2 -Wall -Werror triggers these warnings:

io.c: In function 'do_send':
io.c:196: warning: ignoring return value of 'writev', declared with attribute warn_unused_result
io.c: In function 'do_recv':
io.c:287: warning: ignoring return value of 'writev', declared with attribute warn_unused_result

writev to -1 will always fail, silence the warning by removing the offending
(disabled) debug code.

Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
2012-04-17 18:18:49 +01:00
Keir Fraser acbae3dcf6 tools/libvchan: Beef up the CPU barriers in libvchan.
Although they were sufficient for x86, they weren't safe more generally.

Signed-off-by: Keir Fraser <keir@xen.org>
2012-01-21 17:15:40 +00:00
Daniel De Graaf 1a16a3351f libvchan: interdomain communications library
This library implements a bidirectional communication interface between
applications in different domains, similar to unix sockets. Data can be
sent using the byte-oriented libvchan_read/libvchan_write or the
packet-oriented libvchan_recv/libvchan_send.

Channel setup is done using a client-server model; domain IDs and a port
number must be negotiated prior to initialization. The server allocates
memory for the shared pages and determines the sizes of the
communication rings (which may span multiple pages, although the default
places rings and control within a single page).

With properly sized rings, testing has shown that this interface
provides speed comparable to pipes within a single Linux domain; it is
significantly faster than network-based communication.

Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
2011-10-06 19:44:40 +01:00