From patchwork Thu Jul 11 04:21:30 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: "Xing, Cedric" X-Patchwork-Id: 11039263 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 8B13F138B for ; Thu, 11 Jul 2019 04:21:38 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 7A252289CF for ; Thu, 11 Jul 2019 04:21:38 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 6DF8928A34; Thu, 11 Jul 2019 04:21:38 +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=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id F156D289CF for ; Thu, 11 Jul 2019 04:21:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726510AbfGKEVh (ORCPT ); Thu, 11 Jul 2019 00:21:37 -0400 Received: from mga18.intel.com ([134.134.136.126]:22501 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726048AbfGKEVh (ORCPT ); Thu, 11 Jul 2019 00:21:37 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jul 2019 21:21:36 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.63,476,1557212400"; d="scan'208";a="186293849" Received: from hmendezc-mobl1.amr.corp.intel.com (HELO ubt18m.amr.corp.intel.com) ([10.252.143.173]) by fmsmga001.fm.intel.com with ESMTP; 10 Jul 2019 21:21:35 -0700 From: Cedric Xing To: linux-sgx@vger.kernel.org Cc: Cedric Xing , luto@kernel.org, jethro@fortanix.com, greg@enjellic.com, jarkko.sakkinen@linux.intel.com, sean.j.christopherson@intel.com Subject: [RFC PATCH v3 0/3] x86/sgx: Amend vDSO API to allow enclave/host parameter passing on untrusted stack Date: Wed, 10 Jul 2019 21:21:30 -0700 Message-Id: X-Mailer: git-send-email 2.17.1 MIME-Version: 1.0 In-Reply-To: <20190424062623.4345-1-cedric.xing@intel.com> References: <20190424062623.4345-1-cedric.xing@intel.com> Sender: linux-sgx-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-sgx@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP This patchset is based upon, and can be applied cleanly on SGX1 patch v20 (https://lkml.org/lkml/2019/4/17/344) by Jarkko Sakkinen. The current proposed __vdso_sgx_enter_enclave() requires enclaves to preserve %rsp, which prohibits enclaves from allocating space on the untrusted stack. However, there are existing enclaves (e.g. those built with current Intel SGX SDK libraries) relying on the untrusted stack for passing parameters to untrusted functions (aka. o-calls), which requires allocating space on the untrusted stack by enclaves. After all, passing data via untrusted stack is very easy to implement (by enclaves), with essentially no overhead, therefore is very suitable for exchanging data in small amounts, so could be desirable by future SGX applications as well. This patchset introduces a new ABI for __vdso_sgx_enter_enclave() to anchor its stack frame on %rbp (instead of %rsp), so as to allow enclaves to "push" onto the untrusted stack by decrementing the untrusted %rsp. And in order to service o-calls and to preserve the untrusted stack upon exceptions, the new vDSO API takes one more optional parameter - "callback", which if supplied, will be invoked on all enclave exits (including normal and asynchronous exits). Ample details regarding the new ABI have been documented as comments inside the source code located in arch/x86/entry/vsgx_enter_enclave.S Please note that there was a lengthy discussion on what is the "best" approach for passing parameters for trusted/untrusted calls. Unfortunately there's no single "best" approach that fits all use cases, hence this new ABI has been designed intentionally to accommodate varieties. Therefore, to those not interested in using the untrusted stack, whatever worked with the old ABI proposed by Sean will continue to work with this new ABI. The SGX selftest has been augmented by two new tests. One exercises the new callback interface, and serves as a simple example to showcase how to use it; while the other validates the hand-crafted CFI directives in __vdso_sgx_enter_enclave() by single-stepping through it and unwinding call stack at every instruction. Please note that the selftest CANNOT run to completion yet, as it depends on the vDSO fixup code to signal the process upon #DB/#BP inside enclaves (rather than the current behavior of branching to the handler in vDSO). Changelog: · This is version 3 of this patch series with the following changes. - Per Andy Lutomirski and Sean Christopherson, revised comments and their format in arch/x86/entry/vsgx_enter_enclave.S - Per Jarkko Sakkinen, revised the cover letter to articulate motivation and objective of this patchset. · v2 - https://patchwork.kernel.org/cover/10914161/ · v1 - https://patchwork.kernel.org/cover/10911615/ Cedric Xing (3): selftests/x86: Fixed Makefile for SGX selftest x86/vdso: Modify __vdso_sgx_enter_enclave() to allow parameter passing on untrusted stack selftests/x86: Augment SGX selftest to test new __vdso_sgx_enter_enclave() and its callback interface arch/x86/entry/vdso/vsgx_enter_enclave.S | 214 ++++++++++---- arch/x86/include/uapi/asm/sgx.h | 14 +- tools/testing/selftests/x86/Makefile | 12 +- tools/testing/selftests/x86/sgx/Makefile | 49 ++-- tools/testing/selftests/x86/sgx/main.c | 323 ++++++++++++++++++--- tools/testing/selftests/x86/sgx/sgx_call.S | 40 ++- 6 files changed, 500 insertions(+), 152 deletions(-)