Porting Apps to Tyche
As soon as we will want to have benchmarks, tooling is going to become crucial.
For macrobenchmarks, we will need to limit the number of modifications required to run existing applications.
Thus, I am considering writing a tool to "enclavify" binaries and do most of the work before hand.
There are 3 aspects that I'm considering for the tool:
- Pack together an application and a mini-OS/TRT in a single ELF.
- Provide a .note/manifest ELF that describes the layout of an enclave, i.e., which sections are confidential and which are shared.
- Include page tables for the enclave as confidential supervisor segments with patchable/reloc symbols for actual physical addresses.
Packing User code & Kernel Code
Our model for enclaves requires ring 0 code, even if this is just a TRT shim layer that forwards calls/syscall to the untrusted world.
We might write a small rust kernel that doesn't need to boot or anything but would just act as 64bit running directly in ring 0 and managing IDTs + syscall forwarding.
We would then pack that kernel along side a user application by duplicating ELF sections, i.e., we would have user-text, kernel-text, user-rodata, kernel-rodata etc.
Manifest for Enclave Layout
It would be great for both loading and attestation if the ELF could statically describe what segments are confidential and which ones are shared.
This information would also be useful for remote attestation as it does not rely on runtime mmaps of shared regions but rather describes them directly inside the binary itself (i.e., as sections).
Page Tables inside ELF
This one is a little bit crazier but I would like to pre-generate page tables (potentially in a compressed format) and dump them as RO or WR-S sections in the ELF with patchable symbols for actual physical memory.
The tool that "enclavifies" a user application would be responsible for generating these and appending them to the ELF in a separate section. The loader would then be able to treat page tables as regular ELF sections that need to be populated in memory which would remove a lot of the logic from the driver itself + allow us to debug page tables in user space rather than within the driver.
It is also an advantage for attestation as now the binary also includes the page-table layout (the only thing missing being a mapping between patchable symbol -> physical address).
Porting Apps to Tyche
As soon as we will want to have benchmarks, tooling is going to become crucial.
For macrobenchmarks, we will need to limit the number of modifications required to run existing applications.
Thus, I am considering writing a tool to "enclavify" binaries and do most of the work before hand.
There are 3 aspects that I'm considering for the tool:
Packing User code & Kernel Code
Our model for enclaves requires ring 0 code, even if this is just a TRT shim layer that forwards calls/syscall to the untrusted world.
We might write a small rust kernel that doesn't need to boot or anything but would just act as 64bit running directly in ring 0 and managing IDTs + syscall forwarding.
We would then pack that kernel along side a user application by duplicating ELF sections, i.e., we would have user-text, kernel-text, user-rodata, kernel-rodata etc.
Manifest for Enclave Layout
It would be great for both loading and attestation if the ELF could statically describe what segments are confidential and which ones are shared.
This information would also be useful for remote attestation as it does not rely on runtime mmaps of shared regions but rather describes them directly inside the binary itself (i.e., as sections).
Page Tables inside ELF
This one is a little bit crazier but I would like to pre-generate page tables (potentially in a compressed format) and dump them as RO or WR-S sections in the ELF with patchable symbols for actual physical memory.
The tool that "enclavifies" a user application would be responsible for generating these and appending them to the ELF in a separate section. The loader would then be able to treat page tables as regular ELF sections that need to be populated in memory which would remove a lot of the logic from the driver itself + allow us to debug page tables in user space rather than within the driver.
It is also an advantage for attestation as now the binary also includes the page-table layout (the only thing missing being a mapping between patchable symbol -> physical address).