Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp3973272yba; Tue, 23 Apr 2019 12:45:40 -0700 (PDT) X-Google-Smtp-Source: APXvYqy0QP/XVOjv2z4NZlsP9WMB7Jh17SNYghqojEQHMM4VFBtl9FeYSXJ2Cer+5eKxsOGDHJLP X-Received: by 2002:a62:1795:: with SMTP id 143mr28393717pfx.104.1556048740835; Tue, 23 Apr 2019 12:45:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556048740; cv=none; d=google.com; s=arc-20160816; b=yMUIAfl05yCBFeXHGWa1pjSZXTiM0zkk3WjoXCOU49XXEzyhX5ADlCGZA6CsfPMM7d MiMaiIOGkoJ7jFSK5iqcpspp7saeLWLDM+HowTiSoEHSXr6dCktBqmQ7wwyXUhKUbYze 5v/He+n3M5tTUv+8+xTeMdTHMaWBJQzeWVodSJPS8lKRmckEsQG6NKR4Xkvd31XMWKE4 QWjEggzlWFWrwR1Y0IYHJfMYVgbgvd+lIXD001E6GZ5hXZmmm1CZ6Jz6fDFX3Ww9rdTN /gbrmoTGaxMPaSjDRaCQ/kk2YU/WrjLPhtdznVlC9eeOL9efKqGolVYEb5Xw6+JjMFdR WZIg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version:dkim-signature; bh=YcuiLaNgcaVq/lgdvtW+JDu4KErW8v9Zxv1tIYocNuE=; b=wpYOuG0Yv3izAmgjeloRvZfC5NaIhLClc4VSP297lFcbXjp6H6D35VGl0s/sfqUiI2 vZQFBXCQhhosRt/Qkgtz4HCP/iPZOgE5xNEB7JB2y1GSfb0V51m5Y1gPaRFLeanyKk0Z tibVr5CU1Li/AA32bcYqVGCvHiN2nJ2ogn982mza5inHNVO2gFn9pp96t6mIYYfYgq5z Jta65o7p07urIUntTQ5R4tuiIyQj3UJ8NjsawVwxxMoBl+jbvHCig/ialryy4zK50ooj Ix2SXQqM1s8a6PQrVCGHCmKxHLF01xY2R79L+rw+Jktqor2Dgn/GTUjvz4WGpFLNMftW JFGw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=OQStFlgb; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p2si16477691plr.69.2019.04.23.12.45.25; Tue, 23 Apr 2019 12:45:40 -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=@amacapital-net.20150623.gappssmtp.com header.s=20150623 header.b=OQStFlgb; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726502AbfDWToU (ORCPT + 99 others); Tue, 23 Apr 2019 15:44:20 -0400 Received: from mail-pg1-f195.google.com ([209.85.215.195]:33478 "EHLO mail-pg1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725956AbfDWToU (ORCPT ); Tue, 23 Apr 2019 15:44:20 -0400 Received: by mail-pg1-f195.google.com with SMTP id k19so8124489pgh.0 for ; Tue, 23 Apr 2019 12:44:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amacapital-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YcuiLaNgcaVq/lgdvtW+JDu4KErW8v9Zxv1tIYocNuE=; b=OQStFlgbVKMw9CQpMOd3kSfeHxnakYhdivmi2CtBl4ekxjjMo/Ct0Oo1xbkvr6lM9s KHYcgRtAURTwDnApuJ/ph5hL3NtyoSNlHaa7Ufz9LydfvwPWr1wzw/PyTL4cL9mdjHWe d9fEpuJld64LhCfUl3FMxRwwxcRZdjmjTkam+oqnufvSuoOV+/qC+omQDxeQqwEy3SYv 8aY/Ubm9nbvrji/mDFpFUeqwlpQA4OTo3V9baHPA4+GoBMT1XVJ6PBJHEmITWctp3s5p jFcSEOAqnINPb1nt2L/u+9vslJdMq0VYjYs6fqOJ/ejYhq4R3/ucIHCnNUSlr354C54u KSrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YcuiLaNgcaVq/lgdvtW+JDu4KErW8v9Zxv1tIYocNuE=; b=WnLUOdgXp82RCimIBd4c95DWmS2FaOTypbUP2K0aIzQFJI+pQ6ARj4HKCcVAR9UnVi 3iFS+P2UXoKAyJrF+Vg3jU+L6gtx5H2iXnmeWN/NSvAtyXEdUpPCoMdwgQzYnftSukm9 Hm7dLc05KJ6l5LS6b7tgFqlVK0uHMRUUYjNJOuer4tyJESPuro9p83osLEDhyfv8ysmM lso1c0N6vNZ8PKnqmAm8zdO4RyCs8IZe4BSZQDU3qN8FYE9D6hT465epPrZBB4HqvrgT 5jMnjSmAbVH5pKLU+fYJFT8+0Q6lT/JGIgTTD0H3ACZNhsR+DFkbZRliiqWnH7WRuHEv GVOw== X-Gm-Message-State: APjAAAU7v3CdvWV0fJ9P8Qkj89nT9sqUuQzCywUnSgmtFcMVuY8p4n2e Lg0jd6Az7gbjuKB9/vFqY62F7D+bMIo= X-Received: by 2002:aa7:83d1:: with SMTP id j17mr28862063pfn.78.1556048659111; Tue, 23 Apr 2019 12:44:19 -0700 (PDT) Received: from ?IPv6:2600:1010:b06d:689:56b:56b1:bb0d:6783? ([2600:1010:b06d:689:56b:56b1:bb0d:6783]) by smtp.gmail.com with ESMTPSA id c3sm29430521pfg.88.2019.04.23.12.44.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Apr 2019 12:44:18 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: [RFC PATCH v1 2/3] x86/vdso: Modify __vdso_sgx_enter_enclave() to allow parameter passing on untrusted stack From: Andy Lutomirski X-Mailer: iPhone Mail (16E227) In-Reply-To: <20190423192654.GA12691@linux.intel.com> Date: Tue, 23 Apr 2019 12:44:16 -0700 Cc: Cedric Xing , linux-kernel@vger.kernel.org, x86@kernel.org, linux-sgx@vger.kernel.org, akpm@linux-foundation.org, Hansen@linux.intel.com, Dave , Christopherson@linux.intel.com, nhorman@redhat.com, npmccallum@redhat.com, Ayoun@linux.intel.com, Serge , Katz-zamir@linux.intel.com, Shay , Huang@linux.intel.com, Haitao , andriy.shevchenko@linux.intel.com, tglx@linutronix.de, Svahn@linux.intel.com, Kai , bp@alien8.de, josh@joshtriplett.org, luto@kernel.org, Kai , rientjes@google.com, Jarkko Sakkinen Content-Transfer-Encoding: quoted-printable Message-Id: References: <20190417103938.7762-1-jarkko.sakkinen@linux.intel.com> <20190423192654.GA12691@linux.intel.com> To: Sean Christopherson Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Apr 23, 2019, at 12:26 PM, Sean Christopherson wrote: >=20 >> On Mon, Apr 22, 2019 at 05:37:24PM -0700, Cedric Xing wrote: >> The previous __vdso_sgx_enter_enclave() requires enclaves to preserve %rs= p, >> which prohibits enclaves from allocating and passing parameters for >> untrusted function calls (aka. o-calls). >>=20 >> This patch addresses the problem above by introducing a new ABI that pres= erves >> %rbp instead of %rsp. Then __vdso_sgx_enter_enclave() can anchor its fram= e >> using %rbp so that enclaves are allowed to allocate space on the untruste= d >> stack by decrementing %rsp. Please note that the stack space allocated in= such >> way will be part of __vdso_sgx_enter_enclave()'s frame so will be freed a= fter >> __vdso_sgx_enter_enclave() returns. Therefore, __vdso_sgx_enter_enclave()= has >> been changed to take a callback function as an optional parameter, which i= f >> supplied, will be invoked upon enclave exits (both AEX (Asynchronous Encl= ave >> eXit) and normal exits), with the value of %rsp left >> off by the enclave as a parameter to the callback. >>=20 >> Here's the summary of API/ABI changes in this patch. More details could b= e >> found in arch/x86/entry/vdso/vsgx_enter_enclave.S. >> * 'struct sgx_enclave_exception' is renamed to 'struct sgx_enclave_exinfo= ' >> because it is filled upon both AEX (i.e. exceptions) and normal enclave >> exits. >> * __vdso_sgx_enter_enclave() anchors its frame using %rbp (instead of %rs= p in >> the previous implementation). >> * __vdso_sgx_enter_enclave() takes one more parameter - a callback functi= on to >> be invoked upon enclave exits. This callback is optional, and if not >> supplied, will cause __vdso_sgx_enter_enclave() to return upon enclave e= xits >> (same behavior as previous implementation). >> * The callback function is given as a parameter the value of %rsp at encl= ave >> exit to address data "pushed" by the enclave. A positive value returned b= y >> the callback will be treated as an ENCLU leaf for re-entering the enclav= e, >> while a zero or negative value will be passed through as the return >> value of __vdso_sgx_enter_enclave() to its caller. It's also safe to >> leave callback by longjmp() or by throwing a C++ exception. >>=20 >> Signed-off-by: Cedric Xing >> --- >> arch/x86/entry/vdso/vsgx_enter_enclave.S | 156 ++++++++++++++--------- >> arch/x86/include/uapi/asm/sgx.h | 14 +- >> 2 files changed, 100 insertions(+), 70 deletions(-) >>=20 >> diff --git a/arch/x86/entry/vdso/vsgx_enter_enclave.S b/arch/x86/entry/vd= so/vsgx_enter_enclave.S >> index fe0bf6671d6d..210f4366374a 100644 >> --- a/arch/x86/entry/vdso/vsgx_enter_enclave.S >> +++ b/arch/x86/entry/vdso/vsgx_enter_enclave.S >> @@ -14,88 +14,118 @@ >> .code64 >> .section .text, "ax" >>=20 >> -#ifdef SGX_KERNEL_DOC >=20 > This #ifdef and the pseudo-C code below has a functional purpose. From > the original commit: >=20 > Note, the C-like pseudocode describing the assembly routine is wrapped > in a non-existent macro instead of in a comment to trick kernel-doc into > auto-parsing the documentation and function prototype. This is a double > win as the pseudocode is intended to aid kernel developers, not userland > enclave developers. >=20 > We don't need full pseudocode, but a C-like prototype is necessary to get > the kernel-doc comment parsed correctly. That should be explained in a comment :) =E2=80=94Andy