From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 61DF5425CEE; Fri, 22 May 2026 16:54:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779468866; cv=none; b=LJUmkFXUTSUBV7qICB2ggDx8lCZTPKTsfOsUwK4sjIKu2XbMMIk6a99ihYOsof8XHLB9HAAtYZanAFchZKIz7AiZm6Lk3TlXRWo50D8taRShxrsrn4LZedWvCCcDTyeXoBmXBhaDM5GeqABSW4yEFT7X2A25usYXYqtXZr82FKk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779468866; c=relaxed/simple; bh=BAQBkaJbwUksCFCRdnkv0H9H5clwR/tNu5q8IVW7hvk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Nbzm6vEGyIXuKDEZM2Y56nohOzv0C1m+KtEt7HCFa9yUusjVK3R4jvoszIl4+kpHL7ztpyRZdFhSWHLU0ZULJls3UG1gLmaJt2CIqcxhx42eTk44iYZXj6vzu21M0e/9p8e14LpnYW9ze6r7S1IpkAYyyXsOAbXHNBip7Iw7czk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cE06t9+E; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="cE06t9+E" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D55341F00A3D; Fri, 22 May 2026 16:54:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779468863; bh=XcYjFp3x3nhf41eqAUeiUl4v/jsgL5K+bXT5SclsVso=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=cE06t9+EApM5cZ8hqeZBvMyquUAdwFNLwBd/pgPMD4DtDaxRpAkJ8+4KJOWVlhEN2 IqiMVVaa8tfi+hT+ceLxedykCtt3UAiLaMaRc0V336gvOaIC0UMudkSgkJDTjaQhcR cThdiKLeiXLnwNzq/JFpylLzA77g0DjhsOW+Qi386QnLKbxCGXIGcOpTlSiAlJuQ7l JTt6aCYqfEU3iKMfOz6y4LTD0Ev7qHQOIZCu0ot4ORtJ06hlqihDr4r3X/zDKcavPD ruMumM8yenvRqUSqBZ2yhtkO5jTElnGp3cL4YRSvjxeVURcbgMfQw/FwtvXIntp1K/ MeoV1KZrvsg7Q== Received: from phl-compute-06.internal (phl-compute-06.internal [10.202.2.46]) by mailfauth.phl.internal (Postfix) with ESMTP id 3A52DF4008C; Fri, 22 May 2026 12:54:22 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-06.internal (MEProxy); Fri, 22 May 2026 12:54:22 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdduhedtjedtucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkfhggtggugfgjsehtkeertddttddunecuhfhrohhmpefmihhrhihl ucfuhhhuthhsvghmrghuuceokhgrsheskhgvrhhnvghlrdhorhhgqeenucggtffrrghtth gvrhhnpeeludettdeigfefhffhhfelveeludeuleduvefhgefgueeitedtleffudegfffg gfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehkih hrihhllhdomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqudeiudduiedvieeh hedqvdekgeeggeejvdekqdhkrghspeepkhgvrhhnvghlrdhorhhgsehshhhuthgvmhhovh drnhgrmhgvpdhnsggprhgtphhtthhopeeftddpmhhouggvpehsmhhtphhouhhtpdhrtghp thhtohepuggrvhgvrdhhrghnshgvnhesihhnthgvlhdrtghomhdprhgtphhtthhopehrih gtkhdrphdrvggughgvtghomhgsvgesihhnthgvlhdrtghomhdprhgtphhtthhopehlihhn uhigqdgtohgtoheslhhishhtshdrlhhinhhugidruggvvhdprhgtphhtthhopegtlhhoph gviiesshhushgvrdguvgdprhgtphhtthhopeigkeeisehkvghrnhgvlhdrohhrghdprhgt phhtthhopegrkheslhhinhhugidrihhnthgvlhdrtghomhdprhgtphhtthhopegsphesrg hlihgvnhekrdguvgdprhgtphhtthhopegurghvvgdrhhgrnhhsvghnsehlihhnuhigrdhi nhhtvghlrdgtohhmpdhrtghpthhtohephhhprgesiiihthhorhdrtghomh X-ME-Proxy: Feedback-ID: i10464835:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 22 May 2026 12:54:21 -0400 (EDT) Date: Fri, 22 May 2026 17:54:19 +0100 From: Kiryl Shutsemau To: Dave Hansen Cc: "Edgecombe, Rick P" , "linux-coco@lists.linux.dev" , "clopez@suse.de" , "x86@kernel.org" , "ak@linux.intel.com" , "bp@alien8.de" , "dave.hansen@linux.intel.com" , "hpa@zytor.com" , "mingo@redhat.com" , "linux-kernel@vger.kernel.org" , "Luck, Tony" , "tglx@kernel.org" , "stable@vger.kernel.org" , "kvm@vger.kernel.org" Subject: Re: [PATCH] x86/tdx: Fix zero-extension for CPUID emulation Message-ID: References: <20260512213719.20974-1-clopez@suse.de> <81343db56b8df8f70a2e13a17e62c620bee36897.camel@intel.com> <7f7b8bfd-f39e-417c-991f-d224d58cb52a@intel.com> Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7f7b8bfd-f39e-417c-991f-d224d58cb52a@intel.com> On Tue, May 12, 2026 at 03:14:54PM -0700, Dave Hansen wrote: > On 5/12/26 14:48, Edgecombe, Rick P wrote: > >> - regs->ax = args.r12; > >> - regs->bx = args.r13; > >> - regs->cx = args.r14; > >> - regs->dx = args.r15; > >> + regs->ax = lower_32_bits(args.r12); > >> + regs->bx = lower_32_bits(args.r13); > >> + regs->cx = lower_32_bits(args.r14); > >> + regs->dx = lower_32_bits(args.r15); > >>   > > Can you explain the impact here? Why should the guest fixup what the VMM > > emulates? > > Oh boy. > > args.r12-15 come from the VMM, right? So the VMM Can put whatever it > wants in there. > > CPUID (the instruction) is defined to fill in eax/ebx/ecx/edx. Those are > 32-bit registers so the normal register rules apply: "32-bit operands > generate a 32-bit result, zero-extended to a 64-bit result in the > destination general-purpose register." > > So a properly-behaving CPUID implementation will always end up with the > top 32 bits empty on the four CPUID registers after a CPUID is executed. > > The VMM here obviously might be naughty and might put gunk in > args.r12/r13/r14/r15 that gets copied to ptregs->ax/bx/cx/dx which are > 'unsigned long' on 64-bit. > > The end result is that a TDX guest can use CPUID and end up having bits > set in rax/rbx/rcx/rdx that are architecturally impossible. This patch > is effectively fixing up the VMM naughtiness before the guest CPUID > instance can see it. > > Does anybody disagree with any of that? Not really. But note that the exposure is minimal as we do not issue hypercalls to VMM for anything outside of hypervisor range. I am not sure stable@ is justified, but worth fixing. -- Kiryl Shutsemau / Kirill A. Shutemov