Re: [PATCH v6 00/11] Intel SGX Driver

Re: [PATCH v6 00/11] Intel SGX Driver

[Dr. Greg Wettstein]

On Dec 27,  9:46pm, Pavel Machek wrote:
} Subject: Re: [PATCH v6 00/11] Intel SGX Driver

> Hi!

Good evening Pavel et.al., I hope the New Year has started well for
everyone.

> > > Would you list guarantees provided by SGX?
> >
> > Obviously, confidentiality and integrity.  SGX was designed to address
> > an Iago threat model, a very difficult challenge to address in
> > reality.

> Do you have link on "Iago threat model"?

https://cseweb.ucsd.edu/~hovav/dist/iago.pdf

> > I don't have the citation immediately available, but a bit-flip attack
> > has also been described on enclaves.  Due to the nature of the
> > architecture, they tend to crash the enclave so they are more in the
> > category of a denial-of-service attack, rather then a functional
> > confidentiality or integrity compromise.

> So ... even with SGX, host can generate bitflips in the enclave,
> right?

Correct.

Here is the reference I was trying to recall in my last e-mail:

https://sslab.gtisc.gatech.edu/assets/papers/2017/jang:sgx-bomb.pdf

> People usually assume that bitflip will lead "only" to
> denial-of-service, but rowhammer work shows that even "random" bit
> flips easily lead to priviledge escalation on javascript virtual
> machines, and in similar way you can get root if you have user and
> bit flips happen.
>
> So... I believe we should assume compromise is possible, not just
> denial-of-service.

Prudence always dictates that one assumes the worst.  In this case
however, the bitflip attacks against SGX enclaves are very definitely
in the denial-of-service category.  The attack is designed to trigger
a hardware self-protection feature on the processor.

Each page of memory which is initialized into an enclave has a
metadata block associated with it which contains the integrity state
of that page of memory.  The MM{E,U} hardware on an SGX capable
platform checks this integrity data on each page fetch request arising
from addresses/pages inside of an enclave.

Forcing a bitflip in enclave memory causes the next page fetch
containing the bitflipped location to fail its integrity check.  Since
this technically shouldn't be possible, this situation was classified
as a hardware failure which is handled by the processor locking its
execution state, thus taking the machine down.

It would seem to be a misfeature for the self-protection mechanism to
not generate some type of trappable fault rather then generating a
processor lockup but hindsight is always 20/20.  Philosophically this
is a good example of security risk managment.  Locking a machine is
obviously problematic in a cloud service environment, but it has to be
taken in the perspective of whether or not it would be preferable to
have a successful privilege escalation attack which could result in
exfiltration of sensitive data.

Philosophically we take the approach that for high security assurance
environments it is virtually impossible to allow any untrusted code to
run on a platform.  Which is why we focus on autonomous introspection
for these environments.

> > Unfortunately, in the security field it is way more fun, and
> > seemingly advantageous from a reputational perspective, to break
> > things then to build solutions.... :-)(

> Well, yes :-). And I believe someone is going to have fun with SGX
> ;-).
> 									Pavel

Arguably not as much fun as what appears to be pending, given what
appears to be the difficulty of some Intel processors to deal with
page faults induced by speculative memory references... :-)

Best wishes for a productive New Year.

Dr. Greg

}-- End of excerpt from Pavel Machek

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
------------------------------------------------------------------------------
"It is difficult to produce a television documentary that is both
 incisive and probing when every twelve minutes one is interrupted by
 twelve dancing rabbits singing about toilet paper."
                                -- Rod Serling

Re: [PATCH v6 00/11] Intel SGX Driver

[Christian Stroetmann]

On the 03.Jan.2018 01:59, Dr. Greg Wettstein wrote:

Hello everybody
> On Dec 27,  9:46pm, Pavel Machek wrote:
> } Subject: Re: [PATCH v6 00/11] Intel SGX Driver
>
>> Hi!

[snip]

>> People usually assume that bitflip will lead "only" to
>> denial-of-service, but rowhammer work shows that even "random" bit
>> flips easily lead to priviledge escalation on javascript virtual
>> machines, and in similar way you can get root if you have user and
>> bit flips happen.
>>
>> So... I believe we should assume compromise is possible, not just
>> denial-of-service.
> Prudence always dictates that one assumes the worst.  In this case
> however, the bitflip attacks against SGX enclaves are very definitely
> in the denial-of-service category.  The attack is designed to trigger
> a hardware self-protection feature on the processor.
>
> Each page of memory which is initialized into an enclave has a
> metadata block associated with it which contains the integrity state
> of that page of memory.  The MM{E,U} hardware on an SGX capable
> platform checks this integrity data on each page fetch request arising
> from addresses/pages inside of an enclave.
>
> Forcing a bitflip in enclave memory causes the next page fetch
> containing the bitflipped location to fail its integrity check.  Since
> this technically shouldn't be possible, this situation was classified
> as a hardware failure which is handled by the processor locking its
> execution state, thus taking the machine down.
>
> It would seem to be a misfeature for the self-protection mechanism to
> not generate some type of trappable fault rather then generating a
> processor lockup but hindsight is always 20/20.  Philosophically this
> is a good example of security risk managment.  Locking a machine is
> obviously problematic in a cloud service environment, but it has to be
> taken in the perspective of whether or not it would be preferable to
> have a successful privilege escalation attack which could result in
> exfiltration of sensitive data.
>
> Philosophically we take the approach that for high security assurance
> environments it is virtually impossible to allow any untrusted code to
> run on a platform.  Which is why we focus on autonomous introspection
> for these environments.

Interesting.
I would like to hear more about this autonomous introspection concept, 
specifically
what it monitors and how it reacts on an issue.

Maybe you have a summary or short introduction of the concept or/and a 
link to a document.



Regards
Christian Stroetmann

>>> Unfortunately, in the security field it is way more fun, and
>>> seemingly advantageous from a reputational perspective, to break
>>> things then to build solutions.... :-)(
>> Well, yes :-). And I believe someone is going to have fun with SGX
>> ;-).
>> 									Pavel
> Arguably not as much fun as what appears to be pending, given what
> appears to be the difficulty of some Intel processors to deal with
> page faults induced by speculative memory references... :-)
>
> Best wishes for a productive New Year.
>
> Dr. Greg
>
> }-- End of excerpt from Pavel Machek
>
> 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
> ------------------------------------------------------------------------------
> "It is difficult to produce a television documentary that is both
>   incisive and probing when every twelve minutes one is interrupted by
>   twelve dancing rabbits singing about toilet paper."
>                                  -- Rod Serling
>

Re: [PATCH v6 00/11] Intel SGX Driver

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 3855 bytes --]

Hi!

> Good evening Pavel et.al., I hope the New Year has started well for
> everyone.

:-). Stuff proceeds as usual. Too bad it is raining outside, instead
of snowing.

> > > > Would you list guarantees provided by SGX?
> > >
> > > Obviously, confidentiality and integrity.  SGX was designed to address
> > > an Iago threat model, a very difficult challenge to address in
> > > reality.
> 
> > Do you have link on "Iago threat model"?
> 
> https://cseweb.ucsd.edu/~hovav/dist/iago.pdf
> 
> > > I don't have the citation immediately available, but a bit-flip attack
> > > has also been described on enclaves.  Due to the nature of the
> > > architecture, they tend to crash the enclave so they are more in the
> > > category of a denial-of-service attack, rather then a functional
> > > confidentiality or integrity compromise.
> 
> > So ... even with SGX, host can generate bitflips in the enclave,
> > right?
> 
> Correct.

...

I'd say that you can't generate bitflips because if you do hardware
will kill the enclave. This seems to be significant difference from
AMD "secure" memory encryption...

