linux-kernel - Re: [patch 08/41] x86/fpu: Restrict fpstate sanitizing to legacy components

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]

Message-ID: <87bl8cw36k.ffs@nanos.tec.linutronix.de>
Date:   Fri, 11 Jun 2021 22:34:43 +0200
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Andy Lutomirski <luto@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>
Cc:     Dave Hansen <dave.hansen@...ux.intel.com>,
        Fenghua Yu <fenghua.yu@...el.com>,
        Tony Luck <tony.luck@...el.com>,
        Yu-cheng Yu <yu-cheng.yu@...el.com>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Borislav Petkov <bp@...e.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Kan Liang <kan.liang@...ux.intel.com>
Subject: Re: [patch 08/41] x86/fpu: Restrict fpstate sanitizing to legacy components

On Fri, Jun 11 2021 at 22:33, Thomas Gleixner wrote:

> On Fri, Jun 11 2021 at 12:18, Andy Lutomirski wrote:
>> On 6/11/21 12:03 PM, Andy Lutomirski wrote:
>>> On 6/11/21 9:15 AM, Thomas Gleixner wrote:
>>> Does this result in the mxcsr_mask and mxcsr fields being correct?
>>> There is a silly number of special cases there.
>
> Let me stare at that.
>
>> The SDM says, in a footnote in XRSTOR:
>>
>> There is an exception if RFBM[1] = 0 and RFBM[2] = 1. In this case, the
>> standard form of XRSTOR will load MXCSR from memory, even though MXCSR
>> is part of state component 1 — SSE. The compacted form of XRSTOR does
>> not make this exception.
>>
>> which makes me think that this code has a bug.  Also, the code is
>> manifest nonsense for a different reason:
>>
>> if (!FP)
>>   memset(the whole damn thing, 0);

That's actually my bug. The code I replaced was different. Lemme stare
at it and fix it.

>> if (!SSE)
>>   memset(just part of it, 0);
>>
>> which means that, if the FP bit is clear but the SSE bit is set, this
>> thing will clobber the SSE state.
>>
>> This code is garbage.  So is the architecture that gave rise to this code.
>
> No argument about that :)