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;
Date:   Wed, 19 Dec 2018 12:43:59 +0200
From:   Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To:     Jethro Beekman <jethro@fortanix.com>
Cc:     Andy Lutomirski <luto@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        "x86@kernel.org" <x86@kernel.org>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Peter Zijlstra <peterz@infradead.org>,
        "sean.j.christopherson@intel.com" <sean.j.christopherson@intel.com>,
        "H. Peter Anvin" <hpa@zytor.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-sgx@vger.kernel.org" <linux-sgx@vger.kernel.org>,
        Andy Lutomirski <luto@amacapital.net>,
        Josh Triplett <josh@joshtriplett.org>,
        Haitao Huang <haitao.huang@linux.intel.com>,
        "Dr . Greg Wettstein" <greg@enjellic.com>
Subject: Re: x86/sgx: uapi change proposal
Message-ID: <20181219104015.GA4863@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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <613c6814-4e71-38e5-444a-545f0e286df8@fortanix.com>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Dec 19, 2018 at 09:36:16AM +0000, Jethro Beekman wrote:
> On 2018-12-19 14:41, Jarkko Sakkinen wrote:
> > 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).
> 
> So your plan is that to call EADD, userspace has to pass the device fd AND
> the enclave fd AND the enclave address? That seems a little superfluous.

If the enclave fd would have ioctls to add pages etc., two ioctls APIs
would be already needed now (create for device fd and rest to the
enclave fd). Which one would be more superfluous?

/Jarkko