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

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Fri, Mar 04, 2016 at 01:21:19AM -0700, Jan Beulich wrote:
> 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

Yes. We fixed that in blkback some time ago, but yes that code base
has some quite errant bugs in it.

Would love to say I can fix them, but the TODO list is getting
a bit long.
> 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