Conversation
Parse and load ELF binaries manually instead of using the `elf_loader` crate. This is done for a few reasons: * `elf_loader` is not safe for our use--it assumes it can safely access mapped memory directly via Rust memory access primitives--this is not always true for LiteBox since that memory is user-mode memory. Even when we know there are no other guest threads, so that concurrent mutation should be impossible, we still need to handle that memory differently from Rust memory. * `elf_loader` creates a dependency on shim TLS to get the task object, since the various mmap-related traits do not take `&self`. This prevents some future refactoring to eliminate the use of TLS within the shims. Fixing this upstream seems like a big change, one that would break semver compatibility. * `elf_loader` seems to combine parsing and mapping operations into one step, preventing us from returning errors from `execve` when the target binary is not a valid ELF executable. * `elf_loader` has an awful lot of code marked unsafe with unclear safety contracts. * Loading the binary is a pretty important part of the Linux and OPTEE shims--we want to have a good understanding and control over exactly what loader ABI we are actually implementing. As part of this, implement relocation support for OPTEE, since before we were relying on `elf_loader` for this--this is not necessary for the Linux shim. I am wondering if in the future we can instead inject a loader binary into OPTEE user mode, similar to the interpreter used by Linux binaries; then we can run the relocator and whatever else we want (e.g., TLS allocation) there. he commit message for your changes. Lines starting
|
It seems that this new ELF loader has a problem with the KMPP TA (other three TAs work well). I'll take a look at it more.
|
Is KMPP TA not part of the CI tests? |
|
Hmm, I see, KMPP-TA fails to run but the test succeeds anyway... |
CvvT
left a comment
There was a problem hiding this comment.
LGTM! Thanks! I left one comment. Feel free to merge once all conflicts are resolved.
|
🤖 SemverChecks 🤖 Click for details |
|
The test |
Parse and load ELF binaries manually instead of using the
elf_loadercrate. This is done for a few reasons:elf_loaderis not safe for our use--it assumes it can safely access mapped memory directly via Rust memory access primitives--this is not always true for LiteBox since that memory is user-mode memory. Even when we know there are no other guest threads, so that concurrent mutation should be impossible, we still need to handle that memory differently from Rust memory.elf_loadercreates a dependency on shim TLS to get the task object, since the various mmap-related traits do not take&self. This prevents some future refactoring to eliminate the use of TLS within the shims. Fixing this upstream seems like a big change, one that would break semver compatibility.elf_loaderseems to combine parsing and mapping operations into one step, preventing us from returning errors fromexecvewhen the target binary is not a valid ELF executable.elf_loaderhas an awful lot of code marked unsafe with safety contracts that are unclear (to me).Loading the binary is a pretty important part of the Linux and OPTEE shims--we want to have a good understanding and control over exactly what loader ABI we are actually implementing.
For now, just update the Linux shim to use this new loader--this work has uncovered some design problems with OPTEE that need to be addressed before we can remove the dependency on
elf_loader.