> > People usually assume that bitflip will lead "only" to
> > denial-of-service, but rowhammer work shows that even "random" bit
> > flips easily lead to priviledge escalation on javascript virtual
> > machines, and in similar way you can get root if you have user and
> > bit flips happen.
> >
> > So... I believe we should assume compromise is possible, not just
> > denial-of-service.
> 
> Prudence always dictates that one assumes the worst.  In this case
> however, the bitflip attacks against SGX enclaves are very definitely
> in the denial-of-service category.  The attack is designed to trigger
> a hardware self-protection feature on the processor.
> 
> Each page of memory which is initialized into an enclave has a
> metadata block associated with it which contains the integrity state
> of that page of memory.  The MM{E,U} hardware on an SGX capable
> platform checks this integrity data on each page fetch request arising
> from addresses/pages inside of an enclave.
> 
> Forcing a bitflip in enclave memory causes the next page fetch
> containing the bitflipped location to fail its integrity check.  Since
> this technically shouldn't be possible, this situation was classified
> as a hardware failure which is handled by the processor locking its
> execution state, thus taking the machine down.

So you can't really do bitflips on the SGX protected memory, because
MM{E,U} hardware will catch that and kill machine if you try?

So SGX protected memory is not swappable?

> It would seem to be a misfeature for the self-protection mechanism to
> not generate some type of trappable fault rather then generating a
> processor lockup but hindsight is always 20/20.  Philosophically this
> is a good example of security risk managment.  Locking a machine is
> obviously problematic in a cloud service environment, but it has to be
> taken in the perspective of whether or not it would be preferable to
> have a successful privilege escalation attack which could result in
> exfiltration of sensitive data.

Ok, right, it should fault. They can fix it in new version?

> > Well, yes :-). And I believe someone is going to have fun with SGX
> > ;-).
> 
> Arguably not as much fun as what appears to be pending, given what
> appears to be the difficulty of some Intel processors to deal with
> page faults induced by speculative memory references... :-)

Do you have more info on that? Will they actually leak information, or
is it just good for rowhammering the kernel memory?


Best regards,
									Pavel

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH v6 00/11] Intel SGX Driver

[Jarkko Sakkinen]

On Thu, Feb 08, 2018 at 09:46:53AM +0100, Pavel Machek wrote:
> On Tue 2018-01-09 16:27:30, Jarkko Sakkinen wrote:
> > On Thu, Jan 04, 2018 at 03:17:24PM +0100, Cedric Blancher wrote:
> > > So how does this protect against the MELTDOWN attack (CVE-2017-5754)
> > > and the MELTATOMBOMBA4 worm which uses this exploit?
> > > 
> > > Ced
> > 
> > Everything going out of L1 gets encrypted. This is done to defend
> > against peripheral like adversaries and should work also against
> > meltdown.
> 
> Yeah, but useless against spectre and ability to introduce bit flips
> means this is generally useless...

You are right.

And what I said was simply false. In fact, the encryption is done in
LCC.  I'm sorry that I didn't response to my response and gave incorrect
info. I simply forgot to do this, no other excuses.

/Jarkko

Re: [PATCH v6 00/11] Intel SGX Driver

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 686 bytes --]

On Tue 2018-01-09 16:27:30, Jarkko Sakkinen wrote:
> On Thu, Jan 04, 2018 at 03:17:24PM +0100, Cedric Blancher wrote:
> > So how does this protect against the MELTDOWN attack (CVE-2017-5754)
> > and the MELTATOMBOMBA4 worm which uses this exploit?
> > 
> > Ced
> 
> Everything going out of L1 gets encrypted. This is done to defend
> against peripheral like adversaries and should work also against
> meltdown.

Yeah, but useless against spectre and ability to introduce bit flips
means this is generally useless...

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH v6 00/11] Intel SGX Driver

[Jarkko Sakkinen]

On Tue, Jan 09, 2018 at 03:50:23PM -0600, Dr. Greg Wettstein wrote:
> > Everything going out of L1 gets encrypted. This is done to defend
> > against peripheral like adversaries and should work also against
> > meltdown.
> 
> I don't believe this is an architecturally correct assertion.  The
> encryption/decryption occurs at the 'bottom' of the cache heirarchy.

You are right and I was wrong. It is plain from L1 to LLC, which implies
as you correctly described potential cache missing attacks in addition
to timing attacks.

/Jarkko

Re: [PATCH v6 00/11] Intel SGX Driver

[Dr. Greg Wettstein]

On Jan 9,  4:25pm, Jarkko Sakkinen wrote:
} Subject: Re: [PATCH v6 00/11] Intel SGX Driver

Good afternoon I hope the week is going well for everyone.

In order to minimize spamming mailboxes with two mails I'm
incorporating a reply to Jarkko's second e-mail on the Memory
Encryption Engine below as well, since the issues are all related.

> On Thu, Jan 04, 2018 at 03:06:43AM -0600, Dr. Greg Wettstein wrote:
> > If we are talking about the issues motivating the KPTI work I don't
> > have any useful information beyond what is raging through the industry
> > right now.
> > 
> > With respect to SGX, the issues giving rise to KPTI are characteristic
> > of what this technology is designed to address.  The technical 'news'
> > sites, which are even more of an abomination then usual with this
> > issue, are talking about privileged information such as credentials,
> > passwords et.al being leaked by this vulnerability.
> > 
> > Data committed to enclaves are only accessible by the enclave, even
> > the kernel, by definition, can't access the memory.  Given current
> > events that is an arguably useful behavior.

> Exactly. You could think adversary using meltdown leak utilizing
> malware as having same capabilities as peripheral connected to a
> bus, which we can defend against with SGX.

I believe caution needs to be applied to these statements

Since we design high assurance computing devices that use SGX to
protect our autonomous introspection engine, we obviously have very
significant concerns regarding whether the SGX security guarantees are
still operative in the face of these micro-architectural probing
attacks.  Absent official guidance, we have been pouring over the SGX
architectural documents for a week in order to develop risk guidance.

Based on that review, our conclusion was that there was nothing
inherent in the SGX architectural model that implies protection
against confidentiality losses through micro-architectural side
channel inspection.  Our conclusion was reinforced by a group in
London which has reportedly demonstrated the effectiveness of the
conditional branch misprediction exploit against data processed inside
of an enclave.

We have not yet verified the exploit in our lab, but given our
architectural review there would seem to be no reason why it shouldn't
work.  I posted a note to the SGX developer's forum early this morning
with a summary of our analysis but haven't received any responses.

To 'wit in summary.

In this attack scenario, the potential lack of confidentiality inside
of an enclave is the same as if the code was running in unprotected
memory space.  The MM{U,E} infrastructure is servicing micro-op
resource requests for instructions inside of an enclave, just as it
would normally do in untrusted space.  As a result, code running in an
enclave induces cache state changes which can be externally probed,
ie. the effects of a forced branch mispredict on cache state are the
same if the code executes inside of an enclave as if it were in
untrusted memory.

As I noted in my post to the SGX forum, this would be really
interesting if it could be done by an arbitrary process against an
enclave.  As the sample code demonstrates however, the exploit binary
has to be able to invoke at last two ECALL's (invocation of functions
in trusted space) in order to carry out the attack.  This is somewhat
analogous to an exploit where a process is able to attack its own
memory map.

With respect to the other mail:

> Everything going out of L1 gets encrypted. This is done to defend
> against peripheral like adversaries and should work also against
> meltdown.

I don't believe this is an architecturally correct assertion.  The
encryption/decryption occurs at the 'bottom' of the cache heirarchy.

Based on Shay Gueron's paper, which describes the Memory Encryption
Engine (MEE) and its security characteristics and proofs, the MEE acts
as an extension of the memory controller and mediates CACHE<->DRAM
traffic to the Enclave Page Cache (EPC), ie, the protected data
region.  It is responsible for encrypting and decrypting page data as
well as the generation of the tags which are used to populate the
Merkle integrity tree.

As I mentioned in a previous mail, the MEE is responsible for emitting
the 'drop and lock' verification signal which locks the memory
controller if a memory integrity check fails.  This is to support a
fundamental design tenant of the architecture that no unverified data
reaches the caches.

Based on this I believe all of the data in the caches is in plaintext,
not just from L1 upward.  So by inference, speculative execution is
able to induce the population of the caches with unencrypted data and
act on those results.  If this were not the case it would be difficult
to understand how the demonstrated branch mispredict attack could be
successful.

With respect to protecting access to memory, the SGX modified Page
Miss Handler (PMH) is designed to deny the final population of a TLB
slot if the page is from an 'untrusted' virtual<->physical mapping.
This occurs even later then the standard page access controls and it
was the 'lateness' of those checks, in comparison to the actual
population of the caches, which proved to be the particularly
problematic issue in Meltdown.

