OSDev.org

They are in the specification. Microsoft uses them on removable media to boot the Windows installer.


Runtime services work almost exactly like boot services, except you can continue to call them after you've called ExitBootServices(). Unfortunately, you must also deal with firmware bugs that don't affect Windows, so you should call SetVirtualAddressMap() even though it's supposed to be optional, and you should preserve boot services memory even though the firmware isn't supposed to access it.

Runtime services are not likely to work when processor mode is changed. For 64-bit UEFI, my stub loader switches the processor to protected mode before it starts the kernel. It might have worked with 32-bit UEFI, but those are typically buggy and it's better to boot with MBR on those systems.

Runtime services don't care what mode the processor is in when your OS is running as long as you return the processor to the correct mode before calling them.

these options are part of standard, but they clearly marked there as the "last resort default behavior for removable devices". that is if there is nothing else to boot found, only then they will be tried. so, if you have some OS already installed, this won't work. without additional trickery, like some BIOS-like changing the boot device order. But then it's better to just break into the "load from file" option and start your loader, no matter how it's called and where inside a FAT volume it sits. this option must be present in any sane firmware. just like the possibility of installing UEFI shell. but even for this abused variant, ESP marking for the FAT volume is not necessary. also some iditiotic firmwares won't boot these "magic" bootxxxx.efi things unless you directly allow some "USB boot" or whatever sh1t they invent. the point is it's non comformant inventions, one barely should rely upon, because they would lead an OSL and user experience with it to become a bunch of ugly hacks, extreme mess and frustration still not working half the cases.


just my not asked opinion: better to just weed the idea of trying such a machine out instead of trying to comply with what broke compliance this hard on its own.


who doesn't? OpenBSD does, everybody does. but why? only because it seems "easier". really, it's so much easier to search through lunatic firmwares facing them rejecting to boot at all, no matter how many times and ports you inserted your stick into, then guessing that the USB boot yet needs to be allowed, then finding out how to make that USB boot allowed, then change the order to put the USB boot atop, then waiting the sacral moment of the fw accepting that bootx64.efi, maybe still it won't? it's much easier, than finding "load from file", going through its file navigation capabilities, finding that PciRoot()\Pci()\USB()\USB()\USB()\HD(MBR, 1, b16b00b5)\efi\cooldudes\coolosldr.efi and hitting it. For me, it's a more valuable thing, that I proudly can ensure my user, that they don't need to format their sticks if they want to install my OS, than ability to add a few of machines with pornographicaly bugged firmwares to the supported list.

I suppose that might be possible after all. I already have code that switches to long mode (and back), and adding new code that switch the processor to long mode with an unity page table mapping and then call a runtime service seems to be possible. Not easy, but at least possible.

Well, I generally don't want multiboot, and by booting from an USB stick I can repartition the hard drive, and then the UEFI boot loader will be unable to boot the previous OS and needs to resort to default settings. Maybe ugly, but it seems to work well.