Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756426AbcCUW1h (ORCPT ); Mon, 21 Mar 2016 18:27:37 -0400 Received: from mail-ob0-f170.google.com ([209.85.214.170]:34826 "EHLO mail-ob0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751100AbcCUW1g (ORCPT ); Mon, 21 Mar 2016 18:27:36 -0400 MIME-Version: 1.0 In-Reply-To: <20160321221148.GF5083@two.firstfloor.org> References: <1458576969-13309-1-git-send-email-andi@firstfloor.org> <20160321190322.GZ5083@two.firstfloor.org> <20160321194027.GB5083@two.firstfloor.org> <20160321221148.GF5083@two.firstfloor.org> From: Andy Lutomirski Date: Mon, 21 Mar 2016 15:27:16 -0700 Message-ID: Subject: Re: Updated version of RD/WR FS/GS BASE patchkit To: Andi Kleen Cc: X86 ML , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1628 Lines: 42 On Mon, Mar 21, 2016 at 3:11 PM, Andi Kleen 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.