Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp1667439ioo; Sun, 22 May 2022 23:40:38 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzl4Ln7ZyhjFRrUzB4uCHdBtH3LhEaYlJ5aKtlOo3pBkcLyDUJR/6caYMYNivDCfOC4qzHz X-Received: by 2002:a17:902:cccc:b0:15a:30ec:2f56 with SMTP id z12-20020a170902cccc00b0015a30ec2f56mr21879821ple.169.1653288038730; Sun, 22 May 2022 23:40:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653288038; cv=none; d=google.com; s=arc-20160816; b=F8uAWW3V1FB+lJb//puqM2hdo89dBo7AFV81BzKrwHpqg3iaxvz9/xUU571f9NPmZQ Yk+zNUoNVdCzRL6fnAa0YnjQVJ3Jy17mJmEYqGp3jeh6lCCIrznQGMG9OXjHg8Ik/u2w cH0Iz1y/T5A9aKZNRpL9G63Y4R27upyd4YIB21GOX5bLfwdQoqcgtKfpoU6xDRKTbtYa SdU5FiRm28KA3KVDLtpRimYpVh1o2nFIGHH25MTZmpwZ+A5MJwCLOQbik391CATB1cf0 2mkU8CslWfmSrPdrbEC9RK+/76xax0zkZJCxSe/HH4jxrBM0CCZQRyYM+lAi31Yj/Rhx sraw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=kyhqt6ABCaDHLcuFNN7OVWH093RgfDuPkRTljiVuqq0=; b=K+Zxpwp49BJidT9b7PtceIHIUZ8aZ+F2cqrjgPv5RCUcOMrTQCiHIf0haYWE8/haey sUjSaWtSD9Ij3U4PbSLMAchlRLoV/706yvBJ8uCBlZrNH3cpd0K+fgy1gqy3GgypJncs U5OeO5Ai5A1ynSSHo5RjzKr8mNLgjSqvV2+ya0kUJ7BCpZTCXeupxH+pSU2bODnoLpmo C3woWT9TWrbkPmeNDOVQpo1QzG+zUkdTphi/bn1zv5xKBKz1HbT6XsVjdDIWI4l0YzMI syVaY4Vo3jnZOZZiePjgwJ7fceIhpVmlCq/GVwWIbR1SEGcb86ap49+g3XKb8TS7CGqY X0Tw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=CIrkJvGW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id r3-20020a655083000000b003f9d1bff387si9922518pgp.475.2022.05.22.23.40.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 22 May 2022 23:40:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=CIrkJvGW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 498C76444; Sun, 22 May 2022 23:13:39 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242539AbiETDNv (ORCPT + 99 others); Thu, 19 May 2022 23:13:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45994 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345073AbiETDNj (ORCPT ); Thu, 19 May 2022 23:13:39 -0400 Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2489A149D9D for ; Thu, 19 May 2022 20:13:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1653016418; x=1684552418; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=zI9dty8xwA0hQXIR/uJZISyrrrAzLIt9y6FokLyHGTc=; b=CIrkJvGW9pDBXCkwe0o2UUVPTHk72j62anI2x99d+Ljbbpq3pxfoZAQp Av22iGSFun5UC+5j86G5yKKC9l4i64zDmlXpxeSxF42o/3DUiWLNujLy8 x0XoIK9q9V1phhHESZMaOyAetB55yUQ8O9yGAqnjBoHpfwYILppzwtwH8 5JeeUS1Qw/6PNODVHgbKFArTWR4eX/NEj33xyyz3m3xWUB0WekZNKgbQg p3up7N1BY7+T9PoAkhXwLqg+cnKCQII42YJ5qxEJPe50PxPLv21AVMKq0 oLjkUEnnsoII+qhWTDxQi+qri02weQMZk2pX8E0tNrfY5cejlMiLdhl3Y A==; X-IronPort-AV: E=McAfee;i="6400,9594,10352"; a="335517346" X-IronPort-AV: E=Sophos;i="5.91,238,1647327600"; d="scan'208";a="335517346" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 May 2022 20:13:28 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.91,238,1647327600"; d="scan'208";a="674404235" Received: from black.fi.intel.com ([10.237.72.28]) by fmsmga002.fm.intel.com with ESMTP; 19 May 2022 20:13:24 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 05CAA27D; Fri, 20 May 2022 06:13:25 +0300 (EEST) From: "Kirill A. Shutemov" To: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@intel.com, luto@kernel.org, peterz@infradead.org Cc: ak@linux.intel.com, dan.j.williams@intel.com, david@redhat.com, hpa@zytor.com, linux-kernel@vger.kernel.org, sathyanarayanan.kuppuswamy@linux.intel.com, seanjc@google.com, thomas.lendacky@amd.com, x86@kernel.org, "Kirill A. Shutemov" Subject: [PATCHv2 3/3] x86/tdx: Handle load_unaligned_zeropad() page-cross to a shared page Date: Fri, 20 May 2022 06:13:16 +0300 Message-Id: <20220520031316.47722-4-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220520031316.47722-1-kirill.shutemov@linux.intel.com> References: <20220520031316.47722-1-kirill.shutemov@linux.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org load_unaligned_zeropad() can lead to unwanted loads across page boundaries. The unwanted loads are typically harmless. But, they might be made to totally unrelated or even unmapped memory. load_unaligned_zeropad() relies on exception fixup (#PF, #GP and now #VE) to recover from these unwanted loads. In TDX guests, the second page can be shared page and VMM may configure it to trigger #VE. Kernel assumes that #VE on a shared page is MMIO access and tries to decode instruction to handle it. In case of load_unaligned_zeropad() it may result in confusion as it is not MMIO access. Check fixup table before trying to handle MMIO. The issue was discovered by analysis. It was not triggered during the testing. Signed-off-by: Kirill A. Shutemov --- arch/x86/coco/tdx/tdx.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c index 010dc229096a..1a1c8a92cfa5 100644 --- a/arch/x86/coco/tdx/tdx.c +++ b/arch/x86/coco/tdx/tdx.c @@ -11,6 +11,8 @@ #include #include #include +#include +#include /* TDX module Call Leaf IDs */ #define TDX_GET_INFO 1 @@ -299,6 +301,24 @@ static int handle_mmio(struct pt_regs *regs, struct ve_info *ve) if (WARN_ON_ONCE(user_mode(regs))) return -EFAULT; + /* + * load_unaligned_zeropad() relies on exception fixups in case of the + * word being a page-crosser and the second page is not accessible. + * + * In TDX guests, the second page can be shared page and VMM may + * configure it to trigger #VE. + * + * Kernel assumes that #VE on a shared page is MMIO access and tries to + * decode instruction to handle it. In case of load_unaligned_zeropad() + * it may result in confusion as it is not MMIO access. + * + * Check fixup table before trying to handle MMIO. + */ + if (fixup_exception(regs, X86_TRAP_VE, 0, ve->gla)) { + /* regs->ip is adjusted by fixup_exception() */ + return 0; + } + if (copy_from_kernel_nofault(buffer, (void *)regs->ip, MAX_INSN_SIZE)) return -EFAULT; -- 2.35.1