As a result, we remain very uneasy with respect to the confidentiality
guarantees that are available in the face of these attacks.  Luckily
we depend on the architecture for integrity.

> /Jarkko

We will try and see if we can get some engineering time to reproducing
the branch mispredict exploit that was published and report back.

Have a good evening.

Dr. Greg

}-- End of excerpt from Jarkko Sakkinen

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

Re: [PATCH v6 00/11] Intel SGX Driver

[Jarkko Sakkinen]

On Thu, Jan 04, 2018 at 03:17:24PM +0100, Cedric Blancher wrote:
> So how does this protect against the MELTDOWN attack (CVE-2017-5754)
> and the MELTATOMBOMBA4 worm which uses this exploit?
> 
> Ced

Everything going out of L1 gets encrypted. This is done to defend
against peripheral like adversaries and should work also against
meltdown.

/Jarkko

Re: [PATCH v6 00/11] Intel SGX Driver

[Jarkko Sakkinen]

On Thu, Jan 04, 2018 at 03:06:43AM -0600, Dr. Greg Wettstein wrote:
> If we are talking about the issues motivating the KPTI work I don't
> have any useful information beyond what is raging through the industry
> right now.
> 
> With respect to SGX, the issues giving rise to KPTI are characteristic
> of what this technology is designed to address.  The technical 'news'
> sites, which are even more of an abomination then usual with this
> issue, are talking about privileged information such as credentials,
> passwords et.al being leaked by this vulnerability.
> 
> Data committed to enclaves are only accessible by the enclave, even
> the kernel, by definition, can't access the memory.  Given current
> events that is an arguably useful behavior.

Exactly. You could think adversary using meltdown leak utilizing malware
as having same capabilities as peripheral connected to a bus, which we
can defend against with SGX.

/Jarkko

Re: [PATCH v6 00/11] Intel SGX Driver

[Dr. Greg Wettstein]

On Jan 4, 10:20am, Christian Stroetmann wrote:
} Subject: Re: [PATCH v6 00/11] Intel SGX Driver

> On the 04.Jan.2018 09:02, Dr. Greg Wettstein wrote:

> Aloha

I take it from that you are in Hawaii, if you are be glad, it is -27C
here.

> > AI as we call it.. :-), at a high level, is the notion that an
> > operating system platform can be modeled for its intended
> > behavior, just as is done for buildings, bridges and airplanes.
> > The model is based on a precise mathematical description of the
> > set of desired information exchange events that the operating
> > system will be allowed to mediate.

> So you have artificial intelligence in the operating system
> respectively kernel?

Artifical intelligence is a broad concept and we debate what that
means in the context of our work.

We provide a framework for the operating system to deterministically
know right from wrong, including the opportunity to act in very
granular ways with respect to how to respond if it believes it is
being asked to engage in illicit behavior.

We can debate semantics of intelligence or continue to lose the
information security battle, we fall on the side of trying to
build solutions... :-)

> What is with machine learning?

Mathematically, security behavior can be defined in the contex of a
behavioral field into two broad categories; extra-dimensional and
intra-dimensional

The interface between these two types of behavior is the point where
one needs to transition from deterministic to stochastic
methodologies.  The issues are not dissimilar to multi-scale modeling
in the physical world where one transitions from Quantum Mechanical to
Newtonian models.

We are working to understand how to apply ML techniques to analysis of
the stochastic field.  Not enough hours in the day though.

> Also, you need to ensure that your precise mathematical model is
> correct and that your code implements the model in a correct way.

No arguement there, although the deterministic model and its
implementation are straight forward.

> > Autonomous introspection is the notion of the platform using this
> > model to monitor and self-regulate its behavior.

> This sounds like somekind of a reflective functionality.

A further discussion would require a precise definition of 'reflective
functionality'.

> > Most notably the modeling and control engine have been lifted out
> > of the kernel into an SGX enclave.  In this architecture the
> > kernel cannot act without permission from the enclave based
> > engine, which requires the integrity of the enclave to be violated
> > in order to compromise the kernel.

> This would be ideal with a microkernel based operating system.

Interestingly enough, a proposal to implement exactly that, using
Linux as a server level process under seL4 was put on DARPA's I2O desk
18 months ago with limited success.  I believe it is safe to say there
was a conceptualization problem.

> > Thanks for the interest.

> I think that the others are also interested in this subject matter.

It has been an interesting quest to find that but the journey
continues.

> Regards
> Christian Stroetmann

Enjoy the warm weather if our opening supposition is correct.

Dr. Greg

}-- End of excerpt from Christian Stroetmann

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
------------------------------------------------------------------------------
"There are two things that are infinite; Human stupidity and the
 universe.  And I'm not sure about the universe."
                                -- Albert Einstein

Re: [PATCH v6 00/11] Intel SGX Driver

[Dr. Greg Wettstein]

On Jan 4,  3:27pm, Greg Kroah-Hartman wrote:
} Subject: Re: [PATCH v6 00/11] Intel SGX Driver

Wild day, enjoyed by all I'm sure.

> On Thu, Jan 04, 2018 at 03:17:24PM +0100, Cedric Blancher wrote:
> > So how does this protect against the MELTDOWN attack (CVE-2017-5754)
> > and the MELTATOMBOMBA4 worm which uses this exploit?

> It has nothing to do with it at all, sorry.

Precision seems to be everything in these discussions.

Since SGX obviously does not mitigate micro-architectural state
probing it is not an effective general remediation against MELTDOWN.
Does your statement indicate there is solid documentation that
MELTDOWN can be used by a process of any privilege level to dump out
the unencrypted contents of an initialized enclave?

That would obviously be a big story as well.

> greg k-h

Have a good evening.

Greg

}-- End of excerpt from Greg Kroah-Hartman

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

Re: [PATCH v6 00/11] Intel SGX Driver

[Ozgur]

04.01.2018, 17:30, "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>:
> On Thu, Jan 04, 2018 at 03:17:24PM +0100, Cedric Blancher wrote:
>>  So how does this protect against the MELTDOWN attack (CVE-2017-5754)
>>  and the MELTATOMBOMBA4 worm which uses this exploit?

Hello,

I think this exploit work Intel x64 and only Debian/Redhat/Suse distributions.
The read function was in effect terminating the memory in kernel space.

All distributions teams are published to updates, please keeps up-to-date.

Ozgur

> It has nothing to do with it at all, sorry.
>
> greg k-h

Re: [PATCH v6 00/11] Intel SGX Driver

[James Bottomley]

On Thu, 2018-01-04 at 15:17 +0100, Cedric Blancher wrote:
> So how does this protect against the MELTDOWN attack (CVE-2017-5754)
> and the MELTATOMBOMBA4 worm which uses this exploit?

Actually, a data exfiltration attack against SGX, using page tables has
already been documented:

https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/van-bulck

It doesn't exploit speculation as the mechanism for gathering data (it
exploits page faults), but the structure of the side channel attack
used to exfiltrate data from the supposedly secure enclave is very
similar to Spectre.  The targetting mechanism is very different,
though: the page table exploit assumes you can control the page tables,
so you must be highly privileged on the platform but with Spectre you
merely have to be an ordinary user.

James

Re: [PATCH v6 00/11] Intel SGX Driver

[Greg Kroah-Hartman]

On Thu, Jan 04, 2018 at 03:17:24PM +0100, Cedric Blancher wrote:
> So how does this protect against the MELTDOWN attack (CVE-2017-5754)
> and the MELTATOMBOMBA4 worm which uses this exploit?

It has nothing to do with it at all, sorry.

greg k-h

Re: [PATCH v6 00/11] Intel SGX Driver

[Cedric Blancher]

So how does this protect against the MELTDOWN attack (CVE-2017-5754)
and the MELTATOMBOMBA4 worm which uses this exploit?

Ced

