linux-kernel - Re: [tip:x86/urgent] x86/fpu: Set the xcomp

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: <f2fb890d-f8ff-69e2-acc7-b3c810d6cf02@linux.intel.com>
Date:   Mon, 23 Jan 2017 07:36:20 -0800
From:   Dave Hansen <dave.hansen@...ux.intel.com>
To:     fenghua.yu@...el.com, dvlasenk@...hat.com, peterz@...radead.org,
        oleg@...hat.com, mingo@...nel.org, linux-kernel@...r.kernel.org,
        brgerst@...il.com, yu-cheng.yu@...el.com, luto@...nel.org,
        bp@...en8.de, jpoimboe@...hat.com, haokexin@...il.com,
        hpa@...or.com, quentin.casasnovas@...cle.com, tglx@...utronix.de,
        torvalds@...ux-foundation.org, riel@...hat.com,
        linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/urgent] x86/fpu: Set the xcomp_bv when we fake up a
 XSAVES area

On 01/23/2017 12:28 AM, tip-bot for Kevin Hao wrote:
> x86/fpu: Set the xcomp_bv when we fake up a XSAVES area
> 
> I got the following calltrace on a Apollo Lake SoC with 32-bit kernel:

...
> --- a/arch/x86/kernel/fpu/xstate.c
> +++ b/arch/x86/kernel/fpu/xstate.c
> @@ -1070,6 +1070,7 @@ int copyin_to_xsaves(const void *kbuf, const void __user *ubuf,
>  	 * Add back in the features that came in from userspace:
>  	 */
>  	xsave->header.xfeatures |= xfeatures;
> +	xsave->header.xcomp_bv = XCOMP_BV_COMPACTED_FORMAT | xsave->header.xfeatures;
>  
>  	return 0;
>  }

First of all, thanks for finding this!  As you found, the 32-bit XSAVES
code is a bit light on testing.

I don't doubt that we have a code path that was screwed up like this,
but I don't think this is the right fix.

The kernel xsave buffer should *ALWAYS* have the
XCOMP_BV_COMPACTED_FORMAT bit set.  It should have been set before the
copyin and it should be set when it's finished.

The best fix here would be not to paper over the issue in the copy
function but find where it got clobbered, or where some initialization
code failed to set it.