Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1391382 > unrolled thread

Re: [PATCH 0/6] Intel Secure Guard Extensions

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 0/6] Intel Secure Guard Extensions Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> - 2016-04-29 22:20 +0200
    Re: [PATCH 0/6] Intel Secure Guard Extensions "Austin S. Hemmelgarn" <ahferroin7@gmail.com> - 2016-05-02 17:40 +0200
      Re: [PATCH 0/6] Intel Secure Guard Extensions "Dr. Greg Wettstein" <greg@enjellic.com> - 2016-05-03 11:30 +0200
        Re: [PATCH 0/6] Intel Secure Guard Extensions Pavel Machek <pavel@ucw.cz> - 2016-05-03 17:40 +0200
          Re: [PATCH 0/6] Intel Secure Guard Extensions "Dr. Greg Wettstein" <greg@enjellic.com> - 2016-05-04 11:10 +0200
            Re: [PATCH 0/6] Intel Secure Guard Extensions Pavel Machek <pavel@ucw.cz> - 2016-05-04 13:10 +0200
        Re: [PATCH 0/6] Intel Secure Guard Extensions Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> - 2016-05-06 13:40 +0200
          Re: [PATCH 0/6] Intel Secure Guard Extensions Thomas Gleixner <tglx@linutronix.de> - 2016-05-06 14:00 +0200
            Re: [PATCH 0/6] Intel Secure Guard Extensions Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> - 2016-05-09 07:40 +0200
              Re: [PATCH 0/6] Intel Secure Guard Extensions Thomas Gleixner <tglx@linutronix.de> - 2016-05-09 08:30 +0200
                Re: [PATCH 0/6] Intel Secure Guard Extensions Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> - 2016-05-09 11:30 +0200
                Re: [PATCH 0/6] Intel Secure Guard Extensions "Dr. Greg Wettstein" <greg@enjellic.com> - 2016-05-12 11:00 +0200
              Re: [PATCH 0/6] Intel Secure Guard Extensions Greg KH <gregkh@linuxfoundation.org> - 2016-05-09 09:10 +0200
                Re: [PATCH 0/6] Intel Secure Guard Extensions Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> - 2016-05-09 11:20 +0200
          Re: [PATCH 0/6] Intel Secure Guard Extensions "Dr. Greg Wettstein" <greg@enjellic.com> - 2016-05-08 12:00 +0200
            Re: [PATCH 0/6] Intel Secure Guard Extensions Andy Lutomirski <luto@amacapital.net> - 2016-05-09 03:40 +0200
      Re: [PATCH 0/6] Intel Secure Guard Extensions Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> - 2016-05-06 01:00 +0200
        Re: [PATCH 0/6] Intel Secure Guard Extensions Pavel Machek <pavel@ucw.cz> - 2016-05-06 09:20 +0200
          Re: [PATCH 0/6] Intel Secure Guard Extensions Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> - 2016-05-06 13:30 +0200

#1391382 — Re: [PATCH 0/6] Intel Secure Guard Extensions

On Tue, Apr 26, 2016 at 09:00:10PM +0200, Pavel Machek wrote:
> On Mon 2016-04-25 20:34:07, Jarkko Sakkinen wrote:
> > Intel(R) SGX is a set of CPU instructions that can be used by
> > applications to set aside private regions of code and data.  The code
> > outside the enclave is disallowed to access the memory inside the
> > enclave by the CPU access control.
> > 
> > The firmware uses PRMRR registers to reserve an area of physical memory
> > called Enclave Page Cache (EPC). There is a hardware unit in the
> > processor called Memory Encryption Engine. The MEE encrypts and decrypts
> > the EPC pages as they enter and leave the processor package.
> 
> What are non-evil use cases for this?

I'm not sure what you mean by non-evil.

> 
> 									Pavel
> 
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

/Jarkko

[toc] | [next] | [standalone]

#1392309

On 2016-04-29 16:17, Jarkko Sakkinen wrote:
> On Tue, Apr 26, 2016 at 09:00:10PM +0200, Pavel Machek wrote:
>> On Mon 2016-04-25 20:34:07, Jarkko Sakkinen wrote:
>>> Intel(R) SGX is a set of CPU instructions that can be used by
>>> applications to set aside private regions of code and data.  The code
>>> outside the enclave is disallowed to access the memory inside the
>>> enclave by the CPU access control.
>>>
>>> The firmware uses PRMRR registers to reserve an area of physical memory
>>> called Enclave Page Cache (EPC). There is a hardware unit in the
>>> processor called Memory Encryption Engine. The MEE encrypts and decrypts
>>> the EPC pages as they enter and leave the processor package.
>>
>> What are non-evil use cases for this?
>
> I'm not sure what you mean by non-evil.
>
I would think that this should be pretty straightforward.  Pretty much 
every security technology integrated in every computer in existence has 
the potential to be used by malware for various purposes.  Based on a 
cursory look at SGX, it is pretty easy to figure out how to use this to 
hide arbitrary code from virus scanners and the OS itself unless you 
have some way to force everything to be a debug enclave, which entirely 
defeats the stated purpose of the extensions.  I can see this being 
useful for tight embedded systems.  On a desktop which I have full 
control of physical access to though, it's something I'd immediately 
turn off, because the risk of misuse is so significant (I've done so on 
my new Thinkpad L560 too, although that's mostly because Linux doesn't 
support it yet).

[toc] | [prev] | [next] | [standalone]

#1393230

On May 2, 11:37am, "Austin S. Hemmelgarn" wrote:
} Subject: Re: [PATCH 0/6] Intel Secure Guard Extensions

Good morning, I hope the day is starting out well for everyone.

