[Xen-devel] XSA-155: _apparently_ missing blktap1 fix (up to 4.5)

["Jan Beulich" <JBeulich@xxxxxxxx>]

In the course of backporting other XSA fixes to very old trees I had
noticed that the XSA-155 had shrunk to just the change to
xen/include/public/io/ring.h at some point, which didn't seem right.
Clearly up to 4.5 the situation of blktap1 is the same as that of
blktap2, i.e. one would think it also needs to be fixed. However, in
the course of doing so I stumbled across the code blindly using
req->id as an array index (which similarly is the case for blktap2).
That alone would be another security issue, if only the first change
really addressed one. But it didn't: The rings we're talking about
here are those interfacing with the kernel module, and it's only the
kernel module which interfaces with the guest ring.

Bottom line: No fix is needed to blktap1, and the change to blktap2
didn't really fix anything either. It merely made things slightly slower
due to the extra copy operation. (I haven't fully understood the
purpose of block-log.c yet, but I can't see how it would manage to
bypass the kernel module and interface directly with the frontend
in the guest, the more that tdlog_open() sets up its ring using
shm_open(), implying host local operation. Hence that part of the
change, which has no blktap1 equivalent, should not be needed
either.)

Therefore, Ian, I'd like to request that the blktap2 change not be
backported to any of the stable trees - only the libvchan one
should make it there (and the prereq to the blktap2 one, adding
RING_COPY_REQUEST(), then isn't needed either). Since that
blktap2 change isn't entirely benign, I think we should even
consider reverting it from master.

Jan


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