| |||||||||||||
Qubes beta 1 releasedQubes beta 1 releasedPosted Apr 15, 2011 12:49 UTC (Fri) by jarrett.miller (guest, #60765)In reply to: Qubes beta 1 released by cmccabe Parent article: Qubes beta 1 released
I am afraid you are just plan wrong on that last statement. Please go read the docs.
As long as you believe that Intel correctly implemented the hardware and correctly implemented the AC module (and here I define correct to mean it implements the semantics of the GETSEC[SENTER] instruction without error) then TXT does indeed allow you to know what is running on your computer reliably.
Heck even classical Trusted Computing lets you do that the problem with the old style of it was that you didn't have to just trust Intel to get the hardware and the AC module right you had to trust the BIOS and all the firmware were not doing anything shady (A bad assumption).
(Log in to post comments)
Qubes beta 1 released Posted Apr 16, 2011 21:29 UTC (Sat) by cmccabe (guest, #60281) [Link]
> As long as you believe that Intel correctly implemented the hardware and
> correctly implemented the AC module (and here I define correct to mean it > implements the semantics of the GETSEC[SENTER] instruction without error) > then TXT does indeed allow you to know what is running on your computer > reliably.
Even if I believe that-- and I already discussed some reasons why I shouldn't-- exploit in another layer of the stack will allow an attacker to run something different on my computer. And even if I magically was able to audit all of that software, it still wouldn't tell me anything about what software is running on, for example, my RAID card, or inside my computer mouse.
You can get closer and closer to certainty, but never reach it.
Qubes beta 1 released Posted Apr 20, 2011 18:29 UTC (Wed) by PaXTeam (subscriber, #24616) [Link]
> [...] then TXT does indeed allow you to know what is running on your computer reliably.
not exactly. it tells you what was running at the time SENTER executed, it says nothing about the future. in a post somewhere above you tried to dismiss the problem of exploitable bugs by saying this:
> Some OS partition will be where that wireless driver exists. So when
so this hypervisor wouldn't let guest kernels modify themselves (think of the alternatives mechanism in linux) or load kernel modules? can you name a single widespread (or heck, any) distro which would be able to run on this hypervisor? so you can't do this. but then runtime code generation must be allowed for the guest kernels and that means any kernel exploit is back in business, TXT/hypervisor/etc didn't improve anything, you still don't know what code runs on your box.
|
|||||||||||||