Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp836436img; Wed, 20 Mar 2019 11:55:34 -0700 (PDT) X-Google-Smtp-Source: APXvYqwKqpuVz49oAvbwZyMFJ8R0VfVUTL5XBH7iS59r4U3TL1OowAFtgAKVnMP9oaIpdymhcUAw X-Received: by 2002:a63:f541:: with SMTP id e1mr8794535pgk.388.1553108134154; Wed, 20 Mar 2019 11:55:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553108134; cv=none; d=google.com; s=arc-20160816; b=gQJ0A37ptdOPA8WMllBBW9iLkMh3l0kR4p7kq/UBTPU4ZBlVi2avntLsUTK+1VBj07 OmUpBaVrK/hLsKzlzJL0GmbX3ewrCoBnZX+t4k/xnYGZK94o+hTbr9e28VnhwCrXRf3G 4bFYS6weNA0PHd1unr3q97kYGnaNoK+DV/aSFkLOo5KT6yGqABXwSRovw88FwPERLh9d KBb3uz2T4073uj45jdWQW+JqQP4Z1vd4frtGBW8nEVkEvpcU+NmI8aQyL0KzTeum25Re ZYS/N7ko5LJkqALzOxy5hXvseTWBDNvVCWXzwUaovoQ7+o+xwv/+nKyPnxVAbp+KO/0T TH/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=+EvT1kpQPHd6bop3IS9EHYh9NhSYaOjlp6cn/3ztMkg=; b=OJ6tkgPiLMU3ibTpvT4OjVqaB3Lv2Zu3M7WV/pvkQuo2ZWCS30ZdQt1KQriX30sPi/ HrASOk2S/x6O47Idj75zn4MWnh13xWH92OEbf1Z0Ahd34im4KjyXvuU00xBuhTKBqAtw +TVeoexA/plS1asfnXpQHQU4RfIFqaJ8gsnHhg8j4YAWQFBn0bTgL81aG5UfxZIPjmxm K/lgL7WKbLS+Mpc7PsTF0HSDmwany91KGWzw7qIf0ogjZdjeH/uB/TiC6yyyX9b5P+Nx fTGIR4ulU7wKxA4w2dPRX3WdWPs6GuxVT0k+DgNHbKJ+NuS4FM9bGGS3cVXwE1zNe0/0 PRuA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="0coyyM/R"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i9si2177842pgs.296.2019.03.20.11.55.19; Wed, 20 Mar 2019 11:55:34 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b="0coyyM/R"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727737AbfCTSwk (ORCPT + 99 others); Wed, 20 Mar 2019 14:52:40 -0400 Received: from mail.kernel.org ([198.145.29.99]:41470 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727381AbfCTSwj (ORCPT ); Wed, 20 Mar 2019 14:52:39 -0400 Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 0CAF62146E for ; Wed, 20 Mar 2019 18:52:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1553107958; bh=HUxD4zz8Zf+WY2iSBbRgjfg2I0iw9IDkAFSzHi5UwbM=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=0coyyM/RhxAfI7QyrQoNtZcSaFX+1PKfm8ZtUTnCUTbpoeWM+5zvMmhsCx1J5+TCC lFqIVy++YNJNaUWAJCaS2JDQqHvDnnyqfAtkCXmBUh4b86ovIQFdKV0hHo2YN0xG9J PClAxccVOq0TdIE13GtfH7QhDQG59xdr4qx+3gdM= Received: by mail-wr1-f44.google.com with SMTP id g12so3986162wrm.5 for ; Wed, 20 Mar 2019 11:52:37 -0700 (PDT) X-Gm-Message-State: APjAAAV4tLqh3dyGt/EHsrdRla/gtTJsB2HcUqpW71QHIV9plJB2ri3p Tu8Aq/Tq5HYwJQ3Vw8qO273G1++yg+0T+7tMKkQ53A== X-Received: by 2002:adf:e743:: with SMTP id c3mr9313755wrn.330.1553107956638; Wed, 20 Mar 2019 11:52:36 -0700 (PDT) MIME-Version: 1.0 References: <20190320162119.4469-1-jarkko.sakkinen@linux.intel.com> <20190320162119.4469-25-jarkko.sakkinen@linux.intel.com> <960B34DE67B9E140824F1DCDEC400C0F4E85C484@ORSMSX116.amr.corp.intel.com> In-Reply-To: <960B34DE67B9E140824F1DCDEC400C0F4E85C484@ORSMSX116.amr.corp.intel.com> From: Andy Lutomirski Date: Wed, 20 Mar 2019 11:52:25 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v19,RESEND 24/27] x86/vdso: Add __vdso_sgx_enter_enclave() to wrap SGX enclave transitions To: "Xing, Cedric" Cc: Jarkko Sakkinen , "linux-kernel@vger.kernel.org" , "x86@kernel.org" , "linux-sgx@vger.kernel.org" , "akpm@linux-foundation.org" , "Hansen, Dave" , "Christopherson, Sean J" , "nhorman@redhat.com" , "npmccallum@redhat.com" , "Ayoun, Serge" , "Katz-zamir, Shay" , "Huang, Haitao" , "andriy.shevchenko@linux.intel.com" , "tglx@linutronix.de" , "Svahn, Kai" , "bp@alien8.de" , "josh@joshtriplett.org" , "luto@kernel.org" , "Huang, Kai" , "rientjes@google.com" , Dave Hansen , Haitao Huang , Jethro Beekman , "Dr . Greg Wettstein" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 20, 2019 at 11:30 AM Xing, Cedric wrote= : > > > +/** > > + * __vdso_sgx_enter_enclave() - Enter an SGX enclave > > + * > > + * %eax: ENCLU leaf, must be EENTER or ERESUME > > + * %rbx: TCS, must be non-NULL > > + * %rcx: Optional pointer to 'struct sgx_enclave_exception' > > + * > > + * Return: > > + * 0 on a clean entry/exit to/from the enclave > > + * -EINVAL if ENCLU leaf is not allowed or if TCS is NULL > > + * -EFAULT if ENCLU or the enclave faults > > + * > > + * Note that __vdso_sgx_enter_enclave() is not compliant with the x86- > > 64 ABI. > > + * All registers except RSP must be treated as volatile from the > > +caller's > > + * perspective, including but not limited to GPRs, EFLAGS.DF, MXCSR, > > FCW, etc... > > + * Conversely, the enclave being run must preserve the untrusted RSP > > and stack. > > By requiring preservation of RSP at both AEX and EEXIT, this precludes th= e possibility of using the untrusted stack as temporary storage by enclaves= . While that looks reasonable at first glance, I'm afraid it isn't the case= in reality. The untrusted stack is inarguably the most convenient way for = data exchange between an enclave and its enclosing process, and is in fact = being used for that purpose by almost all existing enclaves to date. Given = the expectation that this API will be used by all future SGX application, i= t looks unwise to ban the most convenient and commonly used approach for da= ta exchange. I'm going to go out on a limb and say that this is a good thing. Using the untrusted stack as a way to exchange data is very convenient, but that doesn't mean it's a good idea. Here are some problems it causes: - It prevents using a normal function to wrap enclave entry (as we're seeing with this patch set). - It makes quite a few unfortunate assumptions about the layout of the untrusted stack. It assumes that the untrusted stack is arbitrarily expandable, which is entirely untrue in languages like Go. It assumes that the untrusted stack isn't further constrained by various CFI mechanisms (e.g. CET), and, as of last time I checked, the interaction between CET and SGX was still not specified. It also assumes that the untrusted stack doesn't have ABI-imposed layout restrictions related to unwinding, and, as far as I know, this means that current enclaves with current enclave runtimes can interact quite poorly with debuggers, exception handling, and various crash dumping technologies. - It will make it quite unpleasant to call into an enclave in a coroutine depending on how the host untrusted runtime implements coroutines. So I think it's a *good* thing if the effect is to make enclave SDKs change their memory management so that untrusted buffers are explicitly supplied by the host runtime. Honestly, I would have much preferred if the architecture did not give the enclave access to RSP and RBP at all. (And, for that matter, RIP.)