DRTM Explained: Intel TXT, AMD SKINIT and Secure Launch

A dynamic root of trust for measurement (DRTM) is a CPU instruction that starts a fresh, measured chain of trust after the firmware has already booted the machine. Intel TXT does it with GETSEC[SENTER], AMD with SKINIT, and Windows System Guard Secure Launch and Linux tboot or TrenchBoot use them. You check it in PCR 17 and msinfo32.

The idea is simple to state and fiddly to get right. A normal measured boot, the static root of trust for measurement (SRTM), records every piece of code from the reset vector onward into the TPM, so anyone verifying the machine has to trust, or at least recognise, every firmware module, option ROM and bootloader that ran. A dynamic launch lets all of that run, then stops the processors, isolates memory, and measures a small, known piece of launch code into a separate set of TPM registers that only the hardware can reset. The verifier then cares mostly about that short chain.

This post goes one level deeper than our TPM 2.0 PCR guide and our Boot Guard and Platform Secure Boot explainer.

Key takeaways

• SRTM measures from reset; DRTM measures from a later CPU event, giving "a new instance of a root of trust for measurement without rebooting the platform" in the TCG's words.
• The launch resets PCRs 17 to 22 through TPM locality 4, which only the processor and chipset reach, so pre-launch software cannot forge those values.
• Intel TXT uses GETSEC[SENTER], an Intel signed SINIT ACM, an optional Launch Control Policy and a Measured Launch Environment. Details go to PCR 17, signing authorities to PCR 18.
• AMD SKINIT DMA protects a 64 KB Secure Loader Block, hashes the Secure Loader into the TPM and jumps to it with SMI held pending.
• Windows System Guard Secure Launch (Windows 10 version 1809 onward) ties the hypervisor and VBS secrets to a short measured launch path.
• Linux supports TXT through tboot. TrenchBoot Secure Launch adds Intel and AMD dynamic launch but is not in mainline as of Linux 7.3.
• DRTM does not remove firmware from the picture. SMM still runs after the launch, and a measurement changes nothing until something seals to it or attests it.

What is a dynamic root of trust for measurement (DRTM)?

A root of trust for measurement is the first piece of code that measures something and records the result in a TPM. Everything later is trusted only because something earlier measured it. The question DRTM answers is where that first piece of code sits.

SRTM: trust from the reset vector

In a static root of trust, the first measurement happens at platform reset. The Linux kernel's Intel TXT documentation describes the burden well: to trust a kernel without TXT, a static root of trust "bases trust in BIOS starting at system reset" and requires measuring all code between reset and the end of kernel boot, plus the data that code uses. For a typical Linux machine that means all of the firmware, every option ROM, the bootloader and its configuration. The kernel documentation points out that much of this changes from boot to boot, and that changing a network card can change the option ROMs that get measured.

Microsoft's System Guard documentation makes the same point from the verifier's side. With thousands of PC makers shipping many models and firmware versions, there is "an incredibly large number of SRTM measurements upon bootup." A verifier can keep a list of known bad values, which an attacker beats by flipping a single bit, or a list of known good values, which needs every new firmware and model combination added by hand.

The static chain is still valuable; it is what PCRs 0 to 7 record and what disk encryption sealing relies on. The problem is scale and churn, not concept.

DRTM: trust from a later, hardware enforced event

A dynamic root of trust starts measuring from a special CPU instruction executed after the firmware has run. The TCG D-RTM Architecture defines D-RTM as "a platform-dependent function that initializes the state of the platform and provides a new instance of a root of trust for measurement without rebooting the platform," and says the initial state "establishes a minimal Trusted Computing Base."

In Microsoft's words, DRTM "lets the system freely boot into untrusted code initially," then forces all CPUs down a known, measured code path. The firmware still brings up the hardware; it just is not where the verifier's chain starts.

Three hardware properties make this work:

1. A special instruction that cannot be emulated. AMD's manual says SKINIT sends the Secure Loader image to the TPM "using unique bus transactions that preclude SKINIT operation from being emulated by software." Intel's GETSEC[SENTER] similarly drives the TPM's hash sequence from hardware.
2. A TPM locality that software cannot reach. The TCG specification requires that the launch event "MUST cause a Locality 4 access to the TPM that resets PCR 17-22 inclusive to zero." Software that ran before the launch cannot reset those registers, so it cannot fake a clean starting value.
3. Isolation during the launch. Interrupts are held off, other processors are parked, and DMA protection covers the launch code so a device cannot rewrite it mid flight.

