I’m not sure I completely understand the question.
But vendor / custom UEFI implementations could obviously pass around whatever structures they want.
The EFI RUNTIME services - for example - could expose custom functions in a proprietary UEFI implementation. Though in my experience this usually is not the case.
Grub should run as an EFI bootloader binary after core UEFI is done. Afaik there is no particular ring / exception level required here. It could vary depending on UEFI implantation.
on android arm32/64 devices I obviously don’t see grub, but core EFI handles and services are not modified much. If anything it’s just expanded to support the next bootloader stage and handle stuff like key combos to select next boot image
What are your must-have packages?
I’ll start:...
ELI5 what is the difference between UEFI handles passed to grub by a proprietary bootloader versus coreboot?
What are the broader implications when it comes to access, security, vulnerabilities, etc?
System sometimes crash with cpu error
Hi,...
GitHub - sjmulder/flood: Rapidly invoke (flood) a command. (github.com)
[feature request] ability to scroll images in a multi-image post
In the current implementation one has to open each individual image one by one in multi-image post....
Filters don't work as expected
This may be a function of Lemmy rather than wefwef (in which case, my apologies but here we go…)...