Add Process support for UEFI

[Ayush1325]

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 Allow blocking Command::output #105458 was merged, the spawn and output implementations are completely independent.

[rustbot]

r? @Nilstrieb

rustbot has assigned @Nilstrieb.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[Noratrieb]

@dvdhrm @nicholasbishop could I get a review from you?

[joboet]

There are a number of cases where we open a protocol, but never close it. Maybe a BorrowedProtocol wrapper with the necessary Drop implementation could help solve this?

[Noratrieb]

r? joboet

[Ayush1325]

There are a number of cases where we open a protocol, but never close it. Maybe a BorrowedProtocol wrapper with the necessary Drop implementation could help solve this?

We are using GET_PROTOCOL attribute to open protocol, which does not require us to close the protocol. Feel free to point out places that might benefit from open protocol in a different way since those will require BorrowedProtocol wrapper.

[joboet]

I think this PR could be simplified quite a bit, which would also help with soundness:

Currently, Command in uefi_command_internal stores things like the system table, stdout, stderr, but it also references these resources in the image load options, or the system table. So in effect, we have a self-referential structure. Those are really tricky to get right, and this PR has some soundness bugs related to them.

Luckily, we can morph this into a Rust-like form, because all these things only need to live for the duration of the output call. So I'd recommend just storing these resources in variables inside output, and then referencing them at the appropriate places:

fn output(&mut self) {
    let stdout = create_pipe(...);
    let stderr = create_pipe(...);
    let args = convert_args(...);
    let mut st = create_st(&stdout, &stderr);
    run(&args, &mut st);
}

@rustbot author

[Dylan-DPC]

@Ayush1325 any updates on this? thanks

[Ayush1325]

@Ayush1325 any updates on this? thanks

Hi. Sorry for the delay. My college exams were going on and am busy with some contract work. Will try to address everything in a few days

[bors]

☔ The latest upstream changes (presumably #124784) made this pull request unmergeable. Please resolve the merge conflicts.

[Ayush1325]

@rustbot ready

[workingjubilee]

This looks basically like how I last saw it, yeah.

@bors r=joboet

[bors]

📌 Commit e290398 has been approved by joboet

It is now in the queue for this repository.

[Ayush1325]

This looks basically like how I last saw it, yeah.

@bors r=joboet

Yup, there was only 1 place of failure after rebase: https://github.com/rust-lang/rust/pull/123196/files#diff-21f19573f63f3900715f66b8ad29e271024c92279c5d73e0b851af423d213129R328