On 25 November 2017 at 20:29, Jarkko Sakkinen
<jarkko.sakkinen@linux.intel.com> 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.
> In a way you can think that SGX provides inverted sandbox. It protects the
> application from a malicious host.
>
> There is a new hardware unit in the processor called Memory Encryption Engine
> (MEE) starting from the Skylake microacrhitecture. BIOS can define one or many
> MEE regions that can hold enclave data by configuring them with PRMRR
> registers.
>
> The MEE automatically encrypts the data leaving the processor package to the
> MEE regions. The data is encrypted using a random key whose life-time is
> exactly one power cycle.
>
> You can tell if your CPU supports SGX by looking into /proc/cpuinfo:
>
>         cat /proc/cpuinfo  | grep sgx
>
> The GIT repositoy for SGX driver resides in
>
>         https://github.com/jsakkine-intel/linux-sgx.git
>
> 'le' branch contains the upstream candidate patches.
>
> 'master' branch contains the same patches with the following differences:
>
> * top-level patch modifies the ioctl API to be SDK compatible
> * does not use flexible launch control but instead relies on SDK provided
>   Intel launch enclave.
>
> Backlog:
> * AES: how to use arch/x86/crypto/aesni-intel_asm.S from the enclave. I
>   guess these routines should be fairly easy to call directly (haven't
>   investigated deeply). Any advice is appreciated.
> * Layout: what and where to place in arch/x86.
> * MAINTAINERS: who to add as reviewer.
>
> v6
> * Fixed semaphore underrun when accessing /dev/sgx from the launch enclave.
> * In sgx_encl_create() s/IS_ERR(secs)/IS_ERR(encl)/.
> * Removed virtualization chapter from the documentation.
> * Changed the default filename for the signing key as signing_key.pem.
> * Reworked EPC management in a way that instead of a linked list of
>   struct sgx_epc_page instances there is an array of integers that
>   encodes address and bank of an EPC page (the same data as 'pa' field
>   earlier). The locking has been moved to the EPC bank level instead
>   of a global lock.
> * Relaxed locking requirements for EPC management. EPC pages can be
>   released back to the EPC bank concurrently.
> * Cleaned up ptrace() code.
> * Refined commit messages for new architectural constants.
> * Sorted includes in every source file.
> * Sorted local variable declarations according to the line length in
>   every function.
> * Style fixes based on Darren's comments to sgx_le.c.
>
> v5:
> * Described IPC between the Launch Enclave and kernel in the commit messages.
> * Fixed all relevant checkpatch.pl issues that I have forgot fix in earlier
>   versions except those that exist in the imported TinyCrypt code.
> * Fixed spelling mistakes in the documentation.
> * Forgot to check the return value of sgx_drv_subsys_init().
> * Encapsulated properly page cache init and teardown.
> * Collect epc pages to a temp list in sgx_add_epc_bank
> * Removed SGX_ENCLAVE_INIT_ARCH constant.
>
> v4:
> * Tied life-cycle of the sgx_le_proxy process to /dev/sgx.
> * Removed __exit annotation from sgx_drv_subsys_exit().
> * Fixed a leak of a backing page in sgx_process_add_page_req() in the
>   case when vm_insert_pfn() fails.
> * Removed unused symbol exports for sgx_page_cache.c.
> * Updated sgx_alloc_page() to require encl parameter and documented the
>   behavior (Sean Christopherson).
> * Refactored a more lean API for sgx_encl_find() and documented the behavior.
> * Moved #PF handler to sgx_fault.c.
> * Replaced subsys_system_register() with plain bus_register().
> * Retry EINIT 2nd time only if MSRs are not locked.
>
> v3:
> * Check that FEATURE_CONTROL_LOCKED and FEATURE_CONTROL_SGX_ENABLE are set.
> * Return -ERESTARTSYS in __sgx_encl_add_page() when sgx_alloc_page() fails.
> * Use unused bits in epc_page->pa to store the bank number.
> * Removed #ifdef for WQ_NONREENTRANT.
> * If mmu_notifier_register() fails with -EINTR, return -ERESTARTSYS.
> * Added --remove-section=.got.plt to objcopy flags in order to prevent a
>   dummy .got.plt, which will cause an inconsistent size for the LE.
> * Documented sgx_encl_* functions.
> * Added remark about AES implementation used inside the LE.
> * Removed redundant sgx_sys_exit() from le/main.c.
> * Fixed struct sgx_secinfo alignment from 128 to 64 bytes.
> * Validate miscselect in sgx_encl_create().
> * Fixed SSA frame size calculation to take the misc region into account.
> * Implemented consistent exception handling to __encls() and __encls_ret().
> * Implemented a proper device model in order to allow sysfs attributes
>   and in-kernel API.
> * Cleaned up various "find enclave" implementations to the unified
>   sgx_encl_find().
> * Validate that vm_pgoff is zero.
> * Discard backing pages with shmem_truncate_range() after EADD.
> * Added missing EEXTEND operations to LE signing and launch.
> * Fixed SSA size for GPRS region from 168 to 184 bytes.
> * Fixed the checks for TCS flags. Now DBGOPTIN is allowed.
> * Check that TCS addresses are in ELRANGE and not just page aligned.
> * Require kernel to be compiled with X64_64 and CPU_SUP_INTEL.
> * Fixed an incorrect value for SGX_ATTR_DEBUG from 0x01 to 0x02.
>
> v2:
> * get_rand_uint32() changed the value of the pointer instead of value
>   where it is pointing at.
> * Launch enclave incorrectly used sigstruct attributes-field instead of
>   enclave attributes-field.
> * Removed unused struct sgx_add_page_req from sgx_ioctl.c
> * Removed unused sgx_has_sgx2.
> * Updated arch/x86/include/asm/sgx.h so that it provides stub
>   implementations when sgx in not enabled.
> * Removed cruft rdmsr-calls from sgx_set_pubkeyhash_msrs().
> * return -ENOMEM in sgx_alloc_page() when VA pages consume too much space
> * removed unused global sgx_nr_pids
> * moved sgx_encl_release to sgx_encl.c
> * return -ERESTARTSYS instead of -EINTR in sgx_encl_init()
>
>
> Haim Cohen (1):
>   x86: add SGX MSRs to msr-index.h
>
> Jarkko Sakkinen (8):
>   intel_sgx: updated MAINTAINERS
>   x86: define IA32_FEATUE_CONTROL.SGX_LC
>   intel_sgx: driver for Intel Software Guard Extensions
>   intel_sgx: ptrace() support
>   intel_sgx: in-kernel launch enclave
>   fs/pipe.c: export create_pipe_files() and replace_fd()
>   intel_sgx: glue code for in-kernel LE
>   intel_sgx: driver documentation
>
> Kai Huang (1):
>   x86: add SGX definition to cpufeature
>
> Sean Christopherson (1):
>   x86: define IA32_FEATURE_CONTROL.SGX_ENABLE
>
>  Documentation/index.rst                            |   1 +
>  Documentation/x86/intel_sgx.rst                    | 101 +++
>  MAINTAINERS                                        |   5 +
>  arch/x86/include/asm/cpufeatures.h                 |   2 +
>  arch/x86/include/asm/msr-index.h                   |   8 +
>  arch/x86/include/asm/sgx.h                         | 233 +++++
>  arch/x86/include/asm/sgx_arch.h                    | 268 ++++++
>  arch/x86/include/uapi/asm/sgx.h                    | 138 +++
>  drivers/platform/x86/Kconfig                       |   2 +
>  drivers/platform/x86/Makefile                      |   1 +
>  drivers/platform/x86/intel_sgx/Kconfig             |  34 +
>  drivers/platform/x86/intel_sgx/Makefile            |  32 +
>  drivers/platform/x86/intel_sgx/le/Makefile         |  26 +
>  drivers/platform/x86/intel_sgx/le/enclave/Makefile |  46 +
>  .../x86/intel_sgx/le/enclave/aes_encrypt.c         | 191 ++++
>  .../platform/x86/intel_sgx/le/enclave/cmac_mode.c  | 254 ++++++
>  .../x86/intel_sgx/le/enclave/encl_bootstrap.S      | 163 ++++
>  .../intel_sgx/le/enclave/include/tinycrypt/aes.h   | 133 +++
>  .../le/enclave/include/tinycrypt/cmac_mode.h       | 194 ++++
>  .../le/enclave/include/tinycrypt/constants.h       |  59 ++
>  .../intel_sgx/le/enclave/include/tinycrypt/utils.h |  95 ++
>  drivers/platform/x86/intel_sgx/le/enclave/main.c   | 203 +++++
>  .../platform/x86/intel_sgx/le/enclave/sgx_le.lds   |  28 +
>  .../platform/x86/intel_sgx/le/enclave/sgxsign.c    | 538 +++++++++++
>  drivers/platform/x86/intel_sgx/le/enclave/utils.c  |  78 ++
>  drivers/platform/x86/intel_sgx/le/entry.S          | 117 +++
>  .../platform/x86/intel_sgx/le/include/sgx_asm.h    |  64 ++
>  .../platform/x86/intel_sgx/le/include/sgx_encl.h   | 110 +++
>  drivers/platform/x86/intel_sgx/le/main.c           | 214 +++++
>  drivers/platform/x86/intel_sgx/le/sgx_le_piggy.S   |  15 +
>  drivers/platform/x86/intel_sgx/sgx.h               | 268 ++++++
>  drivers/platform/x86/intel_sgx/sgx_encl.c          | 999 +++++++++++++++++++++
>  drivers/platform/x86/intel_sgx/sgx_ioctl.c         | 282 ++++++
>  drivers/platform/x86/intel_sgx/sgx_le.c            | 319 +++++++
>  .../platform/x86/intel_sgx/sgx_le_proxy_piggy.S    |  15 +
>  drivers/platform/x86/intel_sgx/sgx_main.c          | 456 ++++++++++
>  drivers/platform/x86/intel_sgx/sgx_page_cache.c    | 619 +++++++++++++
>  drivers/platform/x86/intel_sgx/sgx_util.c          | 394 ++++++++
>  drivers/platform/x86/intel_sgx/sgx_vma.c           | 236 +++++
>  fs/file.c                                          |   1 +
>  fs/pipe.c                                          |   1 +
>  41 files changed, 6943 insertions(+)
>  create mode 100644 Documentation/x86/intel_sgx.rst
>  create mode 100644 arch/x86/include/asm/sgx.h
>  create mode 100644 arch/x86/include/asm/sgx_arch.h
>  create mode 100644 arch/x86/include/uapi/asm/sgx.h
>  create mode 100644 drivers/platform/x86/intel_sgx/Kconfig
>  create mode 100644 drivers/platform/x86/intel_sgx/Makefile
>  create mode 100644 drivers/platform/x86/intel_sgx/le/Makefile
>  create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/Makefile
>  create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/aes_encrypt.c
>  create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/cmac_mode.c
>  create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/encl_bootstrap.S
>  create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/include/tinycrypt/aes.h
>  create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/include/tinycrypt/cmac_mode.h
>  create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/include/tinycrypt/constants.h
>  create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/include/tinycrypt/utils.h
>  create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/main.c
>  create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/sgx_le.lds
>  create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/sgxsign.c
>  create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/utils.c
>  create mode 100644 drivers/platform/x86/intel_sgx/le/entry.S
>  create mode 100644 drivers/platform/x86/intel_sgx/le/include/sgx_asm.h
>  create mode 100644 drivers/platform/x86/intel_sgx/le/include/sgx_encl.h
>  create mode 100644 drivers/platform/x86/intel_sgx/le/main.c
>  create mode 100644 drivers/platform/x86/intel_sgx/le/sgx_le_piggy.S
>  create mode 100644 drivers/platform/x86/intel_sgx/sgx.h
>  create mode 100644 drivers/platform/x86/intel_sgx/sgx_encl.c
>  create mode 100644 drivers/platform/x86/intel_sgx/sgx_ioctl.c
>  create mode 100644 drivers/platform/x86/intel_sgx/sgx_le.c
>  create mode 100644 drivers/platform/x86/intel_sgx/sgx_le_proxy_piggy.S
>  create mode 100644 drivers/platform/x86/intel_sgx/sgx_main.c
>  create mode 100644 drivers/platform/x86/intel_sgx/sgx_page_cache.c
>  create mode 100644 drivers/platform/x86/intel_sgx/sgx_util.c
>  create mode 100644 drivers/platform/x86/intel_sgx/sgx_vma.c
>
> --
> 2.14.1
>