Why was DRTM invented?

Two problems pushed the industry toward a dynamic launch, and both are still current.

The trusted computing base was too large. Every byte of code that runs before the OS and is part of the chain is code the OS has to trust. Platform firmware is large, written by several parties, configured per model and updated on its own schedule. The kernel documentation lists what DRTM adds beyond a smaller chain: "many pre-launch components can be removed from the trust chain, DMA protection is provided to all launched components, a large number of platform configuration checks are performed and values locked," and data is protected after an improper shutdown.

Firmware was distrusted, and still is. NIST's draft SP 800-155 on BIOS integrity measurement, published in December 2011, describes firmware as a "critical security component" because of its "unique and privileged position" and warns that malicious or outdated firmware can cause either a permanent denial of service or a persistent malware presence. NIST SP 800-193, published in May 2018, extends that to platform firmware resiliency: protect firmware from unauthorised change, detect change that happens anyway, and recover. A dynamic launch fits the "detect" leg by reporting what actually took control after the firmware finished.

Microsoft adds an operational reason: if the measured launch path does not depend on the firmware build, a firmware update does not invalidate every attestation rule, and launch code updates can be deployed "more widely and quickly."

What the TCG D-RTM Architecture specifies

The TCG D-RTM Architecture, Document Version 1.0.0, was published on June 17, 2013, alongside a D-RTM overview document. The TCG's resource page describes it as covering "architecture and implementation examples" for a D-RTM "used for measured platform initialization without a hardware platform restart," and notes that it extends the TCG PC Client specification. It is vendor neutral, so its vocabulary is the most useful way to compare implementations:

The specification also fixes how the PCRs are used. The DL Event resets PCRs 17 to 22 to zero through locality 4. The CPU's initial measurement "SHALL be extended in PCR 17." One of PCR 17 and PCR 18 carries "details" (hashes of the actual code) and the other carries "authorities" (the identities of who signed it), and a flag records which is which. PCR 19 is reserved for data the DLME may access, and PCRs 20 to 22 "are reserved for use by the DLME." The DLME receives control with access to locality 2, which lets it extend PCRs 17 to 22 and reset PCRs 20 to 22.

The details and authorities split is the most practical idea in the design: the authorities value survives a signed update, while the details value changes with every one.

A short, dated timeline

How does Intel TXT work?

Intel Trusted Execution Technology adds the Safer Mode Extensions (SMX) to the processor and matching logic to the chipset. The kernel documentation summarises TXT as providing a "dynamic root of trust for measurement (DRTM)," "data protection in case of improper shutdown," and "measurement and verification of launched environment." Four parts do the work.

1. GETSEC[SENTER], the launch instruction

The pre-launch code (tboot, or a bootloader that implements the launch) prepares memory, loads the launch module and the kernel or hypervisor, then executes GETSEC[SENTER] on the initiating processor. TrenchBoot's late launch overview, citing the Intel Software Developer's Manual, lists what the CPU does next:

1. Stop responding to INIT, A20M, NMI and SMI.
2. Check the authenticated code module's location and size, the TXT capable chipset and the power management configuration.
3. Protect memory and I/O from other processor agents, then load the module into an isolated execution area.
4. Authenticate the module's signature and send its hash to the TPM.
5. Unlock the TXT private register space and TPM locality 3, and start executing the module.

SMIs are held off during the launch, so firmware cannot interrupt it, and the other processors are parked in a special sleep state.

2. The SINIT ACM

The Authenticated Code Module is a small binary signed by Intel and specific to a chipset family. The kernel documentation says it is signed "because it operates at a higher privilege level in the system than any other macrocode and its correct operation is critical to the establishment of the DRTM." TrenchBoot's overview adds that this privileged mode can inspect SMRAM, which is how TXT can measure an SMI Transfer Monitor (STM) when a platform uses one.

The ACM checks the platform configuration, DMA protects the MLE using the IOMMU, measures the MLE, and enforces the Launch Control Policy. Microsoft's System Guard requirements state that, for Intel platforms, the SINIT ACM "must be carried in the OEM BIOS" and that platforms must ship "a production ACM signed by the correct production Intel ACM signer." Intel's SDG warns that using a pre-production ACM results in "PCRs 17 and 18 being capped with (pseudo) random values," which is a deliberate way to make test launches unusable for production attestation.

