Tip: Secured-core was first introduced in Windows Server 2022, and is a combination of security features implemented in hardware, firmware, driver and the operating system. However, there is no actual feature named “Secured-core”; instead, it is just a group of security-related settings in UEFI and in Windows that are enabled.

To be certified for Secured-core, new server firmware protection features are required. Currently only ThinkSystem servers with 3rd Gen Intel Xeon Scalable processors are
certified, however ThinkSystem servers with AMD EPYC 7003 Series processors are also
planned in the near future.

Hardware root-of-trust with TPM 2.0

Trusted Platform Module 2.0 (TPM 2.0) comes standard with Secured-core servers. A TPM 2.0 chip can check the integrity of the UEFI and firmware of the devices, comparing it to the information that has been burned into the chip by Lenovo during manufacturing.

This Secure Boot capability ensures that no unauthorized firmware or software has been loaded before the OS. It gives customers a secure store for sensitive keys and data during early boot process and the isolations from software-based attacks. This hardware root-of-trust provides a hardware level verification that the rest of the operating system and applications can rely on.

Figure 1 steps through a trusted boot process in which UEFI uses TPM to measure initial BIOS, Option ROMs, device drivers, and OS components prior to their execution by checking data integrity, consistent of PCR values or hash values. The boot process ensures that, when the OS loads and the user logs in, the system is trusted.

Tip: Measured boot is a way for OS to record the chain of measurements of software
components and configuration information in the TPM through the initialization of the
Windows operating system.

Firmware protection with DRTM

Firmware executes with high privileges and is often invisible to traditional anti-virus solutions, which has given rise to numbers of firmware-based attacks. Attackers compromise the boot flow to achieve low-level malware behaviour that is hard to detect, posing a significant risk to systems.

To keep the server’s firmware and hardware trustworthy and healthy, the server should be able to detect and block malicious software that runs before the operating system initializes or during the boot process itself.

There are two techniques to measure early boot UEFI components:

• Static Root of Trust for Measurement (SRTM)

SRTM provides a fixed piece of trusted code in the UEFI that is loaded at the start of the entire booting chain. SRTM has some shortcomings, however: the SRTM flow is brittle that a minor change can invalidate the chain of trust, and SRTM gives only the load time guarantee but not the run time guarantee for the launched environment.

• Dynamic Root of Trust for Measurement (DRTM)

DRTM is a trust mechanism using Intel’s Trusted Execution Technology (TXT) or AMD’s SKINIT technology to provide run time protection and guarantee. In contrast with the SRTM, DRTM has the advantage that the launch of the measured environment can occur at any time without resorting to a platform reset.

By leveraging built-in silicon instructions or firmware enclaves, DRTM allows the system to freely boot into untrusted code initially, but shortly after launches the system into a trusted state by taking control of all CPUs and forcing untrusted, exploitable code down a specific and measured code path before launching into a trusted state. Then the control of the DRTM environment is transferred to the Hypervisor and OS. The boot chain of trust is setup finally, then hypervisor or OS kernel can be booted securely.

System Guard with Kernel DMA protection

PCIe devices are direct memory-addressing (DMA)-capable, which means they have direct access to read and write system memory, without having to involve the system processor in these operations. This DMA capability makes PCIe devices the highest performing devices, however, having PCI hot-plug devices (such as NVMe hot-swap drives) externally and easily accessible also means unattended device could have a malicious PCIe device plugged into it, which could read the system memory or load malicious code into it, with no protection.

This kind of “drive-by DMA attacks” using PCIe hot plug devices can lead to the disclosure of sensitive information residing on a system, or even the injection of malware that allows attackers to bypass the lock screen or control the system remotely. Kernel DMA Protection is the feature designed to protect the system against this type of attack.

Windows makes use of the system Input/Output Memory Management Unit (IOMMU) to block external peripherals from starting and performing DMA unless the drivers for these peripherals support memory isolation, such as DMA-remapping. DMA remapping restricts the device to a certain pre-assigned memory region, which confirms the device is allocated a clear space of memory to perform its functions and doesn’t have access to any other information stored in system memory. Devices whose drivers are incompatible with DMA remapping are prevented from direct memory access by default until an authorized user is logged onto the system.

Kernel DMA Protection requires the support from the processor, new UEFI firmware, and drivers. With this feature, the OS and the system firmware protect the system against malicious and unintended DMA attacks for all DMA-capable devices. Currently this feature is only available on ThinkSystem servers with 3rd Gen Intel Xeon Scalable processors although ThinkSystem servers with AMD EPYC 7003 Series processors are also planned to support the feature. Kernel DMA Protection only protects against drive-by DMA attacks after the OS is loaded.

Virtualization-based Security (VBS) support

Secured-core servers support virtualization-based security (VBS) features and Hypervisor-protected code integrity (HVCI) so as to leverage virtualization capabilities from hardware and the hypervisor to provide additional protection for critical subsystems and data.

VBS uses hardware virtualization features to create and isolate a secure region of memory from the normal operating system. VBS runs this separate secure kernel at a higher trust level than the actual Windows system kernel. Then the OS kernel and user-mode processes cannot access the protected functions and data directly, thus protecting them from malware infection. VBS also allows for the use of Credential Guard to provide preventative defense for sensitive assets like credentials.

Hypervisor-based code integrity (HVCI) uses VBS to check the integrity of kernel mode drivers and binaries before they are started and prevents unsigned drivers or system files from being loaded into system memory. Enabled with HVCI, a Secured-core server only starts executables signed by known and approved authorities. This ensures that code running within the trusted computing base runs with integrity and is not subject to exploits or attacks.