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: <18af2b84-b350-6bde-9aef-c0266d604e4a@oracle.com>
Date:   Tue, 25 May 2021 17:22:55 -0500
From:   Dave Kleikamp <dave.kleikamp@...cle.com>
To:     Dave Hansen <dave.hansen@...el.com>,
        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
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.
> 
> 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?

I did observe that PKRU is 0 right before the failure.

Shouldn't this still be a valid value?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