-- 
Cedric Blancher <cedric.blancher@gmail.com>
[https://plus.google.com/u/0/+CedricBlancher/]
Institute Pasteur

Re: [PATCH v6 00/11] Intel SGX Driver

[Christian Stroetmann]

On the 04.Jan.2018 09:02, Dr. Greg Wettstein wrote:
Aloha

First of all, I would like to appologize that there was an unusual issue 
with my email
client, so that my email did not reach the mailing list linux-fsdevel.
Hopefully, this does not happen once again with this email.


Thank you for answering but let me ask some more (simple) questions below.

> On Jan 3,  3:00am, Christian Stroetmann wrote:
> } Subject: Re: [PATCH v6 00/11] Intel SGX Driver
>
> Good morning, I hope the day is going well for you.
>
>>> Philosophically we take the approach that for high security
>>> assurance environments that it is virtually impossible to allow
>>> any untrusted code to run on a platform.  Which is why we focus on
>>> autonomous introspection for these environments.
>> Interesting.  I would like to hear more about this autonomous
>> introspection concept, specifically what it monitors and how it
>> reacts on an issue.
> AI as we call it.. :-), at a high level, is the notion that an
> operating system platform can be modeled for its intended behavior,
> just as is done for buildings, bridges and airplanes.  The model is
> based on a precise mathematical description of the set of desired
> information exchange events that the operating system will be allowed
> to mediate.

So you have artificial intelligence in the operating system respectively 
kernel?

What is with machine learning?

Also, you need to ensure that your precise mathematical model is correct 
and that
your code implements the model in a correct way.

>
> Autonomous introspection is the notion of the platform using this
> model to monitor and self-regulate its behavior.

This sounds like somekind of a reflective functionality.

>
>> Maybe you have a summary or short introduction of the concept or/and
>> a link to a document.
> The initial concept and implementation were described by the following
> Linux Security Summit paper:
>
> http://kernsec.org/files/lss2015/idfusion-iso-identity-paper.pdf
>
> The work has matured a great deal since then.
>
> Most notably the modeling and control engine have been lifted out of
> the kernel into an SGX enclave.  In this architecture the kernel
> cannot act without permission from the enclave based engine, which
> requires the integrity of the enclave to be violated in order to
> compromise the kernel.

This would be ideal with a microkernel based operating system.

>
> A virtuous circle.
>
>> Regards
>> Christian Stroetmann
> We can engage further in private e-mail as this may or may not be of
> general interest.
>
> Thanks for the interest.

I think that the others are also interested in this subject matter.



Regards
Christian Stroetmann

>
> Have a good day.
>
> Greg
>
> }-- End of excerpt from Christian Stroetmann

[snip]

Re: [PATCH v6 00/11] Intel SGX Driver

[Dr. Greg Wettstein]

On Jan 3, 10:48am, Pavel Machek wrote:
} Subject: Re: [PATCH v6 00/11] Intel SGX Driver

> Hi!

Good morning.

> :-). Stuff proceeds as usual. Too bad it is raining outside, instead
> of snowing.

-19C here, so we have snow... :-)

> > > So ... even with SGX, host can generate bitflips in the enclave,
> > > right?

> > Correct.

> I'd say that you can't generate bitflips because if you do hardware
> will kill the enclave. This seems to be significant difference from
> AMD "secure" memory encryption.

SGX is an entirely different class of technology compared to AME SME
or the Intel equivalent TME (Total Memory Encryption).  Both of these
are best described as the notion of applying the concept of whole disk
encryption to memory.

There are lots of well understood issues surrounding this approach,
whether the target is memory pages or disk sectors.  I think the issue
comes down to the fact that there is a desire to enable a BIOS option
and become 'secure', unfortunately the world is not that simple.

> > Forcing a bitflip in enclave memory causes the next page fetch
> > containing the bitflipped location to fail its integrity check.
> > Since this technically shouldn't be possible, this situation was
> > classified as a hardware failure which is handled by the processor
> > locking its execution state, thus taking the machine down.

> So you can't really do bitflips on the SGX protected memory, because
> MM{E,U} hardware will catch that and kill machine if you try?

