On Tue, Jul 28, 2020 at 11:35:11PM +0200, Pavel Machek wrote:

Hi!

quoted

+CPUs starting from Icelake use Total Memory Encryption (TME) in the place of
+MEE. TME throws away the Merkle tree, which means losing integrity and
+anti-replay protection but also enables variable size memory pools for EPC.
+Using this attack for benefit would require an interposer on the system bus.

It is not exactly clear what "this attack" means.

(And it would be cool to explain against what SGX is protecting. I
thought it was malicious RAM, but apparently not on Icelake+).

Icelake has the same capabilities against software attacks as
generations before that given the same CPU access control.

A custom interposer on a bus could use replay for the data coming out of
the CPU package. In pre-Icelake (i.e. MEE), this is prevented with a
Merkle tree.

However, DMA is still blocked by the PRMRR to the EPC memory even on
Icelake (SDM section 41.10), which adds some cost to do so (e.g. a
malicous peripheral).

Memory is of course encrypted in both architectures.

Agreed that the current paragraph looks confusing. I'll refine it based
on what I just wrote. I want to make it as transparent as possible but
it cannot be achieved without appropriate feedback.

quoted

+Backing storage
+===============
+
+Backing storage is shared and not accounted. It is implemented as a private
+shmem file. Providing a backing storage in some form from user space is not
+possible - accounting would go to invalid state as reclaimed pages would get
+accounted to the processes of which behalf the kernel happened to be acting on.

"of which behalf" -- I can't parse that?

Executing in a process context.

quoted

+Access control
+==============
+
+`mmap()` permissions are capped by the enclave permissions. A direct
+consequence of this is that all the pages for an address range must be added
+before `mmap()` can be applied. Effectively an enclave page with minimum
+permission in the address range sets the permission cap for the mapping

   ~~~~~~~~~~
    permissions?

Thanks, I'll fix that one.

									Pavel

Sorry for the late response. I came last week back from vacation and
have been purging the piled up stacks of email (looking at your domain
I have to add that I was in Brno, Czech).

/Jarkko