Re: [Qemu-devel] Re: RFC: emulation of system flash

[Jordan Justen]

On Thu, Mar 10, 2011 at 15:41, Carl-Daniel Hailfinger
<address@hidden> 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