MCP: Raise UEFI Targets to Tier-2

[dvdhrm]

Proposal

I am proposing to raise all 3 currently merged UEFI targets to Tier-2 (according to the target-tier-policy):

• aarch64-unknown-uefi
• i686-unknown-uefi
• x86_64-unknown-uefi

Please note that all three targets have very similar targets that are already Tier-2 or even Tier-1:

• aarch64-unknown-uefi: aarch64-unknown-none @ Tier-2
• i686-unknown-uefi: i686-pc-windows-msvc @ Tier-1
• x86_64-unknown-uefi: x86_64-pc-windows-msvc @ Tier-1

The UEFI targets all inherit from msvc_base and are almost equivalent to their windows-targets (except for aarch64 there is currently no windows-target, for various reasons).

target-tier-policy

Following, I will go through all non-trivial requirements of the target-tier-policy (let me know if an omitted entry requires clarification).

A tier 2 target must have value to people other than its maintainers.

UEFI environments are deployed on a global scale and the majority of consumer desktops uses UEFI environments as firmware. Furthermore, in the server market UEFI is gaining adoption for hardware other than x86, especially aarch64.

While C is still the dominant language for UEFI development, there are multiple small to large scale projects using Rust for UEFI development today:

• Tianocore EDK2 (official UEFI SDK) has experimental Rust support
• ConfidentialContainers td-shim supports UEFI through Rust
• CloudHypervisor comes with a rust based minimal UEFI firmware
• Example UEFI drivers like UefiVarMonitor have rust support
• Crates.io has many uefi-related crates, the most used ones being bootloader, uefi, r-efi

A tier 2 target must have a designated team of developers (the "target maintainers") available to consult on target-specific build-breaking issues, or if necessary to develop target-specific language or library implementation details. This team must have at least 2 developers.

Both Nicholas Bishop (@nicholasbishop) and I (@dvdhrm) volunteer to maintain these targets.

The target must not place undue burden on Rust developers not specifically concerned with that target. Rust developers are expected to not gratuitously break a tier 2 target, but are not expected to become experts in every tier 2 target, and are not expected to provide target-specific implementations for every tier 2 target.

The UEFI specification follows closely the target definitions of the Microsoft Windows platform. The major deviation is the lack of kernel and dynamic linking, as well as a different entry-point. Therefore, undue burden is not expected.

The target must provide documentation for the Rust community explaining how to build for the target using cross-compilation, and explaining how to run tests for the target. If at all possible, this documentation should show how to run Rust programs and tests for the target using emulation, to allow anyone to do so. If the target cannot be feasibly emulated, the documentation should explain how to obtain and work with physical hardware, cloud systems, or equivalent.

Official documentation of the target has recently been merged into the target-section of the rustc-book.

The target must document its baseline expectations for the features or versions of CPUs, operating systems, libraries, runtime environments, and similar.

(see previous quote)

If introducing a new tier 2 or higher target that is identical to an existing Rust target except for the baseline expectations for the features or versions of CPUs, operating systems, libraries, runtime environments, and similar, then the proposed target must document to the satisfaction of the approving teams why the specific difference in baseline expectations provides sufficient value to justify a separate target.

All UEFI targets are almost equivalent to their Microsoft Windows targets, where those exist. However, they use a different entry-point with special arguments to gain access to the firmware interface. Additionally, they lack a Windows kernel and instead run in a single address space with the firmware core. And lastly, access to complex hardware features is usually prohibited (only a single core is used, no interrupts except timers, no address space separation, ...).

The bare-metal targets usually compile into ELF rather than PE32+, hence they cannot be used for UEFI targets either.

While technically we could try to create a more generic bare-metal PE32+ target, the fact that UEFI systems are widely adopted today might justify their own specialized target.

Tier 2 targets must not leave any significant portions of core or the standard library unimplemented or stubbed out, unless they cannot possibly be supported on the target.

Supporting std on UEFI requires significant effort, which is underway. However, the targets have proven popular even without std available. Hence, I propose to proceed without std support for now.

Note that the UEFI targets also allow for developing a firmware core (as listed above). This means the UEFI protocols used to implement std are not available (on the contrary, you would be the one implementing them). Hence, even with std support available, there is still a need for no-std UEFI targets.

core and alloc is fully supported on UEFI targets, as long as a global allocator is registered by the application.

Mentors or Reviewers

The previous UEFI targets and PRs have been reviewed by @joshtriplett, @nagisa, @petrochenkov. I would be happy to see them mentor this proposal, but I have not contacted them off-list so far.

I have also communicated with other parties interested in rust UEFI support, who gladly support this effort (CC: @Ayush1325, @makubacki, @phil-opp)

Process

The main points of the Major Change Process are as follows:

• File an issue describing the proposal.
• A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
  • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
  • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
• Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

[rustbot]

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

cc @rust-lang/compiler @rust-lang/compiler-contributors

[oli-obk]

@rustbot second

[apiraino]

@rustbot label -final-comment-period +major-change-accepted