Insufficient sanitization of the x87 FPU tag word in the trusted enclave runtime allowed unprivileged adversaries in the containing host application to induce incoherent or unexpected results for ABI-compliant compiled enclave application code that uses the x87 FPU.
Vulnerability was disclosed to us by Fritz Alder, Jo Van Bulck, David Oswald and Frank Piessens
Revert heterogeneous SocketAddr PartialEq impls
Originally added in #72239.
These lead to inference regressions (mostly in tests) in code that looks like:
```rust
let socket = SocketAddrV4::new(Ipv4Addr::new(127, 0, 0, 1), 8080);
assert_eq!(socket, "127.0.0.1:8080".parse().unwrap());
```
That compiles as of stable 1.44.0 but fails in beta with:
```console
error[E0284]: type annotations needed
--> src/main.rs:3:41
|
3 | assert_eq!(socket, "127.0.0.1:8080".parse().unwrap());
| ^^^^^ cannot infer type for type parameter `F` declared on the associated function `parse`
|
= note: cannot satisfy `<_ as std::str::FromStr>::Err == _`
help: consider specifying the type argument in the method call
|
3 | assert_eq!(socket, "127.0.0.1:8080".parse::<F>().unwrap());
|
```
Closes#73242.
Add methods to go from a nul-terminated Vec<u8> to a CString
Fixes#73100.
Doc tests have been written and the documentation on the error type
updated too.
I used `#[stable(feature = "cstring_from_vec_with_nul", since = "1.46.0")]` but I don't know if the version is correct.
Example about explicit mutex dropping
Fixes#67457.
Following the remarks made in #73074, I added an example on the main `Mutex` type, with a situation where there is mutable data and a computation result.
In my testing it is effectively needed to explicitly drop the lock, else it deadlocks.
r? @dtolnay because you were the one to review the previous PR.
These lead to inference regressions (mostly in tests) in code that looks
like:
let socket = std::net::SocketAddrV4::new(std::net::Ipv4Addr::new(127, 0, 0, 1), 8080);
assert_eq!(socket, "127.0.0.1:8080".parse().unwrap());
That compiles as of stable 1.44.0 but fails in beta with:
error[E0284]: type annotations needed
--> src/main.rs:3:41
|
3 | assert_eq!(socket, "127.0.0.1:8080".parse().unwrap());
| ^^^^^ cannot infer type for type parameter `F` declared on the associated function `parse`
|
= note: cannot satisfy `<_ as std::str::FromStr>::Err == _`
help: consider specifying the type argument in the method call
|
3 | assert_eq!(socket, "127.0.0.1:8080".parse::<F>().unwrap());
|
Enable LVI hardening for x86_64-fortanix-unknown-sgx
This implements mitigations for the Load Value Injection vulnerability (CVE-2020-0551) for the `x86_64-fortanix-unknown-sgx` target by enabling new LLVM passes. More information about LVI and mitigations may be found at https://software.intel.com/security-software-guidance/insights/deep-dive-load-value-injection.
This PR unconditionally enables the mitigations for `x86_64-fortanix-unknown-sgx` since there is no available hardware that doesn't require the mitigations. This may be reconsidered in the future.
* [x] This depends on https://github.com/rust-lang/compiler-builtins/pull/359/
Cstring `from_raw` and `into_raw` safety precisions
Fixes#48525.
Fixes#68456.
This issue had two points:
- The one about `from_raw` has been addressed (I hope).
- The other one, about `into_raw`, has only been partially fixed.
About `into_raw`: the idea was to:
> steer users away from using the pattern of CString::{into_raw,from_raw} when interfacing with C APIs that may change the effective length of the string by writing interior NULs or erasing the final NUL
I tried making a `Vec<c_char>` like suggested but my current solution feels very unsafe and *hacky* to me (most notably the type cast), I included it here to make it available for discussion:
```rust
fn main() {
use std::os::raw::c_char;
let v = String::from("abc")
.bytes()
// From u8 to i8,
// I feel like it will be a problem for values of u8 > 255
.map(|c| c as c_char)
.collect::<Vec<_>>();
dbg!(v);
}
```
Added the documentation for the 'use' keyword
This is a partial fix of #34601.
I heavily inspired myself from the Reference on the `use` keyword.
I checked the links when compiling the documentation, they should be ok.
I also added an example for the wildcard `*` in the case of types, because it's behaviour is not *import everything* like one might think at first.
