linux-kernel - Re: [Xen-devel] [PATCH v2 09/11] x86/xen: use capabilities instead of fake cpuid values for xsave

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:   Thu, 13 Apr 2017 11:35:31 +0100
From:   Andrew Cooper <andrew.cooper3@...rix.com>
To:     Juergen Gross <jgross@...e.com>, <linux-kernel@...r.kernel.org>,
        <xen-devel@...ts.xenproject.org>
CC:     <boris.ostrovsky@...cle.com>
Subject: Re: [Xen-devel] [PATCH v2 09/11] x86/xen: use capabilities instead of
 fake cpuid values for xsave

On 13/04/17 11:11, Juergen Gross wrote:
> @@ -281,22 +274,19 @@ static bool __init xen_check_mwait(void)
>  	return false;
>  #endif
>  }
> -static void __init xen_init_cpuid_mask(void)
> +
> +static bool __init xen_check_xsave(void)
>  {
> -	unsigned int ax, bx, cx, dx;
> -	unsigned int xsave_mask;
> +	unsigned int cx, xsave_mask;
>  
> -	ax = 1;
> -	cx = 0;
> -	cpuid(1, &ax, &bx, &cx, &dx);
> +	cx = cpuid_ecx(1);
>  
>  	xsave_mask =
>  		(1 << (X86_FEATURE_XSAVE % 32)) |
>  		(1 << (X86_FEATURE_OSXSAVE % 32));
>  
>  	/* Xen will set CR4.OSXSAVE if supported and not disabled by force */
> -	if ((cx & xsave_mask) != xsave_mask)
> -		cpuid_leaf1_ecx_mask &= ~xsave_mask; /* disable XSAVE & OSXSAVE */
> +	return (cx & xsave_mask) == xsave_mask;

As you are taking the time to change this logic, could we see about
making it work in a way which doesn't require maintaining
non-architectural hackary in the hypervisor?

(For anyone reading this who isn't familiar with the history,
http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/arch/x86/cpuid.c;h=d359e090f33bb5793524186dc5f1c8bb620f17b3;hb=17cd6621688bce9972d9242611114fd7aba44c31#l726
ought to cover it)

In the presence of the bugs which caused this issue in the first place,
the best way to probe whether xsave is actually available is to try and
execute an xgetbv instruction, and use #UD as a signal that support
isn't actually available.

This also avoids Linux participating in the non-architectural behaviour
of forcing OXSAVE to be something other than a reflection of CR4.

~Andrew