> On 2016-04-29 16:17, Jarkko Sakkinen wrote:
> > On Tue, Apr 26, 2016 at 09:00:10PM +0200, Pavel Machek wrote:
> >> On Mon 2016-04-25 20:34:07, Jarkko Sakkinen wrote:
> >>> Intel(R) SGX is a set of CPU instructions that can be used by
> >>> applications to set aside private regions of code and data.  The code
> >>> outside the enclave is disallowed to access the memory inside the
> >>> enclave by the CPU access control.
> >>>
> >>> The firmware uses PRMRR registers to reserve an area of physical memory
> >>> called Enclave Page Cache (EPC). There is a hardware unit in the
> >>> processor called Memory Encryption Engine. The MEE encrypts and decrypts
> >>> the EPC pages as they enter and leave the processor package.
> >>
> >> What are non-evil use cases for this?
> >
> > I'm not sure what you mean by non-evil.

> I would think that this should be pretty straightforward.  Pretty
> much every security technology integrated in every computer in
> existence has the potential to be used by malware for various
> purposes.  Based on a cursory look at SGX, it is pretty easy to
> figure out how to use this to hide arbitrary code from virus
> scanners and the OS itself unless you have some way to force
> everything to be a debug enclave, which entirely defeats the stated
> purpose of the extensions.  I can see this being useful for tight
> embedded systems.  On a desktop which I have full control of
> physical access to though, it's something I'd immediately turn off,
> because the risk of misuse is so significant (I've done so on my new
> Thinkpad L560 too, although that's mostly because Linux doesn't
> support it yet).

We were somewhat surprised to see Intel announce the SGX driver for
Linux without a bit more community preparation given the nature of the
technology.  But, given the history of opacity around this technology,
it probably isn't surprising.  We thought it may be useful to offer a
few thoughts on this technology as discussion around integrating the
driver moves forward.

We have been following and analyzing this technology since the first
HASP paper was published detailing its development.  We have been
working to integrate, at least at the simulator level, portions of
this technology in solutions we deliver.  We have just recently begun
to acquire validated reference platforms to test these
implementations.

I told my associates the first time I reviewed this technology that
SGX has the ability to be a bit of a Pandora's box and it seems to be
following that course.

SGX belongs to a genre of solutions collectively known as Trusted
Execution Environments (TEE's).  The intent of these platforms is to
support data and application confidentiality and integrity in the face
of an Iago threat environment, ie. a situation where a security
aggressor has complete control of the hardware and operating system,
up to and including the OS 'lying' about what it is doing to the
application.

There are those, including us, who question the quality of the
security gurantee that can be provided but that doesn't diminish the
usefulness or demand for such technology.  If one buys the notion that
all IT delivery will move into the 'cloud' there is certainly a
rationale for a guarantee that clients can push data into a cloud
without concern for whether or not the platform is compromised or
being used to spy on the user's application or data.

As is the case with any security technology, the only way that such a
guarantee can be made is to have a definable origin or root of trust.
At the current time, and this may be the biggest problem with SGX, the
only origin for that root of trust is Intel itself.  Given the nature
and design of SGX this is actually a bilateral root of trust since
Intel, by signing a developer's enclave key, is trusting the developer
to agree to do nothing nefarious while being shrouded by the security
guarantee that SGX provides.

It would be helpful and instructive for anyone involved in this debate
to review the following URL which details Intel's SGX licening
program:

https://software.intel.com/en-us/articles/intel-sgx-product-licensing

Which details what a developer is required to do in order to obtain an
enclave signing key which will be recognized by an SGX capable
processor.   Without a valid signing key an SGX capable system will
only launch an enclave in 'debug' mode which allows the enclave to be
single stepped and examined in a debugger, which obviously invalidates
any TEE based security guarantees which SGX is designed to effect.

Intel is obviously cognizant of the risk surrounding illicit uses of
this technology since it clearly calls out that, by agreeing to have
their key signed, a developer agrees to not implement nefarious or
privacy invasive software.  Given the known issues that Certificate
Authorities have with validating certificate recipients the security
guarantee inherent in such an agreement is questionable.

So, giving Intel the benefit of the doubt, the licensing issues
surrounding SGX is probably more about cognizance of the security risk
associated with the technology rather then a quest for world
domination and control.  They probably have enough on their hands with
attempting to convert humanity to FPGA's and away from devices which
are capable of maintaining a context of exection... :-)

The much bigger debate is about the utility of the security guarantee
inherent in SGX.  Anyone who is interested in understanding all of the
issues surrounding this technology would do well to start by reading
the Haven paper in which Microsoft Research discussed how SGX could be
used to run unmodified Windows applications within an SGX TEE.

I think Intel was somewhat sobered by the follow on paper in which
Microsoft demonstrated that in an Iago environment an interloper was
capable of determing with accuracy levels greater then 60% what was
being done in an SGX TEE.  Matt Hoekstra was very quick to call out
the need for the community to understand and develop side channel
remediation strategies which anyone familiar with the field would have
anticipated to be the primary threat to attempting to induct security
into a completely insecure environment.

One of the participants in the thread suggested that one of the
'non-evil' uses of this technology would be to run virtual machines
and by extensions containers.  It is pretty obvious at this point that
Intel has shifted to advocating limiting the scope of SGX to providing
protection to isolated applications and data, think password managers,
rather then as a wholesale execution shroud.  That is the role we have
leveraged SGX for in our security supervisor.

At the end of the day it is very, very difficult to give up complete
platform control and maintain integrity and confidentiality guarantees
about an application and the data it is operating on.  With its recent
re-organization Intel is obviously going to be heavily focused on the
cloud and the the notion of TEE's are seductive, particularly for data
in which there is no ex-post-facto regress in the face of compromise.

