Fortanix SGX target libunwind build process changes
Ticket: https://github.com/fortanix/rust-sgx/issues/174
LLVM related changes (merged): https://github.com/rust-lang/llvm-project/pull/57
Description: libunwind changes needed to run code in sgx environment via rust-sgx.
Target that uses this in rust: x86_64-fortanix-unknown-sgx.
Without this change, rust std for this toolchain is forced to use a precompiled library loaded via environment variable.
With this change we act the same as musl target.
`improper_ctypes_definitions` lint
Addresses #19834, #66220, and #66373.
This PR takes another attempt at #65134 (reverted in #66378). Instead of modifying the existing `improper_ctypes` lint to consider `extern "C" fn` definitions in addition to `extern "C" {}` declarations, this PR adds a new lint - `improper_ctypes_definitions` - which only applies to `extern "C" fn` definitions.
In addition, the `improper_ctype_definitions` lint differs from `improper_ctypes` by considering `*T` and `&T` (where `T: Sized`) FFI-safe (addressing #66220).
There wasn't a clear consensus in #66220 (where the issues with #65134 were primarily discussed) on the approach to take, but there has [been some discussion in Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/.2366220.20improper_ctypes.20definitions.20vs.20declarations/near/198903086). I fully expect that we'll want to iterate on this before landing.
cc @varkor + @shepmaster (from #19834) @hanna-kruppe (active in discussing #66220), @SimonSapin (#65134 caused problems for Servo, want to make sure that this PR doesn't)
This commit adds a new lint - `improper_ctypes_definitions` - which
functions identically to `improper_ctypes`, but on `extern "C" fn`
definitions (as opposed to `improper_ctypes`'s `extern "C" {}`
declarations).
Signed-off-by: David Wood <david@davidtw.co>
Converted all platform-specific stdin/stdout/stderr implementations to use io:: traits
Currently, some of the platform-specific standard streams (`src/libstd/sys/*/stdio.rs`) manually implement parts of the `io::Write` interface directly as methods on the struct, rather than by actually implementing the trait. There doesn't seem to be any reason for this, other than an unused advantage of `fn write(&self, ...)` instead of `fn write(&mut self, ...)`.
Unfortunately, this means that those implementations don't have the default-implemented io methods, like `read_exact` and `write_all`. This caused #72705, which adds forwarding methods to the user-facing standard stream implementations, to fail to compile on those platforms.
This change converts *all* such standard stream structs to use the standard library traits. This change should not cause any breakages, because the changed types are not publicly exported, and in fact are only ever used in `src/libstd/io/stdio.rs`.
Add a lint to catch clashing `extern` fn declarations.
Closes#69390.
Adds lint `clashing_extern_decl` to detect when, within a single crate, an extern function of the same name is declared with different types. Because two symbols of the same name cannot be resolved to two different functions at link time, and one function cannot possibly have two types, a clashing extern declaration is almost certainly a mistake.
This lint does not run between crates because a project may have dependencies which both rely on the same extern function, but declare it in a different (but valid) way. For example, they may both declare an opaque type for one or more of the arguments (which would end up distinct types), or use types that are valid conversions in the language the extern fn is defined in. In these cases, we can't say that the clashing declaration is incorrect.
r? @eddyb
Prevent attacker from manipulating FPU tag word used in SGX enclave
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
cc: @jethrogb
RISC-V Emulated Testing
Adds a disabled docker image on which to run RISC-V tests. Based on the armhf image.
Test using
```
./src/ci/docker/run.sh riscv64gc-linux
```
cc: @msizanoen1
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
Stabilize process_set_argv0 feature for Unix
This stabilizes process_set_argv0 targeting 1.45.0. It has been
useful in practice and seems useful as-is.
The equivalent feature could be implemented for Windows, but as far as I
know nobody has. That can be done separately.
Tracking issue: #66510
abort_internal is safe
`sys::abort_internal` is stably exposed as a safe function. Forward that assumption "inwards" to the `sys` module by making the function itself safe, too.
This corresponds to what https://github.com/rust-lang/rust/pull/72204 did for the intrinsic. We should probably wait until that lands because some of the intrinsic calls in this PR might then need adjustments.
This stabilizes process_set_argv0 targeting 1.45.0. It has been
useful in practice and seems useful as-is.
The equivalent feature could be implemented for Windows, but as far as I
know nobody has. That can be done separately.
Tracking issue: #66510
Allow a few warnings.
On Windows, these types were causing warnings to be emitted during the
build. These types are allowed to not have idiomatic names, so the
warning should be supressed.
On Windows, these types were causing warnings to be emitted during the
build. These types are allowed to not have idiomatic names, so the
warning should be supressed.
explain the types used in the open64 call
Fixes https://github.com/rust-lang/rust/issues/71915, where I learned about this quirk. I don't actually know what I am talking about here. ;)
