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: <20160321194027.GB5083@two.firstfloor.org>
Date:	Mon, 21 Mar 2016 20:40:27 +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

> You're adding an hwcap bit because you expect user code to use this
> thing, which means you're adding an ABI, which means that the
> semantics should be given due consideration.

Right I did that and concluded the existing semantics are fine.
They also worked fine for many years with the system call.

We have two different modi:

- Code uses old FS/GS selector, gs selector is not zero 
In this case the selector base in GDT/LDT takes preference.

This is legacy, but still works fine.

- Code uses 64bit base, either through arch_prctl or the new
instructions. In this case FS/GS selector has to be zero.

This is the new expected mode for 64bit code.

With the new instructions the modi can be temporarily 
out of sync (GS/FS != 0, but a different base loaded),
but will always be reset on the next context switch.

Your previous objection was that this allows to detect
context switches, but that's already possible in other
ways so I think it's a red hering.

Also if you really want to change it you can do so
in a followon patch under your own name.

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