I think the only way forward to make all of this palatable is to
embrace something similar to what has been done with Secure Boot.  The
Root Enclave Key will need to be something which can be reconfigured
by the Platform Owner through BIOS/EFI.  That model would take Intel
off the hook from a security perspective and establish the notion of
platform trust to be a bilateral relationship between a service
provider and client.

This note is probably a study in TL;DR but this technology is not
inherently evil nor a ubiquitous security solution.  It is simply
another arrow in the quiver and as Satya Nadella from Microsoft has
pointed out, the mess we have gotten ourselves in is not going to be
amenable to a simple or single fix.

In the TL;DR department I would highly recommend that anyone
interested in all of this read MIT's 170+ page review of the
technology before jumping to any conclusions.... :-)

Best wishes for a productive week.

Greg

}-- End of excerpt from "Austin S. Hemmelgarn"

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"If you plugged up your nose and mouth right before you sneezed, would
 the sneeze go out your ears or would your head explode?  Either way I'm
 afraid to try."
                                -- Nick Kean

[toc] | [prev] | [next] | [standalone]

#1393543

Hi!

> We have been following and analyzing this technology since the first
> HASP paper was published detailing its development.  We have been

(1)

> 
> I told my associates the first time I reviewed this technology that
> SGX has the ability to be a bit of a Pandora's box and it seems to be
> following that course.

Can you elaborate on the Pandora's box? System administrator should be able to
disable SGX on the system, and use system to do anything that could be done with
the older CPUs, right?

> support data and application confidentiality and integrity in the face
> of an Iago threat environment, ie. a situation where a security

(2)

> Intel is obviously cognizant of the risk surrounding illicit uses of
> this technology since it clearly calls out that, by agreeing to have
> their key signed, a developer agrees to not implement nefarious or
> privacy invasive software.  Given the known issues that Certificate

Yeah, that's likely to work ... not :-(. "It is not spyware, it is just
collecting some anonymous statistics."

> domination and control.  They probably have enough on their hands with
> attempting to convert humanity to FPGA's and away from devices which
> are capable of maintaining a context of exection... :-)

Heh. FPGAs are not designed to replace CPUs anytime soon... And probably never.

> the Haven paper in which Microsoft Research discussed how SGX could be
> used to run unmodified Windows applications within an SGX TEE.

(3)

> I think Intel was somewhat sobered by the follow on paper in which
> Microsoft demonstrated that in an Iago environment an interloper was
> capable of determing with accuracy levels greater then 60% what was
> being done in an SGX TEE.  Matt Hoekstra was very quick to call out
> the need for the community to understand and develop side channel

(4)

> In the TL;DR department I would highly recommend that anyone
> interested in all of this read MIT's 170+ page review of the
> technology before jumping to any conclusions.... :-)

(5)

Would you have links for 1-5?

Thanks,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1394102

On Tue, May 03, 2016 at 05:38:40PM +0200, Pavel Machek wrote:

> Hi!

Good morning, I hope everyone's day is starting out well.

> > I told my associates the first time I reviewed this technology that
> > SGX has the ability to be a bit of a Pandora's box and it seems to be
> > following that course.

> Can you elaborate on the Pandora's box? System administrator should
> be able to disable SGX on the system, and use system to do anything
> that could be done with the older CPUs, right?

Correct, there is certainly the on/off switch.

I viewed it as a Pandora's box secondary to the fact that it was the
first commodity based shrouded TEE that had the opportunity for
significant market penetration.  As such and secondary to its
technical characteristics, it has the potential for both good and bad
and like TXT in the last decade it was/is bound to induce significant
debate secondary to software freedom and potential monopolistic
practices.

> > Intel is obviously cognizant of the risk surrounding illicit uses of
> > this technology since it clearly calls out that, by agreeing to have
> > their key signed, a developer agrees to not implement nefarious or
> > privacy invasive software.  Given the known issues that Certificate

> Yeah, that's likely to work ... not :-(. "It is not spyware, it is
> just collecting some anonymous statistics."

The notion that an enclave can look out but could not be looked into
introduces privacy issues into the conversation, see my reflections on
Pandoras box... :-)

> > domination and control.  They probably have enough on their hands with
> > attempting to convert humanity to FPGA's and away from devices which
> > are capable of maintaining a context of exection... :-)

> Heh. FPGAs are not designed to replace CPUs anytime soon... And
> probably never.

Never is a long time.

Intel has clearly drawn a very significant line in the sand with
respect to FPGA technology if you read Krzanich's reflections
regarding his re-organization of Intel.  Whether or not they are
successful, they are going to declare a demarcation point with respect
to IOT devices which has the potential to impact the industry in
general and security in particular.  On one side are going to be FPGA
based devices and on the other side devices with a context of
execution.

I doesn't require a long stretch of the imagination to see hordes of
IOT devices with specific behaviors burned into them which export
sensor or telemetry data upstream.  Depending on how successful they
are with the Altera acquisition there are potentially positive
economic security factors which could be in play.

All of that is certainly not a conversation specific to SGX though.

> > In the TL;DR department I would highly recommend that anyone
> > interested in all of this read MIT's 170+ page review of the
> > technology before jumping to any conclusions.... :-)

> Would you have links for 1-5?

First off my apologies to the list as I loathe personal inaccuracy,
the MIT review paper is only 117 pages long.  I was typing the last
e-mail at 0405 in the morning and was scrambling for the opportunity
to get 50 minutes of sleep so my proofreading was sloppy... :-)

The following should provide ample bedstand reading material for those
interested in SGX and TEE's:

