Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: /dItL0OQ9F6sBv0JFp2DrwuuwhIwUaI39abJo4A6LQUPXVamhak+TJhlgpMhM2Z4ogI4GZoQz7
 ZkYbw8wfJvLw==
IronPort-SDR: Lme8ty7I/g9PsqiJtR4D47YuMqBd6NyLtzEbVFSirhG42hpuJfcvDa0Pv2wpB7D/5OOvaVoo9X
 8JjxHTb7FwpQ==
Date:   Wed, 23 Sep 2020 16:43:52 +0300
From:   Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To:     Dave Hansen <dave.hansen@intel.com>
Cc:     Andy Lutomirski <luto@amacapital.net>,
        Sean Christopherson <sean.j.christopherson@intel.com>,
        Andy Lutomirski <luto@kernel.org>, X86 ML <x86@kernel.org>,
        linux-sgx@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
        Linux-MM <linux-mm@kvack.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Matthew Wilcox <willy@infradead.org>,
        Jethro Beekman <jethro@fortanix.com>,
        Darren Kenny <darren.kenny@oracle.com>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        asapek@google.com, Borislav Petkov <bp@alien8.de>,
        "Xing, Cedric" <cedric.xing@intel.com>, chenalexchen@google.com,
        Conrad Parker <conradparker@google.com>, cyhanish@google.com,
        "Huang, Haitao" <haitao.huang@intel.com>,
        Josh Triplett <josh@joshtriplett.org>,
        "Huang, Kai" <kai.huang@intel.com>,
        "Svahn, Kai" <kai.svahn@intel.com>, Keith Moyer <kmoy@google.com>,
        Christian Ludloff <ludloff@google.com>,
        Neil Horman <nhorman@redhat.com>,
        Nathaniel McCallum <npmccallum@redhat.com>,
        Patrick Uiterwijk <puiterwijk@redhat.com>,
        David Rientjes <rientjes@google.com>,
        Thomas Gleixner <tglx@linutronix.de>, yaozhangx@google.com
Subject: Re: [PATCH v38 10/24] mm: Add vm_ops->mprotect()
Message-ID: <20200923134352.GC5160@linux.intel.com>
References: <20200918235337.GA21189@sjchrist-ice>
 <1B23E216-0229-4BDD-8B09-807256A54AF5@amacapital.net>
 <20200922125801.GA133710@linux.intel.com>
 <25d46fdc-1c19-2de8-2ce8-1033a0027ecf@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <25d46fdc-1c19-2de8-2ce8-1033a0027ecf@intel.com>
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
Precedence: bulk

On Tue, Sep 22, 2020 at 08:11:14AM -0700, Dave Hansen wrote:
> On 9/22/20 5:58 AM, Jarkko Sakkinen wrote:
> > Intel Sofware Guard eXtensions (SGX) allows creation of executable blobs
> > called enclaves, of which page permissions are defined when the enclave
> 
> "of which" => "for which"
> 
> > is first loaded. Once an enclave is loaded and initialized, it can be
> > mapped to the process address space.
> 
> Could you compare and contrast this a *bit* with existing executables?
> What's special about SGX?  ELF executables have page permissions inside
> the binary too.  Why don't we use this mechanism for them?

There is no standard file format for enclaves. They are dynamically
built. And the way enclaves are used as part of an app and throwing
container inside enclave differ. A single format would no work too
well for all possible use cases.

I cannot formally prove this of course but it is highly unlikely that
we could ever define such a format. Thus, the security focus is allow
to verify from origin.

And the existing ecosystem around SGX is already too large to suddenly
move to a single format. User base, I guess, is also an argument. This
is not yet mainline code so technically we have zero ABI debt but I
still think this is a valid point because SGX is already widely used.

I'm not really sure what would be the best way to nail this information
to the commit message but I'll try to figure out something before I send
the next version of the patch set.

/Jarkko