Move `freeze_*` methods to `OpenOptionsExt2`
Move the unstable `freeze_last_access_time` and `freeze_last_write_time` from `OpenOptionsExt` to a new `OpenOptionsExt2` trait. This should fixrust-lang/rust#153486.
Improved security section in rustdoc for `current_exe`
A few improvements to the security section of the docs about `current_exe`
0. The explanatory link <https://vulners.com/securityvulns/SECURITYVULNS:DOC:22183> is ~~broken~~ not directly very helpful in understanding the risk.
1. It basically previously says to never trust the result, which is IMO too pessimistic to be helpful. It's worth understanding the behavior but if you have a use case to re-exec the current program, which is not uncommon, this is a reasonable way to do it.
2. The particular risk is about setuid/setgid processes that shouldn't fully trust the user that spawned them.
3. IMO the most important risk with this function is that the invoker can control argv and PATH, so I made this more explicit. (Many unixes, including Linux, don't rely on them in the implementation, but some do.)
4. The previous text about TOCTOU and races is IMO not really coherent: if an attacker can write to the location where you're going to re-exec, they can fundamentally control what program is executed. They don't need to race with your execution of current_exe, and there is no up-front check.
5. Briefly explain the pattern of CVE-2009-1894: on Linux, depending on system configuration, an attacker who can create hardlinks to the executable can potentially control `/proc/self/exe`. On modern Linux this should normally require permission to write to the executable.
I did some web research for "argv0 vulnerability" and similar terms and didn't find anything else we should be documenting here. (There are issues about argc=0 but those should be prevented by memory safety in Rust.)
I found what the link seemed to be pointing to in <https://vulners.com/cve/CVE-2009-1894>, which talks about confusing a setuid program by creating a hardlink to its exe. I think this is in very particular circumstances something people should still be concerned about: a setuid program on a machine with `fs.protected_hardlinks = 0`. I don't think this justifies warning people not to use the function at all.
cc @mgeisler
Test(lib/win/proc): Skip `raw_attributes` doctest under Win7
The current doctest for `ProcThreadAttributeListBuilder::raw_attribute` uses `CreatePseudoConsole`, which is only available on Windows 10 October 2018 Update and above. On older versions of Windows, the test fails due to trying to link against a function that is not present in the kernel32 DLL. This therefore ensures the test is still built, but not run under the Win7 target.
@rustbot label T-libs A-process A-doctests O-windows-7
Fixed ByteStr not padding within its Display trait when no specific alignment is mentioned
Fixesrust-lang/rust#152804. `Path`'s `Display` uses `ByteStr`'s `Display`, which is where the problem was occurring.
The issue was coming from `ByteStr` implementation of `fmt()` in this particular area:
```rust
let Some(align) = f.align() else {
return fmt_nopad(self, f);
};
let nchars: usize = self
.utf8_chunks()
.map(|chunk| {
chunk.valid().chars().count() + if chunk.invalid().is_empty() { 0 } else { 1 }
})
.sum();
let padding = f.width().unwrap_or(0).saturating_sub(nchars);
let fill = f.fill();
let (lpad, rpad) = match align {
fmt::Alignment::Left => (0, padding),
fmt::Alignment::Right => (padding, 0),
fmt::Alignment::Center => {
let half = padding / 2;
(half, half + padding % 2)
}
};
```
The docs for the align implies that `Alignment::Left`, `Alignment::Right`, `Alignment::Center` comes from `:<`, `:>`, and `:^` respectively with `align()` returning `None` if neither of those symbols are used in the formatted string. However, while padding is taken care of in the aligned cases, we could still have padding for things that don't use alignment like:
```rust
assert_eq!(format!("{:10}", Path::new("/foo/bar").display()), "/foo/bar ");
```
We shouldn't write to `f` and return from there when there's no alignment; we should also include any potential padding/filling bytes here.
r? @joboet
The current doctest for `ProcThreadAttributeListBuilder::raw_attribute`
uses `CreatePseudoConsole`, which is only available on Windows 10
October 2018 Update and above. On older versions of Windows, the test
fails due to trying to link against a function that is not present in
the kernel32 DLL. This therefore ensures the test is still built, but
not run under the Win7 target.
Signed-off-by: Paul Mabileau <paul.mabileau@harfanglab.fr>
Remove timing assertion from `oneshot::send_before_recv_timeout`
This test regularly spuriously fails in CI, such as https://github.com/rust-lang/rust/pull/152632#issuecomment-3902778366
We can just remove the assertion but I'd like to understand why, so I'm adding more information to the assert
Test(lib/win/net): Skip UDS tests when under Win7
Unix Domain Socket support has only been added to Windows since Windows 10 Insider Preview Build 17063. Thus, it has no chance of ever being supported under Windows 7, making current tests fail. This therefore adds the necessary in order to make the tests dynamically skip when run under Windows 7, 8, and early 10, as it does not trigger linker errors.
cc rust-lang/rust#150487 @roblabla
@rustbot label T-libs A-io O-windows-7
implement `carryless_mul`
tracking issue: https://github.com/rust-lang/rust/issues/152080
ACP: https://github.com/rust-lang/libs-team/issues/738
This defers to LLVM's `llvm.clmul` when available, and otherwise falls back to a method from the `polyval` crate ([link](https://github.com/RustCrypto/universal-hashes/blob/master/polyval/src/field_element/soft/soft64.rs)).
Some things are missing, which I think we can defer:
- the ACP has some discussion about additional methods, but I'm not sure exactly what is wanted or how to implement it efficiently
- the SIMD intrinsic is not yet `const` (I think I ran into a bootstrapping issue). That is fine for now, I think in `stdarch` we can't really use this intrinsic at the moment, we'd only want the scalar version to replace some riscv intrinsics.
- the SIMD intrinsic is not implemented for the gcc and cranelift backends. That should be reasonably straightforward once we have a const eval implementation though.
Unix Domain Socket support has only been added to Windows since Windows
10 Insider Preview Build 17063. Thus, it has no chance of ever being
supported under Windows 7, making current tests fail. This therefore
adds the necessary in order to make the tests dynamically skip when run
under Windows 7, 8, and early 10, as it does not trigger linker errors.
Signed-off-by: Paul Mabileau <paul.mabileau@harfanglab.fr>
std: introduce path normalize methods at top of `std::path`
Closesrust-lang/rust#142931
Mention other methods that call `conponents` and `canonicalize` that fully normalize path. And fix two typo.
r? libs
std: Don't panic when removing a nonexistent UEFI var
`std::env::remove_var` does not say that deleting a nonexistent variable is an error (and at least on Linux, it indeed does not cause an error).
The UEFI Shell Protocol spec also doesn't say it's an error, but the edk2 implementation delegates to the UEFI runtime `SetVariable` function, which returns `EFI_NOT_FOUND` when trying to delete a nonexistent variable.
Change the UEFI implementation to check for a `NotFound` error and treat it as success.
CC @Ayush1325
`std::env::remove_var` does not say that deleting a nonexistent variable
is an error (and at least on Linux, it indeed does not cause an
error).
The UEFI Shell Protocol spec also doesn't say it's an error, but the
edk2 implementation delegates to the UEFI runtime `SetVariable`
function, which returns `EFI_NOT_FOUND` when trying to delete a
nonexistent variable.
Change the UEFI implementation to check for a `NotFound` error and treat
it as success.
RwLock: refine documentation to emphasize non-reentrancy guarantees
This addresses the need for clarification brought up in rust-lang/rust#149693. Specifically, it notes that some implementations may choose to panic if they detect deadlock situations during recursive locking attempts for both `read()` and `write()` calls.
* Provide an example highlighting that multiple read locks can be held across different threads simultaneously.
* Remove the example that shows a situation that can potentially deadlock. (as demonstrated in the very same documentation a few paragraphs above)
* Improve documentation regarding the possibility of panics during recursive read or write lock attempts.
Issues: https://github.com/rust-lang/rust/issues/149693
Update wasi-sdk used in CI/releases
This is similar to prior updates such as rust-lang/rust#149037 in that this is just updating a URL. This update though has some technical updates accompanying it as well, however:
* The `wasm32-wasip2` target no longer uses APIs from WASIp1 on this target, even for startup. This means that the final binary no longer has an "adapter" which can help making instantiation of a component a bit more lean.
* In rust-lang/rust#147572 libstd was updated to use wasi-libc more often on the `wasm32-wasip2` target. This uncovered a number of bugs in wasi-libc such as rust-lang/rust#149864, rust-lang/rust#150291, and rust-lang/rust#151016. These are all fixed in wasi-sdk-30 so the workarounds in the standard library are all removed.
Overall this is not expected to have any sort of major impact on users of WASI targets. Instead it's expected to be a normal routine update to keep the wheels greased and oiled.
This is similar to prior updates such as 149037 in that this is just
updating a URL. This update though has some technical updates
accompanying it as well, however:
* The `wasm32-wasip2` target no longer uses APIs from WASIp1 on this
target, even for startup. This means that the final binary no longer
has an "adapter" which can help making instantiation of a component a
bit more lean.
* In 147572 libstd was updated to use wasi-libc more often on the
`wasm32-wasip2` target. This uncovered a number of bugs in
wasi-libc such as 149864, 150291, and 151016. These are all fixed in
wasi-sdk-30 so the workarounds in the standard library are all
removed.
Overall this is not expected to have any sort of major impact on users
of WASI targets. Instead it's expected to be a normal routine update to
keep the wheels greased and oiled.
library/std: Rename `ON_BROKEN_PIPE_FLAG_USED` to `ON_BROKEN_PIPE_USED`
This commit is a pure internal rename and does not change any functionality.
The `FLAG_` part of `ON_BROKEN_PIPE_FLAG_USED` comes from that the compiler flag `-Zon-broken-pipe=...` is used to enable the feature.
Remove the `FLAG_` part so the name works both for the current compiler flag `-Zon-broken-pipe=...` and for the upcoming [Externally Implementable Item `#[std::io::on_broken_pipe]`](https://github.com/rust-lang/rust/pull/150591) PR. This makes the diff of that PR smaller.
The local variable name `sigpipe_attr_specified` comes from way back when the feature was controlled with an `fn main()` attribute called `#[unix_sigpipe = "..."]`. Rename that too.
Josh Stone