3. Launch Control Policy

Launch Control Policy (LCP) is how a platform owner says which launched environments and which platform configurations may complete GETSEC[SENTER]. The SDG lists its goals: let the platform owner control which measured environments can launch, which platform configurations as measured by the static root of trust may launch, and which STM may run in SMRAM, all in a way untrusted software cannot undermine.

Policy lives in TPM NV indices. The platform supplier (PS) index is set by the platform maker, and the platform owner (PO) index lets the owner tighten it. The SDG is explicit about the default: "If no policy is present on the platform then the platform shall continue the Intel TXT launch process allowing any configuration and MLE to be launched." TrenchBoot calls LCP "a rarely used mechanism," and that matches what most fleets look like. Without a policy, TXT still measures everything, so attestation works, but it does not refuse a launch. The SDG also notes that LCP helps sealing: an MLE can seal secrets to a representation of the policy rather than to every allowed firmware configuration, so a firmware change does not force a secret migration.

4. The Measured Launch Environment

The MLE is the code that receives control from the ACM. TrenchBoot describes its job as extending trust to "the target runtime" by protecting its memory, measuring it, and optionally enforcing policy. In the Linux world tboot is an MLE; in Windows the TCB Launch component plays that role.

What goes into PCR 17 and PCR 18 on Intel TXT

The SDG says legacy PCR usage, where SINIT and policy went to PCR 17 and the MLE to PCR 18, "is no longer supported." Current TXT uses the Details and Authorities model. PCR 17 is initialised by the hardware hash sequence: PCRs 17 to 23 are reset to 0, then the digest of the SINIT ACM concatenated with the 4 byte SENTER parameters is sent to the TPM. Newer processors compute the SINIT digest with SHA-256.

Because the SDG says its tables "do not reflect the order of extends," a verifier has to replay the TXT event log to recompute PCR 17 and 18, not assume a fixed sequence.

TPM localities on TXT platforms

The SDG lists five TPM localities: locality 0 for "non-trusted and legacy TPM operation," locality 1 for "the trusted operating system," locality 2 for "MLE access," locality 3 for the "Authenticated Code Module," and locality 4 for "Intel TXT hardware use only." Higher localities are only reachable through SMX instructions or after SMX unlocks them. That ladder is why a compromised OS cannot reset PCR 17 to a clean value.

How does AMD SKINIT work?

AMD's design is smaller. TrenchBoot describes it as "a simpler one that allows more control over code executed by the SKINIT instruction." There is no vendor signed launch module equivalent to SINIT. The launch code, called the Secure Loader (SL), is supplied by the platform owner or OS and is measured, not signature checked by the CPU.

The Secure Loader Block

AMD's Architecture Programmer's Manual Volume 2, section 15.27, defines the pieces:

• The Secure Loader Block (SLB) is "a 64Kbyte range of physical memory" at any 64 KB aligned address below 4 GB.
• The SL image starts at offset 0 of the SLB. Its first 16 bit word is the entry point offset, and its second is the image length, with a maximum of 65535 bytes.
• The SL "must be written to execute initially in flat 32-bit protected mode with paging disabled."
• Space between the end of the SL image and the end of the SLB can be used as secure scratch space, for example as the initial stack.

What SKINIT does

SKINIT takes the physical address of the SLB in EAX as its only operand. The AMD manual and TrenchBoot's summary describe the sequence:

1. Reinitialise processor state as for an INIT signal and enter flat 32 bit protected mode with paging disabled. EAX holds the SL base and EDX the processor family, model and stepping.
2. Form the SLB base from EAX and enable device exclusion (DEV) protection for that 64 KB region, so no device can DMA into it.
3. Initialise application processors securely.
4. Transmit the SL image to the TPM in a way that "cannot be emulated" by software; it is hashed into PCR 17.
5. Clear the Global Interrupt Flag, holding off "all interrupts, including NMI, SMI and INIT."
6. Point the stack at the top of the SLB and jump to the SL entry point.

The SL then protects the memory it needs, measures the Security Kernel (SK) it hands off to, and, per AMD's manual, sets GIF back to 1 and restores the earlier context if it "cannot properly initialize a valid SK." TrenchBoot's AMD Secure Kernel Loader is one such SL. Its blueprint says it extends PCR 18 with the hash of the Secure Launch Resource Table (SLRT) passed by the bootloader, before measuring and starting the kernel.