1.) HASP/SGX paper:
https://software.intel.com/sites/default/files/article/413939/hasp-2013-innovative-technology-for-attestation-and-sealing.pdf

2.) IAGO threat model:
https://cseweb.ucsd.edu/~hovav/dist/iago.pdf

3.) Haven paper:
http://research.microsoft.com/pubs/223450/osdi2014-haven.pdf

4.) Controlled sidechannel attacks:
http://research.microsoft.com/pubs/246400/ctrlchannels-oakland-2015.pdf

https://software.intel.com/en-us/blogs/2015/05/19/look-both-ways-and-watch-out-for-side-channels

5.) MIT/SGX analysis:
https://eprint.iacr.org/2016/086.pdf

> Thanks,
> 									Pavel

No problem, enjoy the reading.... :-)

Have a good day.

Greg

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"One problem with monolithic business structures is losing sight
 of the fundamental importance of mathematics.  Consider committees;
 commonly forgotten is the relationship that given a projection of N
 individuals to complete an assignment the most effective number of
 people to assign to the committee is given by f(N) = N - (N-1)."
                                -- Dr. G.W. Wettstein
                                   Guerrilla Tactics for Corporate Survival

[toc] | [prev] | [next] | [standalone]

#1394148

Hi!

> Good morning, I hope everyone's day is starting out well.

:-). Rainy day here.

> > > In the TL;DR department I would highly recommend that anyone
> > > interested in all of this read MIT's 170+ page review of the
> > > technology before jumping to any conclusions.... :-)
> 
> > Would you have links for 1-5?
> 
> First off my apologies to the list as I loathe personal inaccuracy,
> the MIT review paper is only 117 pages long.  I was typing the last
> e-mail at 0405 in the morning and was scrambling for the opportunity
> to get 50 minutes of sleep so my proofreading was sloppy... :-)

Thanks a lot for the links, I'd still say it was more accurate than
average for the lkml.

Best regards,
								Pavel
								
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1395794

On Tue, May 03, 2016 at 04:06:27AM -0500, Dr. Greg Wettstein wrote:
> It would be helpful and instructive for anyone involved in this debate
> to review the following URL which details Intel's SGX licening
> program:
> 
> https://software.intel.com/en-us/articles/intel-sgx-product-licensing

I think it would be good  to note that the licensing process is available
only for Windows. For Linux you can only use debug enclaves at the
moment. The default LE has "allow-all" policy for debug enclaves.

> I think the only way forward to make all of this palatable is to
> embrace something similar to what has been done with Secure Boot.  The
> Root Enclave Key will need to be something which can be reconfigured
> by the Platform Owner through BIOS/EFI.  That model would take Intel
> off the hook from a security perspective and establish the notion of
> platform trust to be a bilateral relationship between a service
> provider and client.

This concern has been raised many times now. Sadly this did not make
into Skyle but in future we will have one shot MSRs (can be set only
once per boot cycle) for defining your own root of trust.

/Jarkko

[toc] | [prev] | [next] | [standalone]

#1395813

On Fri, 6 May 2016, Jarkko Sakkinen wrote:

> On Tue, May 03, 2016 at 04:06:27AM -0500, Dr. Greg Wettstein wrote:
> > It would be helpful and instructive for anyone involved in this debate
> > to review the following URL which details Intel's SGX licening
> > program:
> > 
> > https://software.intel.com/en-us/articles/intel-sgx-product-licensing
> 
> I think it would be good  to note that the licensing process is available
> only for Windows. For Linux you can only use debug enclaves at the
> moment. The default LE has "allow-all" policy for debug enclaves.

Which makes the feature pretty useless.
 
> > I think the only way forward to make all of this palatable is to
> > embrace something similar to what has been done with Secure Boot.  The
> > Root Enclave Key will need to be something which can be reconfigured
> > by the Platform Owner through BIOS/EFI.  That model would take Intel
> > off the hook from a security perspective and establish the notion of
> > platform trust to be a bilateral relationship between a service
> > provider and client.
> 
> This concern has been raised many times now. Sadly this did not make
> into Skyle but in future we will have one shot MSRs (can be set only
> once per boot cycle) for defining your own root of trust.

We'll wait for that to happen.

Thanks,

	tglx

[toc] | [prev] | [next] | [standalone]

#1396595

On Fri, May 06, 2016 at 01:54:14PM +0200, Thomas Gleixner wrote:
> On Fri, 6 May 2016, Jarkko Sakkinen wrote:
> 
> > On Tue, May 03, 2016 at 04:06:27AM -0500, Dr. Greg Wettstein wrote:
> > > It would be helpful and instructive for anyone involved in this debate
> > > to review the following URL which details Intel's SGX licening
> > > program:
> > > 
> > > https://software.intel.com/en-us/articles/intel-sgx-product-licensing
> > 
> > I think it would be good  to note that the licensing process is available
> > only for Windows. For Linux you can only use debug enclaves at the
> > moment. The default LE has "allow-all" policy for debug enclaves.
> 
> Which makes the feature pretty useless.
>  
> > > I think the only way forward to make all of this palatable is to
> > > embrace something similar to what has been done with Secure Boot.  The
> > > Root Enclave Key will need to be something which can be reconfigured
> > > by the Platform Owner through BIOS/EFI.  That model would take Intel
> > > off the hook from a security perspective and establish the notion of
> > > platform trust to be a bilateral relationship between a service
> > > provider and client.
> > 
> > This concern has been raised many times now. Sadly this did not make
> > into Skyle but in future we will have one shot MSRs (can be set only
> > once per boot cycle) for defining your own root of trust.
> 
> We'll wait for that to happen.

