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

Re: [Xen-devel] xen-CVE-2013-1442-XSA-62.patch

On 02/10/13 20:12, AL13N wrote:
> Op woensdag 2 oktober 2013 19:53:06 schreef Andrew Cooper:
> [...]
>> You have a few options
>> 1) Unconditionally force xsave off.  It is at the very least buggy if
>> you are missing the patches causing your patch application problems.
> i can do this programmatorically, so that noone in Mageia 3 will be able to 
> use it?
> does this mean xsave has been buggy on the released 4.2.1 in any case?

Xsave support in Xen has been buggy on all releases, with the final
fixes only appearing very recently.  The upcoming 4.3.1 release is I
believe the first formal Xen release where xsave support is supposedly

If you want to disable xsave, then you need to play with "use_xsave" in

However, if anyone has VMs using xsave, this change in a security update
will break the VM on live migrate.

>> 2) Backport the xsave patches as well.
>> http://xenbits.xen.org/gitweb/?p=xen.git;a=history;f=xen/arch/x86/xstate.c;h
>> b=12b0ee04a16194f064d5b895a844fcdc6414bfc0 should give you a good idea of
>> the patches.
>> http://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=0bda88abe18029c2bbe9
>> dc5d07cc706bd775c9b7 is probably the main patch needed.
>> 3) Rework the security patch yourself using
>> 0bda88abe18029c2bbe9dc5d07cc706bd775c9b7 as a reference of where and how
>> to patch in arch/x86/traps.c
>> I highly recommend option 2.
> thanks for the quick assistance

As I said, option 2 is the only reasonable solution to this problem
which wont cause regressions for users, and has a side effect of making
xsave actually work.


Xen-devel mailing list



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