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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 04.03.16 at 09:21, <JBeulich@xxxxxxxx> 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
> 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.

Since, in the course of verifying 4.5.3, you must have agreed to
the analysis above - what about the revert proposal on master
then?

Jan


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