Correct.

Which obviously has issues in a multi-tenant cloud environment, but
again, it comes down to risk management.  Killing a machine is
problematic, a massive data compromise isn't much fun either.

> So SGX protected memory is not swappable?

The architecture provides support for swapping enclave pages and the
Linux driver supports it.

The swapped pages retain their confidentiality and integrity
protections.

> > It would seem to be a misfeature for the self-protection mechanism to
> > not generate some type of trappable fault rather then generating a
> > processor lockup but hindsight is always 20/20.  Philosophically this
> > is a good example of security risk managment.  Locking a machine is
> > obviously problematic in a cloud service environment, but it has to be
> > taken in the perspective of whether or not it would be preferable to
> > have a successful privilege escalation attack which could result in
> > exfiltration of sensitive data.

> Ok, right, it should fault. They can fix it in new version?

Good question and something only Intel can answer.

A large part of SGX is implemented in microcode, in part due to the
complexity of the technologies involved, notably the group signing
(EPID) implementation.

Beyond that, there was a specific acknowledgement that this was
security sensitive code and may need an upgrade, hence the microcode
implementation.

Since the drop and lock 'feature' is closely tied to the MM{E,U}
implementation, the question would be whether or not this behavior
could be changed with updated firmware.  If it was easy to change the
behavior of the MMU with microcode the industry would be less frantic
right now... :-)

If it would be possible to change the drop and lock response it would
arguably improve the utility of the technology in certain
environments.  SGX2 would have been a great time for that.

> > Arguably not as much fun as what appears to be pending, given what
> > appears to be the difficulty of some Intel processors to deal with
> > page faults induced by speculative memory references... :-)

> Do you have more info on that? Will they actually leak information,
> or is it just good for rowhammering the kernel memory?

If we are talking about the issues motivating the KPTI work I don't
have any useful information beyond what is raging through the industry
right now.

With respect to SGX, the issues giving rise to KPTI are characteristic
of what this technology is designed to address.  The technical 'news'
sites, which are even more of an abomination then usual with this
issue, are talking about privileged information such as credentials,
passwords et.al being leaked by this vulnerability.

Data committed to enclaves are only accessible by the enclave, even
the kernel, by definition, can't access the memory.  Given current
events that is an arguably useful behavior.

> Best regards,
> 									Pavel

Stay dry.

Have a good day.

Greg

}-- End of excerpt from Pavel Machek

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
------------------------------------------------------------------------------
"Lots of folks confuse bad management with destiny."
                                -- Kin Hubbard

-- 

Re: [PATCH v6 00/11] Intel SGX Driver

[Dr. Greg Wettstein]

On Jan 3,  3:00am, Christian Stroetmann wrote:
} Subject: Re: [PATCH v6 00/11] Intel SGX Driver

Good morning, I hope the day is going well for you.

> > Philosophically we take the approach that for high security
> > assurance environments that it is virtually impossible to allow
> > any untrusted code to run on a platform.  Which is why we focus on
> > autonomous introspection for these environments.

> Interesting.  I would like to hear more about this autonomous
> introspection concept, specifically what it monitors and how it
> reacts on an issue.

AI as we call it.. :-), at a high level, is the notion that an
operating system platform can be modeled for its intended behavior,
just as is done for buildings, bridges and airplanes.  The model is
based on a precise mathematical description of the set of desired
information exchange events that the operating system will be allowed
to mediate.

Autonomous introspection is the notion of the platform using this
model to monitor and self-regulate its behavior.

> Maybe you have a summary or short introduction of the concept or/and
> a link to a document.

The initial concept and implementation were described by the following
Linux Security Summit paper:

http://kernsec.org/files/lss2015/idfusion-iso-identity-paper.pdf

The work has matured a great deal since then.

Most notably the modeling and control engine have been lifted out of
the kernel into an SGX enclave.  In this architecture the kernel
cannot act without permission from the enclave based engine, which
requires the integrity of the enclave to be violated in order to
compromise the kernel.

A virtuous circle.

> Regards
> Christian Stroetmann

We can engage further in private e-mail as this may or may not be of
general interest.

Thanks for the interest.

Have a good day.

Greg

}-- End of excerpt from Christian Stroetmann

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
------------------------------------------------------------------------------
"Four year projections, are you kidding me.  We don't know what we are
 supposed to be doing at the 4 o'clock meeting this afternoon."
                                -- Terry Wieland
                                   Resurrection

Re: [PATCH v6 00/11] Intel SGX Driver

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1433 bytes --]

Hi!

> > Would you list guarantees provided by SGX?
> 
> Obviously, confidentiality and integrity.  SGX was designed to address
> an Iago threat model, a very difficult challenge to address in
> reality.

Do you have link on "Iago threat model"?

> I don't have the citation immediately available, but a bit-flip attack
> has also been described on enclaves.  Due to the nature of the
> architecture, they tend to crash the enclave so they are more in the
> category of a denial-of-service attack, rather then a functional
> confidentiality or integrity compromise.

So ... even with SGX, host can generate bitflips in the enclave,
right?

People usually assume that bitflip will lead "only" to
denial-of-service, but rowhammer work shows that even "random" bit
flips easily lead to priviledge escalation on javascript virtual
machines, and in similar way you can get root if you have user and bit
flips happen.

So... I believe we should assume compromise is possible, not just
denial-of-service.

> Unfortunately, in the security field it is way more fun, and seemingly
> advantageous from a reputational perspective, to break things then to
> build solutions.... :-)(

Well, yes :-). And I believe someone is going to have fun with SGX
;-).
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [PATCH v6 00/11] Intel SGX Driver

[Dr. Greg Wettstein]

On Dec 12,  3:07pm, Pavel Machek wrote:
} Subject: Re: [PATCH v6 00/11] Intel SGX Driver

Good morning, I hope this note finds the holiday season going well for
everyone.  This note is a bit delayed due to the holidays, my
apologies.

Pretty wide swath on this e-mail but will include the copy list due to
the possible general interest and impact of these issues.  We have
done an independent implementation of Intel's platform software (PSW),
directed at the use of SGX on intelligent network endpoint devices, so
we have some experience with the issues under discussion.

> On Sat 2017-11-25 21:29:17, 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.  In a way you can think
> > that SGX provides inverted sandbox. It protects the application
> > from a malicious host.

> Would you list guarantees provided by SGX?

Obviously, confidentiality and integrity.  SGX was designed to address
an Iago threat model, a very difficult challenge to address in
reality.

On SGX capable platforms, the Memory Encryption Engine (MEE) is an
integrated component of the hardware MMU, as SGX is a virtual memory
play.  As a result, the executable code and data are encrypted in main
memory and only decrypted when the data is fed from memory onto the
hardware fetch queues.  Irregardless of anything else, this has
implications with respect to cold boot attacks, if an architect
chooses to worry about that threat modality.

In reality, we believe the guarantee that is most important is
integrity, given the issues below.

> For example, host can still observe timing of cachelines being
> accessed by "protected" app, right? Can it also introduce bit flips?

Timing attacks are the bane of SGX, just as they are throughout the
rest of the commodity architectures.  Jarkko cited Beecham's work,
which is a good reference.  Oakland's work on controlled side-channel
attacks is also a very good, and fundamental, read on the issues
involved.

Microsoft Research and Georgia Tech have a paper out discussing the
use of transactional memory to mitigate these.

I don't have the citation immediately available, but a bit-flip attack
has also been described on enclaves.  Due to the nature of the
architecture, they tend to crash the enclave so they are more in the
category of a denial-of-service attack, rather then a functional
confidentiality or integrity compromise.

At the end of the day, giving up complete observational and functional
control to an adversary is a difficult challenge to address.  There is
also a large difference between attacks that can be conducted in a
carefully controlled lab environment and what an adversary or malware
can implement in practice.

Platforms which require security assurances ultimately need a root of
trust.  That either comes from a TPM or a Trusted Execution
Environment like SGX.  Realistically, we think the future involves an
integration of both technologies.  The only other alternative is
perfect software and I think the jury has already weighed in on that.

