linux-kernel - Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 10 Sep 2012 19:40:47 -0700
From:	Matt Wilson <msw@...zon.com>
To:	"Justin M. Forbes" <jmforbes@...uxtx.org>
CC:	Jan Beulich <JBeulich@...e.com>,
	Stefan Bader <stefan.bader@...onical.com>,
	<xen-devel@...ts.xen.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [Xen-devel] [PATCH/RFC] Fix xsave bug on older Xen hypervisors

On Fri, Sep 07, 2012 at 11:00:22AM -0500, Justin M. Forbes wrote:
> On Fri, 2012-09-07 at 16:44 +0100, Jan Beulich wrote:
> > 
> > All of this still doesn't provide evidence that a plain upstream
> > kernel is actually having any problems in the first place. Further,
> > if you say EC2 has a crippled hypervisor patch - is that patch
> > available for looking at somewhere?
> 
> Yes, I can verify that a plain upstream kernel has problems in the first
> place, which is why we are carrying a patch to simply disable xsave all
> together in the pv guest.
> EC2 is not carrying a patch to cripple the hypervisor, there was an old
> xen bug that makes all this fail.  The correct fix for that bug is to
> patch the hypervisor, but they have not done so. Upstream xen has had
> the fix for quite some time, but that doesn't change the fact that a lot
> of xen guest usage these days is on EC2.  This is no different than
> putting in a quirk to work around a firmware bug in common use.

I've done some testing and have results that indicate otherwise. The
out-of-tree xen_write_cr4() patch is not needed as of 2.6.39. I tested
3.2.21 on a machine that has XSAVE capabilities:

[ec2-user@...10-160-18-80 ~]$ cpuid -1 -i | grep -i xsave/xstor
      XSAVE/XSTOR states                      = true
      OS-enabled XSAVE/XSTOR                  = false

on an older hypervisor build:

[ec2-user@...10-160-18-80 ~]$ cat /sys/hypervisor/version/major
3
[ec2-user@...10-160-18-80 ~]$ cat /sys/hypervisor/version/minor
0

and it boots without a problem. This patch correctly detects that the
hypervisor supports XSAVE by testing for OSXSAVE:

commit 947ccf9c3c30307b774af3666ee74fcd9f47f646
Author:     Shan Haitao <haitao.shan@...el.com>
AuthorDate: Tue Nov 9 11:43:36 2010 -0800
Commit:     Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
CommitDate: Wed Apr 6 08:31:13 2011 -0400

    xen: Allow PV-OPS kernel to detect whether XSAVE is supported
    
    Xen fails to mask XSAVE from the cpuid feature, despite not historically
    supporting guest use of XSAVE.  However, now that XSAVE support has been
    added to Xen, we need to reliably detect its presence.
    
    The most reliable way to do this is to look at the OSXSAVE feature in
    cpuid which is set iff the OS (Xen, in this case), has set
    CR4.OSXSAVE.

Matt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/