lkml.org 
[lkml]   [2020]   [May]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v29 00/20] Intel SGX foundations
Date


> On May 2, 2020, at 4:05 PM, Dr. Greg <greg@enjellic.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@enjellic.com
> ------------------------------------------------------------------------------
> "The best way to predict the future is to invent it."
> -- Alan Kay

\
 
 \ /
  Last update: 2020-05-03 02:49    [W:0.202 / U:0.324 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site