3 ms·

UEFI can provide post-boot services, but only in the same sense that a DOS-era BIOS did: by providing memory-mapped code that UEFI applications can call into, e

by derefr 4y ago

UEFI can provide post-boot services, but only in the same sense that a DOS-era BIOS did: by providing memory-mapped code that UEFI applications can call into, exokernel style. The UEFI framework isn't a hypervisor; it has no capacity to have ongoing execution threads "behind" the OS kernel. Rather, the OS kernel just receives a memory+PCIe map from UEFI at startup that contains some stuff UEFI left mapped; and it's up to the OS kernel whether to keep it mapped and make use of it; or just to unmap it. And no production OS kernel really uses any of the code that UEFI maps, or keeps any of said code mapped. It may keep the data-table pages (e.g. ACPI sections) mapped, for a while; but usually only long enough to copy said data into its own internal data structures. (Which is a shame, actually, as an OS kernel that did take advantage of UEFI services like UEFI applications do, would be able to do things that modern kernels currently mostly can't — like storing startup logs and crash dumps in motherboard NAND space reserved for that function, to provide on-device debugging through a separate UEFI crash-log-viewer app in case of startup disk failure, rather than needing to attach a separate serial debugger.)

LargoLasskhyfv 4y ago
On X86/AMD64 there is also ACPI and SMM (System Management Mode), which overlap in parts. ACPI calls into code provided by whichever bootloader, running post-boot above to operating system, or behind its back, so to speak. It's complicated. [1] https://en.wikipedia.org/wiki/System_Management_Mode https://en.wikipedia.org/wiki/System_Management_Mode [2] https://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface https://en.wikipedia.org/wiki/Advanced_Configuration_and_Pow... Mostly for dynamic powermanagement and voltage regulation, monitoring temperatures, hotplugging, etc. That's just the way it is (now). I remember when this first made the rounds over a decade ago with some mainboards from CENSORED Apple supplier which were pretty usable, except when running under something else than Microsoft Windows. IIRC it wasn't malice, only implemented in a way which made this hard to interface with from Linux, or the likes. Of course undocumented. Later, but about the same timeframe the first so called open source/security 'zealots' damning ACPI in general for those reasons. It may be called differently on other platforms, but similar/equivalent mechanisms exist on almost everthing which is not in a museeum or landfill.

by derefr 4y ago

LargoLasskhyfv 4y ago

On X86/AMD64 there is also ACPI and SMM (System Management Mode), which overlap in parts. ACPI calls into code provided by whichever bootloader, running post-boot above to operating system, or behind its back, so to speak. It's complicated. [1] https://en.wikipedia.org/wiki/System_Management_Mode https://en.wikipedia.org/wiki/System_Management_Mode [2] https://en.wikipedia.org/wiki/Advanced_Configuration_and_Power_Interface https://en.wikipedia.org/wiki/Advanced_Configuration_and_Pow... Mostly for dynamic powermanagement and voltage regulation, monitoring temperatures, hotplugging, etc. That's just the way it is (now). I remember when this first made the rounds over a decade ago with some mainboards from CENSORED Apple supplier which were pretty usable, except when running under something else than Microsoft Windows. IIRC it wasn't malice, only implemented in a way which made this hard to interface with from Linux, or the likes. Of course undocumented. Later, but about the same timeframe the first so called open source/security 'zealots' damning ACPI in general for those reasons. It may be called differently on other platforms, but similar/equivalent mechanisms exist on almost everthing which is not in a museeum or landfill.