| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Add Process support for UEFI
UEFI does not have an actual process. However, it does provide methods to launch and execute another UEFI image. Having process support is important since it is possible to run rust test suit using `Command::output` and is the first step towards being able to run it for UEFI.
Here is an overview of how the support is implemented.
- We create a copy of the SystemTable. This is required since at least OVMF seems to crash if the original system table is modified.
- Stdout and Stderr pipe works by registering a new `simple_text_output` Protocol and pointing the child system table to use those.
- `Stdio::Inherit` just points the console to the current running image console which seems to work with even 3 levels of process.
- `spawn` is left unimplemented since it does not make sense for UEFI architecture. Additionally, since https://github.com/rust-lang/rust/pull/105458 was merged, the `spawn` and `output` implementations are completely independent.
|
|
|
|
Feat. adding ext that returns change_time
Addresses #112327
|
|
- Update system table crc32
- Fix unsound use of Box
- Free exit data
- Code improvements
- Introduce OwnedTable
- Update r-efi to latest version
- Use extended_varargs_abi_support for
install_multiple_protocol_interfaces and
uninstall_multiple_protocol_interfaces
- Fix comments
- Stub out args implementation
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
|
|
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
|
|
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
|
|
Also fix stdio inherit
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
|
|
Only tested in 2 levels right now. Need args support for 3 levels
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
|
|
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
|
|
Implement stderr support in similar fashion.
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
|
|
Use a custom simple_text_output protocol to capture output.
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
|
|
Signed-off-by: Ayush Singh <ayushdevel1325@gmail.com>
|
|
Co-authored-by: Jonas Böttiger <jonasboettiger@icloud.com>
|
|
Note that current_guard is probably not unsafe for future work.
|
|
Editorialize on the wisdom of this as we do.
|
|
This is technically "not necessary", as we will "just" segfault instead
if we e.g. arrive inside the handler fn with the null altstack. However,
it seems incorrect to go about this hoping that segfaulting is okay,
seeing as how our purpose here is to mitigate stack overflow problems.
Make sure NEED_ALTSTACK syncs with PAGE_SIZE when we do.
Co-authored-by: Jonas Böttiger <jonasboettiger@icloud.com>
|
|
sometimes a safety comment is a prayer.
avoid fuzzy provenance casts after deref.
Co-authored-by: Jonas Böttiger <jonasboettiger@icloud.com>
|
|
workingjubilee:actually-break-up-big-ass-stack-overflow-fn, r=joboet
unix: break `stack_overflow::install_main_guard` into smaller fn
This was one big deeply-indented function for no reason. This made it hard to reason about the boundaries of its safety. Or just, y'know, read. Simplify it by splitting it into platform-specific functions, but which are still asked to keep compiling (a desirable property, since all of these OS use a similar API).
This is mostly a whitespace change, so I suggest reviewing it only after setting Files changed -> (the options gear) -> [x] Hide whitespace as that will make it easier to see how the code was actually broken up instead of raw line diffs.
|
|
|
|
Prevent double reference in generic futex
In the Windows futex implementation we were a little lax at allowing references to references (i.e. `&&`) which can lead to deadlocks due to reading the wrong memory address. This uses a trait to tighten the constraints and ensure this doesn't happen.
r? libs
|
|
Make more Windows functions `#![deny(unsafe_op_in_unsafe_fn)]`
As part of #127747, I've evaluated some more Windows functions and added `unsafe` blocks where necessary. Some are just trivial wrappers that "inherit" the full unsafety of their function, but for others I've added some safety comments. A few functions weren't actually unsafe at all. I think they were just using `unsafe fn` to avoid an `unsafe {}` block.
I'm not touching `c.rs` yet because that is partially being addressed by another PR and also I have plans to further reduce the number of wrapper functions we have in there.
r? libs
|
|
|
|
This just was a mess.
|
|
This function is purely informative, answering where a stack starts.
This is a safe operation, even if an answer requires unsafe code,
and even if the result is some unsafe code decides to trust the answer.
It also doesn't need to fetch the PAGE_SIZE when its caller just did so!
Let's complicate its signature and in doing so simplify its operation.
This allows sprinkling around #[forbid(unsafe_op_in_unsafe_fn)]
|
|
|
|
|
|
|
|
r=tgross35
std: Forbid unwrapped unsafe ops in xous and uefi modules
|
|
zkvm: add `#[forbid(unsafe_op_in_unsafe_fn)]` in `stdlib`
This also adds an additional `unsafe` block to address compiler errors.
This PR is intended to address https://github.com/rust-lang/rust/issues/127747 for the zkvm target.
|
|
Use futex.rs for Windows thread parking
If I'm not overlooking anything then the Windows 10+ thread parking implementation is practically the same as the futex.rs implementation. So we may as well use the same implementation for both. The old version is still kept around for Windows 7 support.
r? ````@joboet```` if you wouldn't mind double checking I've not missed something
|
|
Clean up more comments near use declarations
#125443 will reformat all use declarations in the repository. There are a few edge cases involving comments on use declarations that require care. This PR fixes them up so #125443 can go ahead with a simple `x fmt --all`. A follow-up to #126717.
r? ``@cuviper``
|
|
|
|
|
|
This also adds an additional `unsafe` block to address compiler errors.
|
|
There are some comments describing multiple subsequent `use` items. When
the big `use` reformatting happens some of these `use` items will be
reordered, possibly moving them away from the comment. With this
additional level of formatting it's not really feasible to have comments
of this type. This commit removes them in various ways:
- merging separate `use` items when appropriate;
- inserting blank lines between the comment and the first `use` item;
- outright deletion (for comments that are relatively low-value);
- adding a separate "top-level" comment.
We also entirely skip formatting for four library files that contain
nothing but `pub use` re-exports, where reordering would be painful.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
this is redundant, so we can just delete it.
|
|
|
|
These need to get their safety story straight
|
|
|
|
|
|
|
|
Make os/windows and pal/windows default to `#![deny(unsafe_op_in_unsafe_fn)]`
This is to prevent regressions in modules that currently pass. I did also fix up a few trivial places where the module contained only one or two simple wrappers. In more complex cases we should try to ensure the `unsafe` blocks are appropriately scoped and have any appropriate safety comments.
This does not fix the windows bits of #127747 but it should help prevent regressions until that is done and also make it more obvious specifically which modules need attention.
|
|
Windows: Remove some unnecessary type aliases
Back in the olden days, C did not have fixed-width types so these type aliases were at least potentially useful. Nowadays, and especially in Rust, we don't need the aliases and they don't help with anything. Notably the windows bindings we use also don't bother with the aliases. And even when we have used aliases they're often only used once then forgotten about.
The only one that gives me pause is `DWORD` because it's used a fair bit. But it's still used inconsistently and we implicitly assume it's a `u32` anyway (e.g. `as` casting from an `i32`).
|