I fully understand if you (and others) want to keep this standpoint but
what if we could get it to staging after I've revised it with suggested
changes and internal changes in my TODO? Then it would not pollute the
mainline kernel but still would be easily available for experimentation.

There was one header out of staging tree in the patch set sgx.h that I
could place to the staging area in the next revision.

For the next revision I'll document how IA32_LEPUBKEYHASHx MSRs work
based on some concerns that Andy raised so that we can hopefully have a
better discussion about this feature.

> Thanks,
> 
> 	tglx

/Jarkko

[toc] | [prev] | [next] | [standalone]

#1396606

On Mon, 9 May 2016, Jarkko Sakkinen wrote:
> On Fri, May 06, 2016 at 01:54:14PM +0200, Thomas Gleixner wrote:
> > On Fri, 6 May 2016, Jarkko Sakkinen wrote:
> > 
> > > On Tue, May 03, 2016 at 04:06:27AM -0500, Dr. Greg Wettstein wrote:
> > > > It would be helpful and instructive for anyone involved in this debate
> > > > to review the following URL which details Intel's SGX licening
> > > > program:
> > > > 
> > > > https://software.intel.com/en-us/articles/intel-sgx-product-licensing
> > > 
> > > I think it would be good  to note that the licensing process is available
> > > only for Windows. For Linux you can only use debug enclaves at the
> > > moment. The default LE has "allow-all" policy for debug enclaves.
> > 
> > Which makes the feature pretty useless.
> >  
> > > > I think the only way forward to make all of this palatable is to
> > > > embrace something similar to what has been done with Secure Boot.  The
> > > > Root Enclave Key will need to be something which can be reconfigured
> > > > by the Platform Owner through BIOS/EFI.  That model would take Intel
> > > > off the hook from a security perspective and establish the notion of
> > > > platform trust to be a bilateral relationship between a service
> > > > provider and client.
> > > 
> > > This concern has been raised many times now. Sadly this did not make
> > > into Skyle but in future we will have one shot MSRs (can be set only
> > > once per boot cycle) for defining your own root of trust.
> > 
> > We'll wait for that to happen.
> 
> I fully understand if you (and others) want to keep this standpoint but
> what if we could get it to staging after I've revised it with suggested

This should not go to staging at all. Either this is going to be a real useful
driver or we just keep it out of tree.

> changes and internal changes in my TODO? Then it would not pollute the
> mainline kernel but still would be easily available for experimentation.

How are we supposed to experiment with that if there is no launch enclave for
Linux available?

Thanks,

	tglx

[toc] | [prev] | [next] | [standalone]

#1396876

On Mon, May 09, 2016 at 08:27:04AM +0200, Thomas Gleixner wrote:
> On Mon, 9 May 2016, Jarkko Sakkinen wrote:
> > On Fri, May 06, 2016 at 01:54:14PM +0200, Thomas Gleixner wrote:
> > > On Fri, 6 May 2016, Jarkko Sakkinen wrote:
> > > 
> > > > On Tue, May 03, 2016 at 04:06:27AM -0500, Dr. Greg Wettstein wrote:
> > > > > It would be helpful and instructive for anyone involved in this debate
> > > > > to review the following URL which details Intel's SGX licening
> > > > > program:
> > > > > 
> > > > > https://software.intel.com/en-us/articles/intel-sgx-product-licensing
> > > > 
> > > > I think it would be good  to note that the licensing process is available
> > > > only for Windows. For Linux you can only use debug enclaves at the
> > > > moment. The default LE has "allow-all" policy for debug enclaves.
> > > 
> > > Which makes the feature pretty useless.
> > >  
> > > > > I think the only way forward to make all of this palatable is to
> > > > > embrace something similar to what has been done with Secure Boot.  The
> > > > > Root Enclave Key will need to be something which can be reconfigured
> > > > > by the Platform Owner through BIOS/EFI.  That model would take Intel
> > > > > off the hook from a security perspective and establish the notion of
> > > > > platform trust to be a bilateral relationship between a service
> > > > > provider and client.
> > > > 
> > > > This concern has been raised many times now. Sadly this did not make
> > > > into Skyle but in future we will have one shot MSRs (can be set only
> > > > once per boot cycle) for defining your own root of trust.
> > > 
> > > We'll wait for that to happen.
> > 
> > I fully understand if you (and others) want to keep this standpoint but
> > what if we could get it to staging after I've revised it with suggested
> 
> This should not go to staging at all. Either this is going to be a real useful
> driver or we just keep it out of tree.
> 
> > changes and internal changes in my TODO? Then it would not pollute the
> > mainline kernel but still would be easily available for experimentation.
> 
> How are we supposed to experiment with that if there is no launch enclave for
> Linux available?

Understood.

I appreciate all the feedback that I've received and come back later
when the time is better with a refined patch set (especially Andys
feedback showed that the documentation needs alot of rework).

> Thanks,
> 
> 	tglx

/Jarkko

[toc] | [prev] | [next] | [standalone]

#1399781

On Mon, May 09, 2016 at 08:27:04AM +0200, Thomas Gleixner wrote:

Good morning.

> > On Fri, 6 May 2016, Jarkko Sakkinen wrote:
> > I fully understand if you (and others) want to keep this standpoint but
> > what if we could get it to staging after I've revised it with suggested
> >
> This should not go to staging at all. Either this is going to be a
> real useful driver or we just keep it out of tree.
> >
> > changes and internal changes in my TODO? Then it would not pollute the
> > mainline kernel but still would be easily available for experimentation.

> How are we supposed to experiment with that if there is no launch
> enclave for Linux available?

Build one in a simulator where an independent root enclave key can be
established.  At least thats the approach we are working on with
Jarkko's patches.

