openenclave / openenclave Goto Github PK
View Code? Open in Web Editor NEWSDK for developing enclaves
Home Page: https://openenclave.io/sdk/
License: MIT License
SDK for developing enclaves
Home Page: https://openenclave.io/sdk/
License: MIT License
The current implementation for obtaining a report only supports its use for remote attestation via the Intel AESM quoting enclave. We need to make the method generic for local attestation use by accepting explicit and targetinfo.
Follow-up to #4.
This issue tracks all functional edits to libunwind code for Open Enclave which are done directly in the 3rdparty sources (unlike the libcxx/libc where our changes kept in separate source files. We need to:
One solution to investigate:
aux
folder)aux
folder handling as well.The diffs currently tracked for libunwind, excluding changes to the build infrastructure include:
3rdparty/libunwind/libunwind/include/libunwind.h
3rdparty/libunwind/libunwind/include/tdep/libunwind_i.h
3rdparty/libunwind/libunwind/src/coredump/libunwind-coredump.pc
3rdparty/libunwind/libunwind/src/ptrace/libunwind-ptrace.pc
3rdparty/libunwind/libunwind/src/setjmp/libunwind-setjmp.pc
3rdparty/libunwind/libunwind/src/unwind/libunwind.pc
#ifdef/ifndef OPENENCLAVE
to selectively compile some parts of these sources:3rdparty/libunwind/libunwind/src/dwarf/Gfind_proc_info-lsb.c
3rdparty/libunwind/libunwind/src/elfxx.h
3rdparty/libunwind/libunwind/src/os-linux.c
3rdparty/libunwind/libunwind/src/os-linux.h
3rdparty/libunwind/libunwind/src/x86_64/Gglobal.c
3rdparty/libunwind/libunwind/src/x86_64/Ginit.c
3rdparty/libunwind/libunwind/src/x86_64/Gtrace.c
3rdparty/libunwind/libunwind/src/x86_64/setcontext.S
#define pthread_mutex_lock pthread_mutex_lock_u
#define pthread_mutex_unlock pthread_mutex_unlock_u
aux
folder to aux-aux
as part of shift to CMake build so as to support Windows (aux is a reserved name in the Windows file system)./* Disable use of adaptive mutexes, which are defined by GCC headers but not
* supported by MUSL pthreads. Note that libunwind is compiled with GCC headers
* but linked with MUSL libc.
*/
#ifdef PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP
#undef PTHREAD_ADAPTIVE_MUTEX_INITIALIZER_NP
#endif
3rdparty/libunwind/libunwind/src/mi/init.c
3rdparty/libunwind/libunwind/src/unwind/RaiseException.c
3rdparty/libunwind/libunwind/src/unwind/unwind-internal.h
As a scoping exercise, we will support and test mbedTLS for use in enclaves but not OpenSSL. As such we should remove the existing host dependencies on OpenSSL and the OpenSSL 3rdparty build project entirely.
Requires #34.
To enable OpenEnclave to run on Windows, we will need the host library to be built as a Windows library that can be incorporated into the Windows SDK toolchains and system dependencies. This includes converting the C runtime dependencies as well as any enclave call-outs to system to use Windows equivalents.
Subitem of #35
To ease adoption of the SDK, we should provide a binary and library drop that does not require non-contributors to build the OpenEnclave project. For Ubuntu, this would be a .deb package published by Microsoft repository with an appropriate hash value documented for it.
The current plan is to release RelWithDebInfo builds of the SDK, and the Open Enclave CMake project is already configured to generate .deb packages via:
build$ cmake -DCMAKE_INSTALL_PREFIX:PATH=/opt/openenclave ..
build$ cpack -G DEB
This story depends on:
This is related to #373 tracking publishing of .rpm packages for RHEL.
Provide a debugging support for GDB on Linux for parity with the Intel SDK.
We need to flush out the details for behaviors of the enclave APIs an validate them. This applies to the updated memory model within the enclave:
To ease adoption of the SDK, we should provide a binary and library drop that does not require non-contributors to build the OpenEnclave project.
This is related to story #371
Follow-up for #29; the goal there was to create a framework for running the existing MUSL Libc and LLVM Libcxx unit tests without modification by dynamically wrapping each test in an enclave.
The resulting tests are partitioned into three groups:
Currently:
This issue tracks resolving the broken tests in this set.
OpenEnclave currently depends on the existing Intel AESM with dependencies on Intel signing for launch and EPID for quoting. We are requesting that Intel supports non-Intel specific versions of these architectural enclaves packaged as a dependency library for the OpenEnclave project so that it can be consumed by the OSS community without business relationships to Intel. This includes:
This is needed to establish a consistent engineering baseline that the maintainers adhere to upfront to avoid double standards on accepting contributions. We would like this to be as lightweight and automated as possible, including the application of tools such as clang.format to enforce mechanical issues such as C/C++ code style.
Many OSS projects switched to out-of-source tree builds for the benefits of a cleaner separation.
Consider this for OE as well, perhaps utilizing cmake.
For convergence with Windows, we would like to implement the mmap family of memory management functions for the enclave runtime that has a better parity with the Windows VirtualAlloc family of methods. This would also enable us to switch over to the MUSL malloc implementation instead of the separate dlmalloc dependency we currently pull in.
As part of this work, we should also implement the virtual address descriptor model so that we have consistent enclave internal memory management semantics.
The current driver for this change will likely be EDMM support in the OE SDK, so leaving this on the backlog.
We need to flush out the details for behaviors of the enclave APIs an validate them. Additional cases include:
On the host side, this will be necessary for allowing the host code to work across OS and the FIPS certified crypto implementations they ship with (BCrypt on Windows and OpenSSL in Ubuntu). Enclave hashing is already needed, and additional support will be needed for quote verification.
On the enclave side, this will be necessary for allowing a developer to plug in their choice of crypto lib instead of mbedTLS. This will need to support hashing, report/quote verification. In the future, this will also need to support seal/unseal.
Need to set up a continuous integration pipelines for Linux.
To explicitly scope the goals for this story, most of the CI systems explored only support hosted builds by default or in their basic/free plans, which precludes running on Azure SGX machines. As such, this story primarily covers enforcing basic engineering checks during PR submission:
For enabling CI to run on Azure SGX machines, see #374.
If we can get a single solution, this can be merged with the Windows one #51.
Follow up to #37, we need to provide clear guidance an instructions for debugging enclaves on Windows.
As an extension of the generic nature of the OpenEnclave API surface, we need to provide OE_* abstractions for data structures involved in the identity model used for sealing policies as well as attestation checks.
Until #44 is complete, production testing of SGX enclaves requires Intel signing. For the Windows developers, supporting digest generation will allow integration with signtool as part of the Windows development tool chain, which supports existing workflows for signing via HSM through BCrypt.
Add a deprecations header for all unsupported enclave library functions (libc, libcxx etc.) Attempts to link will already fail from missing symbols today, but this would allow the unsupported methods to be made explicit at compile time. The proposal is as follows:
Here’s are sample contents of deprecations.h:
#ifndef OELIBC_DEPRECATED
#define OELIBC_DEPRECATED(MSG) __attribute__((deprecated(MSG)))
#endif
#ifndef OELIBC_DISABLE_DEPRECATIONS
#ifndef _OELIBC_DEPRECATED_H
#define _OELIBC_DEPRECATED_H
#include <bits/alltypes.h>
#ifndef OELIBC_ALLOW_PUTCHAR
OELIBC_DEPRECATED(“some message”) int putchar(int c);
#endif
#endif /* _OELIBC_DEPRECATED_H */
#endif /* OELIBC_DISABLE_DEPRECATIONS */
The user can disable this mechanism with the OELIBC_DISABLE_DEPRECATIONS macro or he can disable one or more functions with the corresponding macro (OELIBC_ALLOW_PUTCHAR).
The proposed mechanism can be ifdef to work with Windows as well via __declspec(deprecated(MSG)) as long as the developer is compiling with /W3 or better.
Part of this story also includes verifying that we also deprecate unsafe CRT methods in favor of their safe equivalents as mentioned in #215
To provide support for sealing scenarios using SGX, we need to provide an enclave method to access sealing keys.
Using the work done in #17 as a model, port the mbedTLS test suite to OpenEnclave and ensure all supported tests pass.
Tracking issue to accumulate known cleanup prior to public preview:
We need to flush out the details for behaviors of the enclave APIs and validate them. This includes thread binding behavior and its interactions in multi-threaded scenarios:
We should have this published to have common standards for contribution and CLA established early on.
The current MS SDK provide configuration of some enclave parameters via ENCLAVE_USE_POLICY() in the source code - creating a specific data entry evaluated by the signing tool. Could OE have something similar?
Using the work done in #17 as a model, port the libunwind test suite to OpenEnclave and ensure all supported tests pass.
We need to design out and implement exception handling support in enclaves for both Linux and Windows. This does not include supporting Structured Exception Handling for Windows.
OE SGX GDB should be able to attach to a running process, discover existing enclaves in that process, and debug these enclaves.
This story should also have additional tests that should be added along with #95
For proper C++ execution, global/static C++ constructors must be called.
We need to flush out the details for behaviors of the enclave APIs an validate them. This includes:
OpenEnclave needs to switch its existing dependencies on the AESM and isgx driver over to the new set of architectural enclaves and FLC-aware driver.
Requires #35.
We need to update the getting started docs and readmes we already have for Linux to support Windows developers and minimize their friction in adopting the SDK.
GCC & Windows VSC have different interpretations of "long" in 64-bit mode. include/openenclave/defs.h had a static assert of "long" being 64-bit, making it plausible code used plain "long"-derived types (instead of uint64_t/int64_t) assuming 64-bit width.
Do a CR to replace thus usages.
Subitem of #35
Requires #35.
Once we have a working OpenEnclave stack on Windows, we need to implement a custom debugging solution for it as enclaves will be ELF binaries hosted in a Windows PE process, and the existing Windows debuggers do not handle ELF symbol parsing, nor understand the stack stitching needed for the enclave stack.
This is currently being pursued with the Windbg team to add support in windbg for stack-stitched debugging with OE ELF enclaves.
In preparation for public preview, we will need to provide a specific API surface for public consumption. The refactor will enforce internal and public separation of use for the existing API surface, as well as break runtime headers into functional groupings for clarity of documentation.
Document existing level of support for simulator mode and ensure that unsupported functions have a consistent graceful degradation strategy (fail fast or no-op success). We should consider removing support and the Intel dependency entirely if the value of this outweighs the maintenance cost as features are added.
This story requires extra investigation into effort involved for documenting limits of support and cost to attain Intel parity support for simulator mode.
Documentation: We should specify which libc/libc++ functions/features are supported by the OE runtime, and which are absent from the standard.
We should clarify differences & explicitly mention which of the functions/features may result in OCALLS.
To prevent corruption by a malicious or buggy host, all pointers handed from the host need to be verified to be outside enclave memory and sanitized.
Double-check all pointers handed from the host are checked as of today.
Create design/coding principles to help developers handling safe host data exchange.
Requires #41, #68, #72
For symmetry, since we are not exposing a GetReportingKey API, OpenEnclave needs to offer an abstraction for report verification that support arbitrary local attestation scenarios.
Note that this requires the use of crypto libraries and would require us to design a reverse dependency injection mechanism so that an crypto lib of the developer's choice can be plugged into the enclave runtime (if they choose not to use the default mbedTLS).
This initial work also sets up the basic framework for a vendor to come in and port remaining test suites into OpenEnclave.
We need to onboard a Windows as a default CI configuration in Jenkins to catch build regressions, and specifically regressions in the ELF enclaves on Windows scenario:
The previous investigation on this has been closed in favor of converging on the same CI Jenkins infrastructure as used for the Linux configurations:
Need to set up a continuous integration pipelines for Windows, which requires extra investigation as the existing solution for Linux (#50) does not converge for Windows.
AppVeyor is one solution that other Azure teams have used and provide CI that is publicly visible to OSS contributors as well.
If we can get a single solution, this can be merged with the Linux one #50.
Follow up for implementation of the GDB debugger plugin #19, need to add public docs for how to use it.
Istvan Haller: Scrub all registers on enclave exit, including extended state.
This must include the SSE/AVX registers. For details, see xsave/xrstore/vzeroall.
At least for system-induced or automatically added OCALLS such as host-malloc or scheduler locks, re-entry via arbitrary (if not all) ECALLS on the same thread should be prevented.
Reason about a re-entry prevention for user-created OCALLS.
Reconsider download of external, unverified sources: We cannot build using external downloads without verifying them for integrity
Example: openenclave/3rdparty/dlmalloc/
We need to ensure that the existing test suites pass for the equivalent implementation on Windows. This includes additional porting efforts as necessary for the tests hosts to run on Windows where appropriate.
Remaining tests disabled on Windows:
OpenEnclave currently relies on Makefiles exclusively, which do not work cross-platform for Windows. To allow the host libraries and tools to be built on Windows, we will migrate to CMake for cross-platform build project generation.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.