From patchwork Thu Jun 6 02:11:40 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sean Christopherson X-Patchwork-Id: 10978303 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 558A31398 for ; Thu, 6 Jun 2019 02:11:51 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 45D3D2870E for ; Thu, 6 Jun 2019 02:11:51 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 39A7528786; Thu, 6 Jun 2019 02:11:51 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B92D628710 for ; Thu, 6 Jun 2019 02:11:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726608AbfFFCLu (ORCPT ); Wed, 5 Jun 2019 22:11:50 -0400 Received: from mga17.intel.com ([192.55.52.151]:61631 "EHLO mga17.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726541AbfFFCLu (ORCPT ); Wed, 5 Jun 2019 22:11:50 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jun 2019 19:11:49 -0700 X-ExtLoop1: 1 Received: from sjchrist-coffee.jf.intel.com ([10.54.74.36]) by orsmga004.jf.intel.com with ESMTP; 05 Jun 2019 19:11:49 -0700 From: Sean Christopherson To: Jarkko Sakkinen Cc: Andy Lutomirski , Cedric Xing , Stephen Smalley , James Morris , "Serge E . Hallyn" , LSM List , Paul Moore , Eric Paris , selinux@vger.kernel.org, Jethro Beekman , Dave Hansen , Thomas Gleixner , Linus Torvalds , LKML , X86 ML , linux-sgx@vger.kernel.org, Andrew Morton , nhorman@redhat.com, npmccallum@redhat.com, Serge Ayoun , Shay Katz-zamir , Haitao Huang , Andy Shevchenko , Kai Svahn , Borislav Petkov , Josh Triplett , Kai Huang , David Rientjes , William Roberts , Philip Tricca Subject: [RFC PATCH v2 0/5] security: x86/sgx: SGX vs. LSM Date: Wed, 5 Jun 2019 19:11:40 -0700 Message-Id: <20190606021145.12604-1-sean.j.christopherson@intel.com> X-Mailer: git-send-email 2.21.0 MIME-Version: 1.0 Sender: linux-sgx-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-sgx@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP This series is the result of a rather absurd amount of discussion over how to get SGX to play nice with LSM policies, without having to resort to evil shenanigans or put undue burden on userspace. Discussions are still ongoing, e.g. folks are exploring alternatives to changing the proposed SGX UAPI, but I wanted to get this updated version of the code posted to show a fairly minimal implemenation(from a kernel perspective), e.g. the diff stats aren't too scary, especially considering 50% of the added lines are comments. This series is a delta to Jarkko's ongoing SGX series and applies on Jarkko's current master at https://github.com/jsakkine-intel/linux-sgx.git: dfc89a83b5bc ("docs: x86/sgx: Document the enclave API") The basic gist of the approach is to track an enclave's page protections separately from any vmas that map the page, and separate from the hardware enforced protections. The SGX UAPI is modified to require userspace to explicitly define the protections for each enclave page, i.e. the ioctl to add pages to an enclave is extended to take PROT_{READ,WRITE,EXEC} flags. An enclave page's protections are the maximal protections that userspace can use to map the page, e.g. mprotect() and mmap() are rejected if the protections for the vma would be more permissible than those of the associated enclave page. Tracking protections for an enclave page (in additional to vmas) allows SGX to invoke LSM upcalls while the enclave is being built. This is critical to enabling LSMs to implement policies for enclave pages that are functionally equivalent to existing policies for normal pages. v1: https://lkml.kernel.org/r/20190531233159.30992-1-sean.j.christopherson@intel.com v2: - Dropped the patch(es) to extend the SGX UAPI to allow adding multiple enclave pages in a single syscall [Jarkko]. - Reject ioctl() immediately on LSM denial [Stephen]. - Rework SELinux code to avoid checking EXEMEM multiple times [Stephen]. - Adding missing equivalents to existing selinux_file_protect() checks [Stephen]. - Hold mmap_sem across copy_to_user() to prevent a TOCTOU race when checking the source vma [Stephen]. - Stubify security_enclave_load() if !CONFIG_SECURITY [Stephen]. - Make flags a 32-bit field [Andy]. - Don't validate the SECINFO protection flags against the enclave page's protection flags [Andy]. - Rename mprotect() hook to may_mprotect() [Andy]. - Test 'vma->vm_flags & VM_MAYEXEC' instead of manually checking for a noexec path [Jarkko]. - Drop the SGX defined flags (use PROT_*) [Jarkko]. - Improve comments and changelogs [Jarkko]. Sean Christopherson (5): mm: Introduce vm_ops->may_mprotect() x86/sgx: Require userspace to define enclave pages' protection bits x86/sgx: Enforce noexec filesystem restriction for enclaves LSM: x86/sgx: Introduce ->enclave_load() hook for Intel SGX security/selinux: Add enclave_load() implementation arch/x86/include/uapi/asm/sgx.h | 2 + arch/x86/kernel/cpu/sgx/driver/ioctl.c | 57 ++++++++++++++++++--- arch/x86/kernel/cpu/sgx/driver/main.c | 5 ++ arch/x86/kernel/cpu/sgx/encl.c | 53 ++++++++++++++++++++ arch/x86/kernel/cpu/sgx/encl.h | 4 ++ include/linux/lsm_hooks.h | 13 +++++ include/linux/mm.h | 2 + include/linux/security.h | 12 +++++ mm/mprotect.c | 15 ++++-- security/security.c | 7 +++ security/selinux/hooks.c | 69 ++++++++++++++++++++++++++ 11 files changed, 228 insertions(+), 11 deletions(-)