The advantage of SGX over a TPM is that it is blindingly fast with
respect to performance.  The IMA community has been involved in a
debate over the list digest patches in order to overcome performance
issues with TPM based extension measurements.  We lifted most of the
IMA infrastructure into an SGX enclave and demonstrated significant
performance impacts as a result.

The bigger question, for community integration, is the availability of
hardware.  I see Jarkko's patches are based on the notion of having
flexible launch control available, ie. the ability to program the
relevant MSR's with the checksum of the identity modulus which is to
serve as the root of trust.  I'm not sure there is any hardware in the
wild that currently supports this, Jarkko comments?

Even with that, the question arises as to what is going to be trusted
to program those registers.  The obvious candidate for this is
TXT/tboot which underscores a future involving the integration of
these technologies.

Unfortunately, in the security field it is way more fun, and seemingly
advantageous from a reputational perspective, to break things then to
build solutions.... :-)(

> Pavel

I hope the above clarifications are helpful.

Best wishes for a pleasant holiday weekend to everyone.

Dr. Greg

}-- End of excerpt from Pavel Machek

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
------------------------------------------------------------------------------
"I suppose that could could happen but he wouldn't know a Galois Field
 if it kicked him in the nuts."
                                -- Anonymous mathematician
                                   Resurrection.

Re: [PATCH v6 00/11] Intel SGX Driver

[Jarkko Sakkinen]

On Wed, Dec 20, 2017 at 01:33:46AM +0200, Jarkko Sakkinen wrote:
> On Tue, 2017-12-12 at 15:07 +0100, Pavel Machek wrote:
> > On Sat 2017-11-25 21:29:17, 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.
> > > In a way you can think that SGX provides inverted sandbox. It protects the
> > > application from a malicious host.
> > 
> > Would you list guarantees provided by SGX?
> > 
> > For example, host can still observe timing of cachelines being
> > accessed by "protected" app, right? Can it also introduce bit flips?
> > 
> > 								Pavel
> 
> I'll give a more proper response to this now that all the reported major
> issues in the code have been fixed in v9.
> 
> Yes, SGX is vulnerable to the L1 cacheline timing attacks. Jethro
> Beekman wrote a great summary about this on early March:
> 
>   https://jbeekman.nl/blog/2017/03/sgx-side-channel-attacks/
> 
> The counter measures are the same as without SGX. It really does not
> add or degrade security in this area.

This came up even in my patch set :-) I.e. I switched to kernel AES-NI
from TinyCrypt's AES because the latter is not timing resistant.

/Jarkko

Re: [PATCH v6 00/11] Intel SGX Driver

[Jarkko Sakkinen]

On Tue, 2017-12-12 at 15:07 +0100, Pavel Machek wrote:
> On Sat 2017-11-25 21:29:17, 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.
> > In a way you can think that SGX provides inverted sandbox. It protects the
> > application from a malicious host.
> 
> Would you list guarantees provided by SGX?
> 
> For example, host can still observe timing of cachelines being
> accessed by "protected" app, right? Can it also introduce bit flips?
> 
> 								Pavel

I'll give a more proper response to this now that all the reported major
issues in the code have been fixed in v9.

Yes, SGX is vulnerable to the L1 cacheline timing attacks. Jethro
Beekman wrote a great summary about this on early March:

  https://jbeekman.nl/blog/2017/03/sgx-side-channel-attacks/

The counter measures are the same as without SGX. It really does not
add or degrade security in this area.

/Jarkko

Re: [PATCH v6 00/11] Intel SGX Driver

[Jarkko Sakkinen]

On Tue, Dec 12, 2017 at 03:07:50PM +0100, Pavel Machek wrote:
> On Sat 2017-11-25 21:29:17, 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.
> > In a way you can think that SGX provides inverted sandbox. It protects the
> > application from a malicious host.
> 
> Would you list guarantees provided by SGX?
> 
> For example, host can still observe timing of cachelines being
> accessed by "protected" app, right? Can it also introduce bit flips?
> 
> 								Pavel

I'll put this in my backlog. Thank you.

/Jarkko

Re: [PATCH v6 00/11] Intel SGX Driver

[Pavel Machek]

On Sat 2017-11-25 21:29:17, 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.
> In a way you can think that SGX provides inverted sandbox. It protects the
> application from a malicious host.

Would you list guarantees provided by SGX?

For example, host can still observe timing of cachelines being
accessed by "protected" app, right? Can it also introduce bit flips?

								Pavel

[PATCH v6 00/11] Intel SGX Driver

[Jarkko Sakkinen]

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.
In a way you can think that SGX provides inverted sandbox. It protects the
application from a malicious host.

There is a new hardware unit in the processor called Memory Encryption Engine
(MEE) starting from the Skylake microacrhitecture. BIOS can define one or many
MEE regions that can hold enclave data by configuring them with PRMRR
registers.

The MEE automatically encrypts the data leaving the processor package to the
MEE regions. The data is encrypted using a random key whose life-time is
exactly one power cycle.

You can tell if your CPU supports SGX by looking into /proc/cpuinfo:

	cat /proc/cpuinfo  | grep sgx

The GIT repositoy for SGX driver resides in

	https://github.com/jsakkine-intel/linux-sgx.git

'le' branch contains the upstream candidate patches.

'master' branch contains the same patches with the following differences:

* top-level patch modifies the ioctl API to be SDK compatible
* does not use flexible launch control but instead relies on SDK provided
  Intel launch enclave.

Backlog:
* AES: how to use arch/x86/crypto/aesni-intel_asm.S from the enclave. I
  guess these routines should be fairly easy to call directly (haven't
  investigated deeply). Any advice is appreciated.
* Layout: what and where to place in arch/x86.
* MAINTAINERS: who to add as reviewer.

v6
* Fixed semaphore underrun when accessing /dev/sgx from the launch enclave.
* In sgx_encl_create() s/IS_ERR(secs)/IS_ERR(encl)/.
* Removed virtualization chapter from the documentation.
* Changed the default filename for the signing key as signing_key.pem.
* Reworked EPC management in a way that instead of a linked list of
  struct sgx_epc_page instances there is an array of integers that
  encodes address and bank of an EPC page (the same data as 'pa' field
  earlier). The locking has been moved to the EPC bank level instead
  of a global lock.
* Relaxed locking requirements for EPC management. EPC pages can be
  released back to the EPC bank concurrently.
* Cleaned up ptrace() code.
* Refined commit messages for new architectural constants.
* Sorted includes in every source file.
* Sorted local variable declarations according to the line length in
  every function.
* Style fixes based on Darren's comments to sgx_le.c.

v5:
* Described IPC between the Launch Enclave and kernel in the commit messages.
* Fixed all relevant checkpatch.pl issues that I have forgot fix in earlier
  versions except those that exist in the imported TinyCrypt code.
* Fixed spelling mistakes in the documentation.
* Forgot to check the return value of sgx_drv_subsys_init().
* Encapsulated properly page cache init and teardown.
* Collect epc pages to a temp list in sgx_add_epc_bank
* Removed SGX_ENCLAVE_INIT_ARCH constant.

v4:
* Tied life-cycle of the sgx_le_proxy process to /dev/sgx.
* Removed __exit annotation from sgx_drv_subsys_exit().
* Fixed a leak of a backing page in sgx_process_add_page_req() in the
  case when vm_insert_pfn() fails.
* Removed unused symbol exports for sgx_page_cache.c.
* Updated sgx_alloc_page() to require encl parameter and documented the
  behavior (Sean Christopherson).
* Refactored a more lean API for sgx_encl_find() and documented the behavior.
* Moved #PF handler to sgx_fault.c.
* Replaced subsys_system_register() with plain bus_register().
* Retry EINIT 2nd time only if MSRs are not locked.

v3:
* Check that FEATURE_CONTROL_LOCKED and FEATURE_CONTROL_SGX_ENABLE are set.
* Return -ERESTARTSYS in __sgx_encl_add_page() when sgx_alloc_page() fails.
* Use unused bits in epc_page->pa to store the bank number.
* Removed #ifdef for WQ_NONREENTRANT.
* If mmu_notifier_register() fails with -EINTR, return -ERESTARTSYS.
* Added --remove-section=.got.plt to objcopy flags in order to prevent a
  dummy .got.plt, which will cause an inconsistent size for the LE.
