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 ECD2819B5B1 for ; Mon, 8 Jun 2026 17:31:09 +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=1780939871; cv=none; b=Fq0Dm1YDgAO6AMRX/ozxdodWG55OqS7faEkVKgNMtxqBN3uwDm4zm00ZStAQYLfpAh0kB9uJnfLQDVGhcqS/Klr6midF2U976gWR01fvk+RtAvWOzrOQJPdMEeUAgJWZSW90yOi0/pGJ5nTzPSP0/D2NHb5UlWFdaP96xxvdH1M= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780939871; c=relaxed/simple; bh=yvnNZiLTqMyyj+99iQTCB+0/iZCx4VktKXhQu8dxSVE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=M7p9LKxMTcYc+zZRmZ8rqBPNhMNH6tLdhJB910EAXQc4ywc/GtuMtdoO4b5s46DdSQGWyRCwu0C7ja38lqlQ/st6y0AdipJjPGhLss8fQPHfswhAhrwaM3mYpgevUvBRlLpwFBfkNSSciNHgddgrD1c7GeqCOShx4dYn9xMVZxA= 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=TiY5SNnB; 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="TiY5SNnB" Received: from [10.124.223.149] ([192.55.54.41]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 658HUfxb226190 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 8 Jun 2026 10:30:49 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 658HUfxb226190 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2026052701; t=1780939850; bh=RnDX2IAjTIM8tZdjixtHLN7H13Wjvv9mk3BIpCzsVhE=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=TiY5SNnBudCH1B6HXm1VGEa+ZWnJbm26rwcBpzPIy6L80TCIlP93MA75RwojXQHIU /RlQecMQzF+yvJNbDD2jChaMiviZYgPiEW7gs/LeoOJ22wMEvFCYgp0fQi6Oe5o2cY VGk75uTBKHfTANDjx7ZGB18VUAqnigQP08gZUgIkQ8BZBAJI8eEcB40wGmAhbanAKL VA8SOqU5QfxbtkLjwTFnPGn+NxM2K/lzDhYQAC/9ixv4xyq6sjh0sz+8bzq9XleN/H HQJtOBxOq7/Qy3DacVuqyuZ7o1X1PxkoyF5d2v8d7ORoAZBljH5xWNviZY8QZfvQ7e 2hPmHt1Axvrjg== Message-ID: <87cfce38-4b5a-4014-a098-2c43e3067df1@zytor.com> Date: Mon, 8 Jun 2026 10:30:36 -0700 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Save a WRMSR GS.base? To: Borislav Petkov Cc: Andrew Cooper , x86-ML , LKML References: <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> <079850DB-52FE-4545-825F-E01E918B085D@zytor.com> <20260608143835.GAaibT6_Ypd2OzVkWD@fat_crate.local> Content-Language: en-US, sv-SE From: "H. Peter Anvin" In-Reply-To: <20260608143835.GAaibT6_Ypd2OzVkWD@fat_crate.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2026-06-08 07:38, Borislav Petkov wrote: > On Sun, Jun 07, 2026 at 11:46:34PM -0700, H. Peter Anvin wrote: >> WRxSBASE does a 64-bit write, > > When REX.W. > > The SDM text is confusing: > > "If no REX.W prefix is used, the operand size is 32 bits; the upper 32 bits of > the source register are ignored and upper 32 bits of the base address (for FS > or GS) are cleared." > > Does this last part that GS is cleared, refer to when WRGSBASE is used with no > REX.W or in general? > Without REX.W (e.g. wrgsbase %eax as opposed to wrgsbase %rax). >> but for GS it would incorrectly address the kernel GS.base. > > What does that mean? > It means that in kernel mode, it is the currently active GS.base that is written (or read with rdgsbase), that is, the one that belongs to kernel, not the user space one in what is confusingly enough called MSR_KERNEL_GS_BASE. In other words, not the one we want to task switch, *unless* you are in IDT mode and can surround it with SWAPGS. -hpa