Trusted computing Group
the Backgrounder: .PDF
This is fairly comprehensible and matches Palladium info. The end of page 6 seems to refer to secure booting of an OS. I don’t know what the grand plan is but that would seem to rely on running only a small set of privileged code. This in turn means discarding almost all drivers. That is not the Palladium plan, I think.

On the other hand if you map terminology thus:
TCGNGSCB
OSNexus
Then the two are in sync.

Design Principles: .PDF
I don’t get it. They have fuzzy top level goals and very specific hardware details. I see a huge gap. I don’t see how the details support the goals. I don’t see that the details support our style security or that described for Palladium.

The plan that I think I hear from Palladium is that untrusted code will put trusted code in RAM at a pre-agreed place and invoke the SSC which will hash the code; see that it is good; and give it control in a new CPU mode. Before the SSC starts to hash the code it disables DMA access to the code and halts the CPU. It would seem that the code, called “nexus”, must build the real page tables for that is the only control of access to RAM. The OS must thereby run mapped and be excluded from nexus space by these nexus controlled maps. It would seem that the control registers that define the locations of both the map and interrupt vectors must be denied in privileged mode in order to keep the OS, or viruses that have infected the OS from taking ultimate control of the machine including nexus.

The nexux must take its own traps for they are about code whose state is critical. It is possible to write code that doesn’t trap but a poor software design plan I think. I would hate to give up page faults, except, perhaps, in very early versions. Interrupts during the new cpu mode would have to go to the nexus for the stack frame produced likewise involves critical state. Interrupts are presumably the business of the OS which to which the nexus can politely transfer control. Traps and interrupts to the nexus should be accompanied with a map switch for reasons described here. Alternatives probably require new page table entry bits.

Perhaps registers that locate maps and interrupt vectors can merely be ignored leaving most of the OS alone. Otherwise they most be protected from the privileged code. The real maps can be built by the nexus much as VM/370 builds real maps. In this case the PTLB command in privileged mode must be trapped.

Misc notes.
“TPM-shielded” is used but not defined.
They say “The protected capabilities MUST require TPM Owner authentication or operator physical presence”. This is possible for a program to ensure but presumably not a $5 device with no user interface. I thought this was a hardware requirements list. Of course they may mean the owner must have changed a dip switch to enable the state change, but the owner won’t know from the dip switch the nature of the enabled change.
I see from this Power Point document the concept that booting must take you thru a sequence of steps each with a definite hash. I don’t see the advantage of checking any hash but the last. I think they presume that the checked state is all in RAM and perhaps selected CPU registers. I find “The CRTM builds a chain of hash codes for each portion of the boot. This chain is used to ascertain exactly what software was loaded on boot; the user can then check this with past boot chains and gauge if the boot sequence has been tampered with.” which fits with the chaining functions of the PCR. I cannot imagine any verification with multiple stages that is unavailable with just one stage.
Here is a fairly clear note by someone who thinks he understands the specs.
I presume that a “shielded-location” is state in the TPM that cannot be sensed from outside — like veiled.
I presume that the “caller” is the program that interacts with the TPM.
Part 3, downloads.