Usefulness of UEFI

[PeterX]

I have the impression I was overestimating UEFI all the time:
Question 1.) Is UEFI an important fundament of runtime functions for the kernel, like BIOS interrupts were for DOS? Or is it more like BIOS and 32bit OS where interrupts normally are used only at boot time?

And I thought of all use cases for EFI I can imagine and came up with these:
- turn off watchdog timer
- get mem map
- get video mode
- set video mode
- exit boot services
- load kernel helper files (similar to initial ramdisk)
- boottime messages (diagnostics or bootloader)
- boottime input (bootloader)

Question 2.) Can you name further use cases for UEFI functions?

[nexos]

Quick critique: You mean "boot services", not "runtime functions". The two are different .
Anyway, boot services are only designed for use like BIOS ints. Once you call ExitBootServices, they can't be used. Runtime services, however, can be used as long as their regions are mapped. One use of a runtime service is setting up a new environment variable from the OS in the firmware.

[PeterX]

Quick critique: You mean "boot services", not "runtime functions". The two are different .
Anyway, boot services are only designed for use like BIOS ints. Once you call ExitBootServices, they can't be used. Runtime services, however, can be used as long as their regions are mapped. One use of a runtime service is setting up a new environment variable from the OS in the firmware.

No, I didn't mean boot services! I meant runtime services (at least in my first question). Are they important anyway except the env vars you mentioned? Or is it more like pmode where you normally don't have any BIOS interrutps (with exceptions which aren't important here.)

You know, I sort of thought: When I got the boot stuff working there would be a lot of cool UEFI functionality at OS runtime. But I now have the impression that is wrong.

The second question is about ALL UEFI funtions/services.

Greetings
Peter

[rdos]

It's quite similar to BIOS. While it might be possible to use the real-mode BIOS to access devices like VBE or discs, it's not very practical. Any serious OS will need it's own device drivers anyway.

[Octocontrabass]

Is UEFI an important fundament of runtime functions for the kernel, like BIOS interrupts were for DOS? Or is it more like BIOS and 32bit OS where interrupts normally are used only at boot time?

UEFI runtime services are mainly for convenience. There's one you can use to change the boot order without opening the UEFI setup. There's one you can use to get the system date and time before you've parsed the ACPI tables to detect the RTC. There's one you can use to reboot or shut down without the help of ACPI.

Can you name further use cases for UEFI functions?

Other than ordinary bootloader stuff you already mentioned or the three runtime services I listed above, I don't think I would go out of my way to use any particular UEFI services.

[nexos]

Quick critique: You mean "boot services", not "runtime functions". The two are different .
Anyway, boot services are only designed for use like BIOS ints. Once you call ExitBootServices, they can't be used. Runtime services, however, can be used as long as their regions are mapped. One use of a runtime service is setting up a new environment variable from the OS in the firmware.

No, I didn't mean boot services! I meant runtime services (at least in my first question). Are they important anyway except the env vars you mentioned? Or is it more like pmode where you normally don't have any BIOS interrutps (with exceptions which aren't important here.)

You know, I sort of thought: When I got the boot stuff working there would be a lot of cool UEFI functionality at OS runtime. But I now have the impression that is wrong.

The second question is about ALL UEFI funtions/services.

Greetings
Peter

Oh ok, I misunderstood, sorry . As Octocontrabass stated, UEFI mainly provides convenience functions in runtime. As I already stated, however, it could be a pain calling them, as you need to identity map the runtime services and runtime drivers area of the EFI memory map, which could be incompatible with your OS's memory state.

[kzinti]

As I already stated, however, it could be a pain calling them, as you need to identity map the runtime services and runtime drivers area of the EFI memory map, which could be incompatible with your OS's memory state.

You can remap the runtime services to any virtual address you want by calling SetVirtualAddressMap() after exiting boot services.

[bzt]

I have the impression I was overestimating UEFI all the time:
Question 1.) Is UEFI an important fundament of runtime functions for the kernel, like BIOS interrupts were for DOS?

Definitely NOT. DOS was lucky so that it could stand on the shoulders of BIOS for I/O.

Or is it more like BIOS and 32bit OS where interrupts normally are used only at boot time?

More like it. 99% of UEFI is completely USELESS after exit Boot Services.

And I thought of all use cases for EFI I can imagine and came up with these:
- turn off watchdog timer
- get mem map
- get video mode
- set video mode
- exit boot services
- load kernel helper files (similar to initial ramdisk)
- boottime messages (diagnostics or bootloader)
- boottime input (bootloader)

Forget ALL of these! These aren't runtime services, a kernel can't use any of these. For example DOS could read a sector into memory using BIOS, but your kernel can't use UEFI Block IO to do the same, you'll have to write a native driver!

Question 2.) Can you name further use cases for UEFI functions?

No! Everything UEFI runtime services provide is a lot simpler to achive without using UEFI. Getting the time? Using a few IO commands is a lot simpler than generating an MS ABI conformant call and parsing it's time structure. Reset the computer? Just do a triple-fault, works 100% of the time. Shutdown? That's not even possible with UEFI, needs a native ACPI driver anyway. Using UEFI variables? Why on earth would anyone do that except for setting the boot order occassionally? Setting virtual map? All kernels will change CR3 directly sooner or later...

