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_HELO_NONE,SPF_PASS,USER_AGENT_MUTT autolearn=unavailable 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 5F3B4C04E87 for ; Mon, 20 May 2019 11:41:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3D2F620645 for ; Mon, 20 May 2019 11:41:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730798AbfETLlV (ORCPT ); Mon, 20 May 2019 07:41:21 -0400 Received: from mga05.intel.com ([192.55.52.43]:25986 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727108AbfETLlV (ORCPT ); Mon, 20 May 2019 07:41:21 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 May 2019 04:41:18 -0700 X-ExtLoop1: 1 Received: from mhauser-mobl.ger.corp.intel.com (HELO localhost) ([10.252.47.244]) by orsmga006.jf.intel.com with ESMTP; 20 May 2019 04:41:07 -0700 Date: Mon, 20 May 2019 14:41:05 +0300 From: Jarkko Sakkinen To: Andy Lutomirski Cc: Sean Christopherson , James Morris , "Serge E. Hallyn" , LSM List , Paul Moore , Stephen Smalley , Eric Paris , selinux@vger.kernel.org, Jethro Beekman , "Xing, Cedric" , "Hansen, Dave" , Thomas Gleixner , "Dr. Greg" , Linus Torvalds , LKML , X86 ML , "linux-sgx@vger.kernel.org" , Andrew Morton , "nhorman@redhat.com" , "npmccallum@redhat.com" , "Ayoun, Serge" , "Katz-zamir, Shay" , "Huang, Haitao" , Andy Shevchenko , "Svahn, Kai" , Borislav Petkov , Josh Triplett , "Huang, Kai" , David Rientjes Subject: Re: SGX vs LSM (Re: [PATCH v20 00/28] Intel SGX1 support) Message-ID: <20190520114105.GD27805@linux.intel.com> References: <20190513102926.GD8743@linux.intel.com> <20190514104323.GA7591@linux.intel.com> <20190514204527.GC1977@linux.intel.com> <20190515013031.GF1977@linux.intel.com> <20190517000331.GD11204@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 16, 2019 at 05:26:15PM -0700, Andy Lutomirski wrote: > Is userspace actually requred to mmap() the enclave prior to EADDing things? Nope, not since v20. Here is what I wrote about API to the kernel documentation: "The enclave life-cycle starts by opening `/dev/sgx/enclave`. After this there is already a data structure inside kernel tracking the enclave that is initially uncreated. After this a set of ioctl's can be used to create, populate and initialize the enclave. You can close (if you want) the fd after you've mmap()'d. As long as the file is open the enclave stays alive so you might want to do that after you don't need it anymore. Even munmap() won't destruct the enclave if the file is open. Neither will closing the fd as long as you have mmap() done over the fd (even if it does not across the range defined in SECS)." Enclave can be created and initialized without doing a single mmap() call. /Jarkko