fwupd/docs/hsi.xml

<?xml version="1.0"?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN"
               "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd">
<reference id="hsi">
  <title>Host Security ID Specification</title>
  <warning>
    <para>
      This specification is still in active development: it is incomplete,
      subject to change, and may have errors; use this at your own risk.
      It is based on publicly available information.
    </para>
  </warning>

<!-- only show when document has been verified by all the below people
  <info>
    <authorgroup>
      <author>
        <personname>
          <firstname>Richard</firstname>
          <surname>Hughes</surname>
        </personname>
        <affiliation>
          <orgname>Red Hat</orgname>
        </affiliation>
      </author>
      <author>
        <personname>
          <firstname>Mario</firstname>
          <surname>Limonciello</surname>
        </personname>
        <affiliation>
          <orgname>Dell</orgname>
        </affiliation>
      </author>
      <author>
        <personname>
          <firstname>Alex</firstname>
          <surname>Bazhaniuk</surname>
        </personname>
        <affiliation>
          <orgname>Eclypsium</orgname>
        </affiliation>
      </author>
      <author>
        <personname>
          <firstname>Alex</firstname>
          <surname>Matrosov</surname>
        </personname>
        <affiliation>
          <orgname>Nvidia</orgname>
        </affiliation>
      </author>
    </authorgroup>
  </info>
