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]

Message-ID: <504A1D43.2050909@canonical.com>
Date:	Fri, 07 Sep 2012 18:13:55 +0200
From:	Stefan Bader <stefan.bader@...onical.com>
To:	Jan Beulich <JBeulich@...e.com>
CC:	Matt Wilson <msw@...zon.com>,
	"Justin M. Forbes" <jmforbes@...uxtx.org>, 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 07.09.2012 17:52, Jan Beulich wrote:
>>>> On 07.09.12 at 17:47, Stefan Bader <stefan.bader@...onical.com> wrote:
>> On 07.09.2012 17:44, 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?
>>
>> It was not a hypervisor patch. It was one for the guest. This was the hack:
> 
> So then why do you want to patch the upstream kernel? It won't
> make that hack go away, nor will it help any existing kernels.
> 
> Jan
> 

It would not make it go away automatically, but whoever uses it could drop it.
It was unpatched upstream kernels that would have the problem. However, while
reading again through all the changelogs I noticed

commit 61f4237d5b005767a76f4f3694e68e6f78f392d9
Author: Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>
Date:   Sat Sep 18 22:25:30 2010 -0700

    xen: just completely disable XSAVE

    Some (old) versions of Xen just kill the domain if it tries to set any
    unknown bits in CR4, so we can't reliably probe for OSXSAVE in
    CR4.

    Since Xen doesn't support XSAVE for guests at the moment, and no such
    support is being worked on, there's no downside in just unconditionally
    masking XSAVE support.

    Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>

So until then the write to CR4 was deliberately done to probe the feature. This
was changed by

commit 947ccf9c3c30307b774af3666ee74fcd9f47f646
Author: Shan Haitao <haitao.shan@...el.com>
Date:   Tue Nov 9 11:43:36 2010 -0800

    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.

    [ Cleaned up conditional a bit. - Jeremy ]

    Signed-off-by: Shan Haitao <haitao.shan@...el.com>
    Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@...rix.com>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>

This would make it save again _if_ the HV failing to handle the writes to CR4
(which iirc the kernel code still does when the cpuid bit is set) does have at
least the patch to mask off the cpuid bits (the one Ian mentioned)

Probably a lot of hand wavy iffs... :/


Download attachment "signature.asc" of type "application/pgp-signature" (898 bytes)