Intel does have an instruction accurate simulator, Microsoft used it
for the work which was reported in the Haven paper.  I believe the Air
Force academy used that simulator for their work on SGX as well.

As with other issues SGX related it is unclear why access to the
simulator was/is restricted.  Given that Gen6 hardware is now emerging
there would seem to be even less reason to not have the simulator
generically available to allow implementations to be tested.

> Thanks,
> 
> 	tglx

Have a good day.

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"Everything should be made as simple as possible, but not simpler."
                                -- Albert Einstein

[toc] | [prev] | [next] | [standalone]

#1396633

On Mon, May 09, 2016 at 08:38:25AM +0300, Jarkko Sakkinen wrote:
> On Fri, May 06, 2016 at 01:54:14PM +0200, Thomas Gleixner wrote:
> > On Fri, 6 May 2016, Jarkko Sakkinen wrote:
> > 
> > > On Tue, May 03, 2016 at 04:06:27AM -0500, Dr. Greg Wettstein wrote:
> > > > It would be helpful and instructive for anyone involved in this debate
> > > > to review the following URL which details Intel's SGX licening
> > > > program:
> > > > 
> > > > https://software.intel.com/en-us/articles/intel-sgx-product-licensing
> > > 
> > > I think it would be good  to note that the licensing process is available
> > > only for Windows. For Linux you can only use debug enclaves at the
> > > moment. The default LE has "allow-all" policy for debug enclaves.
> > 
> > Which makes the feature pretty useless.
> >  
> > > > I think the only way forward to make all of this palatable is to
> > > > embrace something similar to what has been done with Secure Boot.  The
> > > > Root Enclave Key will need to be something which can be reconfigured
> > > > by the Platform Owner through BIOS/EFI.  That model would take Intel
> > > > off the hook from a security perspective and establish the notion of
> > > > platform trust to be a bilateral relationship between a service
> > > > provider and client.
> > > 
> > > This concern has been raised many times now. Sadly this did not make
> > > into Skyle but in future we will have one shot MSRs (can be set only
> > > once per boot cycle) for defining your own root of trust.
> > 
> > We'll wait for that to happen.
> 
> I fully understand if you (and others) want to keep this standpoint but
> what if we could get it to staging after I've revised it with suggested
> changes and internal changes in my TODO? Then it would not pollute the
> mainline kernel but still would be easily available for experimentation.

No, staging is not a "dumping ground", it's for code that is not ready
to be merged, and has some work left to do on it and it shows forward
progress on that goal.  I don't put things in there that the maintainers
of the subsystems it affects do not want merged.  See the many previous
examples of code that has been rejected for staging as examples of this.

sorry,

greg k-h

[toc] | [prev] | [next] | [standalone]

#1396874

On Mon, May 09, 2016 at 09:04:09AM +0200, Greg KH wrote:
> On Mon, May 09, 2016 at 08:38:25AM +0300, Jarkko Sakkinen wrote:
> > On Fri, May 06, 2016 at 01:54:14PM +0200, Thomas Gleixner wrote:
> > > On Fri, 6 May 2016, Jarkko Sakkinen wrote:
> > > 
> > > > On Tue, May 03, 2016 at 04:06:27AM -0500, Dr. Greg Wettstein wrote:
> > > > > It would be helpful and instructive for anyone involved in this debate
> > > > > to review the following URL which details Intel's SGX licening
> > > > > program:
> > > > > 
> > > > > https://software.intel.com/en-us/articles/intel-sgx-product-licensing
> > > > 
> > > > I think it would be good  to note that the licensing process is available
> > > > only for Windows. For Linux you can only use debug enclaves at the
> > > > moment. The default LE has "allow-all" policy for debug enclaves.
> > > 
> > > Which makes the feature pretty useless.
> > >  
> > > > > I think the only way forward to make all of this palatable is to
> > > > > embrace something similar to what has been done with Secure Boot.  The
> > > > > Root Enclave Key will need to be something which can be reconfigured
> > > > > by the Platform Owner through BIOS/EFI.  That model would take Intel
> > > > > off the hook from a security perspective and establish the notion of
> > > > > platform trust to be a bilateral relationship between a service
> > > > > provider and client.
> > > > 
> > > > This concern has been raised many times now. Sadly this did not make
> > > > into Skyle but in future we will have one shot MSRs (can be set only
> > > > once per boot cycle) for defining your own root of trust.
> > > 
> > > We'll wait for that to happen.
> > 
> > I fully understand if you (and others) want to keep this standpoint but
> > what if we could get it to staging after I've revised it with suggested
> > changes and internal changes in my TODO? Then it would not pollute the
> > mainline kernel but still would be easily available for experimentation.
> 
> No, staging is not a "dumping ground", it's for code that is not ready
> to be merged, and has some work left to do on it and it shows forward
> progress on that goal.  I don't put things in there that the maintainers
> of the subsystems it affects do not want merged.  See the many previous
> examples of code that has been rejected for staging as examples of this.
> 
> sorry,

NP, point taken.

> greg k-h

/Jarkko

[toc] | [prev] | [next] | [standalone]

#1396407

Hi, I hope the weekend is going well for everyone.

On Fri, May 06, 2016 at 02:39:44PM +0300, Jarkko Sakkinen wrote:
> On Tue, May 03, 2016 at 04:06:27AM -0500, Dr. Greg Wettstein wrote:
> > It would be helpful and instructive for anyone involved in this debate
> > to review the following URL which details Intel's SGX licening
> > program:
> > 
> > https://software.intel.com/en-us/articles/intel-sgx-product-licensing

> I think it would be good to note that the licensing process is
> available only for Windows. For Linux you can only use debug
> enclaves at the moment. The default LE has "allow-all" policy for
> debug enclaves.

