| Age | Commit message (Collapse) | Author | Lines |
|
Rearrange SGX split module files
In #75979 several inlined modules were split out into multiple files.
This PR keeps the multiple files but moves a few things around to
organize things in a coherent way.
|
|
In #75979 several inlined modules were split out into multiple files.
This PR keeps the multiple files but moves a few things around to
organize things in a coherent way.
|
|
|
|
Ensure TLS destructors run before thread joins in SGX
The excellent test is from ```@jethrogb```
For context see: https://github.com/rust-lang/rust/pull/83416#discussion_r617282907
|
|
|
|
Be stricter about rejecting LLVM reserved registers in asm!
LLVM will silently produce incorrect code if these registers are used as operands.
cc `@rust-lang/wg-inline-asm`
|
|
|
|
|
|
Reuse `sys::unix::cmath` on other platforms
Reuse `sys::unix::cmath` on all non-`windows` platforms.
`unix` is chosen as the canonical location instead of `unsupported` or `common` because `unsupported` doesn't make sense semantically and `common` is reserved for code that is supported on all platforms. Also `unix` is already the home of some non-`windows` code that is technically not exclusive to `unix` like `unix::path`.
|
|
|
|
Inline most raw socket, fd and handle conversions
Now that file descriptor types on Unix have niches, it is advantageous for user libraries which provide file descriptor wrappers (e.g. `Socket` from socket2) to store a `File` internally instead of a `RawFd`, so that the niche can be taken advantage of. However, doing so will currently result in worse performance as `IntoRawFd`, `FromRawFd` and `AsRawFd` are not inlined. This change adds `#[inline]` to those methods on std types that wrap file descriptors, handles or sockets.
|
|
|
|
Rework `init` and `cleanup`
This PR reworks the code in `std` that runs before and after `main` and centralizes this code respectively in the functions `init` and `cleanup` in both `sys_common` and `sys`. This makes is easy to see what code is executed during initialization and cleanup on each platform just by looking at e.g. `sys::windows::init`.
Full list of changes:
- new module `rt` in `sys_common` to contain `init` and `cleanup` and the runtime macros.
- `at_exit` and the mechanism to register exit handlers has been completely removed. In practice this was only used for closing sockets on windows and flushing stdout, which have been moved to `cleanup`.
- <s>On windows `alloc` and `net` initialization is now done in `init`, this saves a runtime check in every allocation and network use.</s>
|
|
Remove `sys::args::Args::inner_debug` and use `Debug` instead
This removes the method `sys::args::Args::inner_debug` on all platforms and implements `Debug` for `Args` instead.
I believe this creates a more natural API for the different platforms under `sys`: export a type `Args: Debug + Iterator + ...` vs. `Args: Iterator + ...` and with a method `inner_debug`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Update the minimum external LLVM to 10
r? `@nikic`
|
|
|
|
|
|
|
|
Add is_enclave_range/is_user_range overflow checks
Fixes #76343.
This adds overflow checking to `is_enclave_range` and `is_user_range` in `sgx::os::fortanix_sgx::mem` in order to mitigate possible security issues with enclave code. It also accounts for an edge case where the memory range provided ends exactly at the end of the address space, where calculating `p + len` would overflow back to zero despite the range potentially being valid.
|
|
|
|
|
|
Add Metadata in std::os::fortanix_sgx::io::FromRawFd
Needed for https://github.com/fortanix/rust-sgx/pull/291
cc `@jethrogb`
|
|
Upgrade dlmalloc to version 0.2
In preparation of adding dynamic memory management support for SGXv2-enabled platforms, the dlmalloc crate has been refactored. More specifically, support has been added to implement platform specification outside of the dlmalloc crate. (see https://github.com/alexcrichton/dlmalloc-rs/pull/15)
This PR upgrades dlmalloc to version 0.2 for the `wasm` and `sgx` targets.
As the dlmalloc changes have received a positive review, but have not been merged yet, this PR contains a commit to prevent tidy from aborting CI prematurely.
cc: `@jethrogb`
|
|
|
|
|
|
|
|
|
|
|
|
`#[deny(unsafe_op_in_unsafe_fn)]` in sys/sgx
This is part of #73904.
Enclose unsafe operations in unsafe blocks in `libstd/sys/sgx`.
|
|
Run `./x.py` fmt
Add reference link
Fix reference link
Apply review suggestions.
|
|
This commit keeps all condvars boxed on all platforms, but makes it
trivial to remove the box on some platforms later.
|
|
This commit keeps all mutexes boxed on all platforms, but makes it
trivial to remove the box on some platforms later.
|
|
|
|
|
|
Functions such as `is_enclave_range` and `is_user_range` in
`sgx::os::fortanix_sgx::mem` are often used to make sure memory ranges
passed to an enclave from untrusted code or passed to other trusted code
functions are safe to use for their intended purpose. Currently, these
functions do not perform any checks to make sure the range provided
doesn't overflow when adding the range length to the base address. While
debug builds will panic if overflow occurs, release builds will simply
wrap the result, leading to false positive results for either function.
The burden is placed on application authors to know to perform overflow
checks on their own before calling these functions, which can easily
lead to security vulnerabilities if omitted. Additionally, since such
checks are performed in the Intel SGX SDK versions of these functions,
developers migrating from Intel SGX SDK code may expect these functions
to operate the same.
This commit adds explicit overflow checking to `is_enclave_range` and
`is_user_range`, returning `false` if overflow occurs in order to
prevent misuse of invalid memory ranges. It also alters the checks to
account for ranges that lie exactly at the end of the address space,
where calculating `p + len` would overflow despite the range being
valid.
|
|
|
|
Also doing fmt inplace as requested.
|
|
|
|
Raw standard streams constructors are infallible. Remove unnecessary
result type.
|
|
|