From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.zytor.com (terminus.zytor.com [198.137.202.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D63644A23 for ; Mon, 8 Jun 2026 06:47:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.137.202.136 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780901229; cv=none; b=hK31fthoV6iqq7sgudfiFEjjpMGJFq2SH4m+kTNU6ugDXLCxShphKFAj3S6knfPmNXQ1kA6khvRqgUyu44KAYHF8rngGEagI28hrbUs0LQRARygC87g+AmHB7bZMns+KbD48Ql1qABbgTF6fV5gN0VzUeB30OwR1cO0+qa8tPsQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780901229; c=relaxed/simple; bh=F10zRUzPMCUL0IhbtnS+wZN8v7NwiIVd2itNZd3C7WE=; h=Date:From:To:CC:Subject:In-Reply-To:References:Message-ID: MIME-Version:Content-Type; b=C/Z6ELigDzNKII3XR2bALdSLRbmSVYb5tRtnIBeS22XonejwowFVxnnFA+0tZ7WHQ7HttaL0xTPW62vkVDGPkp0J0c26HUUV1KJgSPlQX3RIJJZWAM9whiLJkhSpydRI/mxv+uC39v479GjyPzzOULjQrluMYFtrLYHBPtIKsp0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com; spf=pass smtp.mailfrom=zytor.com; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b=R6TO+Dan; arc=none smtp.client-ip=198.137.202.136 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=zytor.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b="R6TO+Dan" Received: from ehlo.thunderbird.net (c-76-133-66-138.hsd1.ca.comcast.net [76.133.66.138]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 6586kdJM3327872 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sun, 7 Jun 2026 23:46:39 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 6586kdJM3327872 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2026052701; t=1780901200; bh=Li2jmxxLMjilmVs7eakqFol7L4pQ6e13U5caIy3DiCY=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=R6TO+Dan+SXxNZlpYhyt5yo5z8Ss32Su0x2hoMR9zVSRMCdLIs90moDbLWaoUQAQg lgCGIBA2gYGc5aDHKCvfOkXLjPaPbz8NBpN3Wv0Y5fM2H5Emyx4YujLONBSVf7xTqC LJ47Tp5bXGkY5bs3sowkYyqf2wav1GkUqCUF06S8bxSwlkWt1iwBVwbMMzdGhVmcJD Ov2mgCcuGvCu8oJdGJtrVi1Lk5vEgKLExTM2iha/Mh7Ndl3NIbnES33NH4hzpqUnDf Fx55s2knXtZafVSuMg0XNmRokVInv6pYDeiUlh+sKgaFvNmouiMih14JZuGs2wgV1c 6zKs+prtX2x5A== Date: Sun, 07 Jun 2026 23:46:34 -0700 From: "H. Peter Anvin" To: Borislav Petkov CC: Andrew Cooper , x86-ML , LKML Subject: Re: Save a WRMSR GS.base? User-Agent: K-9 Mail for Android In-Reply-To: <20260605171711.GAaiMEl_CahU4oHpMk@fat_crate.local> References: <20260605025453.GAaiI6fdfradMwrUEk@fat_crate.local> <8820E259-DDAF-46F7-9800-F983D6BBE3DB@zytor.com> <20260605042652.GBaiJQDMRcO_lO0Gig@fat_crate.local> <20260605043846.GCaiJS1iXH8A6Cb3Vy@fat_crate.local> <0F905129-3447-4173-A88B-98EAC8C18E4C@zytor.com> <1E2599FB-0A39-4637-B042-EE36DA224264@zytor.com> <2f297456-d6c6-4cc8-95d8-2dac6bea99ec@citrix.com> <20260605171711.GAaiMEl_CahU4oHpMk@fat_crate.local> Message-ID: <079850DB-52FE-4545-825F-E01E918B085D@zytor.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On June 5, 2026 10:17:11 AM PDT, Borislav Petkov wrote: >On Fri, Jun 05, 2026 at 08:51:04AM -0700, H=2E Peter Anvin wrote: >> No, GS=2Ebase might have been loaded (with wrgsbase) after GS was loade= d, so >> it could be *completely different*=2E > >So you're basically saying, LKGS would load the IA32_KERNEL_GS_BASE which >belongs to the segment selector=2E This is what the pseudo code in the SD= M says: > > GS=2Eselector :=3D SRC; > GS=2Eattributes :=3D descriptor=2Eattributes; > IA32_KERNEL_GS_BASE :=3D descriptor=2Ebase; // bits 63:32 cleared > >Now, luserspace might've put something else in GS=2Ebase with WRGSBASE: > > GS=2Ebase :=3D SRC; > >So now, on context switch, we need to load IA32_KERNEL_GS_BASE with >next->gsbase which is the GS=2Ebase of the next task we're switching to= =2E > >And yes, GS=2Ebase is mapped to IA32_KERNEL_GS_BASE so yes, we must do th= at >update=2E > >And yes, as Andrew points out, both LKGS and WRMGSBASE do 32-bit writes o= nly >so we need to do the full MSR write=2E > >Ok, thanks guys, that makes sense=2E > WRxSBASE does a 64-bit write, but for GS it would incorrectly address the = kernel GS=2Ebase=2E For legacy it can be used under swapgs, but with FRED t= hat is disallowed=2E