Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp6677179imm; Wed, 27 Jun 2018 11:20:44 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIGXanJiKIkdtYhhJ7kIxM0j0enXY+ttSvuL45vYIZnk7YgQ5QhtglmLC2VOszx2bWUxK/E X-Received: by 2002:a17:902:a9:: with SMTP id a38-v6mr7408393pla.102.1530123644810; Wed, 27 Jun 2018 11:20:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530123644; cv=none; d=google.com; s=arc-20160816; b=pup7diLSMwOOUIrIlY0U8wOQ32zCNOBqlEnr9TdNMFAhyiKGLblLivaQ6NK29ZcekJ OzjR6Rs3p4w3EKMFqQW4EM0Pyq9KZqjrkOV74Cy9xso1BKw7WEpCiogNts6hpDYVKDOc olokFpAARlAU0gcH2lOHMd43xy/QdGeX8zsnwY5+yxWEX3Y/B3D7XGP7A8s/0S8Vt/iG WcbKX5O1naBbiv4QSOeWY8rfWyQ7T/On27nWTKvAR9h7LtjMxcse8JYJXhHTL3tlxqpd M2U+FqAccwVR5wFlejIufHrEGA7y4GIAL/cyEMoAY0IDBnM+StD1+Gc/ysxbOq3+i4Ax JCZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=MkWz8H62FHU1VtQRm5wI8XMjrT3Fx85VJ6De31p5NcM=; b=c7C6bLK8aPN+RfizM2o3Qu5WCdnqBra1ToY5YuALCBddao0KgOaAkBorFsEJEdh5PL scTTaX08rnMp8m/YpBZPSj6sNWt2tH1X/m69oCIkviTr8Khi5KpKyKUaPePhuc8w7P92 MjbfoM2006kpSx1U+FsC1GidTrhRMvNzHXTNmDJdmZuYHWS1NZTz45Feb8cURxm07h9/ YYGc76eY6WPjFbhTizuKU/B+xTrciwTO3KGS0AMbMJjX5YsyskUVCbUjL/z1y39U0ieo WoOY6k3bSUhOrb3X/X1o0jrruk11mCjNcxoXyJUk+xjlP9EpXbaITxgeYv24n2Kv41EJ cagA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=sW5dNwl5; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f7-v6si291791plt.4.2018.06.27.11.20.30; Wed, 27 Jun 2018 11:20:44 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=sW5dNwl5; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965775AbeF0STg (ORCPT + 99 others); Wed, 27 Jun 2018 14:19:36 -0400 Received: from mail.kernel.org ([198.145.29.99]:57272 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965529AbeF0STf (ORCPT ); Wed, 27 Jun 2018 14:19:35 -0400 Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 0386D25A20 for ; Wed, 27 Jun 2018 18:19:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1530123575; bh=pnOehvODlQ3idpKR1Lkn6GzjeTgUnKl3Ug3FAHlJf3I=; h=In-Reply-To:References:From:Date:Subject:To:Cc:From; b=sW5dNwl5xquKS640utzph8GAx1gv/UuLv+gZedPC9hFy9KJmArHot7mmISE/aorN0 spENO0N1Wcp9KugjqbcvaXYblNQKiS8+eeh6r/a08Iy7vdT5fOwAOyn3T4KIrHItxr Akys0SsonyDFaaEldRVsi3Rt6XVjD+7LpPQxF+Cg= Received: by mail-wm0-f48.google.com with SMTP id b188-v6so728779wme.3 for ; Wed, 27 Jun 2018 11:19:34 -0700 (PDT) X-Gm-Message-State: APt69E3OBJJn3fpcDn6tP1UIF1htHHk0/X1eLyaucLc06ENPif1G1/m+ wJKUIErJ6/c4RC0OsbFT20bAhQa+rjIQlzJkJN8ECQ== X-Received: by 2002:a1c:6c14:: with SMTP id h20-v6mr5503301wmc.144.1530123573475; Wed, 27 Jun 2018 11:19:33 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a1c:7e92:0:0:0:0:0 with HTTP; Wed, 27 Jun 2018 11:19:12 -0700 (PDT) In-Reply-To: References: <20180621211754.12757-1-h.peter.anvin@intel.com> <20180621211754.12757-2-h.peter.anvin@intel.com> <408ed97a-c64d-c523-c403-4e066d1f34c3@intel.com> From: Andy Lutomirski Date: Wed, 27 Jun 2018 11:19:12 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 1/7] x86/ldt: refresh %fs and %gs in refresh_ldt_segments() To: "H. Peter Anvin" Cc: Andy Lutomirski , LKML , "H. Peter Anvin" , "H. Peter Anvin" , Ingo Molnar , Thomas Gleixner , "Bae, Chang Seok" , "Metzger, Markus T" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jun 22, 2018 at 11:47 AM, Andy Lutomirski wro= te: > > > >> On Jun 22, 2018, at 11:29 AM, H. Peter Anvin w= rote: >> >>> On 06/22/18 07:24, Andy Lutomirski wrote: >>> >>> That RPL3 part is false. The following program does: >>> >>> #include >>> >>> int main() >>> { >>> unsigned short sel; >>> asm volatile ("mov %%ss, %0" : "=3Drm" (sel)); >>> sel &=3D ~3; >>> printf("Will write 0x%hx to GS\n", sel); >>> asm volatile ("mov %0, %%gs" :: "rm" (sel & ~3)); >>> asm volatile ("mov %%gs, %0" : "=3Drm" (sel)); >>> printf("GS =3D 0x%hx\n", sel); >>> return 0; >>> } >>> >>> prints: >>> >>> Will write 0x28 to GS >>> GS =3D 0x28 >>> >>> The x86 architecture is *insane*. >>> >>> Other than that, this patch seems generally sensible. But my >>> objection that it's incorrect with FSGSBASE enabled for %fs and %gs >>> still applies. >>> >> >> Ugh, you're right... I misremembered. The CPL simply overrides the RPL >> rather than trapping. >> >> We still need to give legacy applications which have zero idea about the >> separate bases that apply only to 64-bit mode a way to DTRT. Requiring >> these old crufty applications to do something new is not an option. > >> >> As ugly as it is, I'm thinking the Right Thing is to simply make it a >> part of the Linux ABI that if the FS or GS selector registers point into >> the LDT then we will requalify them; if a 64-bit app does that then they >> get that behavior. This isn't something that will happen >> asynchronously, and if a 64-bit process loads an LDT value into FS or >> GS, they are considered to have opted in to that behavior. > > But the old and crusty apps don=E2=80=99t depend on requalification becau= se we never used to do it. > > I=E2=80=99m not convinced we ever need to refresh the base. In fact, we c= ould start preserving the base of LDT-referencing FS/GS across context swit= ches even without FSGSBASE at some minor performance cost, but I don=E2=80= =99t really see the point. I still think my proposed semantics are easy to = implement and preserve the ABI even if they have the sad property that the = FSGSBASE behavior and the non-FSGSBASE behavior end up different. > There's another reasonable solution: do exactly what your patch does, minus the bugs. We would need to get the RPL !=3D 3 case right (easy) and the case where there's a non-running thread using the selector in question. The latter is probably best handled by adding a flag to thread_struct that says "fsbase needs reloading from the descriptor table" and only applies if the selector is in the LDT or TLS area. Or we could hijack a high bit in the selector. Then we'd need to update everything that uses the fields.