-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Reimplement std's thread parker on top of events on SGX #98391
Conversation
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
(rust-highfive has picked a reviewer for you, use r? to override) |
Cool stuff. It will take use some time to review this to ensure security. cc @mzohreva @raoulstrackx |
Once you have reviewed, please re-assign back to me or someone else for the final r+ |
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
408: Document `TCS` struct limitations r=jethrogb a=raoulstrackx Document that a TCS struct should never be located as the beginning of an enclave. (ref rust-lang/rust#98391) 409: Fix broken link to std library r=jethrogb a=raoulstrackx Co-authored-by: Raoul Strackx <[email protected]>
408: Document `TCS` struct limitations r=jethrogb a=raoulstrackx Document that a TCS struct should never be located as the beginning of an enclave. (ref rust-lang/rust#98391) Co-authored-by: Raoul Strackx <[email protected]>
bors r+ |
Thank you for the review! |
r? @m-ou-se |
@bors r+ |
…iaskrgr Rollup of 10 pull requests Successful merges: - rust-lang#98391 (Reimplement std's thread parker on top of events on SGX) - rust-lang#104019 (Compute generator sizes with `-Zprint_type_sizes`) - rust-lang#104512 (Set `download-ci-llvm = "if-available"` by default when `channel = dev`) - rust-lang#104901 (Implement masking in FileType comparison on Unix) - rust-lang#105082 (Fix Async Generator ABI) - rust-lang#105109 (Add LLVM KCFI support to the Rust compiler) - rust-lang#105505 (Don't warn about unused parens when they are used by yeet expr) - rust-lang#105514 (Introduce `Span::is_visible`) - rust-lang#105516 (Update cargo) - rust-lang#105522 (Remove wrong note for short circuiting operators) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
…ou-se Replace generic thread parker with explicit no-op parker With rust-lang#98391 merged, all platforms supporting threads now have their own parking implementations. Therefore, the generic implementation can be removed. On the remaining platforms (really just WASM without atomics), parking is not supported, so calls to `thread::park` now return instantly, which is [allowed by their API](https://doc.rust-lang.org/nightly/std/thread/fn.park.html). This is a change in behaviour, as spurious wakeups do not currently occur since all platforms guard against them. It is invalid to depend on this, but I'm still going to tag this as libs-api for confirmation. `@rustbot` label +T-libs +T-libs-api +A-atomic r? rust-lang/libs
…ou-se Replace generic thread parker with explicit no-op parker With rust-lang#98391 merged, all platforms supporting threads now have their own parking implementations. Therefore, the generic implementation can be removed. On the remaining platforms (really just WASM without atomics), parking is not supported, so calls to `thread::park` now return instantly, which is [allowed by their API](https://doc.rust-lang.org/nightly/std/thread/fn.park.html). This is a change in behaviour, as spurious wakeups do not currently occur since all platforms guard against them. It is invalid to depend on this, but I'm still going to tag this as libs-api for confirmation. ``@rustbot`` label +T-libs +T-libs-api +A-atomic r? rust-lang/libs
…ou-se Replace generic thread parker with explicit no-op parker With rust-lang#98391 merged, all platforms supporting threads now have their own parking implementations. Therefore, the generic implementation can be removed. On the remaining platforms (really just WASM without atomics), parking is not supported, so calls to `thread::park` now return instantly, which is [allowed by their API](https://doc.rust-lang.org/nightly/std/thread/fn.park.html). This is a change in behaviour, as spurious wakeups do not currently occur since all platforms guard against them. It is invalid to depend on this, but I'm still going to tag this as libs-api for confirmation. ```@rustbot``` label +T-libs +T-libs-api +A-atomic r? rust-lang/libs
…ou-se Replace generic thread parker with explicit no-op parker With rust-lang#98391 merged, all platforms supporting threads now have their own parking implementations. Therefore, the generic implementation can be removed. On the remaining platforms (really just WASM without atomics), parking is not supported, so calls to `thread::park` now return instantly, which is [allowed by their API](https://doc.rust-lang.org/nightly/std/thread/fn.park.html). This is a change in behaviour, as spurious wakeups do not currently occur since all platforms guard against them. It is invalid to depend on this, but I'm still going to tag this as libs-api for confirmation. ````@rustbot```` label +T-libs +T-libs-api +A-atomic r? rust-lang/libs
Mutex and Condvar are being replaced by more efficient implementations, which need thread parking themselves (see #93740). Therefore, the generic
Parker
needs to be replaced on all platforms where the new lock implementation will be used.SGX enclaves have a per-thread event state, which allows waiting for and setting specific bits. This is already used by the current mutex implementation. The thread parker can however be much more efficient, as it only needs to store the
TCS
address of one thread. This address is stored in a state variable, which can also be set to indicate the thread was already notified.park_timeout
does not guard against spurious wakeups like the current condition variable does. This is allowed by the API ofParker
, and I think it is better to let users handle these wakeups themselves as the guarding is quite expensive and might not be necessary.@jethrogb as you wrote the initial SGX support for
std
, I assume you are the target maintainer? Could you help me test this, please? Lacking a x86_64 chip, I can't run SGX.