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:   Fri, 21 Dec 2018 15:48:30 +0200
From:   Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To:     "Dr. Greg" <greg@enjellic.com>
Cc:     Jethro Beekman <jethro@fortanix.com>,
        Andy Lutomirski <luto@kernel.org>,
        Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        "x86@kernel.org" <x86@kernel.org>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Peter Zijlstra <peterz@infradead.org>,
        "sean.j.christopherson@intel.com" <sean.j.christopherson@intel.com>,
        "H. Peter Anvin" <hpa@zytor.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-sgx@vger.kernel.org" <linux-sgx@vger.kernel.org>,
        Andy Lutomirski <luto@amacapital.net>,
        Josh Triplett <josh@joshtriplett.org>,
        Haitao Huang <haitao.huang@linux.intel.com>
Subject: Re: x86/sgx: uapi change proposal
Message-ID: <20181221134830.GA5799@linux.intel.com>
References: <20181214215729.4221-1-sean.j.christopherson@intel.com>
 <7706b2aa71312e1f0009958bcab24e1e9d8d1237.camel@linux.intel.com>
 <598cd050-f0b5-d18c-96a0-915f02525e3e@fortanix.com>
 <20181219144343.GA31189@wind.enjellic.com>
 <20181220103400.GC26410@linux.intel.com>
 <20181220220638.GA25110@wind.enjellic.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20181220220638.GA25110@wind.enjellic.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

On Thu, Dec 20, 2018 at 04:06:38PM -0600, Dr. Greg wrote:
> On Thu, Dec 20, 2018 at 12:34:00PM +0200, Jarkko Sakkinen wrote:
> 
> Good afternoon to everyone.
> 
> > On Wed, Dec 19, 2018 at 08:43:43AM -0600, Dr. Greg wrote:
> > > I believe it is a silent response to the issues we were
> > > prosecuting 4-5 weeks ago, regarding the requirement for an SGX
> > > driver on an FLC hardware platform to have some semblance of
> > > policy management to be relevant from a security/privacy
> > > perspective.  It would have certainly been collegial to include a
> > > reference to our discussions and concerns in the changelog.
> > >
> > > See 364f68f5a3c in Jarkko's next/master.
> > >
> > > The changeset addresses enclave access to the PROVISION key but is
> > > still insufficient to deliver guarantees that are consistent with
> > > the SGX security model.  In order to achieve that, policy
> > > management needs to embrace the use of MRSIGNER values, which is
> > > what our SFLC patchset uses.
> > >
> > > The noted changeset actually implements most of the 'kernel bloat'
> > > that our SFLC patchset needs to bolt onto.
> > >
> > > As of yesterday afternoon next/master still won't initialize a
> > > non-trivial enclave.  Since there now appears to be a wholesale
> > > change in the driver architecture and UAPI we are sitting on the
> > > sidelines waiting for an indication all of that has some hope of
> > > working before we introduce our approach.
> > >
> > > Part of SFLC won't be popular but it is driven by clients who are
> > > actually paying for SGX security engineering and architectures.
> 
> > How many of these people are actually posting here?
> 
> None that I know of.
> 
> The individuals I was referring to are CISO's and security risk
> managers of multi-billion dollar corporations and/or 3-letter
> entities.  It has been my own personal observation that they don't
> have time to post to the Linux Kernel Mailing List.
> 
> The time they do spend on this technology seems to involve sitting in
> meetings and making decisions on whether or not to authorize capital
> expenditure budgets for Intel processors and chipsets, based on
> whether or not an SGX security stack can definably implement the
> security controls that are being imposed on their organizations by the
> government and/or their liability carriers.
> 
> Such issues may be out of mainstream kernel concerns but hopefully not
> conceptually elusive with respect to their implications.

Well, the process is anyway what it is. I'm sending v18 and you are free
to comment the code change associated with the provision.

/Jarkko