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]

Date:	Mon, 21 Mar 2016 23:11:48 +0100
From:	Andi Kleen <andi@...stfloor.org>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Andi Kleen <andi@...stfloor.org>, 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

> 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.

-Andi

-- 
ak@...ux.intel.com -- Speaking for myself only.