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,URIBL_BLOCKED,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 97DE5C11D00 for ; Fri, 21 Feb 2020 01:21:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 74ECD20679 for ; Fri, 21 Feb 2020 01:21:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729486AbgBUBVk (ORCPT ); Thu, 20 Feb 2020 20:21:40 -0500 Received: from wind.enjellic.com ([76.10.64.91]:57724 "EHLO wind.enjellic.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729476AbgBUBVk (ORCPT ); Thu, 20 Feb 2020 20:21:40 -0500 Received: from wind.enjellic.com (localhost [127.0.0.1]) by wind.enjellic.com (8.15.2/8.15.2) with ESMTP id 01L1JE9d015218; Thu, 20 Feb 2020 19:19:14 -0600 Received: (from greg@localhost) by wind.enjellic.com (8.15.2/8.15.2/Submit) id 01L1JDdH015217; Thu, 20 Feb 2020 19:19:13 -0600 Date: Thu, 20 Feb 2020 19:19:13 -0600 From: "Dr. Greg" To: Jarkko Sakkinen Cc: Jethro Beekman , Sean Christopherson , Andy Lutomirski , "linux-sgx@vger.kernel.org" , "serge.ayoun@intel.com" , "shay.katz-zamir@intel.com" Subject: Re: x86/sgx: v23-rc2 Message-ID: <20200221011913.GA15165@wind.enjellic.com> Reply-To: "Dr. Greg" References: <8dc2ab24-baf1-5e57-3906-35e7286f7ffe@fortanix.com> <20191017175735.GD20903@linux.intel.com> <20200215072406.GA9958@linux.intel.com> <20200217185512.GA7677@linux.intel.com> <20200218104243.GA13967@wind.enjellic.com> <20200218155247.GA18374@linux.intel.com> <20200219162640.GA29921@wind.enjellic.com> <20200220195537.GA23349@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200220195537.GA23349@linux.intel.com> User-Agent: Mutt/1.4i X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.3 (wind.enjellic.com [127.0.0.1]); Thu, 20 Feb 2020 19:19:14 -0600 (CST) Sender: linux-sgx-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-sgx@vger.kernel.org On Thu, Feb 20, 2020 at 09:57:11PM +0200, Jarkko Sakkinen wrote: Good evening to everyone. > On Wed, Feb 19, 2020 at 10:26:40AM -0600, Dr. Greg wrote: > > On Tue, Feb 18, 2020 at 05:52:47PM +0200, Jarkko Sakkinen wrote: > > > > Good morning, I hope the day is going well for everyone. > > > > > On Tue, Feb 18, 2020 at 04:42:43AM -0600, Dr. Greg Wettstein wrote: > > > > I believe an accurate summary of Dr. Beekman's concerns are as > > > > follows: > > > > > > > > 1.) He envisions a need for an enclave orchestrator that uses root > > > > privileges to open the SGX driver device and then drop privileges, > > > > presumably in a permanent fashion. The orchestrator would then use > > > > the filehandle to load and initialize multiple enclaves on request. > > > > > > > > 2.) The enclave orchestrator may be run in an environment that has > > > > SECCOMP limitations on the ability to conduct filesystem operations. > > > > > Also UDS sockets with SCM_RIGHTS should work. > > > > The first clarification, I'm assuming you mean passing SCM_RIGHTS over > > AF_UNIX/UNIX-domain sockets, not UDP sockets? > UNIX domain sockets. That is what I thought, I wanted to make sure that UDS wasn't a typo. > > It appears that the sgx_open() function, that is installed as the > > ->open method for the /dev/sgx/enclave device node, allocates the > > master enclave definition structure, that is installed, and > > subsequently released, as private data for the file instance object. > > This master enclave structure has the reference to the virtual memory > > definition for the enclave that is opened. > You can have multiple references to an enclave by using formentioned > tools. Yes, I understand multiple references to a file descriptor/enclave, but see below. > > This would seem to imply that the driver is rather firmly architected > > on the notion of one open() per enclave, a concept that Jethro seems > > to have issues with. > I don't understand what concept you are talking about. If memory serves me correctly, Jethro envisioned a model where a single open of the SGX driver node would return a file descriptor that could then be used to create/load/initialize multiple enclaves. Your clarifications indicate that a separate open will be needed for each and every enclave instance that will be orchestrated. Jethro, if I'm mistating your position on this, please jump in and clarify. > /Jarkko Have a good end of the week. Dr. Greg As always, Dr. Greg Wettstein, Ph.D, Worker IDfusion, LLC SGX secured infrastructure and 4206 N. 19th Ave. autonomously self-defensive platforms. Fargo, ND 58102 PH: 701-281-1686 EMAIL: greg@idfusion.net ------------------------------------------------------------------------------ "Real Programmers consider "what you see is what you get" to be just as bad a concept in Text Editors as it is in women. No, the Real Programmer wants a "you asked for it, you got it" text editor -- complicated, cryptic, powerful, unforgiving, dangerous." -- Matthias Schniedermeyer