The SMM gap on SKINIT

The important difference from TXT is privilege. TrenchBoot notes that SKINIT code runs with "the same accesses as superprivileged mode," so "it is not possible to obtain a measurement of SMRAM at the time of the late launch," and concludes that "the trust boundary of SKINIT still bound to the SRTM." In plain terms, a classic SKINIT launch measures the launch code well, but whatever firmware left in SMM is still there and still privileged. That is the gap newer platform features try to close.

What is AMD Secure Launch on newer platforms?

On recent AMD platforms used with Windows, Microsoft's 2020 Secure Launch post describes an SMM supervisor at CPL0 that runs SMI handler logic at CPL3, guards I/O ports and MSRs, locks CR3, and is "measured into PCR[17] during SKINIT launch." On AMD, "the SKINIT package must be integrated in the Windows system image."

Microsoft's System Guard requirements page lists what an AMD platform needs. Processors from Zen 2 onward are supported. The firmware must ship with the "AMD DRTM driver devnode exposed and the AMD DRTM driver installed," AMD Secure Processor firmware anti rollback protection must be enabled, and AMD Memory Guard must be enabled. The TPM can be a discrete TPM 2.0 or a Microsoft Pluton TPM.

We could not confirm these details on an AMD hosted page, so treat them as Microsoft's account of the platform requirements and check your platform maker's documentation.

Intel TXT and AMD SKINIT side by side

How does Windows System Guard Secure Launch use DRTM?

System Guard is Microsoft's name for the set of Windows features that protect boot integrity and report it. Microsoft says it aims to "protect and maintain the integrity of the system as it starts up" and to "validate that system integrity has truly been maintained through local and remote attestation." Secure Launch is the DRTM part, "first introduced in Windows 10 version 1809."

What it protects

Virtualization based security (VBS) puts sensitive Windows components behind the hypervisor. Microsoft lists "the Windows authentication stack, single sign-on tokens, the Windows Hello biometric stack, and the Virtual Trusted Platform Module" as resources that depend on trustworthy firmware and hardware. Secure Launch protects the hypervisor's own launch, so those VBS secrets are released only if the launch path is the expected one.

How the launch is split

Microsoft's 2020 post describes two phases. The first runs with UEFI boot services, which Secure Launch treats as untrusted. The second runs "without firmware services after the DRTM event" and is called the TCB launch phase. A component called TCB Launch is "measured into the DRTM TPM registers," validates signatures and code integrity of everything it loads, builds the data structures the OS needs, and then hands control of the DRTM environment to the hypervisor, which takes over DMA protection and memory clearing. If unexpected code runs in the DRTM path, it is logged in those registers, and "VBS secrets protected by the hypervisor are not released."

SMM protection on top of Secure Launch

Microsoft states the limit plainly: "Even if System Guard Secure Launch is used to late launch, SMM code can potentially access hypervisor memory and change the hypervisor." Its answer is paging protection plus a hardware supervised SMI handler, and SMM protection "is built on top of the Secure Launch technology." During the DRTM event, SMIs are suspended; TCB Launch then checks the SMM isolation policy the platform reports and, if the policy would let SMM reach OS memory, "may destroy DRTM state and clear OS secrets."

On Intel vPro platforms, Microsoft says the relevant components and the SMM access policy "are bound to PCR[17] during DRTM launch." On AMD, the SMM supervisor is measured into PCR[17] during SKINIT. Microsoft also lists a third platform family: on Qualcomm, the platform "implements DRTM TrustZone application and supports SMC memory protections." Our SMM explainer covers why SMM is such a sensitive place.

Requirements Microsoft lists

Microsoft states that Secure Launch "doesn't support earlier TPM versions, such as TPM 1.2." System Guard is supported on Windows Pro, Enterprise, Pro Education/SE and Education editions. On Secured-core PCs, Microsoft says Secure Launch with SMM protections is "enabled by default."

How it is turned on

Microsoft documents four switches: the DeviceGuard/ConfigureSystemGuardLaunch Policy CSP setting, Group Policy ("Secure Launch Configuration" under Device Guard), Firmware protection under Core isolation in Windows Security, and a registry value. Each works only on a platform that meets the requirements above.

What it reports

