Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751973AbdHGRfr (ORCPT ); Mon, 7 Aug 2017 13:35:47 -0400 Received: from mail-oi0-f42.google.com ([209.85.218.42]:35855 "EHLO mail-oi0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751532AbdHGRfo (ORCPT ); Mon, 7 Aug 2017 13:35:44 -0400 MIME-Version: 1.0 In-Reply-To: References: <73bef0c2-f181-0626-2ac1-e4e0537ca851@list.ru> From: Linus Torvalds Date: Mon, 7 Aug 2017 10:35:43 -0700 X-Google-Sender-Auth: cHSJL4QPs1yydwflSQTEA_QQK8g Message-ID: Subject: Re: FSGSBASE ABI considerations To: Andy Lutomirski Cc: Stas Sergeev , "Bae, Chang Seok" , X86 ML , "linux-kernel@vger.kernel.org" , Borislav Petkov , Brian Gerst , Bart Oldeman 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: 1663 Lines: 43 On Mon, Aug 7, 2017 at 9:20 AM, Andy Lutomirski wrote: > > Windows does something sort of like this (I think), but I don't like > this solution. I fully expect that someone will write a program that > does: > > old = rdgsbase(); > wrgsbase(new); > call_very_fast_function(); > wrgsbase(old); > > This will work if GS == 0, which is fine. The problem is that it will > *also* work if GS != 0 with very high probability, especially if this > code sequence is right after some operation that sleeps. And then > we'll get random crashes with very low probability, depending on where > the scheduler hits. It will work reliably if you just make the scheduler save/restore the base rather than the selector. I really think you need to walk away from the "selector is meaningful" model. Yes, yes, it's the legacy model, but it's the *insane* model. So screw the selector. It doesn't matter. We'll need to save/restore the value, but that's it. What we *really* save and restore is just the base pointer. Why do you care so much about the selector? If people *don't* use the fsgsbase, then the selector and the base of the segment will always match anyway (modulo the system calls that actually change the gdt/ldt, and we can just sat that *then* selectors matter). And if people *do* use fsgsbase, then the selector is by definition not important. So just make the scheduler save the base first, and restore it last. End of problem. Your user-space code above just works. There is no race, i doesn't matter one whit whether GS is 0 ir not, there simply is no problem. So just what is the problem you're trying to solve? Linus