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 5A252C46460 for ; Mon, 3 Jun 2019 21:51:08 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 399B726CFD for ; Mon, 3 Jun 2019 21:51:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726528AbfFCVvH (ORCPT ); Mon, 3 Jun 2019 17:51:07 -0400 Received: from mga03.intel.com ([134.134.136.65]:38696 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726317AbfFCVvH (ORCPT ); Mon, 3 Jun 2019 17:51:07 -0400 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Jun 2019 14:23:38 -0700 X-ExtLoop1: 1 Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.36]) by fmsmga007.fm.intel.com with ESMTP; 03 Jun 2019 14:23:36 -0700 Date: Mon, 3 Jun 2019 14:23:36 -0700 From: Sean Christopherson To: Jarkko Sakkinen Cc: Andy Lutomirski , Stephen Smalley , "Xing, Cedric" , William Roberts , James Morris , "Serge E. Hallyn" , LSM List , Paul Moore , Eric Paris , "selinux@vger.kernel.org" , Jethro Beekman , "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: <20190603212336.GM13384@linux.intel.com> References: <960B34DE67B9E140824F1DCDEC400C0F654E9824@ORSMSX116.amr.corp.intel.com> <20190528202407.GB13158@linux.intel.com> <285f279f-b500-27f0-ab42-fb1dbcc5ab18@tycho.nsa.gov> <960B34DE67B9E140824F1DCDEC400C0F654EB487@ORSMSX116.amr.corp.intel.com> <678a37af-797d-7bd5-a406-32548a270e3d@tycho.nsa.gov> <20190603205405.GE4894@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190603205405.GE4894@linux.intel.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-sgx-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-sgx@vger.kernel.org On Mon, Jun 03, 2019 at 11:54:05PM +0300, Jarkko Sakkinen wrote: > On Thu, May 30, 2019 at 09:14:10AM -0700, Andy Lutomirski wrote: > > > What is the "source file" i.e. the target of the check? Enclave file, > > > sigstruct file, or /dev/sgx/enclave? > > > > Enclave file -- that is, the file backing the vma from which the data > > is loaded. > > Wonder why KVM gets away without having this given that enclaves are > lot alike VMs. >From a memory management perspective, VMs are not at all like enclaves. An enclave is an extension of its host, i.e. runs in the same address. This isn't strictly necessary, e.g. an enclave could run in a sandbox process, but even then the enclave will be running with the kernel's standard page tables. A VM is a essentially an opaque blob of data that gets loaded into memory. KVM builds a completely different set of page tables for the VM, the VM has it's own file system (or perhaps doesn't have a file system at all), etc... Ignoring Spectre and L1TF, the VM is contained to its own world. There are a lot of ways for a userspace VMM to expose things beyond raw memory, but doing so requires the appropriate permissions. And practically speaking, all traditional VMs will effectively need RWX memory, i.e. Qemu (or any other userspace VMM) would be required to have EXECMEM permissions, which would be a net negative for security. > > It's provided by userspace based on whether it thinks the data in > > question is enclave code. source->vm_file is the file from which the > > code is being loaded. I'm assuming that the user code will only set > > excute_intent ==true if it actually wants to execute the code, so, if > > there's a denial, it will be fatal. The normal case will be that the > > request will be granted on the basis of EXECUTE. > > AFAIK user spaces tells that already with the SECINFO flags. I don't > get why we need a duplicate parameter. Please read through the RFC, I think it address a lot of your questions. Hopefully that will help us avoid some thrash.