Re: [PATCH v29 00/20] Intel SGX foundations

[Thomas Gleixner <tglx@linutronix.de>]

Greg,

"Dr. Greg" <greg@enjellic.com> writes:
> As an aside, for those who haven't spent the last 5+ years of their
> life working with this technology.  SGX2 hardware platforms have the
> ability to allow unrestricted code execution in enclave context.

Unrestricted code execution even before loaded? Unrestricted by
priviledge levels?

> No amount of LSM or IMA interventions can provide any control over
> that.

They can restrict what is started and loaded before anything SGX
happens.

If you want to make real technical arguments then please be specific and
precise and spare us the handwaving marketing speak.

> In fact, the Confidential Computing Consortium, sponsored by none
> other then the Linux Foundation, has at its fundamental tenant,

And that's relevant to the technical question in which way?

> the notion of developing an eco-system that allows the execution of
> code and processing of data, over which, the owner or administrator of
> the platform has no visibility or control.  It would seem only logical
> that adversarial interests would indulge themseleves in those
> capabilities as well.
>
> With respect to SGX and these issues, cryptographic policy management
> is important for the same reason that 2-factor authentication is now
> considered standard practice in the security industry.
>
> We appreciate, Jarkko, that you feel that such infrastructure is
> optional, like virtualization support, and is something that can go in
> after the driver is mainlined.  As the diffstat for our patch points
> out, the proposed support has virtually no impact on the driver, the
> same cannot be said for virtualization capabilities.

The diffstat of your patch is irrelevant. What's relevant is the fact
that it is completely unreviewed and that it creates yet another user
space visible ABI with a noticable lack of documentation. 

> Moreover, adding support for key based policy management later would
> require the addition of another ioctl in order to avoid ABI
> compatibility issues.

And that's a problem because? 

> The current initialization ioctl is best suited, from an engineering
> perspective, to support this type of infrastructure.

What's wrong with having IOCTL_INIT_TYPE_A and IOCTL_INIT_TYPE_B?

Nothing at all. It's pretty straight forward and in fact a better
solution than a duct taped multiplexing all in one IOCTL_INIT_PONIES
approach.

> In fact, the necessary support was removed from the ioctl for
> political reasons rather then for any valid engineering rationale on
> flexible launch control platforms, particularly with our patch or an
> equivalent approach.

You're surely making a convincing technical argument by claiming that
this was a political decision. The amount of non-technical, i.e.
political arguments in your mail is definitely larger than the technical
content.

> Hopefully this is a reasoned technical approach to what has been a
> long standing issue surrounding this technology.

It's an approach which guarantees that the driver will miss the next
merge window. If that's your intention, then please let us know.

Merging the current set of patches does not prevent anything you want to
be added. It's an extension to the base implementation and not a
prerequisite.

> Best wishes for a productive week.
>
> Dr. Greg

Thanks a lot for the best wishes. Unfortunately reading this email was
not necessarily productive for me, but I surely wish that you can make
productive use of my reply.

Thanks,

	tglx

> ------------------------------------------------------------------------------
> "Opportunity is missed by most people because it is dressed in overalls
>  and looks like work."
>                                 -- Thomas Edison

------------------------------------------------------------------------------
 "Failure is simply the opportunity to begin again, this time more
  intelligently"

				--  Henry Ford