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

["Aravindh Puthiyaparambil (aravindp)" <aravindp@xxxxxxxxx>]

>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.

Steven,

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.

Thanks,
Aravindh

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