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;
Date:   Thu, 16 May 2019 08:07:05 +0300
From:   Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To:     Andy Lutomirski <luto@amacapital.net>
Cc:     Sean Christopherson <sean.j.christopherson@intel.com>,
        Andy Lutomirski <luto@kernel.org>,
        Jethro Beekman <jethro@fortanix.com>,
        "Xing, Cedric" <cedric.xing@intel.com>,
        "Hansen, Dave" <dave.hansen@intel.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        "Dr. Greg" <greg@enjellic.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        LKML <linux-kernel@vger.kernel.org>, X86 ML <x86@kernel.org>,
        "linux-sgx@vger.kernel.org" <linux-sgx@vger.kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        "nhorman@redhat.com" <nhorman@redhat.com>,
        "npmccallum@redhat.com" <npmccallum@redhat.com>,
        "Ayoun, Serge" <serge.ayoun@intel.com>,
        "Katz-zamir, Shay" <shay.katz-zamir@intel.com>,
        "Huang, Haitao" <haitao.huang@intel.com>,
        Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
        "Svahn, Kai" <kai.svahn@intel.com>, Borislav Petkov <bp@alien8.de>,
        Josh Triplett <josh@joshtriplett.org>,
        "Huang, Kai" <kai.huang@intel.com>,
        David Rientjes <rientjes@google.com>
Subject: Re: [PATCH v20 00/28] Intel SGX1 support
Message-ID: <20190516050705.GB6388@linux.intel.com>
References: <960B34DE67B9E140824F1DCDEC400C0F4E886094@ORSMSX116.amr.corp.intel.com>
 <6da269d8-7ebb-4177-b6a7-50cc5b435cf4@fortanix.com>
 <CALCETrWCZQwg-TUCm58DVG43=xCKRsMe1tVHrR8vdt06hf4fWA@mail.gmail.com>
 <20190513102926.GD8743@linux.intel.com>
 <20190514104323.GA7591@linux.intel.com>
 <CALCETrVbgTCnPo=PAq0-KoaRwt--urrPzn==quAJ8wodCpkBkw@mail.gmail.com>
 <20190514204527.GC1977@linux.intel.com>
 <20190515103531.GB10917@linux.intel.com>
 <20190515110005.GA14718@linux.intel.com>
 <B1DF6DCD-C37D-4C87-AF32-F31785184482@amacapital.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <B1DF6DCD-C37D-4C87-AF32-F31785184482@amacapital.net>
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

On Wed, May 15, 2019 at 07:27:02AM -0700, Andy Lutomirski wrote:
> 
> > On May 15, 2019, at 4:00 AM, Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> wrote:
> > 
> >> On Wed, May 15, 2019 at 01:35:31PM +0300, Jarkko Sakkinen wrote:
> >> This brings me to an open question in Andy's model: lets say that we
> >> change the source for SIGSTRUCT from memory address to fd. How can the
> >> policy prevent the use not creating a file containing a SIGSTRUCT and
> >> passing fd of that to the EINIT ioctl?
> > 
> 
> The policy will presumably check the label on the file that the fd points to.

Right (checked SELinux documentation).

Got one idea from this. Right now creation and initialization does not
require any VMAs to be created (since v20). Requiring to map a VMA for
copying the data would bring in my opinion a glitch to this model that
we have done effort to build up.

What if we similarly change EADD ioctl in a way that it'd take an fd
and an offset? This way we can enforce policy to the source where the
enclave data is loaded from. On the other hand, loading SIGSTRUCT from
fd enforces a legit structure for the enclave.

This would still allow to construct enclaves in VMA independent way.

> > Also wondering if a path would be better than plain fd for defining a
> > reasonable policy i.e. have sigstruct_path as part of the ioctl
> > parameters and not sigstruct_fd.
> > 
> 
> It would save two syscalls at the cost of a decent amount of complexity.

And also using fd gives robustness because it allows SIGSTRUCT
pulled from a file containing it (among other things).

/Jarkko