From nobody Mon Jun 8 18:55:23 2026 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 E988C13C918; Wed, 27 May 2026 12:06:03 +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=1779883565; cv=none; b=jZnmnJVRtbJs9wU7WNxpEwChuuT3InF4LbieVRzIDmlKrmgcTttPhKshwwxvrSRi4XHpILOOmRJ99B/UxU1SC0Cb9RPb1UKfCh7IAh3zghuW1C5ZLRxEJpe63dbu7Ydc3DzZGnURsrYHSl2ApD+/Zisqv9GnSYYPxN/wcsFHDGg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779883565; c=relaxed/simple; bh=5W01sVx2RIds1DAOkxhzGj9ZtpdsFUHRR8oVnYx2nJs=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=t4hwWvIzb+PfC5BdeW8woKoLG1V/fDuoqYlG7oIburF2yIpyLv7+cJuLWcUng0KDW66pF6dvTmC3AohS+uPT917XYcKj+P1ErY3n2V4Pn9/AMVA1g9rZhSdVDNZucHfaeLvX/JB3wZY4eZQfD5Orf71UJgcHGt/jEu3FkeITFx0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=oK8AU559; 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="oK8AU559" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 06A891F000E9; Wed, 27 May 2026 12:06:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779883563; bh=dYvl/3K29ZV0cu6YhcZ12nwDPuy1zRO0Zwwz9harlvI=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=oK8AU559BaLR2fPxyVi7243iqoyERX+Ugey2BDdJscf12Vqg5eAn/pA48SUXxIAsn QmkQGsfDddmcxtKNxK8vmRnIDruyd8OC/0DEiaTSyRnijOyxk1qNW2JYCqQ3MjESFA ZcalzM9xWVxYuQHnbj3rxhjenPkPSv2Rx6GNqI153k8n5js+3bFdtP8ezEkhv2wGkK lTGeRKB1QENiQPpB/aNSRoIQiZ2VL061rDm3DZ27OSRJ8kfpjBqEqlgAfql3SLIw59 Pw7PyyPDXZa57Buw13sguImfvo7/uRAJIkbJiCdhi8QF5N8VStxarQV6BTK1dOS2j0 ldVux0BuBeXGw== Received: from phl-compute-05.internal (phl-compute-05.internal [10.202.2.45]) by mailfauth.phl.internal (Postfix) with ESMTP id 660ADF40092; Wed, 27 May 2026 08:06:02 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-05.internal (MEProxy); Wed, 27 May 2026 08:06:02 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTGqAdtnwb61wYan5C4OJsoWLkQNYl2+q5bhbZ8696FiUgmZzm685bBBUbynyEgwk9 LCDvc8MDP6PRosY/0LosT3Qdb0dk7uwQzgHaQellK3fcQWXXqX07suu6SzIMUDibK4jWkW iOAnXeDPHCbZrTopbRqvNqcS8TJoPKroKLjoTh0vQcgBEa67F2kTYv2fZUhOC9BS3QxCde qrmrfeOswU9Av2XVPIeZlRLWQ/r8fxk5RD4wN5ziq7iwXH+fBtu+wn+B2xVy9yCrzPuhAm W46wVvBf0oF9Jh2+ecSuLnfJtZOU6eoHRXFan8ENohXk0lRn/Dg/NXlu0lNK26nvI9MPie ibQh815KzENS6fVWW0CZSI2U190QERIn3/cVZlQsx4AaHT8h4L9yc+AyCkvpwgQvXy8gf4 482xb2HXFScobWwq5W0/Mj/ggSwRq2cDC/Uf9oPOIQZHCMJGRvLLRRksZKihaNuC/ZfvoT VmlNgr6Cm9pv/QJWW8Y/AkQVxb2EQcT3Loc8FHnpo3+b3/JNLSwtnj0SXEU+A4Etk2nUSy CkIC+zgQmlRLVR3KmNXXUAn4IA7LxqVtky20UrTvE6zt5gE77mHbuZPeX9jr8JmPXA9QeV VjdZyF3NOR2wda9SmRIqbk8QEZOxFqK3TFd+I/TJjD/hip9ekvvjhYP4HPMg X-ME-Proxy: Feedback-ID: i10464835:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 27 May 2026 08:06:00 -0400 (EDT) From: "Kiryl Shutsemau (Meta)" To: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org Cc: "H . Peter Anvin" , Rick Edgecombe , Kuppuswamy Sathyanarayanan , Kai Huang , Sean Christopherson , Borys Tsyrulnikov , linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev, kvm@vger.kernel.org, stable@vger.kernel.org, "Kiryl Shutsemau (Meta)" Subject: [PATCH v3 1/2] x86/tdx: Fix off-by-one in port I/O handling Date: Wed, 27 May 2026 13:05:43 +0100 Message-ID: <20260527120544.2903923-2-kas@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260527120544.2903923-1-kas@kernel.org> References: <20260527120544.2903923-1-kas@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" handle_in() and handle_out() in arch/x86/coco/tdx/tdx.c use: u64 mask =3D GENMASK(BITS_PER_BYTE * size, 0); GENMASK(h, l) includes bit h. For size=3D1 (INB), this produces GENMASK(8, 0) =3D 0x1FF (9 bits) instead of GENMASK(7, 0) =3D 0xFF (8 bits). The mask is one bit too wide for all I/O sizes. Fix the mask calculation. Fixes: 03149948832a ("x86/tdx: Port I/O: Add runtime hypercalls") Reported-by: Borys Tsyrulnikov Link: https://lore.kernel.org/all/CAKw_Dz96rfSQc6Rn+9QBcUFHhmkK+9zu+P=3Dbxo= wfZwxrATCBRg@mail.gmail.com/ Signed-off-by: Kiryl Shutsemau (Meta) Reviewed-by: Kai Huang Reviewed-by: Kuppuswamy Sathyanarayanan Cc: stable@vger.kernel.org Reviewed-by: Rick Edgecombe --- arch/x86/coco/tdx/tdx.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c index 186915a17c50..65119362f9a2 100644 --- a/arch/x86/coco/tdx/tdx.c +++ b/arch/x86/coco/tdx/tdx.c @@ -693,7 +693,7 @@ static bool handle_in(struct pt_regs *regs, int size, i= nt port) .r13 =3D PORT_READ, .r14 =3D port, }; - u64 mask =3D GENMASK(BITS_PER_BYTE * size, 0); + u64 mask =3D GENMASK(BITS_PER_BYTE * size - 1, 0); bool success; =20 /* @@ -713,7 +713,7 @@ static bool handle_in(struct pt_regs *regs, int size, i= nt port) =20 static bool handle_out(struct pt_regs *regs, int size, int port) { - u64 mask =3D GENMASK(BITS_PER_BYTE * size, 0); + u64 mask =3D GENMASK(BITS_PER_BYTE * size - 1, 0); =20 /* * Emulate the I/O write via hypercall. More info about ABI can be found --=20 2.54.0 From nobody Mon Jun 8 18:55:23 2026 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 4FD902F7F12; Wed, 27 May 2026 12:06:12 +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=1779883573; cv=none; b=n7b4Y9bEYm0Huvl7lDuQ7PbWHeplGyOHwSeRGca9REfUcI9DyeKmkSWRczpVjv2ZEIWcMz/7mmonD2Myu+IMY2xAswnHiPBH26Cge0TnhcPgtEWbaIcXwPpYkrrr8QC16b7d2IxGT8PV6RqfFiX/AlT1iNzVsF3nqb0dugaaDAk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779883573; c=relaxed/simple; bh=aF0h8kQ9uMPETYt1a8ckP41P49YvE8igulEOCImHDsA=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=d9vnzTFPrsp/fIz7ZHbSv0yCxfZ9eO/lJjJX+KjnqVeJv1FUmZElpYQeL7MUxSYFUdIPLnf8CtLKlJkMgjDNYJRQuXD2pBrBYZ4ehJUr36uMBufc/ep18xaHv9niHMVtZLxMmdI0XCGN08zNo2JR6GvFdG4KRVYU+Op/B36/QUc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ffRiJDq9; 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="ffRiJDq9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8D9911F00A3D; Wed, 27 May 2026 12:06:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779883572; bh=vBlUsD0hHthgF360A8DY/Gk0Y0irC42OCpMGO8T7fdw=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=ffRiJDq9USTau7HZ9R44yi6HQVLXKBoFzxkogQnZDXP11cFkbe95QlxAApZXrfD7y O/Y+G/qjRSh49sl1CwnU1Q+VnoV+DSmAYkBN6OgCyMRP1vrdQqhyLIcY3haPcMCHFD u2fWN/qBIMs8dKLxCvATgEtSeOZCkqfGhs6gQZbu9c0uIZ/q8VG0XKyj7N9WtERxwM uFzuixwGiRfzRSs0+rpjvNXC58Yg7LeySctP74WzzI1jG1IxWPU2aKVd/fDFFuiDUw P50FsjahUGlmVmifdXZQN4lBscDD3nvifreHxT1s0tapOK+ROPcPvBUBCYuL3bVrbV Ggxv4C4Kro25w== Received: from phl-compute-04.internal (phl-compute-04.internal [10.202.2.44]) by mailfauth.phl.internal (Postfix) with ESMTP id EABFCF40085; Wed, 27 May 2026 08:06:10 -0400 (EDT) Received: from phl-frontend-04 ([10.202.2.163]) by phl-compute-04.internal (MEProxy); Wed, 27 May 2026 08:06:10 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: dmFkZTGqAdtnwb61wYan5C4OJsoWLkQNYl2+q5bhbZ8696FiUgmZzm685bBBUbynyEgwk9 LCDvc8MDP6PRosY/0LosT3Qdb0dk7uwQzgHaQellK3fcQWXXqX07suu6SzIMUDibK4jWkW iOAnXeDPHCbZrTopbRqvNqcS8TJoPKroKLjoTh0vQcgBEa67F2kTYv2fZUhOC9BS3QxCde qrmrfeOswU9Av2XVPIeZlRLWQ/r8fxk5RD4wN5ziq7iwXH+fBtu+wn+B2xVy9yCrzPuhAm W46wVvBf0oF9Jh2+ecSuLnfJtZOU6eoHRXFan8ENohXk0lRn/Dg/NXlu0lNK26nvI9MPnx 8gWQGEu+TZWo/OqSOyKq745PLDp4WCL9eoQ9MQFXxiXM9Jwk+Lqg+YnTB5jBafYvdYPVwF MmcYwBysIbqLmXUhUm/gKifsk3D6WXOaTpug9HwGXLTEzdMPjlbnCEPMl9b/lNcYgxW71w njgasKrJlhA2+kgPMjZCJ7xB7qja+uORE6dsQqiR5hoO2j5uaDzxrb1AylfB7WCiL/3TF+ +IGUtgTG561UuC0I6LVD22DefHkJiA9zIV/5pFThYNsyBuE+LxMYutYOxTIjsEL/itGYOz cfIJJkWroTCRv33XJv4e0vCFvcc6vUIicjrWTuckm03ED9OYVjIc0z2LgVbA X-ME-Proxy: Feedback-ID: i10464835:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 27 May 2026 08:06:09 -0400 (EDT) From: "Kiryl Shutsemau (Meta)" To: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org Cc: "H . Peter Anvin" , Rick Edgecombe , Kuppuswamy Sathyanarayanan , Kai Huang , Sean Christopherson , Borys Tsyrulnikov , linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev, kvm@vger.kernel.org, stable@vger.kernel.org, "Kiryl Shutsemau (Meta)" Subject: [PATCH v3 2/2] x86/tdx: Fix zero-extension for 32-bit port I/O Date: Wed, 27 May 2026 13:05:44 +0100 Message-ID: <20260527120544.2903923-3-kas@kernel.org> X-Mailer: git-send-email 2.54.0 In-Reply-To: <20260527120544.2903923-1-kas@kernel.org> References: <20260527120544.2903923-1-kas@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" According to x86 architecture rules, 32-bit operations zero-extend the result to 64 bits. The current implementation of handle_in() only masks the lower 32 bits, which preserves the upper 32 bits of RAX when a 32-bit port IN instruction is emulated. Update handle_in() to zero out the entire RAX register when the I/O size is 4 bytes to ensure correct zero-extension. For smaller sizes (1 or 2 bytes), continue to preserve the unaffected upper bits. Fixes: 03149948832a ("x86/tdx: Port I/O: Add runtime hypercalls") Reported-by: Borys Tsyrulnikov Link: https://lore.kernel.org/all/CAKw_Dz96rfSQc6Rn+9QBcUFHhmkK+9zu+P=3Dbxo= wfZwxrATCBRg@mail.gmail.com/ Signed-off-by: Kiryl Shutsemau (Meta) Reviewed-by: Kai Huang Reviewed-by: Kuppuswamy Sathyanarayanan Cc: stable@vger.kernel.org --- arch/x86/coco/tdx/tdx.c | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c index 65119362f9a2..58feca419326 100644 --- a/arch/x86/coco/tdx/tdx.c +++ b/arch/x86/coco/tdx/tdx.c @@ -703,8 +703,25 @@ static bool handle_in(struct pt_regs *regs, int size, = int port) */ success =3D !__tdx_hypercall(&args); =20 - /* Update part of the register affected by the emulated instruction */ - regs->ax &=3D ~mask; + /* + * IN writes the result into a sub-register of RAX. Only the + * 32-bit form zero-extends; the smaller forms leave the upper + * bits untouched: + * + * insn dest size bits written bits preserved + * inb AL 1 RAX[ 7: 0] RAX[63: 8] + * inw AX 2 RAX[15: 0] RAX[63:16] + * inl EAX 4 RAX[63: 0] (none, zero-extended) + * + * 'mask' only covers the low 'size' bytes, which is exactly the + * range affected for size 1 and 2. For size 4 the write also + * clears RAX[63:32], so widen the clear-mask. + */ + if (size =3D=3D 4) + regs->ax =3D 0; + else + regs->ax &=3D ~mask; + if (success) regs->ax |=3D args.r11 & mask; =20 --=20 2.54.0