One interesting point that many individuals do not realize is that the TPM is not an active device. Let me explain. For this purpose an active device is one that gets to make a "decision" on the platform and interrupt what else is going on. A passive device only responds to requests.
The TPM design also only contemplates a passive device. The entire command set is designed to respond to requests. There are no commands that work on interrupts or initiate an action. Each TPM command is a response to a specific request from either the platform itself or the users of the platform.
The reason why this distinction is important is that with the TPM being a passive device, using the TPM requires software to request the TPM to perform an operation. The TPM has no mechanism to act independently on it's own.
Now you know why the TPM is a passive device.
PS sorry for not posting for a few days but life can get busy at times.
That's a good point, this was a big misconception in the initial public discussion of the TPM, a lot of people thought it would act as a sort of supervisor chip and take control of the computer.
As far as the LPC bus, it seems to me that eventually the TPM must evolve to be closer to the CPU in order to improve security. With the TXT feature there is a special region of on-chip CPU memory that holds the Authenticated Code module, where data is relatively immune to modification. This module then gets sent to the TPM for hashing. Well, that bus is pretty exposed. Special bus cycles are used but it would probably not be too hard to create a modchip that would mimic those cycles and alter the data as it goes to the TPM. Certainly we have seen modchips for XBoxes and other devices, so such technology is not particularly difficult to develop. And the LPC bus is not super fast or complex, it is in fact relatively simple.
It seems inevitable to me, given the evolution towards multi-core CPUs and diminishing returns from more cores of one type, that TPMs in the future will be on-chip CPU cores. Then there can be more data set aside for AC modules which get hashed into the on-chip TPM, and you will finally have something that's relatively secure even against someone willing to spend fifty bucks on a modchip. To me that would be the minimum security gain necessary to pay back the investment in architecture, design and implementation work which has and will continue to have gone into the TPM and TXT.
BTW speaking of AC modules, do you know if commercial vPro systems with TXT support ship with the SINIT AC module that is necessary to use, for example, the Trusted Boot code from http://sourceforge.net/projects/tboot/ ? Is this provided by BIOS in these machines, as described in the TXT Preliminary Architectural Specification (e.g. section 5.2.2)? The tBoot project seems to want to see it as a file on the disk, but I suppose that could be patched to get it from BIOS if it is not available as a disk file.