Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix memory allocation in the runtime (#320)
This change bundles two bugfixes to Eyrie's memory allocation system. The first is a fix to the `brk` syscall which is used to allocate memory. Often, calls to `brk` will use page aligned addresses as arguments -- but not always. The existing functionality in `brk` specifically runs into problems in the `brk` call *after* such a non-page-aligned call. For example, if we initially have `current_break = 0x2040000000`: `brk(0x2040000B48)`: `req_page_count = 1`. In this case, we allocate one page at VPN `0x2040000`. `brk(0x0000002040021B48)`: `req_page_count = 33`. Since we earlier set `current_break = 0x2040000B48`, we will accidentally *reallocate* VPN `0x2040000` and thus not allocate one page at the end of this requested break. This will result in segfaults on address `0x2040021388`, for example. The second fix to the `alloc_page` function, which now zeroes pages that it allocates. I observed issues with some libcs (musl, specifically) which assume (in the heap implementation) that pages returned from the runtime are zeroed. Since this wasn't the case, some really cursed memory corruptions were observed. This does come at a performance overhead, but I believe that zeroing allocated pages is a pretty standard choice in OS's.
- Loading branch information
b25a682
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@grg-haas who is expected to call this syscall, the runtime or the enclave?
IIUC, enclave heap is statically allocated in the linker script and handled by tiny_malloc.c
b25a682
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@acaldaya Great question. These syscalls are primarily called by the eapp when it is using one of the libc implementations we support. Specifically, I've seen glibc rely more on
brk
while musl relies more onmmap
. Both of these eventually call down to the genericalloc_page
.b25a682
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
interesting
is FreeMem support sufficiently complete to rely only on the RT dynamic memory allocator? (i.e. not using tiny-malloc at all)
my understanding is that it wasn't due to some comments in SDK code.
b25a682
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have been using freemem almost exclusively since I've started working on Keystone (half a year), and haven't run into any issues personally! I'm not quite sure what that comment is about, but may be worth revisiting the SDK in the future