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.3 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 C1847C31E43 for ; Mon, 10 Jun 2019 17:45:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A7EEF2082E for ; Mon, 10 Jun 2019 17:45:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388346AbfFJRp1 (ORCPT ); Mon, 10 Jun 2019 13:45:27 -0400 Received: from mga06.intel.com ([134.134.136.31]:38816 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388342AbfFJRp1 (ORCPT ); Mon, 10 Jun 2019 13:45:27 -0400 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jun 2019 10:45:26 -0700 X-ExtLoop1: 1 Received: from cmargarx-wtg.ger.corp.intel.com (HELO localhost) ([10.249.34.77]) by orsmga007.jf.intel.com with ESMTP; 10 Jun 2019 10:45:13 -0700 Date: Mon, 10 Jun 2019 20:45:06 +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 v2 2/5] x86/sgx: Require userspace to define enclave pages' protection bits Message-ID: <20190610174506.GB13732@linux.intel.com> References: <20190606021145.12604-1-sean.j.christopherson@intel.com> <20190606021145.12604-3-sean.j.christopherson@intel.com> <20190610152717.GB3752@linux.intel.com> <20190610161532.GC15995@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190610161532.GC15995@linux.intel.com> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-sgx-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-sgx@vger.kernel.org On Mon, Jun 10, 2019 at 09:15:33AM -0700, Sean Christopherson wrote: > > 'flags' should would renamed as 'secinfo_flags_mask' even if the name is > > longish. It would use the same values as the SECINFO flags. The field in > > struct sgx_encl_page should have the same name. That would express > > exactly relation between SECINFO and the new field. I would have never > > asked on last iteration why SECINFO is not enough with a better naming. > > No, these flags do not impact the EPCM protections in any way. Userspace > can extend the EPCM protections without going through the kernel. The > protection flags for an enclave page impact VMA/PTE protection bits. > > IMO, it is best to treat the EPCM as being completely separate from the > kernel's EPC management. It is a clumsy API if permissions are not taken in the same format for everything. There is no reason not to do it. The way mprotect() callback just interprets the field is as VMA permissions. It would also be more future-proof just to have a mask covering all bits of the SECINFO flags field. /Jarkko