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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <87eed8w38v.ffs@nanos.tec.linutronix.de>
Date:   Fri, 11 Jun 2021 22:33:20 +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 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);
>
> 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 :)