From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.alien8.de (mail.alien8.de [65.109.113.108]) (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 53F9A34E745 for ; Mon, 8 Jun 2026 21:21:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=65.109.113.108 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780953685; cv=none; b=Et/lOudULt5YMiuP8bcmzIQC9CgTjz1CIbVMISbynKg1TOw4rKHgNKNefCort+qXjUCCKWG3zUBj4/Ey8nossvRa3fwZPOKzDWWxMUd4dLMFYf2kmIjeu2mtdNdjiyAp0Q3uqKm4o0OQ41wNcJIy0tgmA2mnxKhhj5sr6oj3U0M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780953685; c=relaxed/simple; bh=rhhk7fj2L7yHtX/I34CoshmMZAiidp4EZX67SUbaeTw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=nFABw4xAsxntiXkLMcNW3Ycd0FGTltr/v/Wa5HRh7vgEmMYIPT+6YN5tXouQ9YInmKvfpbdjYRdumKv14N1OgzhuKykfEjNLQrVffxzwILZ4vTVG737iREYE0ISnPmW9W92rk5amrtTDhTjRgRjysS5Tur9FIarflkQm0yvnYJA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=alien8.de; spf=pass smtp.mailfrom=alien8.de; dkim=fail (4096-bit key) header.d=alien8.de header.i=@alien8.de header.b=UURfKohe reason="signature verification failed"; arc=none smtp.client-ip=65.109.113.108 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=alien8.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=alien8.de Authentication-Results: smtp.subspace.kernel.org; dkim=fail reason="signature verification failed" (4096-bit key) header.d=alien8.de header.i=@alien8.de header.b="UURfKohe" Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTP id 74AE940E0203; Mon, 8 Jun 2026 21:21:20 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at mail.alien8.de Authentication-Results: mail.alien8.de (amavisd-new); dkim=fail (4096-bit key) reason="fail (body has been altered)" header.d=alien8.de Received: from mail.alien8.de ([127.0.0.1]) by localhost (mail.alien8.de [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id QvEL9oIuBNAe; Mon, 8 Jun 2026 21:21:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=alien8; t=1780953669; bh=8gK0cyxnKVW2fh7skprlYqMDk/ccDzDQ0nGNkA+q8Cc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=UURfKoheKyi1w/jDf+qONdfrTWDZDaV6uLZf9An/YrYTAEp69q2TjgbnWxkwZ+ua2 UrAAzG/FGL/F8OmYKZU4gle/PmjmUIUnDPDoQzmYgmrYcrH3v1lHesSLw5G/QqMN62 jG0/v6boljqhGV/hFlRQXXrJ6EDEJ42/0Sg4g4bcAVbluZk90c592GvmZgk0Mwksc+ vULAf0JAyWd5MN06kIvtk33ZNGy0aM/tMDYL4qAt8tHhEwVq3rUv5MrM3kbQGwY3yU 9DWL88xVhVvTA8Z0tvCqfgWfK5IuQGBZbd2aYLiral2QIWesqMCBZ7tUiRqxGSJg0t pi1tB9k5AujlBAFSnwKvs87rEZhnPy+nM5su7gvenRldpeac2kqoOMpn6JLEAMEvGd 0t+M6iYpPrhX+PBaC0rIoVYEBKpu8xbQeLIiLmWsRJMZRpXxjU+PDESEt5b6LYGE7H lp6oDGoopVnlaViFv5NtyQmjfuy9GRUWPeDmGYs4HEv+cmbox0DJsUcZd/9eqdxhUt 9i0YcDmlI5st7nMY9b51Ilhzy+z+4QqSodDaLoPVDWYji9S8rRhmzzwsdVKOm0mPwj p1PIiX3BQG73x9P8z3IrO8IzkNOZWEs0Up+Uwmj3Itxh0xChA80sC30hAEGlkT1MIH ZJ3P01m2eaJAWy5hvfGo5Qxk= Received: from stx.tnic (unknown [IPv6:2600:1700:38ca:c00::42]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail.alien8.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id B0BEE40E015B; Mon, 8 Jun 2026 21:21:04 +0000 (UTC) Date: Mon, 8 Jun 2026 14:21:00 -0700 From: Borislav Petkov To: "H. Peter Anvin" Cc: Andrew Cooper , x86-ML , LKML Subject: Re: Save a WRMSR GS.base? Message-ID: <20260608212100.GEaicyPO65ii0InnFa@fat_crate.local> References: <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> <079850DB-52FE-4545-825F-E01E918B085D@zytor.com> <20260608143835.GAaibT6_Ypd2OzVkWD@fat_crate.local> <87cfce38-4b5a-4014-a098-2c43e3067df1@zytor.com> <20260608200528.GDaicgiFydU8LVUGL2@fat_crate.local> 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-Disposition: inline In-Reply-To: <20260608200528.GDaicgiFydU8LVUGL2@fat_crate.local> Content-Transfer-Encoding: quoted-printable On Mon, Jun 08, 2026 at 01:05:28PM -0700, Borislav Petkov wrote: > I think this is begging to be written down somewhere. Lemme point AI to= it and > see what it would generate. Something like the below... I am thinking of sticking that somewhere und= er Documentation... oh look: Documentation/arch/x86/x86_64/fsgs.rst. Looks l= ike there was already need to document this stuff which is clearly not really transparent. What's there is covering the userspace side more tho. Anyway, the below is a summary of our thread with AI, it ain't half-bad a= nd I think we should write it down for future reference. Thx. --- GS handling on context switches SWAPGS Swaps the base-address value in MSR_KERNEL_GS_BASE with the active GS.bas= e in the hidden portion of the GS selector register. MOV , GS (legacy path, non-FRED) Loads the GS selector and fetches the descriptor attributes and base from the GDT/LDT. Writes a 32-bit base into the activ= e GS.base. Does not touch MSR_KERNEL_GS_BASE. Useless for task switching th= e user GS base on its own without surrounding SWAPGS calls. LKGS (FRED path, replaces MOV GS) Like MOV GS in that it loads the selector an= d descriptor attributes, but it redirects the base write =E2=80=94 instead = of updating the active GS.base, it writes the descriptor base into IA32_KERNEL_GS_BAS= E (i.e. MSR_KERNEL_GS_BASE). Critical caveat: it only writes a zero-extended 32-bit value, because GDT= /LDT descriptors only encode 32-bit bases. This means it cannot correctly repr= esent a full 64-bit user-space GS base (e.g. a TLS pointer), so a full 64-bit W= RMSR is still required afterwards. WRGSBASE (with REX.W) Writes a full 64-bit value directly into the currently activ= e GS.base as FS.base and GS.base in 64-bit mode are expanded to 64-bit to c= over the full address space. The problem in kernel context: the currently active GS.base belongs to th= e kernel, not the user task. So using this during context switching would corrupt the kernel's own GS.base, unless surrounded by SWAPGS (only safe = in IDT mode). Without REX.W, the upper 32 bits of the base are cleared inste= ad. WRMSR MSR_KERNEL_GS_BASE / WRMSRNS MSR_KERNEL_GS_BASE Writes a full 64-bit value into MSR_KERNEL_GS_BASE, which holds the inact= ive (user-space) GS base =E2=80=94 the one that gets swapped into the active = GS.base on SWAPGS. This is the only instruction that can correctly set a 64-bit user= GS base during a context switch from kernel mode. WRMSRNS is the non-seriali= zing variant, which is preferable here since this MSR is architecturally non-serializing anyway. --=20 Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette