Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp3908ybh; Tue, 17 Mar 2020 16:58:21 -0700 (PDT) X-Google-Smtp-Source: ADFU+vulEt7rsnqvDZ2aiMu1zyI6cuvtEpTjzHFokxopDDXDWdvDnYzsMxnkzpVkxJF2Gp8CvdEo X-Received: by 2002:a05:6830:1b6f:: with SMTP id d15mr1628511ote.285.1584489501473; Tue, 17 Mar 2020 16:58:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584489501; cv=none; d=google.com; s=arc-20160816; b=O7bteD1ksUpVsSPKzvyF58OZxHeia+B1mPVsDSxGeRJp8m93FZ2cLw0DdxO+iYCw0g 17WzW+TJffQ85pq9mTlq2I6huqxWTUKNM0uxxjU7MZjTZItA3vfsv39Is7Ubd1UI0AIm WGqy9n5llseiNCXcOHOhwoJITcOyyNQUUdbC01yBs+4/Blu92DdQdRhktxUi/EobRQ94 /ppn1QY2LzStedZfUtzlQV6qcfHPDeW/E1gORfi/mQDgVCp+x6SeX/2BZiQ24v4Ctk9l kmRivsAKvRqNIFml7XO/5RBup8df7unG1mTulT18VZDQzY4ftKcG0aQCEFI8KNCzNgfY 0b1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:ironport-sdr:ironport-sdr; bh=Uqe+6QwAmxDp90XCRqhS/A44OZzjp7cuK6LHrt6MQ7w=; b=fGucV5RE8pA6KMnsjFaNf0DoiODyu/rrHLRLNNWbgUtkCKTBSZVzptkZa6r5KwC1rA cqc1HRmxPbla6wNLcE1hqMbBlgF1kAeAoP2opg7o/2FgVjhNqM4WugKyPjuFvW75q3kJ Xbilt5/pTRAATsZR8MNHEiPaizfq/Dkbu1QX5O2Cw+AYsA+utIJ3tirvqds7YS5SMv7k fok2zbwCVAibdyuxBnnxqmuzOmJQ+g5yaul0aCVYF0OTuCf/LohEph8rk2JvBX0bl+qR c1/NxHjtbfetVkpgVguaBw0SkjAe7h2f/4FBfQCPlkJVsLhu2ghArI/8uUkSxwjbsSQN O1qw== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a19si2944495otk.60.2020.03.17.16.57.34; Tue, 17 Mar 2020 16:58:21 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726991AbgCQX5N (ORCPT + 99 others); Tue, 17 Mar 2020 19:57:13 -0400 Received: from mga04.intel.com ([192.55.52.120]:55895 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726680AbgCQX5M (ORCPT ); Tue, 17 Mar 2020 19:57:12 -0400 IronPort-SDR: ilKyHzLNizQHyUsRHx3AFzsaPZI4iBACOuO8ZH3J/GiCvZ1aHfHirTosROixOTRCTK7UTkajsC mpZ6z3T8xitA== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 Mar 2020 16:57:12 -0700 IronPort-SDR: B/zyD7SdD9qY+h0RPpxyTFvoomK+whseoGlVtsmDJCpXzWa+ayA2Y69qlgLicY6sgBUbvlm9zl v8IoZpLNvVGQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,565,1574150400"; d="scan'208";a="238041256" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.202]) by fmsmga008.fm.intel.com with ESMTP; 17 Mar 2020 16:57:11 -0700 Date: Tue, 17 Mar 2020 16:57:11 -0700 From: Sean Christopherson To: "Xing, Cedric" Cc: Nathaniel McCallum , Jarkko Sakkinen , linux-kernel@vger.kernel.org, x86@kernel.org, linux-sgx@vger.kernel.org, akpm@linux-foundation.org, dave.hansen@intel.com, Neil Horman , "Huang, Haitao" , andriy.shevchenko@linux.intel.com, tglx@linutronix.de, "Svahn, Kai" , bp@alien8.de, Josh Triplett , luto@kernel.org, kai.huang@intel.com, David Rientjes , Patrick Uiterwijk , Andy Lutomirski , Jethro Beekman , Connor Kuehl , Harald Hoyer , Lily Sturmann Subject: Re: [PATCH v28 21/22] x86/vdso: Implement a vDSO for Intel SGX enclave call Message-ID: <20200317235711.GC14566@linux.intel.com> References: <5dc2ec4bc9433f9beae824759f411c32b45d4b74.camel@linux.intel.com> <20200316225322.GJ24267@linux.intel.com> <20200316235934.GM24267@linux.intel.com> <20200317220948.GB14566@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 17, 2020 at 03:36:57PM -0700, Xing, Cedric wrote: > On 3/17/2020 3:09 PM, Sean Christopherson wrote: > >On Tue, Mar 17, 2020 at 02:40:34PM -0700, Xing, Cedric wrote: > >>Hi Nathaniel, > >> > >>I reread your email today and thought I might have misunderstood your email > >>earlier. What changes are you asking for exactly? Is that just passing @leaf > >>in %ecx rather than in %eax? If so, I wouldn't have any problem. I agree > >>with you that the resulted API would then be callable from C, even though it > >>wouldn't be able to return back to C due to tampered %rbx. But I think the > >>vDSO API can preserve %rbx too, given it is used by both EENTER and EEXIT > >>(so is unavailable for parameter passing anyway). Alternatively, the C > >>caller can setjmp() to be longjmp()'d back from within the exit handler. > > > >Yep, exactly. The other proposed change that is fairly straightforward is > >to make the save/restore of %rsp across the exit handler call relative > >instead of absolute, i.e. allow the exit handler to modify %rsp. I don't > >think this would conflict with the Intel SDK usage model? > > > >diff --git a/arch/x86/entry/vdso/vsgx_enter_enclave.S b/arch/x86/entry/vdso/vsgx_enter_enclave.S > >index 94a8e5f99961..05d54f79b557 100644 > >--- a/arch/x86/entry/vdso/vsgx_enter_enclave.S > >+++ b/arch/x86/entry/vdso/vsgx_enter_enclave.S > >@@ -139,8 +139,9 @@ SYM_FUNC_START(__vdso_sgx_enter_enclave) > > /* Pass the untrusted RSP (at exit) to the callback via %rcx. */ > > mov %rsp, %rcx > > > >- /* Save the untrusted RSP in %rbx (non-volatile register). */ > >+ /* Save the untrusted RSP offset in %rbx (non-volatile register). */ > > mov %rsp, %rbx > >+ and $0xf, %rbx > > > > /* > > * Align stack per x86_64 ABI. Note, %rsp needs to be 16-byte aligned > >@@ -161,8 +162,8 @@ SYM_FUNC_START(__vdso_sgx_enter_enclave) > > mov 0x20(%rbp), %rax > > call .Lretpoline > > > >- /* Restore %rsp to its post-exit value. */ > >- mov %rbx, %rsp > >+ /* Undo the post-exit %rsp adjustment. */ > >+ lea 0x20(%rsp,%rbx), %rsp > > > Yep. Though it looks a bit uncommon, I do think it will work. Heh, I had about the same level of confidence. I'll put together a set of patches tomorrow and post them to linux-sgx (and cc relevant parties). It'll be easier to continue the discussion with code to look at and we can stop spamming LKML for a bit :-)