Tracking Issue for uefi-std

[Ayush1325]

Feature gate: #![feature(uefi_std)]

This is a tracking issue for Std support for UEFI environment. I have been working on implementing this as a part of my Google Summer of Code 2022 project. Information about the current state of this implementation can be found at src/doc/rustc/src/platform-support/unknown-uefi.md. A PR has already been opened here

For those who are wondering how a target like UEFI can benefit from std support, here are a few examples:

1. Writing UEFI shell applications. This includes stuff like benchmarks, self-test utilities, etc. Many drivers should also be able to use std.
2. Finding UEFI target bugs. During this work, I have found 3 numeric tests that cause CPU exceptions for UEFI (they are fixed now. Also, I have found 2 additional bugs (which seem like bugs in llvm soft-float) which went unnoticed because there was no easy way to do any broad testing.
3. Provide a stable interface for library developers. The current std contains some functions under std::os::uefi::env to provide access to the underlying SystemTable and SystemHandle, which are essential for writing anything for UEFI.

Public API

APIs I propose to add under std::os::uefi::env:

1. pub fn get_system_table() -> NonNull<c_void>
2. pub fn get_system_handle() -> NonNull<c_void>
3. pub fn boot_services() -> Option<NonNull<c_void>>

APIs I propose to add under std::os::uefi::ffi (Just re-export std::os::windows::ffi)

1. trait OsStrExt
2. trait OsStringExt

Implementation History

• Add Minimal Std implementation for UEFI #105861
• Stdio support for UEFI #116207
• Implement sys::args for UEFI #116341
• Improve UEFI stdio #117174
• Use ImageDataType for allocation type #117177
• Implement SystemTime for UEFI #120351
• Expand sys/os for UEFI #120419
• Mark UEFI std support as WIP #120640
• Implement Instant for UEFI #120889
• Implement sys/thread for UEFI #120938
• Add Process support for UEFI #123196

[medhefgo]

The allocator seems to be hard-coded to use LOADER_DATA memory type. This should really be based on the current image type as reported by the EFI_LOADED_IMAGE_PROTOCOL. Using the wrong memory type for boot or runtime drivers will likely cause crashes or UB when ExitBootServices are called by the kernel.

Of course, this only applies if uefi-std intends to support boot and runtime drivers.

[Ayush1325]

@medhefgo, The main target for uefi-std, is uefi applications. That being said, I am not opposed to expanding it's scope as long as it is not detrimental to the main target.

Do you mean using EFI_LOADED_IMAGE_PROTOCOL->ImageDataType to decide the memory type? I am not too familiar with it's usage so maybe @dvdhrm and @nicholasbishop can provide insight if it can be used?

One thing to note is that some allocations take place between sys::init and user main. That is the main reason for not providing an endpoint under os::* for setting the allocation type.

[medhefgo]

@medhefgo, The main target for uefi-std, is uefi applications. That being said, I am not opposed to expanding it's scope as long as it is not detrimental to the main target.

It would be nice if boot drivers could be supported as they are not too different from apps. Runtime drivers are probably too niche and probably have too many pitfalls in it.

The main question is what the rust entry point machinery expects: For EFI drivers to be any useful they have to return from main with success code without tearing down anything. The code will continue to be called as needed by the firmware. The real exit tear-down would be handled by the exit handler that would be registered on EFI_LOADED_IMAGE_PROTOCOL.
If the rust machinery cannot handle that setup, it should definitely be documented that only EFI apps are possible as std target.

Do you mean using EFI_LOADED_IMAGE_PROTOCOL->ImageDataType to decide the memory type? I am not too familiar with it's usage so maybe @dvdhrm and @nicholasbishop can provide insight if it can be used?

Yes.

[nicholasbishop]

Using ImageDataType for the memory type sounds good to me, and agree it would be good to document in the target docs exactly which executable types are intended to be supported by uefi-std.

[nicholasbishop]

@Ayush1325 I have a question about the feature gate described here, #![feature(uefi_std)] (which is also shown in the UEFI targets docs).

It doesn't look to me like that feature actually exists. It's used in a couple places under library/std/src/os/uefi/, but it's not defined in compiler/rustc_feature/src/ (see https://rustc-dev-guide.rust-lang.org/implementing_new_features.html#stability-in-code for details how how a feature should be defined).

It seems that right now, even without that feature, I can build a UEFI std program on nightly:

// src/main.rs:
fn main() {
    let p = std::path::Path::new("/test");
    println!("Hello, world! {}", p.display());
}

// Building with `cargo +nightly build --target=x86_64-unknown-uefi` succeeds

I'm not sure if that's intended right now, since std on UEFI hasn't been stabilized as far as I know? The UEFI targets are tier 2 though, so maybe it's fine? I'm not actually sure what the intended policy here is :)

[Ayush1325]

@nicholasbishop As far as I understand it, uefi_std feature only needs to be enabled if you use std::os::uefi::* stuff, not general std. If you try using it without enabling the feature, you get the following error:

error[E0432]: unresolved import `std::os::uefi`
   --> src/main.rs:1:5
    |
1   | use std::os::uefi;
    |     ^^^^^^^^^^^^^ no `uefi` in `os`
    |
note: found an item that was configured out
   --> /var/home/ayush/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/os/mod.rs:148:9
    |
148 | pub mod uefi;
    |         ^^^^
    = note: the item is gated behind the `uefi` feature

On further inspection, I think that link is only for language features. Here is the link for library features: https://rustc-dev-guide.rust-lang.org/stability.html. I think everything required is already present.