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=HEADER_FROM_DIFFERENT_DOMAINS, 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 CABD7C43387 for ; Wed, 19 Dec 2018 09:11:59 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9FAA320874 for ; Wed, 19 Dec 2018 09:11:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727997AbeLSJL7 (ORCPT ); Wed, 19 Dec 2018 04:11:59 -0500 Received: from mga18.intel.com ([134.134.136.126]:10181 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727927AbeLSJL7 (ORCPT ); Wed, 19 Dec 2018 04:11:59 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Dec 2018 01:11:58 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,372,1539673200"; d="scan'208";a="101823214" Received: from quwen-mobl.ccr.corp.intel.com (HELO localhost) ([10.249.254.215]) by orsmga006.jf.intel.com with ESMTP; 19 Dec 2018 01:11:49 -0800 Date: Wed, 19 Dec 2018 11:11:48 +0200 From: Jarkko Sakkinen To: Jethro Beekman Cc: Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "x86@kernel.org" , Dave Hansen , Peter Zijlstra , "sean.j.christopherson@intel.com" , "H. Peter Anvin" , "linux-kernel@vger.kernel.org" , "linux-sgx@vger.kernel.org" , Andy Lutomirski , Josh Triplett , Haitao Huang , "Dr . Greg Wettstein" Subject: Re: x86/sgx: uapi change proposal Message-ID: <20181219091148.GA5121@linux.intel.com> References: <20181214215729.4221-1-sean.j.christopherson@intel.com> <7706b2aa71312e1f0009958bcab24e1e9d8d1237.camel@linux.intel.com> <598cd050-f0b5-d18c-96a0-915f02525e3e@fortanix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <598cd050-f0b5-d18c-96a0-915f02525e3e@fortanix.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 Wed, Dec 19, 2018 at 08:41:12AM +0000, Jethro Beekman wrote: > One weird thing is the departure from the normal mmap behavior that the > memory mapping persists even if the original fd is closed. (See man mmap: > "closing the file descriptor does not unmap the region.") The mmapped region and enclave would be completely disjoint to start with. The enclave driver code would assume that an enclave VMA exists when it maps enclave address space to a process. I.e. VMA would no longer reference to the enclave or vice versa but you would still create an enclave VMA with mmap(). This is IMHO very clear and well-defined semantics. > > struct sgx_enclave_add_page { > > __u64 enclave_fd; > > __u64 src; > > __u64 secinfo; > > __u16 mrmask; > > } __attribute__((__packed__)); > > Wouldn't you just pass enclave_fd as the ioctl fd parameter? I'm still planning to keep the API in the device fd and use enclave_fd as handle to the enclave address space. I don't see any obvious reason to change that behavior. And if we ever add any "global" ioctls, then we would have to define APIs to both fd's, which would become a mess. > How to specify the address of the page that is being added? Yes, that is correct and my bad to remove it (just quickly drafted what I had in mind). /Jarkko