xref: /qemu/docs/devel/uefi-vars.rst (revision 6ff5da16000f908140723e164d33a0b51a6c4162)
1==============
2UEFI variables
3==============
4
5Guest UEFI variable management
6==============================
7
8The traditional approach for UEFI Variable storage in qemu guests is
9to work as close as possible to physical hardware.  That means
10providing pflash as storage and leaving the management of variables
11and flash to the guest.
12
13Secure boot support comes with the requirement that the UEFI variable
14storage must be protected against direct access by the OS.  All update
15requests must pass the sanity checks.  (Parts of) the firmware must
16run with a higher privilege level than the OS so this can be enforced
17by the firmware.  On x86 this has been implemented using System
18Management Mode (SMM) in qemu and kvm, which again is the same
19approach taken by physical hardware.  Only privileged code running in
20SMM mode is allowed to access flash storage.
21
22Communication with the firmware code running in SMM mode works by
23serializing the requests to a shared buffer, then trapping into SMM
24mode via SMI.  The SMM code processes the request, stores the reply in
25the same buffer and returns.
26
27Host UEFI variable service
28==========================
29
30Instead of running the privileged code inside the guest we can run it
31on the host.  The serialization protocol can be reused.  The
32communication with the host uses a virtual device, which essentially
33configures the shared buffer location and size, and traps to the host
34to process the requests.
35
36The ``uefi-vars`` device implements the UEFI virtual device.  It comes
37in ``uefi-vars-x86`` and ``uefi-vars-sysbus`` flavours.  The device
38reimplements the handlers needed, specifically
39``EfiSmmVariableProtocol`` and ``VarCheckPolicyLibMmiHandler``.  It
40also consumes events (``EfiEndOfDxeEventGroup``,
41``EfiEventReadyToBoot`` and ``EfiEventExitBootServices``).
42
43The advantage of the approach is that we do not need a special
44privilege level for the firmware to protect itself, i.e. it does not
45depend on SMM emulation on x64, which allows the removal of a bunch of
46complex code for SMM emulation from the linux kernel
47(CONFIG_KVM_SMM=n).  It also allows support for secure boot on arm
48without implementing secure world (el3) emulation in kvm.
49
50Of course there are also downsides.  The added device increases the
51attack surface of the host, and we are adding some code duplication
52because we have to reimplement some edk2 functionality in qemu.
53
54usage on x86_64
55---------------
56
57.. code::
58
59   qemu-system-x86_64 \
60      -device uefi-vars-x86,jsonfile=/path/to/vars.json
61
62usage on aarch64
63----------------
64
65.. code::
66
67   qemu-system-aarch64 -M virt \
68      -device uefi-vars-sysbus,jsonfile=/path/to/vars.json
69