After boot, Microsoft says System Guard "signs and seals these measurements using the TPM," and a management system can collect them for remote analysis and deny access to a device that lacks integrity. That is the attestation half that turns a measurement into a decision.

What does Linux support?

Linux has two generations of dynamic launch support: tboot for Intel TXT, which has been in the kernel for a long time, and the TrenchBoot Secure Launch work, which is still being upstreamed.

tboot: Trusted Boot for Intel TXT

The kernel documentation describes Trusted Boot (tboot) as "an open source, pre-kernel/VMM module that uses Intel TXT to perform a measured and verified launch of an OS kernel/VMM." The bootloader loads tboot as if it were the kernel, with the real kernel, initrd and the SINIT ACM as modules. tboot then:

1. Checks whether the platform supports TXT and is configured correctly. If not, for example "the SINIT AC Module was incorrect," it "will directly launch the kernel with no changes to any state."
2. Executes GETSEC[SENTER] to start the dynamic launch.
3. When SENTER returns, verifies the environment, for example that TPM NV is locked and the memory map has no invalid entries.
4. Wakes the other processors through a small VT-x guest, because processors in the TXT environment do not respond to INIT or SIPI.
5. Applies an optional launch policy, rooted in TPM NV, to verify the kernel and initrd. The kernel documentation stresses that "if not present then any kernel will be launched," and that a policy can either halt on failure or log and continue.
6. Protects all of RAM from DMA using VT-d protected memory ranges, which is why the kernel should boot with intel_iommu=on to replace that blanket protection with page level protection.
7. Passes a shared page to the kernel and steps aside until sleep or shutdown. On S3 resume it re-establishes the measured environment and checks a TPM sealed MAC over kernel memory.

In firmware setup, the kernel documentation says TPM, TXT, VT-x and VT-d must all be enabled. Note the fail open behaviour in step 1: a misconfigured TXT machine boots normally. That is convenient and also a reason to check PCR 17 rather than assume a launch happened.

TrenchBoot and Linux Secure Launch

TrenchBoot describes itself as "a framework that allows individuals and projects to build security engines to perform launch integrity actions for their systems." It publishes a Secure Launch specification, which "describes a common approach for implementing Dynamic Launch" so "any conforming bootloader" can start "a Dynamic Launch of any conforming OS kernel." Its blueprints cover GRUB late launch for TXT and for AMD, the AMD Secure Kernel Loader, a coreboot DRTM payload, Xen late launch, and exploratory work on DRTM for Arm and Qualcomm platforms.

Its Linux blueprint makes the kernel itself "the late launch kernel for both AMD (Secure Loader) and Intel TXT (Measured Launch Environment)." Patch series have been posted to the kernel mailing lists in several revisions.

As of this writing, the mainline tree at Linux 7.3 still contains arch/x86/kernel/tboot.c and the Intel TXT documentation, and does not contain the Secure Launch documentation or code. So the practical status for most readers is: tboot is the in tree path for Intel TXT, and TrenchBoot Secure Launch is available from the TrenchBoot project's kernel and GRUB trees and some distribution builds, not from a stock mainline kernel.

Comparison: four ways to establish boot trust

Step by step: check whether a machine supports and uses DRTM

These checks only read state. They do not change firmware settings, TPM contents or boot configuration.

On Windows

Step 1. Look at System Information. Run msinfo32 and look at the System Summary. Microsoft's verification step is to read the "Virtualization-based Security Services Running" and "Virtualization-based Security Services Configured" lines. If Secure Launch is running, it appears in the Running line.

Step 2. Query the same data from PowerShell. In an elevated PowerShell session:

Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard |
  Select-Object VirtualizationBasedSecurityStatus, SecurityServicesConfigured, SecurityServicesRunning

Step 3. Read the result. Microsoft's documentation defines the values in SecurityServicesConfigured and SecurityServicesRunning:

If 3 is in SecurityServicesConfigured but not in SecurityServicesRunning, Secure Launch is requested but did not start. The usual reasons are the platform requirements above: wrong TPM type, TXT disabled in firmware, missing SINIT ACM or AMD DRTM driver, or DMA protection not met.

On Linux

Step 1. Check the processor. The kernel exposes CPU feature flags. smx means the processor has Safer Mode Extensions (Intel TXT); skinit means it has the AMD SKINIT instruction.

grep -o -w -E 'smx|skinit' /proc/cpuinfo | sort -u

