From patchwork Thu Jan 12 10:14:07 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Kirill A. Shutemov" X-Patchwork-Id: 42351 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4e01:0:0:0:0:0 with SMTP id p1csp3801669wrt; Thu, 12 Jan 2023 02:16:52 -0800 (PST) X-Google-Smtp-Source: AMrXdXu8SWO+07Bo2YdMdKRFtCkAxb/lNVHMEfGTd/Us09vgHZbLVZ+x1uSvjl48Jz9j/Tw5DRI0 X-Received: by 2002:a17:907:9712:b0:7aa:491c:6cdf with SMTP id jg18-20020a170907971200b007aa491c6cdfmr81663616ejc.18.1673518611897; Thu, 12 Jan 2023 02:16:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673518611; cv=none; d=google.com; s=arc-20160816; b=Q1cJ6xLAvaJ2i0q3OI11z3k1GliAs/fkT1suunVYyir5QVcJg7Uu6hOyrtRpaD9PEA EsSDHrv3KXrppMWLWMS36uMtUvtAwPNaTWEw07Om5kkJfXfz9C7rmJlxj5o0XH9X81WS nkhgZxmLDxXNHCYVQunI33CPzeZcMv16tnVtBeD0CNMZNAtvj7kGBlavySQnjvBd9kXc jxB4YEJHt4oPRfrqitUwOV7Q1MBcVZf3fWVMEfkyve9aR76Hq+s2LRE8aTdetVvsSNiw 5l7Ze+1NBx9K1lQXwrL5D4oZ1guAIHhqTBmodp1uLCtjR7EFWWfkjFcRsGjSVgccuz82 WkBw== 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=HBK2+MLM21xEEDlhalF8hPP82+Z3DJVuIKn0sPTb5Kc=; b=kIMmDd1EfscxvYggd7exYTccrodTekuNqcj1MfTbr3hw8+zaLOxtSV/7nahxoJ46s9 bDLbxvm+ippZSldUHvwYMrHfbA1wajDpk9G9K4V+ZvduSDJCF1lb0srcYj7EyW8YPceW Ekwxh7gTM+7NkMFZhFcqEv4LdOY3lvVeP05azDAns5QkHW+7LefMVP+1qg9PYyJHNNzp 35voWayuOG7jOxJKOQ6IJawSVtgau3dV/Tv0iZXMs7gNr+VLACBq2lfsnse2A5kNV9P/ VVY/YM911aHWwXK8R1gdyd3PHWrr0k5O7g+FJOlagtzbat7uKmzWXN20U7aDi7GI+BaE J2Fg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=ZuovMUXY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id xf10-20020a17090731ca00b0084d42589be6si340256ejb.787.2023.01.12.02.16.26; Thu, 12 Jan 2023 02:16:51 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=ZuovMUXY; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239988AbjALKQM (ORCPT + 99 others); Thu, 12 Jan 2023 05:16:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46440 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237019AbjALKPA (ORCPT ); Thu, 12 Jan 2023 05:15:00 -0500 Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AF8DB62E7 for ; Thu, 12 Jan 2023 02:14:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1673518464; x=1705054464; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=LevyWGVkjbR3XtkwGaqhIDNbRXys+KmZlOUqinj8SNU=; b=ZuovMUXY6fnFmy0ZxxCgq8sGq4SPLSlFZSOrgn1mQYYXXlO8iflfKasJ oS985OVzy/VHlsAxmr4mdAySriRdm0V6XxT6uQZQDAw+gPfDGmtqW23qe Zf3wDgPQflyGswv/2Fmwajx8VKHHqXKyKVSwBq2L9xFedDzG7WZ95/QVy WM8m2SIotqTXcwFXYMSIQLHcAijvkvQdcESZVabRPRsKHjJf2SlsIWpam EhQBaMyaHpxZa3DyB03RErqzPvaDUkYxqUWoVk/xK+6kNjktkcEa71XDg Ai4Y2AoNf7NZja7xqR8zBOejgD57Of9RuQ5upMN+wldBIhmFGSkjETHxi Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10586"; a="324899417" X-IronPort-AV: E=Sophos;i="5.96,319,1665471600"; d="scan'208";a="324899417" Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jan 2023 02:14:24 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10586"; a="903128288" X-IronPort-AV: E=Sophos;i="5.96,319,1665471600"; d="scan'208";a="903128288" Received: from glieseu-mobl.ger.corp.intel.com (HELO box.shutemov.name) ([10.252.52.1]) by fmsmga006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Jan 2023 02:14:21 -0800 Received: by box.shutemov.name (Postfix, from userid 1000) id B9318109AF7; Thu, 12 Jan 2023 13:14:13 +0300 (+03) From: "Kirill A. Shutemov" To: Dave Hansen , Borislav Petkov , Andy Lutomirski Cc: Kuppuswamy Sathyanarayanan , Thomas Gleixner , Elena Reshetova , x86@kernel.org, linux-coco@lists.linux.dev, linux-kernel@vger.kernel.org, "Kirill A. Shutemov" Subject: [PATCHv2 7/7] x86/tdx: Disable NOTIFY_ENABLES Date: Thu, 12 Jan 2023 13:14:07 +0300 Message-Id: <20230112101407.24327-8-kirill.shutemov@linux.intel.com> X-Mailer: git-send-email 2.38.2 In-Reply-To: <20230112101407.24327-1-kirill.shutemov@linux.intel.com> References: <20230112101407.24327-1-kirill.shutemov@linux.intel.com> MIME-Version: 1.0 X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE autolearn=ham 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 X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1754811451614984180?= X-GMAIL-MSGID: =?utf-8?q?1754811451614984180?= == Background == There is a class of side-channel attacks against SGX enclaves called "SGX Step"[1]. These attacks create lots of exceptions inside of enclaves. Basically, run an in-enclave instruction, cause an exception. Over and over. There is a concern that a VMM could attack a TDX guest in the same way by causing lots of #VE's. The TDX architecture includes new countermeasures for these attacks. It basically counts the number of exceptions and can send another *special* exception once the number of VMM-induced #VE's hits a critical threshold[2]. == Problem == But, these special exceptions are independent of any action that the guest takes. They can occur anywhere that the guest executes. This includes sensitive areas like the entry code. The (non-paranoid) #VE handler is incapable of handling exceptions in these areas. == Solution == Fortunately, the special exceptions can be disabled by the guest via write to NOTIFY_ENABLES TDCS field. NOTIFY_ENABLES is disabled by default, but might be enabled by a bootloader, firmware or an earlier kernel before the current kernel runs. Disable NOTIFY_ENABLES feature explicitly and unconditionally. Any NOTIFY_ENABLES-based #VE's that occur before this point will end up in the early #VE exception handler and die due to unexpected exit reason. [1] https://github.com/jovanbulck/sgx-step [2] https://intel.github.io/ccc-linux-guest-hardening-docs/security-spec.html#safety-against-ve-in-kernel-code Signed-off-by: Kirill A. Shutemov Reviewed-by: Dave Hansen --- arch/x86/coco/tdx/tdx.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/arch/x86/coco/tdx/tdx.c b/arch/x86/coco/tdx/tdx.c index 2f4fbb7cd990..d72176a7d3a0 100644 --- a/arch/x86/coco/tdx/tdx.c +++ b/arch/x86/coco/tdx/tdx.c @@ -19,6 +19,10 @@ #define TDX_GET_VEINFO 3 #define TDX_GET_REPORT 4 #define TDX_ACCEPT_PAGE 6 +#define TDX_WR 8 + +/* TDCS fields. To be used by TDG.VM.WR and TDG.VM.RD module calls */ +#define TDCS_NOTIFY_ENABLES 0x9100000000000010 /* TDX hypercall Leaf IDs */ #define TDVMCALL_MAP_GPA 0x10001 @@ -863,6 +867,9 @@ void __init tdx_early_init(void) tdx_parse_tdinfo(&cc_mask); cc_set_mask(cc_mask); + /* Kernel does not use NOTIFY_ENABLES and does not need random #VEs */ + tdx_module_call(TDX_WR, 0, TDCS_NOTIFY_ENABLES, 0, -1ULL, NULL); + /* * All bits above GPA width are reserved and kernel treats shared bit * as flag, not as part of physical address.