[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Xen Security Advisory 99 - unexpected pitfall in xenaccess API

>On Tue, 2014-06-17 at 23:24 +1000, Steven Haigh wrote:
>> Also note:
>> [netwiz@dev xen-4.2.4]$ patch -p1 < ../xsa-99.patch patching file
>> tools/libxc/xc_mem_access.c Hunk #1 succeeded at 24 with fuzz 2.
>> patching file tools/libxc/xc_mem_event.c patching file
>> tools/libxc/xenctrl.h Hunk #1 succeeded at 1907 (offset -116 lines).
>> Hunk #2 succeeded at 1933 with fuzz 2 (offset -116 lines).
>> patching file tools/tests/xen-access/xen-access.c
>> Hunk #1 succeeded at 233 (offset 10 lines).
>> Hunk #2 succeeded at 254 (offset 10 lines).
>> Hunk #3 succeeded at 269 (offset 10 lines).
>> Hunk #4 FAILED at 293.
>> 1 out of 4 hunks FAILED -- saving rejects to file
>> tools/tests/xen-access/xen-access.c.rej
>> In a nutshell, it doesn't apply cleanly either...
>The purpose of the advisory was to give a heads up to people who had based
>code on xenaccess a heads up that they need to look at their possibly xen-
>acces derived code. The patch was really intended as an example of how to fix
>your application and as such was based on xen-unstable. It was not
>considered necessary to backport it.


I guess we should have been more explicit about mentioning that this patch is 
against xen-unstable only. Moreover, backporting the xen-access changes would 
require picking up some other fixes for it to apply against 4.2.4. I am just 
throwing this out there in case you are looking in to doing it. Rather than 
that, I would suggest that you fix your mem_access client for older Xen 
versions in a similar manner to the libxc helper API that I introduced.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.