On Thu, Mar 10, 2011 at 15:41, Carl-Daniel Hailfinger <c-d.hailfinger.devel.2...@gmx.net> wrote: > Auf 10.03.2011 23:58, Jordan Justen schrieb: >> Would the firmware >> be able to depend on having control of the device at OS runtime? This >> would be needed for UEFI non-volatile variables to make sure they can >> always be written. >> > > UEFI _should not_ have control of the device at OS runtime on real > hardware for security reasons, unless UEFI slipped a rootkit into the > OS. Not sure about Windows, but I'm pretty sure Linux will not run any > UEFI code (except maybe during early init).
UEFI non-volatile variables are a runtime service, meaning the OS should be able to utilize them at any time. It is up to the OS whether it wants to actually make use of the runtime services, of course. Both Windows and Linux do have interfaces available to modify UEFI variables at runtime. > Think flash update. If some flash update software runs under your OS of > choice, and UEFI is allowed to perform read/write accesses to flash at > the same time, you will get random corruption. You could do it like some > AMD chipsets, and provide some sort of semaphore for flash access > coordination between a flash updater and the BIOS/EFI, but I don't think > any Intel chipset can do that. Newer Intel chipsets allow locking out > flash accesses not coming from the management engine, but UEFI does not > run in the management engine, so that feature won't help us here. The UEFI systems (meaning motherboard+firmware) that I have worked on generally do not allow the flash (code) to be modified while the OS is running. Instead, UEFI has a 'capsule' concept where firmware update data is transfered to the firmware from the OS during a 'reboot' of sorts. The firmware validates the capsule data, and then flashes it on the boot following the reset. But, the sections of the flash which non-volatile variables are stored in can be updated by the UEFI firmware, and there are mechanisms which can restrict this access as well to prevent corruption of the NV variables. Unfortunately, I assume these security mechanisms often come into conflict with useful tools like flashrom. (At least during OS runtime.) > That said, if any OS out there indeed runs UEFI code regularly during OS > runtime, and that UEFI code wants to access flash, it has to hope that > nobody else is trying to access flash at the same time. An easy way out > would be to use the ACPI NVS region while the machine is running an OS, > but changes would not automatically be persistent without help from the > OS or some ACPI handler on shutdown. To be UEFI compatible, the non-volatile variable write should become persistent immediately after the call returns successfully. This has been the case on most UEFI systems that I have worked on. -Jordan