* Documented sgx_encl_* functions.
* Added remark about AES implementation used inside the LE.
* Removed redundant sgx_sys_exit() from le/main.c.
* Fixed struct sgx_secinfo alignment from 128 to 64 bytes.
* Validate miscselect in sgx_encl_create().
* Fixed SSA frame size calculation to take the misc region into account.
* Implemented consistent exception handling to __encls() and __encls_ret().
* Implemented a proper device model in order to allow sysfs attributes
  and in-kernel API.
* Cleaned up various "find enclave" implementations to the unified
  sgx_encl_find().
* Validate that vm_pgoff is zero.
* Discard backing pages with shmem_truncate_range() after EADD.
* Added missing EEXTEND operations to LE signing and launch.
* Fixed SSA size for GPRS region from 168 to 184 bytes.
* Fixed the checks for TCS flags. Now DBGOPTIN is allowed.
* Check that TCS addresses are in ELRANGE and not just page aligned.
* Require kernel to be compiled with X64_64 and CPU_SUP_INTEL.
* Fixed an incorrect value for SGX_ATTR_DEBUG from 0x01 to 0x02.

v2:
* get_rand_uint32() changed the value of the pointer instead of value
  where it is pointing at.
* Launch enclave incorrectly used sigstruct attributes-field instead of
  enclave attributes-field.
* Removed unused struct sgx_add_page_req from sgx_ioctl.c
* Removed unused sgx_has_sgx2.
* Updated arch/x86/include/asm/sgx.h so that it provides stub
  implementations when sgx in not enabled.
* Removed cruft rdmsr-calls from sgx_set_pubkeyhash_msrs().
* return -ENOMEM in sgx_alloc_page() when VA pages consume too much space
* removed unused global sgx_nr_pids
* moved sgx_encl_release to sgx_encl.c
* return -ERESTARTSYS instead of -EINTR in sgx_encl_init()


Haim Cohen (1):
  x86: add SGX MSRs to msr-index.h

Jarkko Sakkinen (8):
  intel_sgx: updated MAINTAINERS
  x86: define IA32_FEATUE_CONTROL.SGX_LC
  intel_sgx: driver for Intel Software Guard Extensions
  intel_sgx: ptrace() support
  intel_sgx: in-kernel launch enclave
  fs/pipe.c: export create_pipe_files() and replace_fd()
  intel_sgx: glue code for in-kernel LE
  intel_sgx: driver documentation

Kai Huang (1):
  x86: add SGX definition to cpufeature

Sean Christopherson (1):
  x86: define IA32_FEATURE_CONTROL.SGX_ENABLE

 Documentation/index.rst                            |   1 +
 Documentation/x86/intel_sgx.rst                    | 101 +++
 MAINTAINERS                                        |   5 +
 arch/x86/include/asm/cpufeatures.h                 |   2 +
 arch/x86/include/asm/msr-index.h                   |   8 +
 arch/x86/include/asm/sgx.h                         | 233 +++++
 arch/x86/include/asm/sgx_arch.h                    | 268 ++++++
 arch/x86/include/uapi/asm/sgx.h                    | 138 +++
 drivers/platform/x86/Kconfig                       |   2 +
 drivers/platform/x86/Makefile                      |   1 +
 drivers/platform/x86/intel_sgx/Kconfig             |  34 +
 drivers/platform/x86/intel_sgx/Makefile            |  32 +
 drivers/platform/x86/intel_sgx/le/Makefile         |  26 +
 drivers/platform/x86/intel_sgx/le/enclave/Makefile |  46 +
 .../x86/intel_sgx/le/enclave/aes_encrypt.c         | 191 ++++
 .../platform/x86/intel_sgx/le/enclave/cmac_mode.c  | 254 ++++++
 .../x86/intel_sgx/le/enclave/encl_bootstrap.S      | 163 ++++
 .../intel_sgx/le/enclave/include/tinycrypt/aes.h   | 133 +++
 .../le/enclave/include/tinycrypt/cmac_mode.h       | 194 ++++
 .../le/enclave/include/tinycrypt/constants.h       |  59 ++
 .../intel_sgx/le/enclave/include/tinycrypt/utils.h |  95 ++
 drivers/platform/x86/intel_sgx/le/enclave/main.c   | 203 +++++
 .../platform/x86/intel_sgx/le/enclave/sgx_le.lds   |  28 +
 .../platform/x86/intel_sgx/le/enclave/sgxsign.c    | 538 +++++++++++
 drivers/platform/x86/intel_sgx/le/enclave/utils.c  |  78 ++
 drivers/platform/x86/intel_sgx/le/entry.S          | 117 +++
 .../platform/x86/intel_sgx/le/include/sgx_asm.h    |  64 ++
 .../platform/x86/intel_sgx/le/include/sgx_encl.h   | 110 +++
 drivers/platform/x86/intel_sgx/le/main.c           | 214 +++++
 drivers/platform/x86/intel_sgx/le/sgx_le_piggy.S   |  15 +
 drivers/platform/x86/intel_sgx/sgx.h               | 268 ++++++
 drivers/platform/x86/intel_sgx/sgx_encl.c          | 999 +++++++++++++++++++++
 drivers/platform/x86/intel_sgx/sgx_ioctl.c         | 282 ++++++
 drivers/platform/x86/intel_sgx/sgx_le.c            | 319 +++++++
 .../platform/x86/intel_sgx/sgx_le_proxy_piggy.S    |  15 +
 drivers/platform/x86/intel_sgx/sgx_main.c          | 456 ++++++++++
 drivers/platform/x86/intel_sgx/sgx_page_cache.c    | 619 +++++++++++++
 drivers/platform/x86/intel_sgx/sgx_util.c          | 394 ++++++++
 drivers/platform/x86/intel_sgx/sgx_vma.c           | 236 +++++
 fs/file.c                                          |   1 +
 fs/pipe.c                                          |   1 +
 41 files changed, 6943 insertions(+)
 create mode 100644 Documentation/x86/intel_sgx.rst
 create mode 100644 arch/x86/include/asm/sgx.h
 create mode 100644 arch/x86/include/asm/sgx_arch.h
 create mode 100644 arch/x86/include/uapi/asm/sgx.h
 create mode 100644 drivers/platform/x86/intel_sgx/Kconfig
 create mode 100644 drivers/platform/x86/intel_sgx/Makefile
 create mode 100644 drivers/platform/x86/intel_sgx/le/Makefile
 create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/Makefile
 create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/aes_encrypt.c
 create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/cmac_mode.c
 create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/encl_bootstrap.S
 create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/include/tinycrypt/aes.h
 create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/include/tinycrypt/cmac_mode.h
 create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/include/tinycrypt/constants.h
 create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/include/tinycrypt/utils.h
 create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/main.c
 create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/sgx_le.lds
 create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/sgxsign.c
 create mode 100644 drivers/platform/x86/intel_sgx/le/enclave/utils.c
 create mode 100644 drivers/platform/x86/intel_sgx/le/entry.S
 create mode 100644 drivers/platform/x86/intel_sgx/le/include/sgx_asm.h
 create mode 100644 drivers/platform/x86/intel_sgx/le/include/sgx_encl.h
 create mode 100644 drivers/platform/x86/intel_sgx/le/main.c
 create mode 100644 drivers/platform/x86/intel_sgx/le/sgx_le_piggy.S
 create mode 100644 drivers/platform/x86/intel_sgx/sgx.h
 create mode 100644 drivers/platform/x86/intel_sgx/sgx_encl.c
 create mode 100644 drivers/platform/x86/intel_sgx/sgx_ioctl.c
 create mode 100644 drivers/platform/x86/intel_sgx/sgx_le.c
 create mode 100644 drivers/platform/x86/intel_sgx/sgx_le_proxy_piggy.S
 create mode 100644 drivers/platform/x86/intel_sgx/sgx_main.c
 create mode 100644 drivers/platform/x86/intel_sgx/sgx_page_cache.c
 create mode 100644 drivers/platform/x86/intel_sgx/sgx_util.c
 create mode 100644 drivers/platform/x86/intel_sgx/sgx_vma.c

-- 
2.14.1