Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751352AbdGaVXt (ORCPT ); Mon, 31 Jul 2017 17:23:49 -0400 Received: from mga02.intel.com ([134.134.136.20]:20652 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751017AbdGaVXs (ORCPT ); Mon, 31 Jul 2017 17:23:48 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,304,1498546800"; d="scan'208";a="117861715" From: "Bae, Chang Seok" To: Andy Lutomirski CC: X86 ML , "linux-kernel@vger.kernel.org" , Linus Torvalds , Borislav Petkov , "Brian Gerst" , Stas Sergeev Subject: RE: FSGSBASE ABI considerations Thread-Topic: FSGSBASE ABI considerations Thread-Index: AQHTCan9DzzDPFjdZkS7yWknwbomlqJubgQw Date: Mon, 31 Jul 2017 21:23:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [172.18.205.10] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id v6VLNsKd003669 Content-Length: 1437 Lines: 20 > On an FSGSBASE-enabled system, I think we need to provide deterministic, documented, tested behavior. I can think of three plausible choices: > 1a. modify_ldt() immediately updates FSBASE and GSBASE all threads that reference the modified selector. > 1b. modify_ldt() immediatley updates FSBASE and GSBASE on all threads that reference the LDT. > 2. modify_ldt() leaves FSBASE and GSBASE alone on all threads. > (2) is trivial to implement, whereas (1a) and (1b) are a bit nasty to implement when FSGSBASE is on. > The tricky bit is that 32-bit kernels can't do (2), so, if we want modify_ldt() to behave the same on 32-bit and 64-bit kernels, we're stuck with (1). While implementing (1) is still unclear for context switch, here is one idea for (1b): - thread struct has new entry for ldt pointer that last seen - modify_ldt happens - ldtr upated for active threads via IPI - for inactive threads being scheduled in, ldtr updated before __switch_to - in __switch_to, read ldtr by sldt and compare the new ldt pointer sldt is ucode that likely takes only a couple cycles - mostly matched given modify_ldt is rare - unmatched, don't write gsbase if gs indicating LDT > (I think we can implement (2) with acceptable performance on 64-bit non-FSGSBASE kernels if we wanted to.) Nonetheless, with Andy's argument for (1), (2) might be straightforward assuming that user code already followed the legacy around modify_ldt in 64bit.