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 C516CC28CC6 for ; Tue, 4 Jun 2019 11:15:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A3CF624B70 for ; Tue, 4 Jun 2019 11:15:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727697AbfFDLPm (ORCPT ); Tue, 4 Jun 2019 07:15:42 -0400 Received: from mga11.intel.com ([192.55.52.93]:64072 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727323AbfFDLPl (ORCPT ); Tue, 4 Jun 2019 07:15:41 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Jun 2019 04:15:40 -0700 X-ExtLoop1: 1 Received: from jsakkine-mobl1.tm.intel.com (HELO localhost) ([10.237.50.189]) by fmsmga001.fm.intel.com with ESMTP; 04 Jun 2019 04:15:33 -0700 Date: Tue, 4 Jun 2019 14:15:33 +0300 From: Jarkko Sakkinen To: Sean Christopherson 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: Re: [RFC PATCH 0/9] security: x86/sgx: SGX vs. LSM Message-ID: <20190604111533.GA15393@linux.intel.com> References: <20190531233159.30992-1-sean.j.christopherson@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190531233159.30992-1-sean.j.christopherson@intel.com> 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 Fri, May 31, 2019 at 04:31:50PM -0700, Sean Christopherson wrote: > 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. The discussion > definitely wandered into completely insane territory at times, but I > think/hope we ended up with something reasonable. By definition this is a broken series because it does not apply to mainline. Even RFC series should at least apply. Would be better idea to discuss design ideas and use snippets instead. Now you have to take original v20 and apply to these patches to evaluate anything. > The basic gist of the approach is to require userspace to declare what > protections are maximally allowed for any given page, e.g. add a flags > field for loading enclave pages that takes ALLOW_{READ,WRITE,EXEC}. LSMs > can then adjust the allowed protections, e.g. clear ALLOW_EXEC to prevent > ever mapping the page with PROT_EXEC. SGX enforces the allowed perms > via a new mprotect() vm_ops hook, e.g. like regular mprotect() uses > MAY_{READ,WRITE,EXEC}. mprotect() does not use MAY_{READ,WRITE,EXEC} constants. It uses VM_MAY{READ,WRITE,EXEC,SHARED} constants. What are ALLOW_{READ,WRITE,EXEC} and how they are used? What does the hook do and why it is in vm_ops and not in file_operations? Are they arguments to the ioctl or internal variables that are set based on SECINFO? /Jarkko