Tracking Issue for uefi-std

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:

Writing UEFI shell applications. This includes stuff like benchmarks, self-test utilities, etc. Many drivers should also be able to use std.
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.
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:

pub fn get_system_table() -> NonNull<c_void>
pub fn get_system_handle() -> NonNull<c_void>
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)

trait OsStrExt
trait OsStringExt

Implementation History

@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.

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.

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.

Rollup merge of rust-lang#117177 - Ayush1325:uefi-alloc-type, r=worki…

Unrolled build for rust-lang#117177

@Ayush1325

@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 :)

@nicholasbishop

@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.

println don't write a new line. For new line it needs \r. Do we just add \r at the end, or is it worth it of modifying this macro ? I think println add a \n here.

println don't write a new line. For new line it needs \r. Do we just add \r at the end, or is it worth it of modifying this macro ? I think println add a \n here.

I think I had this discussion in the past, and the reason for not adding \r was that since UEFI shell also has pipes, piping to a file will become inconsistent (since we are adding an extra character).

Additionally, do note that some UEFI shell tools do seem to work fine with just \n (pipe output to a file and then use cat on it), so it seems like just LF is fine for files.

Is it possible to let the user type things and get that into a String using std::io::stdin().read_line(&mut input)?

Is it possible to let the user type things and get that into a String using std::io::stdin().read_line(&mut input)?

Reading exact characters does work. But not sure if read_line works. If I remember correctly, read_line expects \n and UEFI gives \r on enter (on OVMF at least. other UEFI implementations might give something else). But I have not tested it recently since well, I am not using rust UEFI in my current work. Maybe just try it?

Is it possible to let the user type things and get that into a String using std::io::stdin().read_line(&mut input)?

Reading exact characters does work. But not sure if read_line works. If I remember correctly, read_line expects \n and UEFI gives \r on enter (on OVMF at least. other UEFI implementations might give something else). But I have not tested it recently since well, I am not using rust UEFI in my current work. Maybe just try it?

Yeah, I got it to work with read_char from the uefi crate.

Navigation Menu

Repository navigation

Tracking Issue for uefi-std #100499

Public API

Implementation History

6 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking Issue for uefi-std #100499

Description

Public API

Implementation History

Activity

6 remaining items

Ayush1325 commented on Oct 22, 2023

medhefgo commented on Oct 22, 2023

nicholasbishop commented on Oct 24, 2023

nicholasbishop commented on Nov 4, 2023

Ayush1325 commented on Nov 4, 2023

Zekirax commented on Feb 2, 2025

Ayush1325 commented on Feb 2, 2025

t3kkm0tt commented on May 15, 2026

Ayush1325 commented on May 15, 2026

t3kkm0tt commented on May 15, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions