Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor: abstract SDK interface for libsgxstep #28

Open
jovanbulck opened this issue Jun 10, 2020 · 5 comments
Open

Refactor: abstract SDK interface for libsgxstep #28

jovanbulck opened this issue Jun 10, 2020 · 5 comments
Labels

Comments

@jovanbulck
Copy link
Owner

Ideally libsgxstep should be less tightly coupled to the Intel SGX-SDK and rely on a clean and stable interface that can be easily ported to other SDKs or libOSs, eg at least the following:

  • set AEP by hooking EENTER to allow for custom AEP stub for single-stepping
  • get TCS for current enclave to allow to retrieve metadata (eg base address) via the driver. This should be similarly possible by intercepting EENTER
  • refactor build system to more easily link libsgxstep to other SDKs

At least the user-space SDK components should be easily pluggable. Integration with the kernel space isgx driver may be more tight, but that should be less of an issue as most SDKs rely on the isgx driver anyway..

@jovanbulck
Copy link
Owner Author

jovanbulck commented Jun 21, 2022

some relevant notes on moving fwd here; currently we rely on the following patches (which can probably be further reduced as outlined):

  • sgx_get/set_aep: this is the only crucial part: we must be able to set our custom aep_trampoline.S stub on EENTER-ing the enclave -- current patch does not work with the VDSO eenter provided by newer Linux kernels..
  • sgx_get_tcs: to query TCS address that is saved on first EENTER -- we can probably get rid of this and by saving the TCS in rbx in SGX-Step's aep_trampoline.S

TODO: look into how to best support __vdso_sgx_enter_enclave; maybe we can trick the vdso_detector to take our customized vdso_sgx_enter_enclave function so we wouldn't need any patches in the SGX SDK runtime ^^

Note: Linux VDSO system sets the AEP here

@jovanbulck
Copy link
Owner Author

idea to look into: maybe we can simply replace all enclu instructions in VDSO and shared libraries with ud2 and trap these with a users-space signal handler to automatically redirect to our stub without needing to recompile or patch any untrusted runtime..

jovanbulck added a commit that referenced this issue Oct 12, 2022
Proper integration of SGX-Step with different runtimes is
still an outstanding issue (#28). Currently, only the Intel SDK is
"officially" supported. An (untested) stub to start on integration with
Gramine is, furthermore, provided "as is" in the `gramine` directory.
jovanbulck added a commit that referenced this issue Sep 23, 2024
Trap any ENCLU occurences in shared libraries before loading using
LD_LIBRARY_PATH and redirect them transparently to SGX-Step at runtime (cf.
issue #28).

This should allow to get rid of the custom patched SDK dependency and make
SGX-Step inherently SDK-agnostic. In principle, SGX-Step could in this way also
attached as a LD_PRELOAD shared library to a precompiled SGX application (eg in
case of a libOS like Gramine).
@jovanbulck
Copy link
Owner Author

idea to look into: maybe we can simply replace all enclu instructions in VDSO and shared libraries with ud2 and trap these with a users-space signal handler to automatically redirect to our stub without needing to recompile or patch any untrusted runtime..

this is now PoC implemented in the commit above

remaining TODOs:

  • cleanup patch.sh flow (eg via Makefile or run script cf Refactor build system #67 )
  • support VDSO patching/interception similarly (without recompiling the kernel)
  • use LD_PRELOAD to attach to precompiled libOS runner libraries like Gramine and SCONE
  • add example programs

@jovanbulck
Copy link
Owner Author

support VDSO patching/interception similarly (without recompiling the kernel)

This may be easy as the VDSO text region seems to be mapped as copy-on-write:

https://elixir.bootlin.com/linux/v6.10.10/source/arch/x86/entry/vdso/vma.c#L243

@jovanbulck
Copy link
Owner Author

hot-patching VDSO to redirect ENCLU seems to work:

0f11447

This would allow SGX-Step to run without any binary patches on recent SDKs 🎉

Needs cleanup and testing before merging, but binary patching + vdso patching both should work now and the cumbersome SDK source patching dependency can hopefully be dropped..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant