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 for Android: free password hash cracker in your pocket

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

Date:   Tue, 25 May 2021 19:03:12 -0500
From:   Babu Moger <babu.moger@....com>
To:     Dave Hansen <dave.hansen@...el.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 5:18 PM, Dave Hansen wrote:
> 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.

You mean the offsets can be different? Not sure how to figure that out.
Let me take a look.

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

Yes. I noticed that. I did not see that happening on Intel box where test
runs successfully.
> 
>>  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?

It goes back to default value 0x55555554. The test is expecting it to be
0. Printed them below.

test_ptrace_of_child()::1346, pkey_reg: 0x0000000055555554 shadow:
0000000000000000
protection_keys_64: pkey-helpers.h:127: _read_pkey_reg: Assertion
`pkey_reg == shadow_pkey_reg' failed.


>  Any idea how xfeatures&0x200 got clear?

Printed all the flags while in __switch_to, the header flags and CR4 flags
appears to be intact. Dont know how the feature 0x200 got cleared. Let me
check if XRSTOR is coming into play here.