exit_boot_services should consume the host BootServices

[HadrienG2]

Since the boot services are invalidated upon calling exit_boot_services, they should not remain available in the safe API. So I would propose having BootServices::exit_boot_services take a self value as a parameter, rather than a &self reference.

One point to be resolved, though, is what should happen if exit_boot_services fails, for example if the mmap_key is invalid. In this case, perhaps the BootServices value, or a subset thereof (to account for partial shutdown), should be returned in order to let the user try again?

[GabrielMajeri]

@HadrienG2 I currently have two ideas for solving this:

• Making the function unsafe, and have the user handle the unsafety. This is the simplest solution to implement, but requires the user to be really careful of what references they keep.

• Use a closure / callback which is only allowed to update the memory map, since that is the only function UEFI allows us to call after the first exit_boot_services call.

The issue is that it's not easy to "move" the boot services table into the function, since we only have a reference to it stored in the system table.

In fact, even the system table is modified, in a way (the stdout / stdin handles are invalidated, etc.), meaning it's even more complicated to detect this at compile time.

[HadrienG2]

Given this extra info, maybe we could combine my original idea and your second idea as follows:

• The exit_boot_services method is moved to the SystemTable object in the Rust API (which makes it more explicit that it also consumes portions of the system table).
• It takes a closure as a parameter, allowing the user to check the memory map.
• It consumes portions of the system table, through either of the following strategies:
  1. Turn these portions into Options, and set them to None
  2. Consume the SystemTable object and return a simpler RuntimeSystemTable object

One issue to be resolved is that in both of these cases, we need to somehow move or modify the SystemTable object, which we cannot do because UEFI only gives us a &'static SystemTable. Maybe we could approach this by having uefi-rs insert a small shim before the user entry point which builds a system table wrapper object from the UEFI-provided pointer.

Or, as you say, we could also make exit_boot_services unsafe now, and leave that question for later.

[toothbrush7777777]

But it is possible to re-enter boot services — as far as I remember — if you keep all the memory allocated by UEFI and reload the GDT with the UEFI one. Or something like that.

[GabrielMajeri]

@toothbrush7777777 It is not possible.

Once ExitBootServices is called, there is no StartBootServices function or anything like that.

You might be thinking of runtime services - those services are available as long as the computer is running, and work as long as the OS informs UEFI of the updated memory map.

[toothbrush7777777]

@GabrielMajeri Yes, perhaps I was thinking of that. Did they include services for shutting down / restarting the computer?

[GabrielMajeri]

@toothbrush7777777 Yes. Runtime services include things like power management, as well as the Graphics Output Protocol and some other drivers.

This issue is about the unsafety of calling functions which only work in the boot environment after UEFI is loaded, but unsafety can also appear by calling runtime services when some conditions are not met (e.g. interrupts must be disabled, memory map has to be updated, etc.)

[HadrienG2]

After reading through chapter 2 of the UEFI spec, and in particular pp 29-30, it looks like even runtime services have a pretty elaborate calling contract that cannot be reasonably guaranteed at the library level (there are so many clauses that it would be prohibitively expensive to check and ensure everything). So ideally we should figure out a way to make runtime services unsafe after ExitBootServices are called, to remind OSes of the need to uphold that contract.

I haven't given this much thought yet, but I think resolving the "consuming boot time services part" should directly allow us to provide a different interface to run time services too. It's the first bit that will take some thought :)

Another part which will take some thought is that exiting boot services invalidates most protocols in flight. I have a hunch that we might be able to leverage the Rust lifetime system to prevent dangling protocols here, but until I've tried, there's no way to tell if this actually works and provides an ergonomic interface.

[HadrienG2]

I think a promising design would be to have a repr(transparent) newtype around an &'static SystemTable, and pretend that the UEFI entry point receives that as a parameter instead of the system table reference. repr(transparent) should ensure that this works, and the newtype should provide enough flexibility to implement "table-consuming semantics".

[HadrienG2]

I've played around this a bit this week-end, and as a first step I've started clarifying the lifetimes in uefi-rs so that the borrow checker can analyze more (less meaningless 'statics). I think I'm not that far away from a clean and safe interface for exiting boot services anymore, but only time will tell.

[GabrielMajeri]

The README recommends people to only use UEFI for the boot loader part, and try to keep their real app as an ELF payload.
This way, the actual UEFI binary only runs until a kernel is loaded and ExitBootServices gets called, at which point only runtime service calls should get made.

UEFI is such a "great" API people try to avoid using it as much as possible in practice. And the less they interact with it, the lower the risk of errors / unsafety.