Platform Comparison

Aspect	Talos II	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.
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 closed-source but user-modifiable firmware. The device is behind the system IOMMU, so the security threat posed is limited. Work on writing open source replacement firmware is ongoing. Usage is optional; the device can be disabled. An alternative NIC could be used via PCIe.	Varies by board and I/O peripherals.
SAS/SATA Firmware	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. 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	No DRM functionality configured as shipped. DRM schemes may be implemented using the system entirely under owner control via provided owner controlled Secure/Trusted Boot functionality. End users in any DRM scheme, who have physical access, may always assert ownership over a system. This assertion is entirely undeniable. A previous owner may detect when an user has replaced them as the owner of a system if that system continues to communicate with the previous owner. End users, who have become owners through physical assertion, may replace entirely any DRM scheme without communications with or the procurement of the cooperation or agreement of any previous owner.	Contains DRM functionality for protection of video content. No known way to disable DRM functionality. System functionality protected by DRM is always controlled by vendor.
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 comparable to un-mitigated x86. In this case, it is the responsibility of application programmers who require intra-process Spectre protection to apply mitigations such as retpoline.	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.