From patchwork Fri Jun 16 15:25:30 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jarkko Sakkinen X-Patchwork-Id: 9792085 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id E5E9360325 for ; Fri, 16 Jun 2017 15:26:13 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id DEA8528358 for ; Fri, 16 Jun 2017 15:26:13 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id D2A6F28649; Fri, 16 Jun 2017 15:26:13 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received: from ml01.01.org (ml01.01.org [198.145.21.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 52A8128358 for ; Fri, 16 Jun 2017 15:26:13 +0000 (UTC) Received: from [127.0.0.1] (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id AFA7E21C8EFBF; Fri, 16 Jun 2017 08:24:54 -0700 (PDT) X-Original-To: intel-sgx-kernel-dev@lists.01.org Delivered-To: intel-sgx-kernel-dev@lists.01.org Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 0F6C221C8EFB9 for ; Fri, 16 Jun 2017 08:24:53 -0700 (PDT) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga105.fm.intel.com with ESMTP; 16 Jun 2017 08:26:11 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos; i="5.39,347,1493708400"; d="scan'208"; a="1183383484" Received: from gmckenzi-mobl.ger.corp.intel.com (HELO localhost) ([10.252.9.55]) by fmsmga002.fm.intel.com with ESMTP; 16 Jun 2017 08:25:48 -0700 From: Jarkko Sakkinen To: intel-sgx-kernel-dev@lists.01.org Date: Fri, 16 Jun 2017 17:25:30 +0200 Message-Id: <20170616152530.25196-1-jarkko.sakkinen@linux.intel.com> X-Mailer: git-send-email 2.11.0 Subject: [intel-sgx-kernel-dev] [PATCH] intel_sgx: update documentation with VM guest fallback X-BeenThere: intel-sgx-kernel-dev@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Project: Intel® Software Guard Extensions for Linux*: https://01.org/intel-software-guard-extensions" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: kai.huang@intel.com MIME-Version: 1.0 Errors-To: intel-sgx-kernel-dev-bounces@lists.01.org Sender: "intel-sgx-kernel-dev" X-Virus-Scanned: ClamAV using ClamSMTP I implemented fallback mechanism for the driver in the last Fall originally because I had to drop all BUG_ON() usage. The driver gracefully fallbacks from failing ENCLS in any situation. It turns out that this could happen in a VM guest even if the driver is working correctly. This patch adds to the documentation an explanation how we fallback after the host has woken up in a VM guest. Signed-off-by: Jarkko Sakkinen --- Documentation/x86/intel_sgx.rst | 38 ++++++++++++++++++++++++++------------ 1 file changed, 26 insertions(+), 12 deletions(-) diff --git a/Documentation/x86/intel_sgx.rst b/Documentation/x86/intel_sgx.rst index 71026732af61..ee7fe9487d7b 100644 --- a/Documentation/x86/intel_sgx.rst +++ b/Documentation/x86/intel_sgx.rst @@ -77,29 +77,43 @@ every time when an enclave is launched. This does not scale because for generic case because BIOS might lock down the MSRs before handover to the OS. +Debug enclaves +-------------- + +Enclave can be set as a *debug enclave* of which memory can be read or written +by using the ENCLS(EDBGRD) and ENCLS(EDBGWR) opcodes. The Intel provided launch +enclave provides them always a valid EINITTOKEN and therefore they are a low +hanging fruit way to try out SGX. + Virtualization +============== + +Launch control -------------- The values for IA32_SGXLEPUBKEYHASHn MSRs cannot be emulated for a virtual machine guest. It would easily seem feasible to hold virtual values for these -MSRs, trap EINIT and use the host LE to generate a token when a guest LE is -initialized. +MSRs, trap ENCLS(EINIT) and use the host LE to generate a token when a guest LE +is initialized. -However, looking at the pseudo code of ENCLS(EINIT) from the SDM there is -a constraint that the instruction will fail if ATTRIBUTES.EINITTOKENKEY is -set (the documentation does not tell the reason why the constraint exists -but it exists). +However, looking at the pseudo code of ENCLS(EINIT) from the SDM there is a +constraint that the instruction will fail if ATTRIBUTES.EINITTOKENKEY is set +(the documentation does not tell the reason why the constraint exists but it +exists). Thus, only when the MSRs are left unlocked before handover to the OS the setting of these MSRs can be supported for VM guests. -Debug enclaves --------------- +Suspend and resume +------------------ -Enclave can be set as a *debug enclave* of which memory can be read or written -by using the ENCLS(EDBGRD) and ENCLS(EDBGWR) opcodes. The Intel provided launch -enclave provides them always a valid EINITTOKEN and therefore they are a low -hanging fruit way to try out SGX. +If the host suspends and resumes, the enclave memory for the VM guest could +become invalid. This can make ENCLS leaf operations suddenly fail. + +The driver has a graceful fallback mechanism to manage this situation. If any of +the ENCLS leaf operations fail, the driver will fallback by kicking threads out +of the enclave, removing the TCS entries and marking enclave as invalid. After +this no new pages can be allocated for the enclave and no entry can be done. SGX uapi ========