Qubes beta 1 released

That trusted software of yours might have holes in it. And when an attacker successfully tricks that software into running his code, it'll be just as trusted as anything else. Just witness all those game consoles out there, they have a lot more elaborate protection than TXT but every single one has been hacked to run unsigned ("homebrew") code.

The truth about the PC platform is that there are a lot of gaping holes in the security model at the hardware level. For example, the PCI bus allows PCI devices to do arbitrary DMA transfers to and from system memory. ACPI bytecode is loaded into the kernel and executed at ring level 0. If TXT allows Intel to work around some of these problems, then it will be a good thing.

However, you can never really completely get away from the need to trust your hardware vendor. That is what I was getting at with the first example, and I think you missed it. Once the data leaves the motherboard and flows to, for example, a separate ethernet card, that card can do whatever it wants. TXT may be able to protect my system memory, but it can't prevent the firmware in my ethernet card from doing something unexpected.

Countries buying military hardware are increasingly concerned about the possibility of "kill switches" being embedded in it. Trusting Intel, an American company, probably isn't something that they're that excited about. Intel, like every other company, has had exploitable bugs in their software in the past. I remember Joanna Rutkowska pointing out an exploitable flaw in an SMM. It would also be relatively easy for them to embed a backdoor into TXT or into the processor itself if they really wanted to.

Of course this whole discussion ignores the many exploitable flaws in the software stack. Until those are fixed, many organizations will quite reasonably regard spending money on implementing TXT as closing a mouse hole, while leaving the barn door open. Chinese hackers only needed to exploit a few vulnerabilities in Adobe (PDF) Reader to steal the secrets of dozens of Fortune 500 companies.

Long story short, TXT is an interesting technology, but it does not allow you to "reliably know what software is running on your machine." That is something that you probably can never do. You can only get closer and closer to certainty, but never reach it.

I think you need to elaborate on what you mean by "trust" here -- it's a notoriously polysemous word. Certainly if some program's correctness depends on its ability to send packets, then it has to trust the ethernet driver to actually do that. Of course, right now the ethernet driver can also go ahead and read any random piece of host memory that it wants to via DMA -- fixing that would certainly improve things.

> In a TXT style system there is going to be a hypervisor and it protects itself from all of the OS's that it is in control of via hardware protections (basically IOMMU with page protection lists).

Not a critical point, but this is exactly how the kernel works now.

> So when someone exploits that flaw and roots that OS partition then the hypervisor should be able to tell (new executable pages come in to existence or the contents of executable pages change).

We already have NX protection, which does essentially the same thing -- prevents buggy programs from creating new executable code. It helps, but it's by no means a guarantee. There are the clever tricks for accomplishing exploits without generating executable code (return-to-libc and all that), and if you can exploit an environment that contains a JIT or dynamic language runtime then you can perform arbitrary actions without triggering the protections.

So I don't really see how TXT makes that much of a difference.