-->

  <partintro>

    <refsect1 id="introduction">
      <title>Introduction</title>
      <para>
        Not all system vendors prioritize building a secure platform.
        The truth is that <emphasis role="strong">security costs money</emphasis>.
        Vendors have to choose between saving a few cents on a bill-of-materials
        by sharing a SPI chip, or correctly implementing BootGuard.
        Discovering security vulnerabilities often takes an external researcher
        filing a disclosure.
        These disclosures are often technical in nature and difficult for an
        average consumer to decipher.
      </para>
      <para>
        The Linux Vendor Firmware Service (LVFS) could provide some
        <emphasis role="strong">easy-to-understand</emphasis> information to
        people buying hardware.
        The service already knows a huge amount of information about machines
        from signed reports uploaded to the LVFS and from analyzing firmware binaries.
        However this information alone does not explain firmware security to the
        user in a way they can actually interpret.
      </para>
    </refsect1>

    <refsect2 id="other-tools">
      <title>Other Tools</title>
      <para>
        Traditionally, figuring out the true security of your hardware and firmware
        requires sifting through the marketing documentation provided by the
        OEM and in many cases just “trusting” they did it right.
        Tools such as Chipsec can check the hardware configuration, but they do
        not work out of the box and use technical jargon that an average user
        cannot interpret.
        Unfortunately, running a tool like Chipsec requires that you actively
        turn off some security layers such as UEFI Secure Boot, and allow 3rd
        party unsigned kernel modules to be loaded.
      </para>
    </refsect2>

    <refsect1 id="verifying">
      <title>Verifying Host Firmware Security</title>
      <para>
        To start out some core protections must be assigned a relative importance.
        Then an evaluation must be done to determine how each vendor is conforming
        to the model.
        For instance, a user might say that for home use any hardware the bare
        minimum security level (<code>HSI:1</code>) is <emphasis>good enough</emphasis>.
        For a work laptop the company IT department might restrict the choice of
        models to anything meeting the criteria of level <code>HSI:2</code> or
        above.
        A journalist or a security researcher would only buy level <code>HSI:3</code>
        and above.
        The reality is that <code>HSI:4</code> is going to be more expensive
        than some unbranded hardware that is rated <code>HSI:0</code>.
      </para>
      <para>
        To be trusted, this rating information should be distributed in a
        centralized agnostic database such as the LVFS.
      </para>
      <para>
        Of course, tools need to detect implementation errors, and to verify that
        the model that is measured does indeed match the HSI level advertised by
        the LVFS.
        Some existing compliance solutions place the burden on the OEM to define
        what firmware security has been implemented, which is easy to get wrong
        and in some cases impossible to verify.
      </para>
      <para>
        For this reason HSI will only measure security protections that can be
        verified by the end user without requiring any extra hardware to be
        connected, additional software to be installed, or disabling any existing
        security layers to measure.
      </para>
      <para>
        The HSI specification is primarily designed for laptop and desktop
        hardware, although some tests <emphasis>may</emphasis> still make sense
        on server or embedded hardware.
        It is not expected that non-consumer hardware will publish an HSI number.
      </para>
    </refsect1>

    <refsect2 id="runtime-behaviour">
      <title>Runtime Behavior</title>
      <para>
        Orthogonal to the security features provided by the firmware there are
        other security considerations related to the firmware which may require
        internet access to discover or that runtime OS changes directly affect
        the security of the firmware.
        It would not make sense to have <emphasis>have updates on the LVFS</emphasis>
        as a requirement for a specific security level as this would mean
        offline the platform might be a higher level initially but as soon as
        it is brought online it is downgraded which would be really confusing to
        users.
        The <emphasis>core</emphasis> security level will not change at
        Operating System runtime, but the suffix may.
      </para>
    </refsect2>

    <refsect2 id="hsi-level0">
      <title>HSI:0 (Insecure)</title>
      <para>
        The lowest security level with little or no detected firmware protections.
        This is the default security level if no tests can be run or some tests
        in the next security level have failed.
      </para>
    </refsect2>

    <refsect2 id="hsi-level1">
      <title>HSI:1 (Critical)</title>
      <para>
        This security level corresponds to the most basic of security protections
        considered essential by security professionals.
        Any failures at this level would have critical security impact and could
        likely be used to compromise the system firmware without physical access.
      </para>
    </refsect2>

    <refsect2 id="hsi-level2">
      <title>HSI:3 (Theoretical)</title>
      <para>
        This security level corresponds to firmware security issues that pose a
        theoretical concern or where any exploit would be difficult or
        impractical to use.
        At this level various technologies may be employed to protect the boot
        process from modification by an attacker with local access to the machine.
      </para>
    </refsect2>

    <refsect2 id="hsi-level4">
      <title>HSI:4 (System Protection)</title>
      <para>
        This security level corresponds to out-of-band protection of the system
        firmware perhaps including recovery.
      </para>
    </refsect2>

    <refsect2 id="hsi-level5">
      <title>HSI:5 (System Attestation)</title>
      <para>
        This security level corresponds to out-of-band attestation of the system
        firmware.
        There are currently no tests implemented for HSI:5 and so this security
        level cannot yet be obtained.
      </para>
    </refsect2>

    <refsect3 id="org.fwupd.hsi.Fwupd.Updates">
      <title>HSI Runtime Suffix <code>U</code></title>
      <para>
        Updates available on the <ulink url="https://fwupd.org/">
        Linux Vendor Firmware Service </ulink> which are less than 12 months old.
      </para>
    </refsect3>

    <refsect3 id="org.fwupd.hsi.Fwupd.Attestation">
      <title>HSI Runtime Suffix <code>A</code></title>
      <para>
        Attestation data is available to verify the current system firmware.
        For most UEFI platforms, this is usually the Trusted Platform Module (TPM)
        PCR0 hash, but other attestation checksums could be used.
      </para>
    </refsect3>

    <refsect3 id="runtime-bang">
      <title>HSI Runtime Suffix <code>!</code></title>
      <para>
        A runtime security issue detected.
      </para>
      <itemizedlist>
        <listitem id="org.fwupd.hsi.Uefi.SecureBoot">
          <para>
            UEFI <ulink url="https://wiki.ubuntu.com/UEFI/SecureBoot">
            Secure Boot</ulink> has been turned off. <emphasis>v1.5.0</emphasis>
          </para>
        </listitem>
        <listitem id="org.fwupd.hsi.Kernel.Tainted">
          <para>
            The kernel is <ulink url="https://www.kernel.org/doc/html/latest/admin-guide/tainted-kernels.html">
            tainted</ulink> due to a non-free module or critical firmware issue. <emphasis>v1.5.0</emphasis>
          </para>
        </listitem>
        <listitem id="org.fwupd.hsi.Kernel.Lockdown">
          <para>
            The kernel is not <ulink url="https://mjg59.dreamwidth.org/50577.html">
            locked down</ulink>. <emphasis>v1.5.0</emphasis>
          </para>
        </listitem>
        <listitem id="org.fwupd.hsi.Kernel.Swap">
          <para>
            Unencrypted <ulink url="https://wiki.archlinux.org/index.php/Dm-crypt/Swap_encryption">
            swap partition</ulink>. <emphasis>v1.5.0</emphasis>
          </para>
        </listitem>
        <listitem id="org.fwupd.hsi.Fwupd.Plugins">
          <para>
            The installed fwupd is running with <ulink url="https://github.com/fwupd/fwupd/tree/master/plugins">
            custom or modified plugins</ulink>. <emphasis>v1.5.0</emphasis>
          </para>
        </listitem>
      </itemizedlist>
    </refsect3>

    <refsect2 id="tests">
      <title>Tests included in fwupd</title>
      <para>
        The set of tests is currently x86 UEFI-centric, but will be expanded
        in the future for various ARM or RISC-V firmware protections as required.
        Where the requirement is architecture or processor specific it has been noted.
      </para>
    </refsect2>

    <refsect3 id="org.fwupd.hsi.Uefi.SecureBoot">
      <title>UEFI SecureBoot</title>
      <para>
        UEFI Secure boot is a verification mechanism for ensuring that code
        launched by firmware is trusted.
      </para>
      <para>
        Secure Boot requires that each binary loaded at boot is validated
        against trusted certifictes.
      </para>
      <itemizedlist>
        <listitem>
          <para>
            For HSI-1 SecureBoot must be available for use on UEFI systems.
            <emphasis>v1.5.0</emphasis>
          </para>
        </listitem>
      </itemizedlist>
      <note>
        <para>
          See also:
          <itemizedlist>
            <listitem>
              <ulink url="https://wiki.ubuntu.com/UEFI/SecureBoot">
                UEFI Wiki Entry
              </ulink>
            </listitem>
          </itemizedlist>
        </para>
      </note>
    </refsect3>

    <refsect3 id="org.fwupd.hsi.Spi.Bioswe">
      <title>BIOS Write Enable (BWE)</title>
      <para>
        Intel hardware provides this mechanism to protect the SPI ROM chip
        located on the motherboard from being overwritten by the operating system.
      </para>
      <itemizedlist>
        <listitem>
          <para>
            For HSI-1 the ``BIOSWE`` bit must be unset. <emphasis>v1.5.0</emphasis>
          </para>
        </listitem>
      </itemizedlist>
      <note>
        <para>
          See also:
          <itemizedlist>
            <listitem>
              <ulink url="http://www.intel.com/content/www/us/en/chipsets/6-chipset-c200-chipset-datasheet.html">
                Intel C200 Datasheet
              </ulink>
            </listitem>
          </itemizedlist>
        </para>
      </note>
    </refsect3>

    <refsect3 id="org.fwupd.hsi.Spi.Ble">
      <title>BIOS Lock Enable (BLE)</title>
      <para>
        If the lock bit is set then System Management Interrupts (SMIs) are
        raised when setting BIOS Write Enable.
        The <code>BLE</code>` bit must be enabled in the PCH otherwise
        <code>BIOSWE</code> can easily be unset.
      </para>
      <itemizedlist>
        <listitem>
          <para>
            For HSI-1 this should be set. <emphasis>v1.5.0</emphasis>
          </para>
        </listitem>
      </itemizedlist>
      <note>
        <para>
          See also:
          <itemizedlist>
            <listitem>
              <ulink url="http://www.intel.com/content/www/us/en/chipsets/6-chipset-c200-chipset-datasheet.html">
                Intel C200 Datasheet
              </ulink>
            </listitem>
          </itemizedlist>
        </para>
      </note>
    </refsect3>

    <refsect3 id="org.fwupd.hsi.Spi.SmmBwp">
      <title>SMM Bios Write Protect (SMM_BWP)</title>
      <para>
        This bit set defines when the BIOS region can be written by the host.
        The <code>SMM_BWP</code> bit must be set to make the BIOS region
        non-writable unless all processors are in system management mode.
      </para>
      <itemizedlist>
        <listitem>
          <para>
            For HSI-1 this should be set <emphasis>v1.5.0</emphasis>
          </para>
        </listitem>
      </itemizedlist>
      <note>
        <para>
          See also:
          <itemizedlist>
            <listitem>
              <ulink url="http://www.intel.com/content/www/us/en/chipsets/6-chipset-c200-chipset-datasheet.html">
                Intel C200 Datasheet
              </ulink>
            </listitem>
          </itemizedlist>
        </para>
      </note>
    </refsect3>

    <refsect3 id="org.fwupd.hsi.Tpm.Version20">
      <title>TPM 2.0 Present</title>
      <para>
        A TPM securely stores platform specific secrets that can only be divulged
        to trusted consumers in a secure environment.
      </para>
      <itemizedlist>
        <listitem>
          <para>
            For HSI-1 this should be available for use by the OS or applications <emphasis>v1.5.0</emphasis>
          </para>
        </listitem>
      </itemizedlist>
      <note>
        <para>
          See also:
          <itemizedlist>
            <listitem>
              <ulink url="https://en.wikipedia.org/wiki/Trusted_Platform_Module">
                Wikipedia TPM Article
              </ulink>
            </listitem>
          </itemizedlist>
        </para>
      </note>
    </refsect3>

    <refsect3 id="org.fwupd.hsi.Mei.ManufacturingMode">
      <title>ME not in manufacturing mode</title>
      <para>
        There have been some unfortunate cases of the ME being distributed in
        manufacturing mode.
        In manufacturing mode many features from the ME can be interacted with
        that decrease the platform’s security.
      </para>
      <itemizedlist>
        <listitem>
          <para>
            For HSI-1 this should be unset <emphasis>v1.5.0</emphasis>
          </para>
        </listitem>
      </itemizedlist>
      <note>
        <para>
          See also:
          <itemizedlist>
            <listitem>
              <ulink url="http://blog.ptsecurity.com/2018/10/intel-me-manufacturing-mode-macbook.html">
                ME Manufacturing Mode: obscured dangers
              </ulink>
            </listitem>
            <listitem>
              <ulink url="https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00086.html">
                Intel security advisory SA-00086
              </ulink>
            </listitem>
          </itemizedlist>
        </para>
      </note>
    </refsect3>

    <refsect3 id="org.fwupd.hsi.Mei.OverrideStrap">
      <title>ME Flash Descriptor Override</title>
      <para>
        The Flash Descriptor Security Override Strap is not accessible to end
        users on consumer boards and Intel stresses that this is for debugging only.
      </para>
      <itemizedlist>
        <listitem>
          <para>
            For HSI-1 this should be unset <emphasis>v1.5.0</emphasis>
          </para>
        </listitem>
      </itemizedlist>
      <note>
        <para>
          See also:
          <itemizedlist>
            <listitem>
              <ulink url="https://chromium.googlesource.com/chromiumos/third_party/flashrom/+/master/Documentation/mysteries_intel.txt">
                Chromium documentation for Intel ME
              </ulink>
            </listitem>
          </itemizedlist>
        </para>
      </note>
    </refsect3>

    <refsect3 id="org.fwupd.hsi.Mei.Version">
      <title>CSME Version</title>
      <para>
        Converged Security and Manageability Engine is a standalone management
        module that can manage and control some local devices without the host
        CPU involvement.
        The CSME lives in the PCH and can only be updated by the OEM vendor.
        The version of the CSME module can be checked to detect the most common
        and serious vulnerabilities.
      </para>
      <itemizedlist>
        <listitem>
          <para>
            For HSI-1 this should not be vulnerable to CVE-2017-5705, CVE-2017-5708,
            CVE-2017-5711, CVE-2017-5712, CVE-2017-5711, CVE-2017-5712, CVE-2017-5706,
            CVE-2017-5709, CVE-2017-5707 or CVE-2017-5710 <emphasis>v1.5.0</emphasis>
          </para>
        </listitem>
      </itemizedlist>
      <note>
        <para>
          See also:
          <itemizedlist>
            <listitem>
              <ulink url="https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00086.html">
                Intel CSME Security Review Cumulative Update
              </ulink>
            </listitem>
          </itemizedlist>
        </para>
      </note>
    </refsect3>

    <refsect3 id="org.fwupd.hsi.IntelDci">
      <title>Intel DCI</title>
      <para>
        Newer Intel CPUs support debugging over USB3 via a proprietary Direct
        Connection Interface (DCI) with the use of off-the-shelf hardware.
        DCI should always be disabled and locked on production hardware.
      </para>
      <itemizedlist>
        <listitem>
          <para>
            For HSI-1 this should be disabled. <emphasis>v1.5.0</emphasis>
          </para>
        </listitem>
        <listitem>
          <para>
            For HSI-2 this should be locked. <emphasis>v1.5.0</emphasis>
          </para>
        </listitem>
      </itemizedlist>
      <note>
        <para>
          See also:
          <itemizedlist>
            <listitem>
              <ulink url="https://www.intel.co.uk/content/www/uk/en/support/articles/000029393/processors.html">
                Intel Direct Connect Interface
              </ulink>
            </listitem>
            <listitem>
              <ulink url="https://github.com/chipsec/chipsec/blob/master/chipsec/cfg/8086/pch_4xxlp.xml#L270">
                Chipsec 4xxlp register definitions
              </ulink>
            </listitem>
            <listitem>
              <ulink url="https://github.com/riscv/riscv-edk2-platforms/blob/85a50de1b459d1d6644a402081120770aa6dd8c7/Silicon/Intel/CoffeelakeSiliconPkg/Pch/Include/Register/PchRegsDci.h">
                RISC-V EDK PCH register definitions
              </ulink>
            </listitem>
          </itemizedlist>
        </para>
      </note>
    </refsect3>

    <refsect3 id="org.fwupd.hsi.Tpm.ReconstructionPcr0">
      <title>PCR0 TPM Event Log Reconstruction</title>
      <para>
        The TPM event log records which events are registered for the PCR0 hash.
        When reconstructed the event log values should always match the TPM PCR0.
        If extra events are included in the event log, or some are missing,
        the reconstitution will fail.
      </para>
      <itemizedlist>
        <listitem>
          <para>
            For HSI-2 this should match the TPM-provided PCR0 <emphasis>v1.5.0</emphasis>
          </para>
        </listitem>
      </itemizedlist>
      <note>
        <para>
          See also:
          <itemizedlist>
            <listitem>
              <ulink url="https://www.kernel.org/doc/html/latest/security/tpm/tpm_event_log.html">
                Linux Kernel TPM Documentation
              </ulink>
            </listitem>
          </itemizedlist>
        </para>
      </note>
    </refsect3>
    <refsect3 id="org.fwupd.hsi.AcpiDmar">
      <title>Pre-boot DMA protection</title>
      <para>
        The IOMMU on modern systems is used to mitigate against DMA attacks.
        All I/O for devices capable of DMA is mapped into a private virtual
        memory region.
        The ACPI DMAR table is used to set up pre-boot DMA protection which
        eliminates some firmware attacks.
      </para>
      <itemizedlist>
        <listitem>
          <para>
            For HSI-2 this should be available <emphasis>v1.5.0</emphasis>
          </para>
        </listitem>
      </itemizedlist>
      <note>
        <para>
          See also:
          <itemizedlist>
            <listitem>
              <ulink url="https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit">
                Wikipedia IOMMU article
              </ulink>
            </listitem>
          </itemizedlist>
        </para>
      </note>
    </refsect3>

    <refsect3 id="org.fwupd.hsi.IntelBootguard">
      <title>Intel BootGuard</title>
      <para>
        BootGuard is a processor feature that prevents the machine from running
        firmware images not released by the system manufacturer.
        It forms a root-of-trust by fusing in cryptographic keys into the processor
        itself that are used to verify the Authenticated Code Modules found in
        the SPI flash.
      </para>
      <itemizedlist>
        <listitem>
          <para>
            For HSI-1 verified boot must be enabled with ACM protection. <emphasis>v1.5.0</emphasis>
          </para>
        </listitem>
        <listitem>
          <para>
            For HSI-2 the error enforcement policy must be set to “immediate shutdown”. <emphasis>v1.5.0</emphasis>
          </para>
        </listitem>
      </itemizedlist>
      <note>
        <para>
          See also:
          <itemizedlist>
            <listitem>
              <ulink url="https://github.com/coreboot/coreboot/blob/master/src/soc/intel/jasperlake/include/soc/me.h">
                Coreboot documentation
              </ulink>
            </listitem>
          </itemizedlist>
        </para>
      </note>
    </refsect3>

    <refsect3 id="org.fwupd.hsi.SuspendToRam">
      <title>Suspend to RAM disabled</title>
      <para>
        Suspend to Ram (S3) keeps the raw contents of the DRAM refreshed when
        the system is asleep.
        This means that the memory modules can be physically removed and the
        contents recovered, or a cold boot attack can be performed with a USB device.
      </para>
      <itemizedlist>
        <listitem>
          <para>
            For HSI-3 the firmware should be configured to prefer using suspend
            to idle instead of suspend to ram or to not offer suspend to
            RAM. <emphasis>v1.5.0</emphasis>
          </para>
        </listitem>
      </itemizedlist>
      <note>
        <para>
          See also:
          <itemizedlist>
            <listitem>
              <ulink url="https://en.wikipedia.org/wiki/Cold_boot_attack">
                Wikipedia article on cold boot attacks
              </ulink>
            </listitem>
          </itemizedlist>
        </para>
      </note>
    </refsect3>

    <refsect3 id="org.fwupd.hsi.IntelCet">
      <title>Intel CET Available</title>
      <para>
        Control enforcement technology is available on new Intel platforms and
        prevents exploits from hijacking the control-flow transfer instructions
        for both forward-edge (indirect call/jmp) and back-edge transfer (ret).
      </para>
      <itemizedlist>
        <listitem>
          <para>
            For HSI-3 this should be available and enabled <emphasis>v1.5.0</emphasis>
          </para>
        </listitem>
      </itemizedlist>
      <note>
        <para>
          See also:
          <itemizedlist>
            <listitem>
              <ulink url="https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf">
                Intel CET Technology Preview
              </ulink>
            </listitem>
          </itemizedlist>
        </para>
      </note>
    </refsect3>

    <refsect3 id="org.fwupd.hsi.EncryptedRam">
      <title>DRAM total memory encryption (TME)</title>
      <para>
        Total memory encryption technology is used by the firmware on supported
        SOCs to encrypt all data on external memory buses.
        It mitigates against an attacker being able to capture memory data while
        the system is running or to capture memory by removing a DRAM chip.
      </para>
      <itemizedlist>
        <listitem>
          <para>
            For HSI-4 this should be supported and enabled <emphasis>v1.5.0</emphasis>
          </para>
        </listitem>
      </itemizedlist>
      <note>
        <para>
          See also:
          <itemizedlist>
            <listitem>
              <ulink url="https://software.intel.com/content/www/us/en/develop/blogs/intel-releases-new-technology-specification-for-memory-encryption.html">
                Intel TME Press Release
              </ulink>
            </listitem>0
          </itemizedlist>
        </para>
      </note>
    </refsect3>
    <refsect3 id="org.fwupd.hsi.IntelSmap">
      <title>Supervisor Mode Access Prevention</title>
      <para>
        Without Supervisor Mode Access Prevention, the supervisor code usually
        has full read and write access to user-space memory mappings.
        This can make exploits easier to write, as it allows the kernel to
        access user-space memory when it did not intend to.
      </para>
      <itemizedlist>
        <listitem>
          <para>
            For HSI-4 the SMAP and SMEP features should be available on the CPU. <emphasis>v1.5.0</emphasis>
          </para>
        </listitem>
      </itemizedlist>
      <note>
        <para>
          See also:
          <itemizedlist>
            <listitem>
              <ulink url="https://en.wikipedia.org/wiki/Supervisor_Mode_Access_Prevention">
                Wikipedia SMAP Article
              </ulink>
            </listitem>
          </itemizedlist>
        </para>
      </note>
    </refsect3>

    <refsect3 id="org.fwupd.hsi.Iommu">
      <title>Kernel DMA protection</title>
      <para>
        The IOMMU on modern systems is used to mitigate against DMA attacks.
        All I/O for devices capable of DMA is mapped into a private virtual
        memory region.
        Common implementations are Intel VT-d and AMD-Vi.
      </para>
      <itemizedlist>
        <listitem>
          <para>
            For HSI-2 this should be available for use. <emphasis>v1.5.0</emphasis>
          </para>
        </listitem>
      </itemizedlist>
      <note>
        <para>
          See also:
          <itemizedlist>
            <listitem>
              <ulink url="https://en.wikipedia.org/wiki/Input%E2%80%93output_memory_management_unit">
                Wikipedia IOMMU article
              </ulink>
            </listitem>
          </itemizedlist>
        </para>
      </note>
    </refsect3>

    <refsect3 id="org.fwupd.hsi.SuspendToIdle">
      <title>Suspend-to-Idle</title>
      <para>
        The platform should be set up with Suspend-to-Idle as the default S3
        sleep state.
      </para>
      <itemizedlist>
        <listitem>
          <para>
            For HSI-3 this should be set <emphasis>v1.5.0</emphasis>
          </para>
        </listitem>
      </itemizedlist>
    </refsect3>

    <refsect1 id="conclusions">
      <title>Conclusion</title>
      <para>
        Any system with a Host Security ID of <code>0</code> can easily be
        modified from userspace.
        PCs with confidential documents should have a <code>HSI:3</code> or
        higher level of protection.
        In a graphical tool that would show details about the computer (such as
        GNOME Control Center’s details tab) the OS could display a field
        indicating Host Security ID.
        The ID should be shown with an alert color if the security is not at
        least <code>HSI:1</code> or the suffix is <code>!</code>.
      </para>
      <para>
        On Linux <code>fwupd</code> is used to enumerate and update firmware.
        It exports a property <code>HostSecurityId</code> and a
        <code>GetHostSecurityAttrs()</code> method.
        The attributes are supposed to represent the <emphasis>system as a whole</emphasis>
        but individual (internal) devices are able to make a claim that they
        worsened the state of the security of the system.
        Certain attributes can “obsolete” other attributes.
        An example is BIOSGuard will set obsoletes to <code>org.intel.prx</code>.
      </para>
      <para>
        A plugin method gets called on each plugin which adds attributes directly
        from the hardware or kernel.
        Several attributes may be dependent upon the kernel performing measurements
        and it will take time for these to be upstreamed.
        In some cases security level measurements will only be possible on systems
        with a newer kernel.
      </para>
      <para>
        The long term goal is to increase the <code>HSI:x</code> level of systems
        being sold to consumers.
        By making some of the <code>HSI:x</code> attributes part of the LVFS
        uploaded report we can allow users to compare vendors and models before
        purchasing hardware.
      </para>
    </refsect1>

    <refsect2 id="ommissions">
      <title>Intentional Omissions</title>
    </refsect2>
    <refsect3 id="intel-sgx">
      <title>Intel SGX</title>
      <para>
        This is not widely used as it has several high severity security issues.
      </para>
    </refsect3>
    <refsect3 id="intel-mpx">
      <title>Intel MPX</title>
      <para>
        MPX support was removed from GCC and the Linux kernel in 2019 and it is
        now considered obsolete.
      </para>
    </refsect3>

    <refsect1 id="further-work">
      <title>Further Work</title>
      <para>
        More internal and external devices should be factored into the security
        equation.
        For now the focus for further tests should be around internal device
        firmware as it is what can be most directly controlled by fwupd and the
        hardware manufacturer.
      </para>
      <para>
        Security conscious manufacturers are actively participating in the
        development of future initiatives in the Trusted Computing Group (TCG).
        As those become ratified standards that are available in hardware,
        there are opportunities for synergy with this specification.
      </para>
    </refsect1>

  </partintro>
</reference>