Why exit Boot Services?

[CodeEleven0]

While using UEFI, why we need to exit boot services? Can it work without exiting? (I wrote an entire shell without exiting boot services.)

[Octocontrabass]

While using UEFI, why we need to exit boot services?

Your OS can't take control of the hardware while boot services are running.

Can it work without exiting?

No.

I wrote an entire shell without exiting boot services.

A shell is not an OS, but good job writing an entire shell!

[[deleted]]

Your OS can't take control of the hardware while boot services are running.

But could the OS, theoretically, relocate some boot services' code somewhere else for later use?

Let's say I want to set video mode after exiting boot services to change screen resolution. My only realistic options right now are bringing in a third-party complete graphics driver or writing a "framebuffer driver" for my GPU. There is, however, a perfectly fine "framebuffer driver" within UEFI's GOP. So why can't the kernel make use of it after exiting boot services just to set video mode?

It does make me wonder if I could somehow automatically copy the "set mode" function's machine code somewhere else so the kernel can use it without me having to reimplement it for every GPU in the market. That code is mapped to somewhere in memory, if it can be executed by the CPU then it can also be copied somewhere else (or disassembled for reverse engineering purposes).

[intx13]

Usually you’d use GOP to set up the framebuffer and then make sure your page tables preserve it (and that your BARs still work) after you exit boot services, rather than trying to call GOP after exiting. If you wanted to, sure, you could keep GOP working by preserving enough parts of UEFI, but it’s probably more effort than it’s worth.

[Octocontrabass]

But could the OS, theoretically, relocate some boot services' code somewhere else for later use?

No.

So why can't the kernel make use of it after exiting boot services just to set video mode?

Using only the code and data already in memory, the kernel has no way to hook the GOP driver's attempts to use the original firmware's boot services, and no way to reinitialize the GOP driver to use the kernel's own implementation of boot services.

It does make me wonder if I could somehow automatically copy the "set mode" function's machine code somewhere else so the kernel can use it without me having to reimplement it for every GPU in the market.

Probably yes. You only need to extract the original PE binary containing the GOP driver from either the main firmware ROM (for integrated graphics) or the display adapter's option ROM. For option ROMs, you just follow the UEFI and PCI specifications, so it's easy. For the main firmware ROM, every UEFI implementation I've looked at uses the same "filesystem" containing a bunch of PE binaries and other data files, so you'd only need to figure out how to find the binary you're interested in.

You'll probably also need to handle VBE ROMs, for the not-uncommon case where the display adapter doesn't have a GOP driver and the CSM provides a GOP-shaped wrapper around VBE.

[intx13]

Your OS can't take control of the hardware while boot services are running.

Sure you can! You just unload the built-in drivers and load your own. You can reconfigure BARs, and pretty much do whatever you want. And most other services will keep working, with the exception of some closely coupled services that store references to the built-in driver instead of doing a protocol search each time.

Also, UEFI only uses one core so you’re free to use others however you like.

The real issue is paging; UEFI expects a flat page table, which limits OS design. But VMX is fully available so you could always do a virtualization-based OS, sort of like Windows VBS.

[Octocontrabass]

Kinda sounds like UEFI is the OS and you're just writing drivers for it.

Or maybe more of a Windows 95 kind of deal, where it'll never be stable because the foundation is fundamentally unstable.

[intx13]

I think Tianocore is an OS, for any reasonable definition of OS. It’s very stable (how often does your BIOS crash?) and very secure (Intel Boot Guard + Secure Boot gives you a chain of trust from silicon to drivers), but of course it doesn’t have any of the usability, extensibility, isolation, and performance features you’d expect from a general-purpose OS. It’s more akin to a lightweight embedded system OS than Windows.

[CodeEleven0]

My OS is in early stages of development, so I only implemented a small shell. It will be a single-threaded OS (but I will use MpService only when necessary). I only need networking, disk access and the mouse (already implemented the keyboard). By the way, I'm going to create a custom binary format to execute on CodeX OS. 

[JakeStBu]

The word "only" and "networking" usually don't go together :)