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 8DCFA2D1931 for ; Fri, 5 Jun 2026 03:21:23 +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=1780629686; cv=none; b=qyrEnJOvrvTzNvRGsPqBEakMIo9Vvdy06aoFtE0oletTmH8YWuFeIoDbxOE2Vv7MBWaxxO5+DxUlNXwVcsRWCw5rAFgWOEXt9N6p5YtfmIOzoguUjbiWnHdH6npE2fpDdz8D+wFItMoPB4C3yJMvcxomGT6bUjh4Lo1FpqH3B8E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780629686; c=relaxed/simple; bh=Dw622N5fPyp6amymCK7FU40P7N7qWmAlSCr5N+sMQ54=; h=Date:From:To:CC:Subject:In-Reply-To:References:Message-ID: MIME-Version:Content-Type; b=Mb5b7PEihHWAVBZWm6o4xe2eCiVnSgo5sm1zn82n8y4AzhDMrqV8x2UOFheKK73rXVff9YqAcCtVboG5IWG70CJN1gmyFr9sc7Y/LfUXoFD1utBD0DAjp9P/VE+WHGPlEfUfL/EkFZBXMblR3/C5J6+C19StzRpIoQliz/i/70A= 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=AADGdpew; 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="AADGdpew" 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 6553L3gl212191 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 4 Jun 2026 20:21:03 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 6553L3gl212191 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2026052701; t=1780629663; bh=KhKCFnaT20pfync2FSMJs4F9fUSu0vMd4JXsc71KZ3I=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=AADGdpewvtmIpXjJQIcFaQINMnseLHgNNqLzHvXm7seblvJLgj6FB3BDbZRTKOWES U2agy4fcI7mCHdgUAMcXq+c0eA1ky1hD3ToMyLBB6vU6HCDAOVV4Y9kG0nmuK0NB0S EoXf+8W6waasR0Y39aOQ/HEr+oDVmDMttFzlmMqNpoDsvlo8Xq9JRhcLZx34P8HsXS C97qboORYXoP/kKDv2cpYERNIzMFYFvi0gXK1nth0bXG1qGR/RguPJsXPgQFr2zzkZ 7og0YNad73asc6jNprHvQAPz8g45l2MvlWAzzlPuMEddBVjleVzz/yoeT2TU59sghF XkjAKOGUR/aTw== Date: Thu, 04 Jun 2026 20:20:57 -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: <20260605025453.GAaiI6fdfradMwrUEk@fat_crate.local> References: <20260604015303.GEaiDafyuU0bwP4Y05@fat_crate.local> <180aeb02-4ed9-436c-ba61-c8559eb7994c@citrix.com> <20260605022428.GBaiIzXL7TgIjMj8d7@fat_crate.local> <18B4FA09-40DE-43D0-A3D0-DD16DE652B87@zytor.com> <20260605025453.GAaiI6fdfradMwrUEk@fat_crate.local> Message-ID: <8820E259-DDAF-46F7-9800-F983D6BBE3DB@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 4, 2026 7:54:53 PM PDT, Borislav Petkov wrote: >On Thu, Jun 04, 2026 at 07:36:01PM -0700, H=2E Peter Anvin wrote: >> >diff --git a/arch/x86/kernel/process_64=2Ec b/arch/x86/kernel/process_= 64=2Ec >> >index b85e715ebb30=2E=2E248c39da9ba0 100644 >> >--- a/arch/x86/kernel/process_64=2Ec >> >+++ b/arch/x86/kernel/process_64=2Ec >> >@@ -391,16 +391,23 @@ static __always_inline void x86_pkru_load(struct= thread_struct *prev, >> > static __always_inline void x86_fsgsbase_load(struct thread_struct *p= rev, >> > struct thread_struct *next) >> > { >> >+ bool loaded_gs =3D false; >> >+ >> > if (static_cpu_has(X86_FEATURE_FSGSBASE)) { >> > /* Update the FS and GS selectors if they could have changed=2E */ >> > if (unlikely(prev->fsindex || next->fsindex)) >> > loadseg(FS, next->fsindex); >> >- if (unlikely(prev->gsindex || next->gsindex)) >> >+ >> >+ if (unlikely(prev->gsindex || next->gsindex)) { >> > loadseg(GS, next->gsindex); >> >+ loaded_gs =3D true; >> >+ } >> >=20 >> > /* Update the bases=2E */ >> > wrfsbase(next->fsbase); >> >- __wrgsbase_inactive(next->gsbase); >> >+ >> >+ if (!(cpu_feature_enabled(X86_FEATURE_LKGS) && loaded_gs)) >> >+ __wrgsbase_inactive(next->gsbase); >> > } else { >> > load_seg_legacy(prev->fsindex, prev->fsbase, >> > next->fsindex, next->fsbase, FS); >> > >> > >> >Thx=2E >> > >>=20 >> Also consider that user space might have done:=20 >>=20 >> mov gs,=2E=2E=2E >> wrgsbase =2E=2E=2E >>=20 >> So gs=2Eselector > 3 doesn't necessarily mean that the base is consiste= nt with the descriptor=2E > >Right, I want to avoid the second write to KERNEL_GS_BASE iff we have don= e >LKGS before=2E > I guess the question is why there is a "first" one=2E Logically the sequence should be LKGS first, if needed; then WRMSR(NS)=2E = LKGS can be replaced with swapgs/mov gs/swapgs on legacy=2E