lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 2 May 2020 17:48:30 -0700
From:   Andy Lutomirski <>
To:     "Dr. Greg" <>
Cc:     Jarkko Sakkinen <>,
        Sean Christopherson <>,,,,,,,,,,,,,,,,,,,
Subject: Re: [PATCH v29 00/20] Intel SGX foundations

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

Powered by blists - more mailing lists