yahoo-eng-team team mailing list archive

[Kashyap Chamarthy <kchamart@xxxxxxxxxx>]

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