linux-kernel - Re: [PATCH 05/11] x86/fpu: set PKRU state for kernel threads

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:   Fri, 19 Oct 2018 11:26:19 -0700
From:   Dave Hansen <dave.hansen@...ux.intel.com>
To:     Andy Lutomirski <luto@...capital.net>
Cc:     Paolo Bonzini <pbonzini@...hat.com>,
        Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        Andrew Lutomirski <luto@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>,
        Radim Krcmar <rkrcmar@...hat.com>,
        kvm list <kvm@...r.kernel.org>,
        "Jason A. Donenfeld" <Jason@...c4.com>,
        Rik van Riel <riel@...riel.com>
Subject: Re: [PATCH 05/11] x86/fpu: set PKRU state for kernel threads

On 10/19/2018 10:37 AM, Andy Lutomirski wrote:
>> I think it's much more straightforward to just not enforce pkeys. 
>> Having this "phantom" value could cause a very odd, nearly
>> undebuggable I/O failure.
> But now we have the reverse. The IO can work if it’s truly async but,
> if the kernel decides to synchronously complete IO (with GUP or
> copy_to_user), it’ll fail, right. This isn’t exactly friendly
> either.

Yeah, but a synchronous I/O failure is really straightforward to debug
because you get an immediate error message about it.  This is certainly
not the weirdest behavior or asymmetry that we would see from
synchronous vs. async I/O.