As others have noted, unfortunately, this renders the technology
largely useless on Linux, at least for anything beyond
experimentation.  That is somewhat strange given that one of the
primary intentions of the technology is to push applications into
untrusted cloud environments, particularly given the use of Linux in
the 'cloud'.  So I guess Azure is the only security beneficiary at
this time... :-)

I assume that Intel will be releasing a launch enclave with its
upcoming Linux SDK?

> > I think the only way forward to make all of this palatable is to
> > embrace something similar to what has been done with Secure Boot.  The
> > Root Enclave Key will need to be something which can be reconfigured
> > by the Platform Owner through BIOS/EFI.  That model would take Intel
> > off the hook from a security perspective and establish the notion of
> > platform trust to be a bilateral relationship between a service
> > provider and client.

> This concern has been raised many times now. Sadly this did not make
> into Skyle but in future we will have one shot MSRs (can be set only
> once per boot cycle) for defining your own root of trust.

It is encouraging to hear that Intel will be implementing one shot
MSR's for the identity modulus signature.  That would be consistent
with what we would advocate for.

This now means the security of SGX on 'unlocked' platforms, at least
from a trust perspective, will be dependent on using TXT so as to
provide a hardware root of trust on which to base the SGX trust model.
I was out walking with Izzy our Golden Retriever last night and as I
thought about the implicatioins of all this I think the solution, at
least as we would implement it, will tie together rather nicely.

I would assume that everyone is using signed Launch Control Policies
(LCP) as we are.  This means that TXT/tboot already has access to the
public key which is used for the LCP data file signature.  It would
seem logical to have tboot compute the signature on that public key
and program that signature into the module signature registers.  That
would tie the hardware root of trust to the SGX root of trust.

If that is undesirable the other alternative would be to pass a custom
LCP policy element into tboot which would define the desired SGX
trust signature.

It is unfortunate that SGX took the path it did on Linux.  We actually
have application for the technology now in our security supervisor.

When you say that unlocked SGX did not make it into Skylake does this
mean we need to wait for a new micro-architecture or a die shrink?
Given that tick/tock is now expanding in time it would be useful to
have unlocked SGX be one of the extension features of Skylake.
Otherwise there is certainly no rush for the Linux driver... :-)

> /Jarkko

Have a good week.

Greg

As always,
Dr. G.W. Wettstein, Ph.D.   Enjellic Systems Development, LLC.
4206 N. 19th Ave.           Specializing in information infra-structure
Fargo, ND  58102            development.
PH: 701-281-1686
FAX: 701-281-3949           EMAIL: greg@enjellic.com
------------------------------------------------------------------------------
"If you get to thinkin' you're a person of some influence, try
 orderin' somebody else's dog around."
                                -- Cowboy Wisdom

[toc] | [prev] | [next] | [standalone]

#1396532

On May 8, 2016 2:59 AM, "Dr. Greg Wettstein" <greg@enjellic.com> wrote:
>
>
> This now means the security of SGX on 'unlocked' platforms, at least
> from a trust perspective, will be dependent on using TXT so as to
> provide a hardware root of trust on which to base the SGX trust model.

Can you explain what you mean by "trust"?  In particular, what kind of
"trust" would you have with a verified or trusted boot plus verified
SGX launch root key that you would not have in the complete absence of
hardware launch control.

I've heard multiple people say they want launch control but I've never
heard a cogent explanation of a threat model in which it's useful.

> I would assume that everyone is using signed Launch Control Policies
> (LCP) as we are.  This means that TXT/tboot already has access to the
> public key which is used for the LCP data file signature.  It would
> seem logical to have tboot compute the signature on that public key
> and program that signature into the module signature registers.  That
> would tie the hardware root of trust to the SGX root of trust.

Now I'm confused.  TXT, in theory*, lets you establish a good root of
trust for TPM PCR measurements.  So, with TXT, if you had one-shop
launch control MSRs, you could attest that you've locked the launch
control policy.

But what do you gain by doing such a thing?  All you're actually
attesting is that you locked it until the next reboot.  Someone who
subsequently compromises you can reboot you, bypass TXT on the next
boot, and launch any enclave they want.  In any event, SGX is supposed
to make it so that your enclaves remain secure regardless of what
happens to the kernel, so I'm at a loss for what you're trying to do.

* There are some serious concerns about the security of TXT.  SGX is
supposed to be better.

--Andy

[toc] | [prev] | [next] | [standalone]

#1395453

On Mon, May 02, 2016 at 11:37:52AM -0400, Austin S. Hemmelgarn wrote:
> On 2016-04-29 16:17, Jarkko Sakkinen wrote:
> >On Tue, Apr 26, 2016 at 09:00:10PM +0200, Pavel Machek wrote:
> >>On Mon 2016-04-25 20:34:07, Jarkko Sakkinen wrote:
> >>>Intel(R) SGX is a set of CPU instructions that can be used by
> >>>applications to set aside private regions of code and data.  The code
> >>>outside the enclave is disallowed to access the memory inside the
> >>>enclave by the CPU access control.
> >>>
> >>>The firmware uses PRMRR registers to reserve an area of physical memory
> >>>called Enclave Page Cache (EPC). There is a hardware unit in the
> >>>processor called Memory Encryption Engine. The MEE encrypts and decrypts
> >>>the EPC pages as they enter and leave the processor package.
> >>
> >>What are non-evil use cases for this?
> >
> >I'm not sure what you mean by non-evil.
> >
> I would think that this should be pretty straightforward.  Pretty much every
> security technology integrated in every computer in existence has the
> potential to be used by malware for various purposes.  Based on a cursory
> look at SGX, it is pretty easy to figure out how to use this to hide
> arbitrary code from virus scanners and the OS itself unless you have some
> way to force everything to be a debug enclave, which entirely defeats the
> stated purpose of the extensions.  I can see this being useful for tight
> embedded systems.  On a desktop which I have full control of physical access
> to though, it's something I'd immediately turn off, because the risk of
> misuse is so significant (I've done so on my new Thinkpad L560 too, although
> that's mostly because Linux doesn't support it yet).

