Platform Comparison

Aspect	Talos II, Blackbird	Modern Intel or AMD x86-64 System
Hardware Initialization Firmware	Early hardware initialization is performed by the SBE, the firmware for which is open source and user-modifiable.	Early hardware initialization is performed by the Intel Management Engine (ME) or AMD Platform Security Processor (PSP), a closed-source vendor-signed blob which cannot be modified by the end user. The vendor and its select partners can modify the blob at will and/or under external coercion.
Microcode	POWER9 lacks horizontal or vertical microcode, aside from a few instructions which use a hardcoded sequencer. All instruction decode logic is implemented in silicon and is entirely immutable.	Microcode is provided by vendor as an encrypted and vendor-signed blob decrypted and verified by the CPU during boot. Cannot be examined or modified by the end user. See above.
Auxiliary Processor Code	A number of auxillary processors on the CPU chip perform thermal and power regulation. The code for these processors is open source and user-modifiable.	The number or purpose of any auxillary processors on Intel and AMD x86-64 designs is not well documented, though at least one such processor is known to exist on current AMD x86-64 designs (the "System Management Unit"). More may exist. The code for these processors is not open source; it is unclear whether it is user-modifiable.
Boot Firmware	Ships with open source and user-modifiable firmware.	A typical vendor x86-64 system uses closed source boot firmware, and in some cases (where "Intel Boot Guard" is used) it may not be user-modifiable either. Although open source boot firmware such as Coreboot is available, on modern x86-64 systems, it incorporates vendor-supplied binary blobs to perform essential platform initialization.
OS Bootloader	Ships with Petitboot open-source and user-modifiable OS bootloader; uses Linux (open-source and well-audited) for device enumeration. Petitboot is loaded directly from flash (so a malicious storage device cannot affect it).	Typically closed-source UEFI executes a bootloader (e.g. GRUB) stored on a storage device. Coreboot allows GRUB or Linux-based bootloaders to be loaded from flash like on POWER9. GRUB is much less well-audited than Linux.
Management Firmware	Ships with OpenBMC, an open source and user-modifiable IPMI stack.	A typical x86-64 server uses a closed source IPMI stack, which may or may not be user-modifiable.
FPGA Firmware	The Verilog source code for the FPGA used for power sequencing is open source. The specific FPGA used was chosen because an open source toolchain exists for it. (As a result, the bitstream can be built on the Talos II itself, allowing self-hosted firmware development.)	A typical x86-64 board may or may not use an FPGA or microcontroller for power sequencing; if used, the bitstream or source code is generally not available.
NIC Firmware	Integrated BCM5719 Gigabit Ethernet NIC has firmware. Systems shipped after 10th May 2021 ship with 100% open source NIC firmware based on reverse engineering of original proprietary firmware. Older systems shipped with proprietary Broadcom firmware, but if desired users can reflash the NIC to use the new open source firmware. Note that the device is behind the system IOMMU, so the security threat posed is limited. Usage of the NIC is optional; the device can be disabled. An alternative NIC can also be used via PCIe.	Varies by board and I/O peripherals.
SAS/SATA Firmware	Talos II: Optional PM8068 SAS/SATA controller has closed-source firmware. It is unknown whether it is user-modifiable, but the firmware is of a size and complexity likely to make development of an open source replacement infeasible. The device may be disabled, and boards may be ordered with the SAS/SATA controller not present. An alternative storage controller could be used via PCIe. Blackbird: Uses a firmware-free Marvell SATA controller. Note: Since all known SAS/SATA HDD/SSDs use proprietary firmware, the security advantages of open source storage controller firmware appear limited. The IOMMU protects the system from malicious I/O devices, including both storage controllers and storage devices. Properly configured full disk encryption solutions prevent the disclosure of user data to controller firmware. Full disk encryption solutions which also feature data authentication permit the system to detect data modification by controller firmware.	Varies by board and I/O peripherals.
Board Schematics	Provided with all shipped boards.	Generally not available.
Secure Boot	Optional secure boot functionality with an owner-controlled root of trust for both firmware and OS.	Secure boot configuration varies by vendor. Root of trust for OS kernel verification is generally configurable, but root of trust for vendor firmware may be locked to the vendor.
Trusted Boot	An optional FlexVer module is planned to provide trusted boot. Emphasis on physical tamper-proofing provides greater resilience against physical attack than a standard TPM. Firmware will be open source and user-modifiable.	TPM-based, generally as an optional module. Almost always vulnerable to physical attack (e.g. TPM reset attacks). Currently available TPMs are understood to have closed-source firmware. It is unknown whether this firmware is user-modifiable.
DRM	Does not contain DRM functionality.	Contains vendor-controlled DRM functionality for protection of video content.
Vulnerability to Meltdown	Shipped without vulnerability to Meltdown.	Most Intel systems are vulnerable to Meltdown without microcode updates, which are encrypted, Intel-signed binary blobs. AMD systems are not vulnerable. Alternatively, can be mitigated via kernel mitigations, but this may cause severe performance loss.
Vulnerability to Spectre	Shipped with full, highly conservative Spectre mitigation by default, including both inter-process and intra-process mitigations. This carries a substantial performance cost compared to "mitigated" x86, which does not mitigate against intra-process Spectre. The intra-process Spectre mitigation may be disabled if desired, in order to obtain performance and protection comparable to "mitigated" x86. In this case, it is the responsibility of application programmers who require intra-process Spectre protection to apply mitigations such as retpoline. Additionally, the intra-process and process/kernel Spectre mitigation may be disabled if desired, in order to obtain even higher performance and protection comparable to un-mitigated x86. In this case, it is the responsibility of systems users to ensure that only isolated, validated and verified workloads are run as all system security and isolation guarantees are potentially violated by any and all running code.	Mitigation of Spectre in full requires firmware updates and OS updates for inter-process mitigation. x86 vendors elected not to mitigate intra-process Spectre in hardware due to the high performance cost; it is the responsibility of application programmers who require intra-process Spectre protection to apply mitigations such as retpoline. (Where application programmers fail to do so, even a "mitigated" system may continue to be vulnerable.) Alternatively an entire OS distribution could be recompiled with retpoline enabled, which is likely to have a high performance cost.
IOMMU	Always enabled and denies all access by default. There is no window of vulnerability during boot. Any I/O device which attempts to read or write to memory to which it does not have access is immediately disabled and the PCIe link to it is shut down.	IOMMU must be enabled and configured correctly by the OS to provide full protection against malicious I/O devices. Not all OSes do this. The IOMMU is not on at boot, which creates a window of vulnerability during the boot process which an I/O device could use to compromise the system, even if the OS is designed to setup the IOMMU correctly. Once the IOMMU is enabled, attempts by an I/O device to read or write to memory to which it does not have access are ignored; the device is not shut down and may make further attempts. (This makes it easier for a malicious I/O device to probe for memory which may be erroneously exposed to it.)
System Management Mode	No equivalent to x86 SMM exists on POWER. The OS kernel is in full control of the cores and is never preempted by system firmware. When an event needs to be handled by the firmware (all of which is open source) after boot, it is passed to the kernel and the kernel decides when (or if) to pass it to firmware for handling.	Boot firmware may install a SMM handler which can preempt the kernel and run unknown firmware-designated code periodically. OS kernel cannot prevent or disable this, or examine the SMM handler code. Proprietary firmware almost always uses such a handler. Coreboot can be built to not install a SMM handler for some platforms.