That being said, it's not the usefulness of UEFI that's the question. That's the only thing you can use to boot your kernel, so you must support it, whether you like it or not. We must cook from the ingredients we got.

Cheers,
bzt

[Octocontrabass]

Getting the time? Using a few IO commands is a lot simpler than generating an MS ABI conformant call and parsing it's time structure.

If a legacy RTC exists, yes.

Setting virtual map? All kernels will change CR3 directly sooner or later...

That function is for relocating UEFI runtime services to different virtual addresses. It doesn't change CR3 or the page tables.

[bzt]

That function is for relocating UEFI runtime services to different virtual addresses. It doesn't change CR3 or the page tables.

The other way around: changing CR3 will remove the ground under UEFI runtime's feet, and "relocating UEFI runtime services" is an utterly and completely dead concept, failure by design. How are you supposed to call SetVirtualAddressMap to configure runtime services' mapping for the new address space, when SetVirtualAddressMap itself is a runtime service? Which one was first, chicken or egg?

And I can't imagine that any OS would afford the unnecessary overhead of calling SetVirtualAddressMap() on each and every task switch when they modify CR3 for some useless functions that are already implemented in the kernel any way. And if they do call it, then they most certainly just expose their kernels to a huge attack vector by allowing UEFI rootkits and malware that installed their own runtime services to poison the OS... Nah, better to forget about UEFI entirely after calling Boot Services, or even better actively stop it from running.

There's simply nothing that would worth having UEFI run-time services for, but at least it's a huge security risk... (sarcasm)

Cheers,
bzt

[PeterX]

That being said, it's not the usefulness of UEFI that's the question. That's the only thing you can use to boot your kernel, so you must support it, whether you like it or not. We must cook from the ingredients we got.

Yes, true. I just had some fancy dreams about using some sort of UEFI "drivers" at runtime for all kinds of hardware or at least for some hardware. But I know better now: UEFI is mostly for booting, maybe with some exceptions, but more or less that.

Greetings
Peter

[Octocontrabass]

How are you supposed to call SetVirtualAddressMap to configure runtime services' mapping for the new address space, when SetVirtualAddressMap itself is a runtime service? Which one was first, chicken or egg?

The call to SetVirtualAddressMap() must be done with the physical mappings. On successful return from this function, the system must then make any future calls with the newly assigned virtual mappings.

And I can't imagine that any OS would afford the unnecessary overhead of calling SetVirtualAddressMap() on each and every task switch

A virtual address map may only be applied one time. Once the runtime system is in virtual mode, calls to this function return EFI_UNSUPPORTED.

[vvaltchev]

Apparently, there's a widespread misconception about UEFI:
https://www.reddit.com/r/osdev/comments ... _tutorial/

The good thing is that a guy shared a playlist on youtube by "Poncho" about writing an operating system
from scratch: https://www.youtube.com/playlist?list=P ... a8l0Jb6l8-
I believe that it might be useful to people here as well.

[off-topic]
Btw, I have a question: is r/osdev related with this community or it's just completely unrelated?
[/off-topic]

[bzt]

So it even must less useful as I've originally thought! If what you say is true, then there's really no use of SetVirtualAddressMap!

How are you supposed to call SetVirtualAddressMap to configure runtime services' mapping for the new address space, when SetVirtualAddressMap itself is a runtime service? Which one was first, chicken or egg?

The call to SetVirtualAddressMap() must be done with the physical mappings. On successful return from this function, the system must then make any future calls with the newly assigned virtual mappings.

Erhm, UEFI on 64 bit can't be set to physical mapping mode, as virtual mapping is a requirement for long mode.

And I can't imagine that any OS would afford the unnecessary overhead of calling SetVirtualAddressMap() on each and every task switch

A virtual address map may only be applied one time. Once the runtime system is in virtual mode, calls to this function return EFI_UNSUPPORTED.

Hehe, any OS would switch the virtual mappings pretty frequently during task switches... Those UEFI Consurtium guys really were fools! (Unless they expected the run-time services to be mapped in kernel-space, in which case they unarguably using UEFi as an excuse to create a backdoor in OSes.) Either way, forget UEFI run-time, that's the best!

Cheers,
bzt

[Octocontrabass]

Erhm, UEFI on 64 bit can't be set to physical mapping mode, as virtual mapping is a requirement for long mode.

I think you've misunderstood something. The spec uses "physical mappings" to refer to virtual addresses that are equal to physical addresses. You can easily satisfy that requirement without disabling paging by using identity mapping.

Hehe, any OS would switch the virtual mappings pretty frequently during task switches... Those UEFI Consurtium guys really were fools! (Unless they expected the run-time services to be mapped in kernel-space, in which case they unarguably using UEFi as an excuse to create a backdoor in OSes.) Either way, forget UEFI run-time, that's the best!

Why do you assume you must keep the UEFI runtime code and data mapped all the time? You can remove the mappings when you're not using them, and put them back when you want to call a UEFI runtime service.