linux-kernel - Re: How should we handle illegal task FPU state?

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]

Date:   Thu, 1 Oct 2020 14:50:37 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Sean Christopherson <sean.j.christopherson@...el.com>,
        "Yu, Yu-cheng" <yu-cheng.yu@...el.com>
Cc:     Andy Lutomirski <luto@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>,
        Rik van Riel <riel@...riel.com>,
        Andrew Cooper <andrew.cooper3@...rix.com>
Subject: Re: How should we handle illegal task FPU state?

On 10/1/20 1:58 PM, Sean Christopherson wrote:
> One thought for a lowish effort approach to pave the way for CET would be to
> try XRSTORS multiple times in switch_fpu_return().  If the first try fails,
> then WARN, init non-supervisor state and try a second time, and if _that_ fails
> then kill the task.  I.e. do the minimum effort to play nice with bad FPU
> state, but don't let anything "accidentally" turn off CET.

I'm not sure we should ever keep running userspace after an XRSTOR*
failure.  For MPX, this might have provided a nice, additional vector
for an attacker to turn off MPX.  Same for pkeys if we didn't correctly
differentiate between the hardware init state versus the "software init"
state that we keep in init_task.

What's the advantage of letting userspace keep running after we init its
state?  That it _might_ be able to recover?