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: [email protected]
------------------------------------------------------------------------------
"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
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