Struct padding leakage

[david-oswald]

Hi,

Not quite sure where to open this issue, but since it would mainly affect the runtime I put it here - if you think it should go somewhere else feel free to close this issue and put it where it belongs.

The initial idea for this issue comes from this paper: https://pdfs.semanticscholar.org/fb9c/164a53194117fbd163e25b97f9b0fb3c8fbb.pdf

The basic problem is that the compiler may insert padding within a struct, and then leak the content of stack/heap in these padding bytes.

I verified that this can be a problem with Keystone using the calc_message_t from the Keystone demo. This struct happens to include 6 padding bytes between msg_type and len.

See the following patch to the hello-native app to demonstrate this issue: keystone-struct-padding.txt

In there, I first make sure to init the stack to a known state (0x41), and then alloc the struct on the stack and pass it over an ocall. The result is that the host app gets a couple of 0x41 bytes in the padding:

# ./hello_native.ke 
Verifying archive integrity... All good.
Uncompressing Keystone vault archive  100%  
sizeof(calc_message_t) = 16
sizeof(msg_type) = 2
sizeof(len) = 8
ab 00 41 41 41 41 41 41 12 00 00 00 00 00 00 00 

Solving this is obviously hard (impossible) for a generic ocall interface, unless you'd introduce an EDL-like tool later that does a member-wise deep copy of any struct passed from enclave to host. I guess for now the best is to mention this issue in the doc?

This problem might also be relevant in the syscall interface or other plugins (where it could be fixed). One option is to force struct packing for all relevant instances.

[dkohlbre]

You are right that we should set the packing on the syscall structs, though its not an issue for ones where we write the struct fields directly into the buffer.

For the U-mode generic ocalls this is part of the edge generation tools we're writing. Long term we've got a few further refinements that will avoid the block struct copy in most cases.

Unfortunately there is a limited amount we can do for eapps, we can update our examples and tooling, but fundamentally developers can build their eapps using whatever tools make sense for their use-case. This is a general known problem with copying data structures that hopefully a secure application developer is aware of.

Updating docs and examples seems like the right answer for now.