| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
SGX target: simplify usercall internals
This moves logic from assembly to Rust and removes the special case for exit/panic handling, merging it with regular usercall handling.
Also, this fixes a bug in the exit usercall introduced in a75ae00. The bug would make regular exits look like panics with high probability. It would also with some probability leak information through uncleared registers.
cc @VardhanThigle
r? @alexcrichton
|
|
|
|
MaybeUninit: some docs, rename into_inner -> into_initialized, return &mut from set
|
|
|
|
This moves logic from assembly to Rust and removes the special
case for exit/panic handling, merging it with regular usercall
handling.
Also, this fixes a bug in the exit usercall introduced in a75ae00.
The bug would make regular exits look like panics with high
probability. It would also with some probability leak information
through uncleared registers.
|
|
SGX target: handle empty user buffers correctly
Also, expose correct items in `os::fortanix_sgx::usercalls::alloc`
* [read_alloc documentation](https://edp.fortanix.com/docs/api/fortanix_sgx_abi/struct.Usercalls.html#method.read_alloc)
* [Clarified ByteBuffer documentation](https://github.com/fortanix/rust-sgx/pull/94/files#diff-ca843ad9e25cacd63a80579c0f7efa56)
r? @joshtriplett
|
|
|
|
|
|
Fixes https://github.com/fortanix/rust-sgx/issues/88
|
|
|
|
|
|
Add os::fortanix_sgx::ffi module
This uses the same byte slice accessors that Unix has. The [ABI specifies](https://docs.rs/fortanix-sgx-abi/0.3.2/fortanix_sgx_abi/struct.ByteBuffer.html) byte slices.
|
|
|
|
|
|
|
|
|
|
Fix undefined behavior
From the [`MaybeUninit::get_mut` docs](https://doc.rust-lang.org/std/mem/union.MaybeUninit.html):
> It is up to the caller to guarantee that the the MaybeUninit really is in an initialized state, otherwise this will immediately cause undefined behavior.
r? @joshtriplett
|
|
|
|
image-base could be used by crates like backtrace to providing to make
symbol resolution easier.
|
|
|
|
|
|
Add `io` and `arch` modules to `std::os::fortanix_sgx`
This PR adds two more (unstable) modules to `std::os::fortanix_sgx` for the `x86_64-fortanix-unknown-sgx` target.
### io
`io` allows conversion between raw file descriptors and Rust types, similar to `std::os::unix::io`.
### arch
`arch` exposes the `ENCLU[EREPORT]` and `ENCLU[EGETKEY]` instructions. The current functions are very likely not going to be the final form of these functions (see also https://github.com/fortanix/rust-sgx/issues/15), but this should be sufficient to enable experimentation in libraries. I tried using the actual types (from the [`sgx-isa` crate](https://crates.io/crates/sgx-isa)) instead of byte arrays, but that would make `std` dependent on the `bitflags` crate which I didn't want to do at this time.
|
|
|
|
|
|
Add `std::os::fortanix_sgx` module
This PR adds the `std::os::sgx` module to expose platform-specific APIs behind the `sgx_platform` feature gate.
Depends on https://github.com/rust-lang/rust/pull/56972 to be able to meaningfully build `std::os` documentation for non-standard targets.
Tracking issue: https://github.com/rust-lang/rust/issues/56975
|
|
r=alexcrichton
Adding unwinding support for x86_64_fortanix_unknown_sgx target.
Unwinding support is provided by our port of LLVM's libunwind which is available from https://github.com/fortanix/libunwind/tree/release_50.
libunwind requires support for rwlock and printing to stderr, which is only provided by `std` for this target. This poses two problems: 1) how to expose the `std` functionality to C and 2) dependency inversion.
### Exposing `std`
For exposing the functionality we chose to expose the following symbols:
* __rust_rwlock_rdlock
* __rust_rwlock_wrlock
* __rust_rwlock_unlock
* __rust_print_err
* __rust_abort
Also, the following are needed from `alloc`:
* __rust_alloc
* __rust_dealloc
#### Rust RWLock in C
In `libunwind`, RWLock is initialized as a templated static variable:
```c
pthread_rwlock_t DwarfFDECache<A>::_lock = PTHREAD_RWLOCK_INITIALIZER;
```
I don't know of a good way to use the Rust sys::rwlock::RWLock type and initializer there. We could have a static global variable in Rust, but that doesn't work with the templating. The variable needs to be initialized statically, since this target doesn't support the .init section. Currently, I just used a byte array and standard C array initialization. The mapping between this C type and the Rust type needs to be manually maintained. There is a compile-time check and a unit test to make sure the Rust versions of these C definitions match the actual Rust type. If any reviewer knows of a better solution, please do tell.
### Dependency inversion issue
`std` depends on `panic_unwind` which depends on `libunwind`, and `libunwind` depends on `std`. This is not normally supported by Rust's linking system. Therefore we use raw C exports from `std` *and* `libunwind.a` is linked last in the target `post_link_objects` instead of being built as part of the Rust `libunwind`. Currently, all C exports are defined in `src/libstd/sys/sgx/rwlock.rs` to overcome LTO issues. Only the `__rust_rwlock_*` definitions *need* to live there for privacy reasons. Once again, if any reviewer knows of a better solution, please do tell.
r? @alexcrichton
|
|
Always run rustc in a thread
cc @ishitatsuyuki @eddyb
r? @pnkfelix
[Previously](https://github.com/rust-lang/rust/pull/48575) we moved to only producing threads when absolutely necessary. Even before we opted to only create threads in some cases, which [is unsound](https://github.com/rust-lang/rust/pull/48575#issuecomment-380635967) due to the way we use thread local storage.
|
|
|
|
|
|
This reverts commit 134661917bf4b086b027a2c58219d50ba57a1453.
|
|
|
|
Remove some unnecessary feature gates
fixes #56585
cc @jethrogb
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The files src/libstd/sys/sgx/*.rs are mostly copied/adapted from
the wasm target.
This also updates the dlmalloc submodule to the very latest version.
|
