From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A2FD5C2BB1D for ; Tue, 17 Mar 2020 00:27:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 81FA520674 for ; Tue, 17 Mar 2020 00:27:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733228AbgCQA1H (ORCPT ); Mon, 16 Mar 2020 20:27:07 -0400 Received: from mga05.intel.com ([192.55.52.43]:11938 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1733009AbgCQA1G (ORCPT ); Mon, 16 Mar 2020 20:27:06 -0400 IronPort-SDR: SWYlLZolBDWgGg27spfn+BDNr9JSrfcecYrvVdvAeQ50w98B+8VupXfi4cH5/FtfW0FYKcu8WO YhHlzfyp50OQ== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 16 Mar 2020 17:27:06 -0700 IronPort-SDR: f6fK7XCFbrqoX9QH1ubWde0FEwjXYcIVIFQIg2HLkvaCEhnvMUzkd3g7CoAam5wv6BSWBZZJRg KITRnQGJhFkA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,562,1574150400"; d="scan'208";a="390888441" Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.202]) by orsmga004.jf.intel.com with ESMTP; 16 Mar 2020 17:27:06 -0700 Date: Mon, 16 Mar 2020 17:27:06 -0700 From: Sean Christopherson To: "Xing, Cedric" Cc: Jarkko Sakkinen , Nathaniel McCallum , 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: <20200317002706.GN24267@linux.intel.com> References: <20200315012523.GC208715@linux.intel.com> <94ce05323c4de721c4a6347223885f2ad9f541af.camel@linux.intel.com> <5dc2ec4bc9433f9beae824759f411c32b45d4b74.camel@linux.intel.com> <20200316225322.GJ24267@linux.intel.com> <20200316235934.GM24267@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 Mon, Mar 16, 2020 at 05:18:14PM -0700, Xing, Cedric wrote: > On 3/16/2020 4:59 PM, Sean Christopherson wrote: > >On Mon, Mar 16, 2020 at 04:50:26PM -0700, Xing, Cedric wrote: > >>On 3/16/2020 3:53 PM, Sean Christopherson wrote: > >>>On Mon, Mar 16, 2020 at 11:38:24PM +0200, Jarkko Sakkinen wrote: > >>>>>My suggestions explicitly maintained robustness, and in fact increased > >>>>>it. If you think we've lost capability, please speak with specificity > >>>>>rather than in vague generalities. Under my suggestions we can: > >>>>>1. call the vDSO from C > >>>>>2. pass context to the handler > >>>>>3. have additional stack manipulation options in the handler > >>>>> > >>>>>The cost for this is a net 2 additional instructions. No existing > >>>>>capability is lost. > >>>> > >>>>My vague generality in this case is just that the whole design > >>>>approach so far has been to minimize the amount of wrapping to > >>>>EENTER. > >>> > >>>Yes and no. If we wanted to minimize the amount of wrapping around the > >>>vDSO's ENCLU then we wouldn't have the exit handler shenanigans in the > >>>first place. The whole process has been about balancing the wants of each > >>>use case against the overall quality of the API and code. > >>> > >>The design of this vDSO API was NOT to minimize wrapping, but to allow > >>maximal flexibility. More specifically, we strove not to restrict how info > >>was exchanged between the enclave and its host process. After all, calling > >>convention is compiler specific - i.e. the enclave could be built by a > >>different compiler (e.g. MSVC) that doesn't share the same list of CSRs as > >>the host process. Therefore, the API has been implemented to pass through > >>virtually all registers except those used by EENTER itself. Similarly, all > >>registers are passed back from enclave to the caller (or the exit handler) > >>except those used by EEXIT. %rbp is an exception because the vDSO API has to > >>anchor the stack, using either %rsp or %rbp. We picked %rbp to allow the > >>enclave to allocate space on the stack. > > > >And unless I'm missing something, using %rcx to pass @leaf would still > >satisfy the above, correct? Ditto for saving/restoring %rbx. > > > >I.e. a runtime that's designed to work with enclave's using a different > >calling convention wouldn't be able to take advantage of being able to call > >the vDSO from C, but neither would it take on any meaningful burden. > > > Not exactly. > > If called directly from C code, the caller would expect CSRs to be > preserved. Then who should preserve CSRs? It can't be the enclave because it > may not follow the same calling convention. Moreover, the enclave may run > into an exception, in which case it doesn't have the ability to restore > CSRs. So it has to be done by the vDSO API. That means CSRs will be > overwritten upon enclave exits, which violates the goal of "passing all > registers back to the caller except those used by EEXIT". IIUC, Nathaniel's use case is to run only enclaves that are compatible with Linux's calling convention and to handle enclave exceptions in the exit handler. As I qualified above, there would certainly be runtimes and use cases that would find no advantage in passing @leaf via %rcx and preserving %rbx. I'm well aware the Intel SDK falls into that bucket. But again, the cost to such runtimes is precisely one reg->reg MOV instruction.