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 C3B6B352025 for ; Thu, 18 Jun 2026 18:18:34 +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=1781806716; cv=none; b=GxyYZGMvOl1FhENlOGIh8hWJXayyAZ8uxZuBi8NVtoBxpAK9i0o0O4So0GJDd8gyb1MT4ze7g8/BvbzUNKPohzhMRA3pK4H/PyKz2r2VqhMMvd0lYP91aW0AtsLnW2mUXzlJZ2ZIR8suEYgREomSKca+HrzHFkFt+1W96QAc9ug= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781806716; c=relaxed/simple; bh=1BOttbCirD/6v830PRAD1nc4g0OmYMhQ3w+9B4gBQuM=; h=Date:From:To:CC:Subject:In-Reply-To:References:Message-ID: MIME-Version:Content-Type; b=bJWq5G/jyctJlscmmX4TRbT8jLqelblma61G3vfxfRFgGEru06MQZ8V/TLhCw2y/bPUWtVGTQlvjGks9cVhXXWvp/Oy5t7us8I/VRmIN8wCY0EY+6EYl3wHA1PDX47SiqTqRH1GF95Lm24trnMBJY8gh2WUrwAG+5IJxDj6p9bg= 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=Lh1sjyVG; 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="Lh1sjyVG" 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 65III0mn3484040 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 18 Jun 2026 11:18:01 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 65III0mn3484040 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2026052701; t=1781806681; bh=Xn0gblPInVnCiMwsx5FE1vrCfsLvvF4szECBeqlTwDM=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=Lh1sjyVGy/8V0IDzX6Da3GqXDo73R+AeKkOMGHx2wikQKd0ZHcJschZnTZxBuI5KC 54mxUDEMucHZ37t6H1/6cCFi1zrbqAiXxtCy1we1aMEJUDU9mB2QZBdBj0c3qfSv5D xQm/PB5hCiHdkaOok0G/hsa0aP+kWxIHA51jKaw1tH74xRmP1LACAXVpp5MeYmKa3D tZVJuBbIyfGvZZQeDQ5gLLTSIh7tqigMWjbriWuccxCjLjMR6EghKF3CXULMN9hYeu tLO3KuAOnTkwHffn8k1swouThN4VrgPrdU9PNxbHzVJEyrQ7Q+shmiirMO287hJFBD zrDvOO3URUx3g== Date: Thu, 18 Jun 2026 11:17:56 -0700 From: "H. Peter Anvin" To: David Laight , 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: <20260618112256.1ed7904b@pumpkin> References: <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> <20260608212100.GEaicyPO65ii0InnFa@fat_crate.local> <20260618010902.GAajNFLjwKOM-Cdj5l@fat_crate.local> <20260618112256.1ed7904b@pumpkin> Message-ID: 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 18, 2026 3:22:56 AM PDT, David Laight wrote: >On Wed, 17 Jun 2026 18:09:02 -0700 >Borislav Petkov wrote: > >> Ok, >>=20 >> I think I incorporated them all: >=2E=2E=2E >> +Btw, while running in kernel mode, MSR_KERNEL_GS_BASE contains actuall= y the >> +*user* GS=2Ebase=2E Thus, the naming can be confusing=2E Unless one th= inks of it as >> +the kernel's access to GS=2Ebase as MSRs are accessible only in CPL0= =2E > >That last sentence doesn't read right=2E Maybe: > >The naming of MSR_KERNEL_GS_BASE is rather confusing=2E >In can only be accessed in kernel mode where it normally contains the >USER GS=2Ebase=2E >The only time it contains the KERNEL GS=2Ebase is on system call/interrup= t entry >prior to swapgs being executed (and late in the return to user paths)=2E > >As an aside I think a 32bit program can detect hardware interrupts=2E >If %gs/%fs is loaded from an LDT and then the LDT entry changed (eg >a different limit) then the new limit will be loaded by the ISR >return path=2E >I seem to remember deciding that it was impossible to actual restore >the actual register value=2E > > David Not just 32-bit programs; any program using IDT, simply by loading a nonze= ro null selector=2E FRED does close that gap=2E