[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 fixed. If you want to disable xsave, then you need to play with "use_xsave" in xen/arch/x86/cpu/common.c 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. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |