Reasoning Behind DRTM

[Safayet_A_1]

What is the reasoning behind having a separate DRTM? Is there any security vulnerability associated with having just the static root of trust?

For example:

1) Hardware Microcode verifies BIOS ACM

2) BIOS ACM verifies BIOS

3) BIOS verifies its components

4) BIOS verifies the initial-program loader (IPL) and IPL configurations. In Linux, this would include GRUB and the GPT table or MBR.

You then have this gap where GRUB can load modules and run commands without anything getting measured.

5) Then GRUB loads tboot which issues the GETSEC SENETER instruction.

6) Again the hardware (u-code) kicks in to measure yet another ACM (SINIT ACM)

7) SINIT ACM measures tboot and enforces the Launch-Control Policy based on PCR values and tboot measurements

8) tboot measures the kernel/ RAM disk image and enforces the verified launch policy (VLP) based on its measurement

Question

Why do you need DRTM? Is it to offer greater flexibility or is there a security advantage? Isn't it possible to have a setup where immediately after static measurements, GRUB measures its modules, the kernel, and the init RAM disk image?

[Colleen_C_Intel]

DRTM improves the root of trust in several ways. A Static root of trust (SRT) requires 
measuring all the code executed from system boot/reset through kernel boot plus 
measuring any data objects used by that code - including the whole BIOS, option ROMS,
the bootloader, boot config, etc. Even without malicious intent, some of these items 
change between boots (like opROMs).

DRTM focuses later, starting after tboot launch and can dynamically change the chain 
to remove prelaunch components (doesn't have to include all of BIOS) while adding 
DMA protection of launched components, checking platform configs (and locking values), 
and even verify policy. And it can do this even from an improper shutdown. Then it 
stores the dynamic chain of trust measurement in PCR17.