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
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Pavel Machek]

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


signature.asc
Description: Digital signature

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
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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 t

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
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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  58102development.
PH: 701-281-1686
FAX: 701-281-3949   EMAIL: g...@enjellic.com
--
"If you get to thinkin' you're a person of some influence, try
 orderin' somebody else's dog around."
-- Cowboy Wisdom
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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
 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 

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  58102development.
PH: 701-281-1686
FAX: 701-281-3949   EMAIL: g...@enjellic.com

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

[Pavel Machek]

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


signature.asc
Description: Digital signature

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  58102development.
PH: 701-281-1686
FAX: 701-281-3949   EMAIL: g...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Pavel Machek]

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


signature.asc
Description: Digital signature

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  58102development.
PH: 701-281-1686
FAX: 701-281-3949   EMAIL: g...@enjellic.com
--
"I suppose that could could happen

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
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[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