Public bug reported:
Background on OVMF builds
-------------------------
[This following is verbatim explanation from Laszlo Ersek (thank you),
OVMF maintainer.]
One feature that can be built into OVMF is the "Secure Boot
Feature". This is different from the operational mode called
"Secure Boot" (SB). If the firmware contains the feature, then the
guest can enable or disable the operational mode. If the firmware
does not contain the feature, then the guest cannot enable the
operational mode.
Another feature that can be built into OVMF is called "SMM" (Secure
Management Mode). This means a driver stack that consists of a set
of privileged drivers that run in SMM, and another, interfacing set
of unprivileged drivers that only format requests for the privileged
half, and parse responses from it. Once the SMM feature is built
into OVMF, then SMM emulation by the QEMU platform is
*non-optional*, it is required.
The Secure Boot Feature and the SMM feature stack are orthogonal.
You can build OVMF in all four configurations. However, if you want
to allow trustworthy code in your guests to enable the Secure Boot
operational mode (for protecting itself), and *also* want to prevent
malicious code in your guests from *circumventing* the actual
security of the Secure Boot operational mode, then you have to build
*both* features into OVMF.
* * *
IMPORTANT: Different distributions ship different kinds of builds. E.g.
Fedora ships both variants of OVMF firmware binaries: one without either
without either SB or SMM, and the other with both SB or SMM. Other
distributions ship different builds as well, and under different
pathnames. Even if they ship an SB+SMM OVMF build, the pathname for the
firmware binary may be different.
Current state of affairs in Nova
--------------------------------
Currently in Nova, we check the DEFAULT_UEFI_LOADER_PATH:
[...]
DEFAULT_UEFI_LOADER_PATH = {
"x86_64": "/usr/share/OVMF/OVMF_CODE.fd",
"aarch64": "/usr/share/AAVMF/AAVMF_CODE.fd"
}
[...]
However, that is not sufficient to enable Secure Boot (SB) + Secure
Management Mode (SMM). See the following section for what needs to be
done.
Items for upstream Nova to support OVMF SB + SMM
------------------------------------------------
[Also thanks to Laszlo for the explanation]
Taking x86_64 architecture as example, to enable guests to boot with
OVMF binary that provides the Secure Boot + Secure Management Mode
feature set, Nova should generate the XML with the following two items.
Taking CentOS as example:
(1) Enable SMM in the guest XML:
<features>
[...]
<smm state='on'/>
</features>
(2) And the OVMF 'loader' related snippet looks as following (for a
CentOS host), with Q35 machine type:
<os>
<type arch='x86_64' machine='pc-q35-rhel7.4.0'>hvm</type>
<loader readonly='yes' secure='yes'
type='pflash'>/usr/share/OVMF/OVMF_CODE.secboot.fd</loader>
[...]
</os>
NB: The paths for the UEFI binary will be different for different
distributions. At least the ones that I know of: Fedora, RHEL,
SUSE, etc
Explanation:
- The machine type should be Q35 only, and preferably 2.9 or later.
(Some earlier Q35 machine types work as well, but you'll get better
"quality of service" if you go with "pc-q35-2.9" or later.)
- The "os/loader/@secure" attribute must be set to "yes". This is what
instructs QEMU to prevent non-SMM guest code from tampering with the
varstore pflash chip.
- The "features/smm" element must exist, and the "features/smm/@state"
attribute must be set to "on". This makes sure QEMU will emulate
SMM.
* * *
NOTE: For AArch64 architecture, the OVMF binary paths will be different:
<os>
<type arch='aarch64' machine='virt-2.9'>hvm</type>
<loader readonly='yes' type='pflash'>...</loader>
[<nvram template='...'/>]
</os>
<features>
<acpi/>
</features>
So it needs consideration, too.
** Affects: nova
Importance: Undecided
Status: New
** Tags: libvirt
** Tags added: libvirt
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1707007
Title:
Add support to make Nova instances to boot with OVMF Secure Boot + SMM
(Secure Management Mode)
Status in OpenStack Compute (nova):
New
Bug description:
Background on OVMF builds
-------------------------
[This following is verbatim explanation from Laszlo Ersek (thank you),
OVMF maintainer.]
One feature that can be built into OVMF is the "Secure Boot
Feature". This is different from the operational mode called
"Secure Boot" (SB). If the firmware contains the feature, then the
guest can enable or disable the operational mode. If the firmware
does not contain the feature, then the guest cannot enable the
operational mode.
Another feature that can be built into OVMF is called "SMM" (Secure
Management Mode). This means a driver stack that consists of a set
of privileged drivers that run in SMM, and another, interfacing set
of unprivileged drivers that only format requests for the privileged
half, and parse responses from it. Once the SMM feature is built
into OVMF, then SMM emulation by the QEMU platform is
*non-optional*, it is required.
The Secure Boot Feature and the SMM feature stack are orthogonal.
You can build OVMF in all four configurations. However, if you want
to allow trustworthy code in your guests to enable the Secure Boot
operational mode (for protecting itself), and *also* want to prevent
malicious code in your guests from *circumventing* the actual
security of the Secure Boot operational mode, then you have to build
*both* features into OVMF.
* * *
IMPORTANT: Different distributions ship different kinds of builds. E.g.
Fedora ships both variants of OVMF firmware binaries: one without either
without either SB or SMM, and the other with both SB or SMM. Other
distributions ship different builds as well, and under different
pathnames. Even if they ship an SB+SMM OVMF build, the pathname for the
firmware binary may be different.
Current state of affairs in Nova
--------------------------------
Currently in Nova, we check the DEFAULT_UEFI_LOADER_PATH:
[...]
DEFAULT_UEFI_LOADER_PATH = {
"x86_64": "/usr/share/OVMF/OVMF_CODE.fd",
"aarch64": "/usr/share/AAVMF/AAVMF_CODE.fd"
}
[...]
However, that is not sufficient to enable Secure Boot (SB) + Secure
Management Mode (SMM). See the following section for what needs to be
done.
Items for upstream Nova to support OVMF SB + SMM
------------------------------------------------
[Also thanks to Laszlo for the explanation]
Taking x86_64 architecture as example, to enable guests to boot with
OVMF binary that provides the Secure Boot + Secure Management Mode
feature set, Nova should generate the XML with the following two items.
Taking CentOS as example:
(1) Enable SMM in the guest XML:
<features>
[...]
<smm state='on'/>
</features>
(2) And the OVMF 'loader' related snippet looks as following (for a
CentOS host), with Q35 machine type:
<os>
<type arch='x86_64' machine='pc-q35-rhel7.4.0'>hvm</type>
<loader readonly='yes' secure='yes'
type='pflash'>/usr/share/OVMF/OVMF_CODE.secboot.fd</loader>
[...]
</os>
NB: The paths for the UEFI binary will be different for different
distributions. At least the ones that I know of: Fedora, RHEL,
SUSE, etc
Explanation:
- The machine type should be Q35 only, and preferably 2.9 or later.
(Some earlier Q35 machine types work as well, but you'll get better
"quality of service" if you go with "pc-q35-2.9" or later.)
- The "os/loader/@secure" attribute must be set to "yes". This is what
instructs QEMU to prevent non-SMM guest code from tampering with the
varstore pflash chip.
- The "features/smm" element must exist, and the "features/smm/@state"
attribute must be set to "on". This makes sure QEMU will emulate
SMM.
* * *
NOTE: For AArch64 architecture, the OVMF binary paths will be
different:
<os>
<type arch='aarch64' machine='virt-2.9'>hvm</type>
<loader readonly='yes' type='pflash'>...</loader>
[<nvram template='...'/>]
</os>
<features>
<acpi/>
</features>
So it needs consideration, too.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1707007/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
