2 ms·
Agreed. The claim is "The reason behind it is that EFI variables are stored on UFS, while firmware and OS cannot share the UFS device." Ok, but why can't it us
by jsmith45 6y ago
Agreed. The claim is "The reason behind it is that EFI variables are stored on UFS, while firmware and OS cannot share the UFS device."
Ok, but why can't it use the EFI runtime services to write to the efi vars, like Windows' bcdedit does? After all, bypassing the firmware to write the vars should actually be riskier, as to my knowledge UEFI does not mandate any specific format for them in NVRAM, so a vendor very much could use a custom format if they wanted, even though almost everybody just uses a modified version of the reference implementation.
- CyberRabbi 6y agoI think that probably answers my question. There is a raw memory space for efivars that is accessible by the kernel but might also be under control of lower-level runtime services. If that is truly the case then I agree with you, the kernel should default to using the efi runtime to modify the efivars.
- my123 6y agoOn Windows, Qualcomm uses the SCM driver to hook the Get/SetVariable implementation and replace it with their own. The UEFI standard SetVariable implementation is nonfunctional and the GetVariable one is at the same state since ExitBootServices. This is due to the fact that the firmware and the OS cannot control the storage device at the same time. The issue isn't seen on most x86 PCs since those use a separate SPI flash chip for the UEFI.