A flag only says the CPU can do it. The chipset, firmware and TPM also have to support it, and TXT must be enabled in firmware setup.

Step 2. Check for a TPM 2.0.

ls /dev/tpm0 /dev/tpmrm0
cat /sys/class/tpm/tpm0/tpm_version_major

Step 3. Read the dynamic PCRs. With the tpm2-tools package installed:

sudo tpm2_pcrread sha256:17,18,19

Step 4. Read the result. If PCR 17 is all zeros or all f digits, nothing extended it in this boot, so no dynamic launch happened. A launch resets PCRs 17 to 22 to zero and then extends them, so any other value means something did extend them. That alone does not prove the right code launched; compare against a known good value from a machine you trust, or replay the launch event log.

Step 5. If you use tboot, check its log. The kernel prints a line prefixed tboot: when it finds the tboot shared page, and exposes the tboot log through debugfs:

sudo dmesg | grep -i 'tboot'
sudo cat /sys/kernel/debug/x86/tboot_log | tail -n 50

Step 6. Do not expect the dynamic launch in the firmware event log. The UEFI log at /sys/kernel/security/tpm0/binary_bios_measurements records the static chain. The D-RTM log is separate (located through the DRT ACPI table, or the TXT heap on Intel), so read it with the launch software's or attestation agent's tooling.

sudo tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements | grep -E 'PCRIndex: (0|7)$' | sort | uniq -c

What the results usually mean

How DRTM fits with NIST guidance and attestation

Neither NIST SP 800-155 nor SP 800-193 requires a dynamic launch. They describe outcomes. The SP 800-155 draft is about a BIOS integrity measurement and reporting chain that lets organisations "detect problems with the BIOS" and act. SP 800-193 groups platform firmware resiliency into protection, detection and recovery, and tells administrators they "can use this document to guide procurement strategies."

DRTM serves the detection leg. It does not make firmware trustworthy or repair a corrupted flash chip. It narrows what has to be trusted when the OS or hypervisor starts and produces a compact, hardware anchored report of what took control. Protection and recovery still need firmware signing, write protection (see our SPI flash write protection guide) and a tested recovery path. Firmware changes still show up in PCR 0 and 2; the dynamic registers stay stable across them, and the authorities in PCR 18 stay constant across signed updates.

Common mistakes

Assuming DRTM removes firmware from the trust chain entirely. It removes pre-launch firmware from the launch measurement. It does not stop SMM from running afterwards. Microsoft says outright that SMM code "can potentially access hypervisor memory" even after a late launch, which is why SMM protection exists and why TrenchBoot describes SKINIT's trust boundary as "still bound to the SRTM." Keep firmware updated and check SMM protection status.

Not provisioning a Launch Control Policy and assuming TXT blocks bad launches. Without an owner policy, the SDG says TXT allows "any configuration and MLE to be launched." tboot behaves the same way without a launch policy. Measurement still works, but only if something checks the values.

Measuring without consuming the measurement. A PCR value that no one seals to and no one attests is a log entry. Seal secrets to the launch, run remote attestation, or both, and replay the event log rather than hard coding PCR 17: an ACM update changes it, and a pre-production ACM caps PCRs 17 and 18 with random values.

Confusing DRTM with Secure Boot. UEFI Secure Boot verifies signatures on boot components before they run. DRTM measures a launch after the firmware has run. They complement each other; one is not a replacement for the other. Our Boot Guard post covers the verified boot side.

Treating a CPU flag as proof of support. The smx or skinit flag says the instruction exists. The chipset, firmware, TPM type and IOMMU configuration decide whether a launch can actually succeed.

Forgetting DMA. A dynamic launch DMA protects the launch code, but the OS then has to keep IOMMU protection on. On Linux with tboot, that means booting with intel_iommu=on. On Windows, Kernel DMA Protection is a prerequisite.

FAQ

What does DRTM stand for?

Dynamic Root of Trust for Measurement. It is a hardware supported way to start a new, measured chain of trust while the machine is running, instead of only at power on.

What is the difference between SRTM and DRTM?

SRTM starts measuring at platform reset and records all firmware, option ROMs and bootloaders in PCRs 0 to 7. DRTM starts measuring at a special CPU instruction later in boot, resets PCRs 17 to 22 through TPM locality 4, and records a much shorter launch path.

What is PCR 17 used for?

