Here is a detailed breakdown of how both mechanisms work under the hood:
Both Intel TXT and AMD SVM/SKINIT solve the same fundamental problem: how do you establish a clean, verifiable trust anchor after the system has already booted, without having to power cycle? A Dynamic Launch is achieved with a lightweight processor bootstrap initiated through a CPU instruction. An important function of x86 Late Launch CPU instructions is that they "measure" the execution code provided for the launch — accomplished by taking a cryptographic hash using an algorithm supported by the TPM so that it may store the measurement within one of the TPM's Platform Configuration Registers (PCR). This initial measurement, referred to as the Core Root of Trust Measurement (CRTM), is the trust anchor for the DRTM.
While they share the same goal, the two implementations are architecturally quite different.
Intel's approach is the more complex and holistic one, built around a special instruction set extension called Safer Mode Extensions (SMX).
From the moment when the SENTER instruction is invoked until execution control is handed to the MLE, a series of computations are completed by the CPU and then by the ACM to generate integrity assertions in the form of measurements about the platform environment as well as the MLE that will be given control.
The CPU itself executes a detailed sequence of steps upon SENTER:
- Inhibit processor response to external events: INIT, A20M, NMI, and SMI.
- Establish and check the location and size of the authenticated code module to be executed.
- Check for the existence of an Intel TXT-capable chipset.
- Verify the current power management configuration is acceptable.
- Broadcast a message to enable protection of memory and I/O from the activities of other processor agents.
- Load the designated AC module into the authenticated code execution area.
- Isolate the content of the authenticated code execution area from further state modification by external agents.
- Authenticate the AC module.
- Update the TPM with the authenticated code module's hash.
- Initialize processor state based on the authenticated code module header information.
- Unlock the Intel TXT-capable chipset private configuration register space and TPM locality 3 space.
- Begin execution in the authenticated code module at the defined entry point.
The ACM is a critical piece of Intel's design. An authenticated code module is a piece of code provided by the chipset manufacturer, signed by the manufacturer, and executes at one of the highest security levels within a special secure memory internal to the processor. The processor microcode loads the SINIT ACM into secure memory, internal to the processor, in order to protect it from any outside influence, and verifies that the ACM matches the chipset and that the hash of its public key matches the hash hardcoded into the chipset.
The ACM is entrusted with a series of responsibilities: IOMMU-protecting the MLE, measuring the MLE, and enforcement of the Launch Control Policy (LCP).
The LCP is an optional but powerful policy mechanism: the LCP allows for defining expected values for TPM PCRs and/or the expected hash value of the MLE. If a policy check fails, then the LCP Policy Engine will trigger the ACM to error exit from the SENTER instruction.
When doing a measured launch, the GETSEC(SENTER) instruction microcode performs special hardware-triggered _TPM_Hash_Start, _TPM_Hash_Data, and _TPM_Hash_End commands. These commands are triggered by writing to special TPM interface registers that can only be written from Locality 4 — chipset hardware restricts access to these Locality 4 registers to hardware or microcode. The special hash commands extend PCR17 with measured launch measurements during the microcode's execution of GETSEC(SENTER). After entering the SINIT ACM, this ACM extends other dynamic launch measurements into PCR17 and PCR18.
PCR17 is a dedicated register for holding the computed hash of the authenticated code module loaded and subsequently executed by GETSEC[SENTER]. As part of this process, the dynamic PCRs 18–22 are reset so that they can be utilized by subsequently launched software for registration of additional code and data modules.
For the OS/VMM to do a measured launch, it places its trusted post-launch code (referred to as the Measured Launch Environment, or MLE) in contiguous memory, fills in a table indicating where the code resides and where the platform owner's LCP data structure resides, and then invokes the GETSEC[SENTER] instruction.
As the ACM conducted a transitive trust extension to the MLE, the MLE should similarly conduct a transitive trust extension to bring the target runtime within the SMX trust boundary by protecting the runtime's memory from tampering, measuring it, and optionally enforcing policy to ensure only authorized runtimes are allowed to execute.
AMD's approach is notably simpler and more direct, giving the software developer more control, but with some trade-offs.
The AMD approach is a simpler one that allows more control over code executed by the SKINIT instruction, including environment setup and measurements, but unlike Intel's ACM, execution is limited to the same accesses as superprivileged mode. This means it is not possible to obtain a measurement of SMRAM at the time of the late launch.
When SKINIT is called, the base address of the Secure Loader (SL) is passed in the EAX register. The CPU then executes this sequence:
- Reinitialize the processor state similar to an INIT signal.
- Enter 32-bit protected mode with paging disabled.
- Clear all general-purpose registers except EAX (start address of SL) and EDX (CPU model/family/stepping).
- Secure registers: clear EFER MSR, set DPD, R_INIT, and DIS_A20M flags in the VM_CR register unconditionally to 1.
- Page-align EAX and use it as the start address for 64 KB of DEV (Device Exclusion Vector) protection.
- Securely initialize APs: clear the Global Interrupt Flag (GIF), set DPD, R_INIT, and DIS_A20M flags.
- Transmit the SL image to the TPM for hashing — any failure triggers a SKINIT failure.
- Clear the GIF on the BSP, disabling all interrupts including NMI, SMI, and INIT.
- Update ESP to point at the SL stack.
- Jump to the SL entry point.
The measurement is extended into PCR17, just as with Intel TXT: the SKINIT instruction writes the contents of the SLB to an address that is redirected into the TPM via _Hash_Init, _Hash_Start, and _Hash_End signals, measuring the contents of the SLB into PCR17.
A key security concern during this process is DMA attacks — a malicious peripheral could overwrite the SL in memory while it's being hashed. AMD handles this via the DEV (Device Exclusion Vector): SKINIT extends PCR17 with the hash, protects the SLB (Secure Launch Block, always 64 KB) against DMA access from devices, puts the CPU in a defined execution state, and jumps to the entry point specified in the header.
| Feature | Intel TXT | AMD SKINIT |
|---|---|---|
| Launch instruction | GETSEC[SENTER] |
SKINIT |
| Measured code | SINIT ACM (Intel-signed) + MLE | Secure Loader (developer-provided) |
| SMM visibility | ACM can inspect SMRAM | Cannot access SMRAM |
| Policy enforcement | Launch Control Policy (LCP) | None built-in (up to SL) |
| DMA protection | IOMMU configured by ACM | DEV (Device Exclusion Vector) |
| TPM PCR written | PCR17 (and PCR18 by ACM) | PCR17 |
| Complexity | Higher (Intel microcode + ACM) | Lower (more software control) |
In TrustVisor's context, the TPM stores measurements of TrustVisor when it is invoked via hardware DRTM, and TrustVisor in turn measures each PAL when it is registered. This design avoids Flicker's performance issues and monopolization of the platform's DRTM capabilities, since PAL integrity measurements are maintained in a software µTPM rather than requiring repeated hardware DRTM invocations.