Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp1994651yba; Fri, 17 May 2019 08:42:59 -0700 (PDT) X-Google-Smtp-Source: APXvYqz/wXI7SZ7jCj9Fol9DgoYqu/VCDE/QXMgI8+CoVsIk7OmKxQsXX9nMdF1rsRnrBrNjABD7 X-Received: by 2002:aa7:90ca:: with SMTP id k10mr61656280pfk.20.1558107779150; Fri, 17 May 2019 08:42:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1558107779; cv=none; d=google.com; s=arc-20160816; b=vWaQNCtUA5fyy+lP1ep8//0cebKxXYKfRL1p+FAbRN7mEzXOfEaM0Rx6klXy5tjojg DyfACl13HIGfM7ZIkfWNomriM2ex0Fjy2LUwsv7GEb797xc3mxFZX89v8psiTfYpfP0B HDIdSdZWA+/YRdGCbSRqMz+B81/F8foheCPfzXX2if/VzjmfuOAQk5UuB4vjZhT9bwHu 5J5scX3C7WP4hs+9SWWzLgEXxKzvJ3pdmigVXVO9+2qdYINRZRGowYOrgCiOBcKV9ns6 GPFP3DA1LDIM/liLmv4jYBNAkIOHwD3kBc3Q2HvIpqDmzz12+4a+GjpnGvbLjY/ZkDWv QwLw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=83YSzSWXAbgZg4qCh8Xy77ZwSCzafl8lD/RHQ+ON7O0=; b=XPgErDRFglVfmlmKl0fNa2TMW3n7Pn+deDwjg7NNX/lF4h9Uch92HOvMKXGW8cI+tU HTPM8V7jlUQyIvwboNoidgNig8CgLvLLJ6h0vcy2U1MvarslT2QaC+UYlMJW6IH3BzUY tRUzCyGoJ/RS1nxEIYL3GlNaAmNGOK5VwU8yszb2yaFT98XfjVvUUfQxHrIznhhdsPgn WHJ4E9S+ZPIup0umPqOk5CaDaFrvRXFtOUAe8Edp4glLijoZrkX/Z4SLw7514rcpEd74 KVKJVcyQp3w/r1pYtCPSvrdTNPqtnTjD54+Z2xBMOqGUc9O6XbP3rOSSSC8TDRhwMvau N0Ew== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d20si7621502pgv.102.2019.05.17.08.42.43; Fri, 17 May 2019 08:42:59 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729202AbfEQPla (ORCPT + 99 others); Fri, 17 May 2019 11:41:30 -0400 Received: from mga01.intel.com ([192.55.52.88]:12103 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729158AbfEQPla (ORCPT ); Fri, 17 May 2019 11:41:30 -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 fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 May 2019 08:41:29 -0700 X-ExtLoop1: 1 Received: from sjchrist-coffee.jf.intel.com (HELO linux.intel.com) ([10.54.74.36]) by orsmga006.jf.intel.com with ESMTP; 17 May 2019 08:41:28 -0700 Date: Fri, 17 May 2019 08:41:28 -0700 From: Sean Christopherson To: Andy Lutomirski Cc: James Morris , "Serge E. Hallyn" , LSM List , Paul Moore , Stephen Smalley , Eric Paris , selinux@vger.kernel.org, Jarkko Sakkinen , 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: <20190517154128.GA15006@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: User-Agent: Mutt/1.5.24 (2015-08-30) 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: > On Thu, May 16, 2019 at 5:03 PM Sean Christopherson > wrote: > > > > On Wed, May 15, 2019 at 11:27:04AM -0700, Andy Lutomirski wrote: > > > Here's a very vague proposal that's kind of like what I've been > > > thinking over the past few days. The SGX inode could track, for each > > > page, a "safe-to-execute" bit. When you first open /dev/sgx/enclave, > > > you get a blank enclave and all pages are safe-to-execute. When you > > > do the ioctl to load context (which could be code, data, or anything > > > else), the kernel will check whether the *source* VMA is executable > > > and, if not, mark the page of the enclave being loaded as unsafe. > > > Once the enclave is initialized, the driver will clear the > > > safe-to-execute bit for any page that is successfully mapped writably. > > > > > > The intent is that a page of the enclave is safe-to-execute if that > > > page was populated from executable memory and not modified since then. > > > LSMs could then enforce a policy that you can map an enclave page RX > > > if the page is safe-to-execute, you can map any page you want for > > > write if there are no executable mappings, and you can only map a page > > > for write and execute simultaneously if you can EXECMOD permission. > > > This should allow an enclave to be loaded by userspace from a file > > > with EXECUTE rights. > > > > I'm still confused as to why you want to track execute permissions on the > > enclave pages and add SGX-specific LSM hooks. Is there anything that > > prevents userspace from building the enclave like any other DSO and then > > copying it into enclave memory? > > It's entirely possible that I'm the one missing something. But here's > why I think this: > > > I feel like I'm missing something. > > > > 1. Userspace loads enclave into regular memory, e.g. like a normal DSO. > > All mmap(), mprotect(), etc... calls are subject to all existing > > LSM policies. > > > > 2. Userspace opens /dev/sgx/enclave to instantiate a new enclave. > > > > 3. Userspace uses mmap() to allocate virtual memory for its enclave, > > again subject to all existing LSM policies (sane userspaces map it RO > > since the permissions eventually get tossed anyways). > > Is userspace actually requred to mmap() the enclave prior to EADDing things? It was a requirement prior to the API rework in v20, i.e. unless someone was really quick on the draw after the v20 update all existing userspace implementations mmap() the enclave before ECREATE. Requiring a valid enclave VMA for EADD shoudn't be too onerous. > > 4. SGX subsystem refuses to service page faults for enclaves that have > > not yet been initialized, e.g. signals SIGBUS or SIGSEGV. > > > > 5. Userspace invokes SGX ioctl() to copy enclave from regulary VMA to > > enclave VMA. > > > > 6. SGX ioctl() propagates VMA protection-related flags from source VMA > > to enclave VMA, e.g. invokes mprotect_fixup(). Enclave VMA(s) may > > be split as part of this process. > > Does this also call the LSM? If so, what is it expected to do? Nope. My reasoning behind skipping LSM checks is that the LSMs have already ok'd the source VMAs, similar to how dup_mmap() doesn't redo LSM checks. > What happens if there are different regions with different permissions on > the same page? SGX has 256-byte granularity right? No, EPC pages have 4k granularity. The EPC is divided into EPC pages. An EPC page is 4KB in size and always aligned on a 4KB boundary EEXTEND is the only aspect of SGX that works on 256-byte chunks, and that goofiness is primarily to keep the latency of EEXTEND low enough so that the instruction doesn't have to be interruptible, a la EINIT. > > > > 7. At all times, mprotect() calls on the enclave VMA are subject to > > existing LSM policies, i.e. it's not special cased for enclaves. > > I don't think the normal behavior actually works here. An enclave is > always MAP_SHARED, so (with SELinux) mprotecting() to X or RX requires > EXECUTE and mprotecting() to RWX requires extra permissions. Requiring extra permissions is good though, right? My thinking is to make the EADD "VMA copy" the happy/easy path, while using mprotect() to convert EPC memory to executable would require PROCESS__EXECMEM (assuming we back enclaves with anon inodes instead of /dev/sgx/enclave). > But user code can also mmap() the enclave again. What is supposed to > happen in that case? Hmm, it can't effectively re-mmap() the enclave as executable since entering the enclave requires using the correct virtual address range, i.e. EENTER would fail. It could, I think, do munmap()->mmap() to change the permissions. We could handle that case fairly easily by invoking security_file_mprotect() in SGX's mmap() hook if any pages have been added to the enclave, i.e. treat mmap() like mprotect().