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.5 required=3.0 tests=MAILING_LIST_MULTI,SPF_PASS, USER_AGENT_MUTT autolearn=ham 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 ADE5DC43387 for ; Thu, 20 Dec 2018 13:12:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 83EC6217D8 for ; Thu, 20 Dec 2018 13:12:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731797AbeLTNMW (ORCPT ); Thu, 20 Dec 2018 08:12:22 -0500 Received: from mga06.intel.com ([134.134.136.31]:30973 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730884AbeLTNMV (ORCPT ); Thu, 20 Dec 2018 08:12:21 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Dec 2018 05:12:21 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,377,1539673200"; d="scan'208";a="102148596" Received: from unknown (HELO localhost) ([10.249.254.232]) by orsmga006.jf.intel.com with ESMTP; 20 Dec 2018 05:12:14 -0800 Date: Thu, 20 Dec 2018 15:12:13 +0200 From: Jarkko Sakkinen To: Andy Lutomirski Cc: Sean Christopherson , Jethro Beekman , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "x86@kernel.org" , Dave Hansen , Peter Zijlstra , "H. Peter Anvin" , "linux-kernel@vger.kernel.org" , "linux-sgx@vger.kernel.org" , Josh Triplett , Haitao Huang , "Dr . Greg Wettstein" Subject: Re: x86/sgx: uapi change proposal Message-ID: <20181220131213.GA4848@linux.intel.com> References: <20181214215729.4221-1-sean.j.christopherson@intel.com> <7706b2aa71312e1f0009958bcab24e1e9d8d1237.camel@linux.intel.com> <598cd050-f0b5-d18c-96a0-915f02525e3e@fortanix.com> <20181219091148.GA5121@linux.intel.com> <613c6814-4e71-38e5-444a-545f0e286df8@fortanix.com> <20181219144515.GA30909@linux.intel.com> <20181220103204.GB26410@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181220103204.GB26410@linux.intel.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-sgx-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-sgx@vger.kernel.org On Thu, Dec 20, 2018 at 12:32:04PM +0200, Jarkko Sakkinen wrote: > On Wed, Dec 19, 2018 at 06:58:48PM -0800, Andy Lutomirski wrote: > > Can one of you explain why SGX_ENCLAVE_CREATE is better than just > > opening a new instance of /dev/sgx for each encalve? > > I think that fits better to the SCM_RIGHTS scenario i.e. you could send > the enclav to a process that does not have necessarily have rights to > /dev/sgx. Gives more robust environment to configure SGX. My only open for the implementation is where to swap? If it is a VMA, whose VMA? Please share your views here. Not a blocker for me to work on the implementation, though. I'll use a private shmem file up until there is a better option. This ioctl API discussion is kind of meaningless for me ATM because it does not have that much effect to the internals even if it wouldn't be perfect in v19. Very trival to change. /Jarkko