The code in enclave binary is in clear text so it does not really
allow you to completely hide any code. It's a signed binary, not
encypted binary.

/Jarkko

[toc] | [prev] | [next] | [standalone]

#1395654

On Fri 2016-05-06 01:52:04, Jarkko Sakkinen wrote:
> On Mon, May 02, 2016 at 11:37:52AM -0400, Austin S. Hemmelgarn wrote:
> > On 2016-04-29 16:17, Jarkko Sakkinen wrote:
> > >On Tue, Apr 26, 2016 at 09:00:10PM +0200, Pavel Machek wrote:
> > >>On Mon 2016-04-25 20:34:07, Jarkko Sakkinen wrote:
> > >>>Intel(R) SGX is a set of CPU instructions that can be used by
> > >>>applications to set aside private regions of code and data.  The code
> > >>>outside the enclave is disallowed to access the memory inside the
> > >>>enclave by the CPU access control.
> > >>>
> > >>>The firmware uses PRMRR registers to reserve an area of physical memory
> > >>>called Enclave Page Cache (EPC). There is a hardware unit in the
> > >>>processor called Memory Encryption Engine. The MEE encrypts and decrypts
> > >>>the EPC pages as they enter and leave the processor package.
> > >>
> > >>What are non-evil use cases for this?
> > >
> > >I'm not sure what you mean by non-evil.
> > >
> > I would think that this should be pretty straightforward.  Pretty much every
> > security technology integrated in every computer in existence has the
> > potential to be used by malware for various purposes.  Based on a cursory
> > look at SGX, it is pretty easy to figure out how to use this to hide
> > arbitrary code from virus scanners and the OS itself unless you have some
> > way to force everything to be a debug enclave, which entirely defeats the
> > stated purpose of the extensions.  I can see this being useful for tight
> > embedded systems.  On a desktop which I have full control of physical access
> > to though, it's something I'd immediately turn off, because the risk of
> > misuse is so significant (I've done so on my new Thinkpad L560 too, although
> > that's mostly because Linux doesn't support it yet).
> 
> The code in enclave binary is in clear text so it does not really
> allow you to completely hide any code. It's a signed binary, not
> encypted binary.

Umm. Now you are evil.

Yes, the code that starts in the enclave may not be encrypted, but I'm
pretty sure the enclave will download some more code from remote
server after attestation... x86 or some kind of interpretted code.

(But of course we already know that the technology is evil, as only
Intel can use it, see Ingo's reply.)
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1395784

On Fri, May 06, 2016 at 09:14:43AM +0200, Pavel Machek wrote:
> On Fri 2016-05-06 01:52:04, Jarkko Sakkinen wrote:
> > On Mon, May 02, 2016 at 11:37:52AM -0400, Austin S. Hemmelgarn wrote:
> > > On 2016-04-29 16:17, Jarkko Sakkinen wrote:
> > > >On Tue, Apr 26, 2016 at 09:00:10PM +0200, Pavel Machek wrote:
> > > >>On Mon 2016-04-25 20:34:07, Jarkko Sakkinen wrote:
> > > >>>Intel(R) SGX is a set of CPU instructions that can be used by
> > > >>>applications to set aside private regions of code and data.  The code
> > > >>>outside the enclave is disallowed to access the memory inside the
> > > >>>enclave by the CPU access control.
> > > >>>
> > > >>>The firmware uses PRMRR registers to reserve an area of physical memory
> > > >>>called Enclave Page Cache (EPC). There is a hardware unit in the
> > > >>>processor called Memory Encryption Engine. The MEE encrypts and decrypts
> > > >>>the EPC pages as they enter and leave the processor package.
> > > >>
> > > >>What are non-evil use cases for this?
> > > >
> > > >I'm not sure what you mean by non-evil.
> > > >
> > > I would think that this should be pretty straightforward.  Pretty much every
> > > security technology integrated in every computer in existence has the
> > > potential to be used by malware for various purposes.  Based on a cursory
> > > look at SGX, it is pretty easy to figure out how to use this to hide
> > > arbitrary code from virus scanners and the OS itself unless you have some
> > > way to force everything to be a debug enclave, which entirely defeats the
> > > stated purpose of the extensions.  I can see this being useful for tight
> > > embedded systems.  On a desktop which I have full control of physical access
> > > to though, it's something I'd immediately turn off, because the risk of
> > > misuse is so significant (I've done so on my new Thinkpad L560 too, although
> > > that's mostly because Linux doesn't support it yet).
> > 
> > The code in enclave binary is in clear text so it does not really
> > allow you to completely hide any code. It's a signed binary, not
> > encypted binary.
> 
> Umm. Now you are evil.
> 
> Yes, the code that starts in the enclave may not be encrypted, but I'm
> pretty sure the enclave will download some more code from remote
> server after attestation... x86 or some kind of interpretted code.
> 
> (But of course we already know that the technology is evil, as only
> Intel can use it, see Ingo's reply.)

Somehow that email from Ingo dissolved to my inbox :( Anyway, I gave
now my response.

For my part I'll create a second revision of the patch set and update the
documentation so that it has reasonable explanation about root of trust
SGX.

> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

/Jarkko

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web