linux-kernel - Re: x86/fpu/xsave: protection key test failures

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: <7a407363-e074-aa84-3ca1-909b497122aa@intel.com>
Date:   Tue, 25 May 2021 15:18:53 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Babu Moger <babu.moger@....com>, linux-kernel@...r.kernel.org,
        linux-kselftest@...r.kernel.org
Cc:     tglx@...utronix.de, mingo@...hat.com, bp@...en8.de, x86@...nel.org,
        hpa@...or.com, dave.hansen@...ux.intel.com, luto@...nel.org,
        peterz@...radead.org, shuah@...nel.org, jroedel@...e.de,
        ubizjak@...il.com, viro@...iv.linux.org.uk, jpa@....mail.kapsi.fi,
        fenghua.yu@...el.com, kan.liang@...ux.intel.com,
        akpm@...ux-foundation.org, rppt@...nel.org, Fan_Yang@...u.edu.cn,
        anshuman.khandual@....com, b.thiel@...teo.de, jgross@...e.com,
        keescook@...omium.org, seanjc@...gle.com, mh@...ndium.org,
        sashal@...nel.org, krisman@...labora.com, chang.seok.bae@...el.com,
        0x7f454c46@...il.com, jhubbard@...dia.com, sandipan@...ux.ibm.com,
        ziy@...dia.com, kirill.shutemov@...ux.intel.com,
        suxingxing@...ngson.cn, harish@...ux.ibm.com,
        rong.a.chen@...el.com, linuxram@...ibm.com, bauerman@...ux.ibm.com,
        dave.kleikamp@...cle.com
Subject: Re: x86/fpu/xsave: protection key test failures

On 5/25/21 2:37 PM, Babu Moger wrote:
> My suspicion at this point is towards the selftest tool protection_keys.c.
> I will keep looking. Any feedback would be much appreciated to debug further.

The pkey selftest code that pokes at the signal stack is rather hackish.
 If I had to guess, I'd suspect that PKRU ends up in there in a slightly
different place than on Intel CPUs.

One oddity is that xfeatures seems to lose its pkey bit somewhere:

>  protection_keys-17350 [035] 59275.834197: x86_fpu_copy_src:     	x86/fpu: 0xffff93d7595e2dc0 load: 0 xfeatures: 202 xcomp_bv: 8000000000000207
>  protection_keys-17350 [035] 59275.834197: x86_fpu_copy_dst:     	x86/fpu: 0xffff93d722877800 load: 0 xfeatures: 2 xcomp_bv: 8000000000000207 

The only legitimate way that can happen (on Intel at least) is an XRSTOR
that brings PKRU back to the init state.  That would destroy all
meaningful PKRU state, unless PKRU=0, which it almost never does on Linux.

What values do PKRU and the shadow have when the test fails?  Is PKRU 0?
 Any idea how xfeatures&0x200 got clear?