linux-kernel - Re: Updated version of RD/WR FS/GS BASE patchkit

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: <CALCETrVrZyg98YiNOtMpx2m2pcjZm6TuqQDPPuohu8+puke5xw@mail.gmail.com>
Date:	Mon, 21 Mar 2016 15:27:16 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	X86 ML <x86@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Updated version of RD/WR FS/GS BASE patchkit

On Mon, Mar 21, 2016 at 3:11 PM, Andi Kleen <andi@...stfloor.org> wrote:
>> So a patchset to enable these asinine new instructions needs to take
>> this into account, and the ABI issue needs to be addressed, even if
>
> What's the ABI issue?
>
> AFAIK we're perfectly consistent.
>
>> the answer is that the proposed code is fine.
>>
>> (Also, the existing code is fscked up.  Guess what xor %eax, %eax; mov
>> %ax, %gs does to the base on AMD?  The existing code is *wrong*, and I
>> don't want to see it get wronger.)
>
> I have no idea, but changing it is definitely not in scope for my patches.
>
>>
>> And no, I don't really care about programs detecting context switches.
>> I do, however, care about allowing non-determinism in things that
>> ought to behave deterministically.  Writing a nonzero value to %gs and
>> then doing WRGSBASE is something that user code will be able to do
>> whether we like it or not, some shitty threading library is likely to
>> do this just to spite us, the the kernel needs to do *something* when
>> this happens.
>
> They will quickly notice it if there is a problem, so I don't think
> we need to worry about that.

Really?

Imagine that some brilliant lightweight threading library does:

 - set GS to nonzero (by whatever means -- arch_prctl(ARCH_SET_GS,
whatever) on a pre-IVB host followed by migration, some modify_ldt
garbage, simple bloody-mindedness, whatever);
 - WRGSBASE
 - Use GS for a bit

This will work most of the time until it gets unlucky with preemption.
And yes, runtime library authors really do mess up in amazing ways.

It's an issue.  It needs conscious design.