Date:   Sat, 2 May 2020 17:48:30 -0700
From:   Andy Lutomirski <luto@...capital.net>
To:     "Dr. Greg" <greg@...ellic.com>
Cc:     Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
        Sean Christopherson <sean.j.christopherson@...el.com>,
        torvalds@...ux-foundation.org, linux-kernel@...r.kernel.org,
        x86@...nel.org, linux-sgx@...r.kernel.org,
        akpm@...ux-foundation.org, dave.hansen@...el.com,
        nhorman@...hat.com, npmccallum@...hat.com, haitao.huang@...el.com,
        andriy.shevchenko@...ux.intel.com, tglx@...utronix.de,
        kai.svahn@...el.com, bp@...en8.de, josh@...htriplett.org,
        luto@...nel.org, kai.huang@...el.com, rientjes@...gle.com,
        cedric.xing@...el.com, puiterwijk@...hat.com
Subject: Re: [PATCH v29 00/20] Intel SGX foundations



> On May 2, 2020, at 4:05 PM, Dr. Greg <greg@...ellic.com> wrote:
> 
> On Thu, Apr 30, 2020 at 06:59:11AM +0300, Jarkko Sakkinen wrote:
> 
> Good afternoon, I hope the weekend is going well for everyone.
> 
>>> On Wed, Apr 29, 2020 at 08:14:59AM -0700, Sean Christopherson wrote:
>>> On Wed, Apr 29, 2020 at 08:23:29AM +0300, Jarkko Sakkinen wrote:
>>>> On Sun, Apr 26, 2020 at 11:57:53AM -0500, Dr. Greg wrote:
>>>>> On Wed, Apr 22, 2020 at 12:52:56AM +0300, Jarkko Sakkinen wrote:
>>>> 
>>>>>> The current implementation requires that the firmware sets
>>>>>> IA32_SGXLEPUBKEYHASH* MSRs as writable so that ultimately
>>>>>> the kernel can decide what enclaves it wants run. The
>>>>>> implementation does not create any bottlenecks to support
>>>>>> read-only MSRs later on.
>>>> 
>>>>> It seems highly unlikely that a driver implementation with any type of
>>>>> support for read-only launch control registers would ever get into the
>>>>> kernel.  All one needs to do is review the conversations that Matthew
>>>>> Garrett's lockdown patches engender to get a sense of that, ie:
>>>>> 
>>>>> https://lwn.net/Articles/818277/
>>>> 
>>>> We do not require read-only MSRs.
>>> 
>>> Greg is pointing out the opposite, that supporting read-only MSRs is highly
>>> unlikely to ever be supported in the mainline kernel.
> 
>> In a nutshell, what is wrong in the current code changes and what
>> *exactly* should we change? This is way too high level at the moment
>> at least for my limited brain capacity.
> 
> In a nutshell, the driver needs our patch that implements
> cryptographic policy management.
> 
> A patch that:
> 
> 1.) Does not change the default behavior of the driver.
> 
> 2.) Implements capabilities that are consistent with what the hardware
> was designed to do, but only at the discretion of the platform owner.
> 
> 3.) Has no impact on the driver architecture.
> 
> The only consumer for this driver are SGX runtimes.  To our knowledge,
> there exist only two complete runtime implementations, Intel's and
> ours.  It us unclear why our approach to the use of the technology
> should be discriminated against when it doesn't impact the other user
> community.

Can you clarify how exactly this patch set discriminates against your stack?

> 
> The Linux kernel that I have worked on and supported since 1992 has
> always focused on technical rationale and meritocracy rather then
> politics.  We would be interested in why our proposal for the driver
> fails on the former grounds rather then the latter.
> 
>> /Jarkko
> 
> Best wishes for a productive week.
> 
> Dr. Greg
> 
> As always,
> Dr. Greg Wettstein, Ph.D, Worker      Artisans in autonomously
> Enjellic Systems Development, LLC     self-defensive IOT platforms
> 4206 N. 19th Ave.                     and edge devices.
> Fargo, ND  58102
> PH: 701-281-1686                      EMAIL: greg@...ellic.com
> ------------------------------------------------------------------------------
> "The best way to predict the future is to invent it."
>                                -- Alan Kay

Powered by blists - more mailing lists