On Sat, May 02, 2020 at 05:48:30PM -0700, Andy Lutomirski wrote:
Good morning, I hope the week is starting well for everyone.
> > On May 2, 2020, at 4:05 PM, Dr. Greg <greg@xxxxxxxxxxxx> wrote:
> > 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 driver has no provisions for implementing cryptographically based
SGX policy management of any type.
Our stack is extremely lightweight with no external dependencies and
is used in privacy and security sensitive applications, including
financial services of certain types. There is a desire in this, and
other venues, to use cloud and edge resources with a strong guarantee
that the platforms have only had a known set of behaviors. The
current DAC based controls in the driver are insufficient to provide
those guarantees.
I believe I have discussed our use of SGX previously. In a nutshell,
we use SGX based modeling engines to supervise kernel based behavioral
namespaces, one enclave per namespace. The closest equivalent work
that we have seen may be the IPE architecture advanced by Deven Bowers
at Microsoft but we address a number of issues that work does not,
including non-kernel based behavioral supervision.
We support the concern over hardware locked platforms and do not
disagree with the driver not supporting those platforms. That being
said, there is no technical rationale for not providing cryptographic
policy management on FLC based platforms, as I believe our patch
demonstrates.
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 platforms.
4206 N. 19th Ave.
Fargo, ND 58102
PH: 701-281-1686 EMAIL: greg@xxxxxxxxxxxx
------------------------------------------------------------------------------
"Can't they?
A 64bit number incremented every millisecond can grow for half a
billion years. As far as I'm concerned, that is forever."
-- Neil Brown
linux-raid
