Re: [PATCH v40 00/24] Intel SGX foundations

[Andy Lutomirski]

On Tue, Nov 24, 2020 at 2:56 AM Dr. Greg <greg@xxxxxxxxxxxx> wrote:
>
> On Sat, Nov 21, 2020 at 08:25:23AM -0800, Dave Hansen wrote:
>

> You will get a fully 'git am' compliant patch, including a changelog.
>
> The changelog was written in a parlance consistent with someone who
> would have a basic understanding of the technology under review.  If
> this entire review and vetting process is being done absent that kind
> of understanding, then the case can be made that the kernel
> development process has larger issues on its hands.

No, it wasn't.

I have a fairly good understanding of SGX, and I told you quite
explicitly what was wrong with your changelog.  Understanding the
sentences you wrote and having the background is not at all the same
thing as extracting meaning from your writing.  Your patch conveyed no
information.  This email you just sent also conveys no information.



>
> Lets be honest though, that is not the case here, we have been talking
> about this issue for over a year, everyone involved with this
> technology knows what the problem is.
>
> Since LKML is copied, the basic issue is as follows:
>
> 1.) SGX as a technology is designed to execute code and operate on
> data in a manner that is confidential to inspection and impervious to
> modification and control by the kernel.
>
> 2.) The mindset of the driver developers is that the kernel should be
> the ultimate authority on what SGX is allowed to do.
>
> The two world views are inherently and technically incompatible and
> lead to a potential security dilemma for the kernel.  We simply
> advocate for an additional level of cryptographic security that
> supplements, not replaces, kernel controls to address this issue.

No, they are not.

The kernel can and will enforce policy on what SGX may do.  Your own
NAKked patch, in fact, does exactly this.  At the same time, SGX
provides security to the contents of enclaves.  These are not mutually
exclusive.


> Our patch has two external functions of around 30 lines (~1 screen)
> each that impact the driver.  The bulk of the 700 lines, all in one
> file, is boilerplate code, largely replicated for each instance,
> needed to read/write sysfs files and maintain four, nearly identical,
> linked lists.  If this is an insurmountable review burden then the
> kernel development process has larger problems on its hands.

Frankly, the largest problem in the kernel development process with
regards to SGX is the distraction created by your emails.  Please just
stop.

If you have something useful to say, distill it down to the smallest
amount of text that actually says what you're trying to say.  And
don't forget the part about "something useful to say".  If you do not
have something useful to say, please don't say it.