PCR 17 holds the first measurement of a dynamic launch. On Intel TXT it is the "details" register with the SINIT ACM, MLE and policy measurements. On AMD SKINIT it holds the hash of the Secure Loader. If it is still at its untouched value, no dynamic launch happened this boot.

Is Intel TXT the same as Intel Boot Guard?

No. Boot Guard verifies or measures the initial firmware at reset, which is part of the static chain. TXT performs a dynamic launch later. They can interact: the SDG lists Boot Guard manifest digests among the values extended into PCRs 17 and 18.

Does AMD have an equivalent of Intel TXT?

Yes. AMD's SKINIT instruction provides a dynamic launch of an owner supplied Secure Loader. On recent platforms used with Windows, Microsoft describes an AMD DRTM driver, Memory Guard and a measured SMM supervisor as part of what it calls AMD Secure Launch platforms.

How do I know if System Guard Secure Launch is running?

Open msinfo32 and read "Virtualization-based Security Services Running," or query Win32_DeviceGuard in PowerShell and look for value 3 in SecurityServicesRunning.

Is TrenchBoot Secure Launch in the mainline Linux kernel?

Not as of Linux 7.3. The mainline kernel carries tboot support for Intel TXT. TrenchBoot's Secure Launch code is available from the project and has been posted for upstream review in several revisions.

Does DRTM protect against SMM attacks?

Not by itself. SMM can still run after the launch. Windows pairs Secure Launch with SMM protection and measures the SMM policy or supervisor into PCR 17, and Intel TXT can measure an SMI Transfer Monitor when one is present.

Where Safeguard fits

Safeguard does not analyse firmware, check TPM state or verify PCR values, and it is not an attestation service. Its fit is indirect. The software around a dynamic launch is ordinary software with dependencies: tboot, GRUB and Linux builds, TPM tooling such as tpm2-tools, and the attestation verifiers, agents and dashboards teams build to consume PCR 17 and 18. Those live in repositories and container images, and Safeguard can generate a software bill of materials for them, match components against vulnerability databases, show which projects carry a given component version, and open fix pull requests when a fixed version exists.

A measured launch tells you which kernel and launch code took control, but the attestation services, provisioning scripts and management tools that read those measurements are built from open source packages and container images. Keeping that layer patched is the part of boot integrity work a software team controls directly.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session: the assistant reads a lodash finding, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, and pushes nothing. The same flow applies when your attestation dashboard carries an outdated library.

Click through it at your own pace, or open it full screen.

The second demo sets up the local runner on your own machine, approves it with a device code and scans from the terminal. It suits a team that maintains its own tboot, GRUB or kernel packaging repository and wants a component inventory without sending source code anywhere.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. Once connected, you can ask which of your projects carry a given version of a TPM library or attestation dependency.

Click through it at your own pace, or open it full screen.

To try it on your own projects, download Safeguard and follow the CLI documentation.

Quick check

Sources

• TCG: D-RTM Architecture specification page (archived copy)
• TCG D-RTM Architecture, Document Version 1.0.0, June 17, 2013 (PDF, archived copy)
• Intel TXT Software Development Guide, Measured Launch Environment Developer's Guide, revision 017.4 (PDF, TrenchBoot mirror)
• AMD64 Architecture Programmer's Manual Volume 2, section 15.27, revision 3.29 (PDF, TrenchBoot mirror)
• Linux kernel documentation: Intel TXT Overview
• Linux kernel source: arch/x86/kernel/tboot.c
• Microsoft Learn: System Guard, how a hardware-based root of trust helps protect Windows
• Microsoft Learn: System Guard Secure Launch and SMM protection
• Microsoft Learn: Enable memory integrity, Win32_DeviceGuard values
• Microsoft Security Blog: Force firmware code to be measured and attested by Secure Launch on Windows 10 (September 1, 2020)
• TrenchBoot project home
• TrenchBoot: Introduction to Late Launch
• TrenchBoot: Secure Launch Specification
• TrenchBoot: AMD Secure Kernel Loader blueprint
• TrenchBoot: Linux Late Launch blueprint
• NIST SP 800-155 (initial public draft), BIOS Integrity Measurement Guidelines
• NIST SP 800-193, Platform Firmware Resiliency Guidelines

Last reviewed: 25 October 2026. Platform requirements, launch modules and kernel support change with new hardware and releases; check the linked specifications and vendor documentation for your exact platform before relying on them.