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