From: Mike H. <mi...@pl...> - 2008-07-14 00:31:26
|
Hiya, I'm interested in playing with LaGrande/TXT. I've read the book, although it's sort of confusing and probably out of date now. It seems clear to me that from a users perspective, messing around with the low level GETSEC instructions is the wrong way to go - I need drivers. Tboot appears to be that project. >From reading the archives though it seems that the hardware still isn't quite solid yet. Comments like "you are lucky" to somebody who actually got it to (sort of) work aren't reassuring :) Does anybody know of a decently priced laptop that implements a known to work LaGrande setup? Including the protected graphics/keyboard channels? Also, does anybody have some example code of launching an app[let] into a protected domain? How far is there left to go, really? Thanks! -mike |
From: Hal F. <hal...@gm...> - 2008-07-14 22:11:40
|
Hi Mike - Boy, you'd think this would be easy to find out, wouldn't you? I just wasted (more optimistically, spent or even invested!) an hour trying to see what current chips, chipsets and systems support TXT. It certainly doesn't help that Intel chose such a widely used 3 letter acronym. It doesn't look to me like any laptops yet support TXT. This file: http://download.intel.com/products/roadmap/roadmap.pdf on page 5 indicates that the first mobile platform with TXT is the one Intel code-names Montevina, using processors code-named Penryn and a chipset code-named Cantiga, and that this should be coming out in Q2 08. Unfortunately, the mapping of these codenames to actual products seems to be a tightly held Intel secret - at least, I couldn't find it. However, Wikipedia has some useful information on the Montevina platform: http://en.wikipedia.org/wiki/Centrino#Montevina_platform_.282008.29 says, "The code-name Montevina refers to the fifth-generation Centrino platform, now formally named Centrino 2 to avoid confusion with previous Centrino platforms. It was scheduled for release at Computex Taipei 2008, which took place on June 3 - 7, 2008,[6] but has been delayed until July 14, due to problems with integrated graphics and wireless certification." July 14 happens to be today, so your question is in a way quite timely. And this tells us that what you want to look for would be Centrino 2. However it will probably be a while before systems are available with that architecture. And whether they will actually support TXT is unknown. When Trusted Execution was announced, 3 models of computers were identified as supporting it: The HP Compaq dc7800, Dell OptiPlex 755 PC, and the Lenovo ThinkCentre M57p. I don't know of any others that have been added to that list since then. As far as the use of Tboot, it seems to be primarily oriented around launching the Xen virtual machine monitor, making it a measured VMM or MVMM. Xen can then launch Linux or certain other OS's, perhaps even measuring them as well. Personally I prefer the direction of Jonathan McCune's "Flicker" project, http://sparrow.ece.cmu.edu/group/flicker.html - it similar to what you describe, launching from within a running OS self-contained applets (which I think he should call, flicklets) that run for a brief moment in a measured, protected mode, perform some sensitive calculation and then return to the conventional OS. I was working on a similar idea but he is quite a bit further along with it, and last I heard it was already working with AMD's skinit and almost there with Intel TXT. Hal Finney On Sun, Jul 13, 2008 at 2:27 PM, Mike Hearn <mi...@pl...> wrote: > Hiya, > > I'm interested in playing with LaGrande/TXT. I've read the book, although > it's sort of confusing and probably out of date now. It seems clear to me > that from a users perspective, messing around with the low level GETSEC > instructions is the wrong way to go - I need drivers. Tboot appears to be > that project. > > From reading the archives though it seems that the hardware still isn't > quite solid yet. Comments like "you are lucky" to somebody who actually got > it to (sort of) work aren't reassuring :) > > Does anybody know of a decently priced laptop that implements a known to > work LaGrande setup? Including the protected graphics/keyboard channels? > > Also, does anybody have some example code of launching an app[let] into a > protected domain? > > How far is there left to go, really? > > Thanks! > -mike > > ------------------------------------------------------------------------- > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > _______________________________________________ > tboot-devel mailing list > tbo...@li... > https://lists.sourceforge.net/lists/listinfo/tboot-devel > > |
From: Cihula, J. <jos...@in...> - 2008-07-14 23:32:53
|
I can't specifically recommend any systems, but I can add that the Intle(R) DQ35JO motherboard also supports TXT. And as Hal pointed out, the first mobile system will be available shortly (I can't comment on production dates, but the one in my office works with TXT just fine). Shortly we will be adding Linux support to tboot (i.e. to boot a Linux kernel) and posting the corresponding patches for Linux to LKML. Joe -----Original Message----- From: tbo...@li... [mailto:tbo...@li...] On Behalf Of Hal Finney Sent: Monday, July 14, 2008 3:12 PM To: Mike Hearn Cc: tbo...@li... Subject: Re: [tboot-devel] Buying a machine that will actually work with TXT Hi Mike - Boy, you'd think this would be easy to find out, wouldn't you? I just wasted (more optimistically, spent or even invested!) an hour trying to see what current chips, chipsets and systems support TXT. It certainly doesn't help that Intel chose such a widely used 3 letter acronym. It doesn't look to me like any laptops yet support TXT. This file: http://download.intel.com/products/roadmap/roadmap.pdf on page 5 indicates that the first mobile platform with TXT is the one Intel code-names Montevina, using processors code-named Penryn and a chipset code-named Cantiga, and that this should be coming out in Q2 08. Unfortunately, the mapping of these codenames to actual products seems to be a tightly held Intel secret - at least, I couldn't find it. However, Wikipedia has some useful information on the Montevina platform: http://en.wikipedia.org/wiki/Centrino#Montevina_platform_.282008.29 says, "The code-name Montevina refers to the fifth-generation Centrino platform, now formally named Centrino 2 to avoid confusion with previous Centrino platforms. It was scheduled for release at Computex Taipei 2008, which took place on June 3 - 7, 2008,[6] but has been delayed until July 14, due to problems with integrated graphics and wireless certification." July 14 happens to be today, so your question is in a way quite timely. And this tells us that what you want to look for would be Centrino 2. However it will probably be a while before systems are available with that architecture. And whether they will actually support TXT is unknown. When Trusted Execution was announced, 3 models of computers were identified as supporting it: The HP Compaq dc7800, Dell OptiPlex 755 PC, and the Lenovo ThinkCentre M57p. I don't know of any others that have been added to that list since then. As far as the use of Tboot, it seems to be primarily oriented around launching the Xen virtual machine monitor, making it a measured VMM or MVMM. Xen can then launch Linux or certain other OS's, perhaps even measuring them as well. Personally I prefer the direction of Jonathan McCune's "Flicker" project, http://sparrow.ece.cmu.edu/group/flicker.html - it similar to what you describe, launching from within a running OS self-contained applets (which I think he should call, flicklets) that run for a brief moment in a measured, protected mode, perform some sensitive calculation and then return to the conventional OS. I was working on a similar idea but he is quite a bit further along with it, and last I heard it was already working with AMD's skinit and almost there with Intel TXT. Hal Finney On Sun, Jul 13, 2008 at 2:27 PM, Mike Hearn <mi...@pl...> wrote: > Hiya, > > I'm interested in playing with LaGrande/TXT. I've read the book, although > it's sort of confusing and probably out of date now. It seems clear to me > that from a users perspective, messing around with the low level GETSEC > instructions is the wrong way to go - I need drivers. Tboot appears to be > that project. > > From reading the archives though it seems that the hardware still isn't > quite solid yet. Comments like "you are lucky" to somebody who actually got > it to (sort of) work aren't reassuring :) > > Does anybody know of a decently priced laptop that implements a known to > work LaGrande setup? Including the protected graphics/keyboard channels? > > Also, does anybody have some example code of launching an app[let] into a > protected domain? > > How far is there left to go, really? > > Thanks! > -mike > > ------------------------------------------------------------------------ - > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > _______________________________________________ > tboot-devel mailing list > tbo...@li... > https://lists.sourceforge.net/lists/listinfo/tboot-devel > > ------------------------------------------------------------------------ - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ tboot-devel mailing list tbo...@li... https://lists.sourceforge.net/lists/listinfo/tboot-devel |
From: Mike H. <mi...@pl...> - 2008-07-15 15:55:48
|
> It certainly doesn't help that Intel chose such a widely used 3 > letter acronym. Hah, I was going to comment on that. I wonder if it is truly too late to go back to the old codename, which is far easier to say and search. > As far as the use of Tboot, it seems to be primarily oriented around > launching the Xen virtual machine monitor, making it a measured VMM or > MVMM. Xen can then launch Linux or certain other OS's, perhaps even > measuring them as well. Right. The use case I'm actually interested in is somewhere between the two - I'd like to launch Firefox in a protected domain and have it usable for surfing the web. My vague, poorly thought out plan was to let the user pick a photo from a library as proof of the trusted path, then show it in a tab at startup. Once you saw the personal photo, you'd know you were interacting with a copy of the browser that'd be safe to use even on a malware-riddled machine. > Personally I prefer the direction of Jonathan McCune's "Flicker" > project, http://sparrow.ece.cmu.edu/group/flicker.html - it similar to > what you describe, launching from within a running OS self-contained > applets (which I think he should call, flicklets) that run for a brief > moment in a measured, protected mode, perform some sensitive > calculation and then return to the conventional OS. I was working on a > similar idea but he is quite a bit further along with it, and last I > heard it was already working with AMD's skinit and almost there with > Intel TXT. Huh, OK. I'm still pretty new to this whole space. I had no idea AMD had a TXT equivalent. Is it actually an implementation of the same system or are they separate/proprietary but with similar goals? For a trusted Firefox you really do need the whole stack AFAICT - including trusted channels to the video card and keyboard. Perhaps not the remote attestation although I suspect it'd be useful for allowing updates and/or allowing you to use a trusted firefox at a friends house. I need to consider that a bit more though. Something else I'm interested in figuring out is how much of the tboot/flicker code could be re-used in a Windows context, as obviously, that's where the biggest security problems lie. Tboot seems pretty Linux specific although presumably it could be ported to the equivalent Windows kernel APIs. Launching an actual copy of Linux inside another MVMM is pretty heavy - I'd really want a completely minimal ring 0 environment inside the MVMM ..... enough to let Firefox establish a channel to the GFX card and keyboard, then I'd want it to communicate back through to the main OS for things like disk/network IO. |
From: Cihula, J. <jos...@in...> - 2008-07-15 19:57:36
|
I should have also mentioned that all '08 (and forward) vPro and cPro systems will support TXT and that the DQ35JO motherboard is used in various ODMs' systems. Joe -----Original Message----- From: Cihula, Joseph Sent: Monday, July 14, 2008 4:33 PM To: 'Hal Finney'; Mike Hearn Cc: tbo...@li... Subject: RE: [tboot-devel] Buying a machine that will actually work with TXT I can't specifically recommend any systems, but I can add that the Intle(R) DQ35JO motherboard also supports TXT. And as Hal pointed out, the first mobile system will be available shortly (I can't comment on production dates, but the one in my office works with TXT just fine). Shortly we will be adding Linux support to tboot (i.e. to boot a Linux kernel) and posting the corresponding patches for Linux to LKML. Joe -----Original Message----- From: tbo...@li... [mailto:tbo...@li...] On Behalf Of Hal Finney Sent: Monday, July 14, 2008 3:12 PM To: Mike Hearn Cc: tbo...@li... Subject: Re: [tboot-devel] Buying a machine that will actually work with TXT Hi Mike - Boy, you'd think this would be easy to find out, wouldn't you? I just wasted (more optimistically, spent or even invested!) an hour trying to see what current chips, chipsets and systems support TXT. It certainly doesn't help that Intel chose such a widely used 3 letter acronym. It doesn't look to me like any laptops yet support TXT. This file: http://download.intel.com/products/roadmap/roadmap.pdf on page 5 indicates that the first mobile platform with TXT is the one Intel code-names Montevina, using processors code-named Penryn and a chipset code-named Cantiga, and that this should be coming out in Q2 08. Unfortunately, the mapping of these codenames to actual products seems to be a tightly held Intel secret - at least, I couldn't find it. However, Wikipedia has some useful information on the Montevina platform: http://en.wikipedia.org/wiki/Centrino#Montevina_platform_.282008.29 says, "The code-name Montevina refers to the fifth-generation Centrino platform, now formally named Centrino 2 to avoid confusion with previous Centrino platforms. It was scheduled for release at Computex Taipei 2008, which took place on June 3 - 7, 2008,[6] but has been delayed until July 14, due to problems with integrated graphics and wireless certification." July 14 happens to be today, so your question is in a way quite timely. And this tells us that what you want to look for would be Centrino 2. However it will probably be a while before systems are available with that architecture. And whether they will actually support TXT is unknown. When Trusted Execution was announced, 3 models of computers were identified as supporting it: The HP Compaq dc7800, Dell OptiPlex 755 PC, and the Lenovo ThinkCentre M57p. I don't know of any others that have been added to that list since then. As far as the use of Tboot, it seems to be primarily oriented around launching the Xen virtual machine monitor, making it a measured VMM or MVMM. Xen can then launch Linux or certain other OS's, perhaps even measuring them as well. Personally I prefer the direction of Jonathan McCune's "Flicker" project, http://sparrow.ece.cmu.edu/group/flicker.html - it similar to what you describe, launching from within a running OS self-contained applets (which I think he should call, flicklets) that run for a brief moment in a measured, protected mode, perform some sensitive calculation and then return to the conventional OS. I was working on a similar idea but he is quite a bit further along with it, and last I heard it was already working with AMD's skinit and almost there with Intel TXT. Hal Finney On Sun, Jul 13, 2008 at 2:27 PM, Mike Hearn <mi...@pl...> wrote: > Hiya, > > I'm interested in playing with LaGrande/TXT. I've read the book, although > it's sort of confusing and probably out of date now. It seems clear to me > that from a users perspective, messing around with the low level GETSEC > instructions is the wrong way to go - I need drivers. Tboot appears to be > that project. > > From reading the archives though it seems that the hardware still isn't > quite solid yet. Comments like "you are lucky" to somebody who actually got > it to (sort of) work aren't reassuring :) > > Does anybody know of a decently priced laptop that implements a known to > work LaGrande setup? Including the protected graphics/keyboard channels? > > Also, does anybody have some example code of launching an app[let] into a > protected domain? > > How far is there left to go, really? > > Thanks! > -mike > > ------------------------------------------------------------------------ - > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > _______________________________________________ > tboot-devel mailing list > tbo...@li... > https://lists.sourceforge.net/lists/listinfo/tboot-devel > > ------------------------------------------------------------------------ - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ tboot-devel mailing list tbo...@li... https://lists.sourceforge.net/lists/listinfo/tboot-devel |
From: Martin T. <ma...@th...> - 2008-07-16 06:43:19
|
Hello, regarding the original posters mention of trusted graphics and input paths: Does anyone know what the status on this is? I know this is separate technology from TXT but certainly it is part of trusted computing. Back in 2003 when especially Microsoft talked a lot about trusted computing, they envisaged end-to-end encryption to/from the keyboard and the possibility for creating trusted windows on the display that could not be grapped or overwritten by non-trusted programs (and that could be recognized by the user by some to be defined mechanism, like the one Mike suggested). I even read that ATI and Nvidia were on board on the graphics part. I haven't heard anything about this since and the relevant discussion forums on the trusted computing groups seem to be closed. So do any of you have more recent info on whether these techs are being/have been standardized somewhere? Thanks, Martin Thiim On 7/15/08, Cihula, Joseph <jos...@in...> wrote: > > I should have also mentioned that all '08 (and forward) vPro and cPro > systems will support TXT and that the DQ35JO motherboard is used in > various ODMs' systems. > > Joe > > -----Original Message----- > From: Cihula, Joseph > Sent: Monday, July 14, 2008 4:33 PM > To: 'Hal Finney'; Mike Hearn > Cc: tbo...@li... > Subject: RE: [tboot-devel] Buying a machine that will actually work with > TXT > > I can't specifically recommend any systems, but I can add that the > Intle(R) DQ35JO motherboard also supports TXT. > > And as Hal pointed out, the first mobile system will be available > shortly (I can't comment on production dates, but the one in my office > works with TXT just fine). > > Shortly we will be adding Linux support to tboot (i.e. to boot a Linux > kernel) and posting the corresponding patches for Linux to LKML. > > Joe > > -----Original Message----- > From: tbo...@li... > [mailto:tbo...@li...] On Behalf Of Hal > Finney > Sent: Monday, July 14, 2008 3:12 PM > To: Mike Hearn > Cc: tbo...@li... > Subject: Re: [tboot-devel] Buying a machine that will actually work with > TXT > > Hi Mike - Boy, you'd think this would be easy to find out, wouldn't > you? I just wasted (more optimistically, spent or even invested!) an > hour trying to see what current chips, chipsets and systems support > TXT. It certainly doesn't help that Intel chose such a widely used 3 > letter acronym. > > It doesn't look to me like any laptops yet support TXT. This file: > http://download.intel.com/products/roadmap/roadmap.pdf on page 5 > indicates that the first mobile platform with TXT is the one Intel > code-names Montevina, using processors code-named Penryn and a chipset > code-named Cantiga, and that this should be coming out in Q2 08. > Unfortunately, the mapping of these codenames to actual products seems > to be a tightly held Intel secret - at least, I couldn't find it. > However, Wikipedia has some useful information on the Montevina > platform: > http://en.wikipedia.org/wiki/Centrino#Montevina_platform_.282008.29 > says, > > "The code-name Montevina refers to the fifth-generation Centrino > platform, now formally named Centrino 2 to avoid confusion with > previous Centrino platforms. It was scheduled for release at Computex > Taipei 2008, which took place on June 3 - 7, 2008,[6] but has been > delayed until July 14, due to problems with integrated graphics and > wireless certification." > > July 14 happens to be today, so your question is in a way quite > timely. And this tells us that what you want to look for would be > Centrino 2. However it will probably be a while before systems are > available with that architecture. And whether they will actually > support TXT is unknown. > > When Trusted Execution was announced, 3 models of computers were > identified as supporting it: The HP Compaq dc7800, Dell OptiPlex 755 > PC, and the Lenovo ThinkCentre M57p. I don't know of any others that > have been added to that list since then. > > As far as the use of Tboot, it seems to be primarily oriented around > launching the Xen virtual machine monitor, making it a measured VMM or > MVMM. Xen can then launch Linux or certain other OS's, perhaps even > measuring them as well. > > Personally I prefer the direction of Jonathan McCune's "Flicker" > project, http://sparrow.ece.cmu.edu/group/flicker.html - it similar to > what you describe, launching from within a running OS self-contained > applets (which I think he should call, flicklets) that run for a brief > moment in a measured, protected mode, perform some sensitive > calculation and then return to the conventional OS. I was working on a > similar idea but he is quite a bit further along with it, and last I > heard it was already working with AMD's skinit and almost there with > Intel TXT. > > Hal Finney > > > > > > On Sun, Jul 13, 2008 at 2:27 PM, Mike Hearn <mi...@pl...> wrote: > > Hiya, > > > > I'm interested in playing with LaGrande/TXT. I've read the book, > although > > it's sort of confusing and probably out of date now. It seems clear to > me > > that from a users perspective, messing around with the low level > GETSEC > > instructions is the wrong way to go - I need drivers. Tboot appears to > be > > that project. > > > > From reading the archives though it seems that the hardware still > isn't > > quite solid yet. Comments like "you are lucky" to somebody who > actually got > > it to (sort of) work aren't reassuring :) > > > > Does anybody know of a decently priced laptop that implements a known > to > > work LaGrande setup? Including the protected graphics/keyboard > channels? > > > > Also, does anybody have some example code of launching an app[let] > into a > > protected domain? > > > > How far is there left to go, really? > > > > Thanks! > > -mike > > > > > ------------------------------------------------------------------------ > - > > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > > Studies have shown that voting for your favorite open source project, > > along with a healthy diet, reduces your potential for chronic lameness > > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > > _______________________________________________ > > tboot-devel mailing list > > tbo...@li... > > https://lists.sourceforge.net/lists/listinfo/tboot-devel > > > > > > ------------------------------------------------------------------------ > - > Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! > Studies have shown that voting for your favorite open source project, > along with a healthy diet, reduces your potential for chronic lameness > and boredom. Vote Now at http://www.sourceforge.net/community/cca08 > _______________________________________________ > tboot-devel mailing list > tbo...@li... > https://lists.sourceforge.net/lists/listinfo/tboot-devel > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > tboot-devel mailing list > tbo...@li... > https://lists.sourceforge.net/lists/listinfo/tboot-devel > |
From: Mike H. <mi...@pl...> - 2008-07-16 09:42:19
|
On Wed, Jul 16, 2008 at 8:43 AM, Martin Thiim <ma...@th...> wrote: > regarding the original posters mention of trusted graphics and input paths: Does anyone know what the status on this is? I know this is separate technology from TXT but certainly it is part of trusted computing. The "safer computing initiative" book talks a bit about this but the details are frustratingly absent. Essentially: - Yes it's a part of TXT - There is a defined mechanism for this (TGTT) - The process is that the video card is given restricted access to some section of a VMs memory space - The video card composites the trusted surface with the untrusted surface such that trusted surface is always top in the z-order No mention was made of how this would interact with composited desktops like Compiz, Aqua or Vista. I strongly suspect this straightforward implementation will have to be scrapped or at least augmented to allow for a VM to be bound to a secure OpenGL texture that the main untrusted OS can then composite into the final image. The trick being that the video card would have to somehow prevent the main VM from reading back any section of the screen that had been touched by the secure texture - including arbitrary transforms like reflection using pixel shaders. Ugh. Sounds complicated. I'll settle for a basic system that uses the technique described in the book for now, but obviously for production desktop use if you want to use a trusted graphics path then the issue of compositing will need to be addressed. The trusted channel to the keyboard seemed more fleshed out, there was a long discussion of how to handle laptop keyboards (as they aren't usb devices like on a desktop) although I don't remember the exact details of how you authenticate that the keyboard is a real hardware keyboard and not an emulation. |
From: Martin T. <ma...@th...> - 2008-07-16 14:09:59
|
Hi Mike Ok I found the TOC for the book and it looks very interesting. I'm wondering if it is Intel's / TCG's "vision" that trusted graphics can be realized with current hardware or if it is to make use of some to-be-announced graphics hardware of the future. Maybe this is clear from the book you mention. If you take Intel's TXT, the MLE will have full control of the computing environment. Hence, it should be able to seize complete control of the graphics cards and also have control over what (if any) other software can access the display. It could simply chose to clear the display of secrets before returning to the "unsafe" mode. The user would be able to recognize the trusted mode based on shared secret arranged at a time when the user trusts the computer was indeed executing in the trusted mode. All this would be possible with today's hardware and would at least allow for a "poor man's trusted graphics." However, this solution is hardly practical - people will want to have "trusted windows" running alongside the untrusted windows and non-trusted programs should still be able to run in the background (but not be able to interfere with the trusted windows). Can this be handled with current hardware? I'm not sure but maybe. The driver actually communicating with the hardware would have to execute in the trusted mode. It would have full responsibility for communicating with the graphics hardware. All painting etc. from untrusted applications would have to go through the trusted mode / trusted driver which can then take care of fitering the requests as approprate. So the question is if access to the graphics hardware can be blocked from the untrusted mode? The MLE could also act as a hypervisor and (assuming a late-launch scenario) move the running, untrusted operating system into a virtual machine and present it with a virtual graphics card or at least provide it with a graphics driver that would do the actual painting using hypervisor calls ending up in the trusted driver. At least theoretically the trusted driver would be able to completely control utilization of the graphics resources (including textures, z-plane etc.) but I don't know if it is feasible performance-wise. The framebuffer would have to be protected from DMA transfers - the TXT chipset registers could be used for this purpose. The biggest problem is that you need to have a trusted graphics driver and that as things are now will be hardware dependent. Thanks, Martin Thiim On 7/16/08, Mike Hearn <mi...@pl...> wrote: > > Only the book, sorry. If you google for "trusted graphics translation > table" you can see a few patents and presentations on it, but this is > all early days. > > On Wed, Jul 16, 2008 at 1:38 PM, Martin Thiim <ma...@th...> wrote: > > Interesting. However, as far as I can see it is not part of TXT. TXT is > > short for Trusted Execution Technology and all the documentation I've > seen > > from Intel about TXT seems to concern itself with trusted execution with > no > > mention of trusted I/O. > > > > You say there is a defined mechanism for trusted graphics, TGTT. However, > I > > can't find anything on this via Google. Do you have any references? > > > > Thanks, > > > > Martin Thiim > > > > On 7/16/08, Mike Hearn <mi...@pl...> wrote: > >> > >> On Wed, Jul 16, 2008 at 8:43 AM, Martin Thiim <ma...@th...> wrote: > >> > regarding the original posters mention of trusted graphics and input > >> > paths: Does anyone know what the status on this is? I know this is > separate > >> > technology from TXT but certainly it is part of trusted computing. > >> > >> The "safer computing initiative" book talks a bit about this but the > >> details are frustratingly absent. Essentially: > >> > >> - Yes it's a part of TXT > >> - There is a defined mechanism for this (TGTT) > >> - The process is that the video card is given restricted access to > >> some section of a VMs memory space > >> - The video card composites the trusted surface with the untrusted > >> surface such that trusted surface is always top in the z-order > >> > >> No mention was made of how this would interact with composited > >> desktops like Compiz, Aqua or Vista. I strongly suspect this > >> straightforward implementation will have to be scrapped or at least > >> augmented to allow for a VM to be bound to a secure OpenGL texture > >> that the main untrusted OS can then composite into the final image. > >> The trick being that the video card would have to somehow prevent the > >> main VM from reading back any section of the screen that had been > >> touched by the secure texture - including arbitrary transforms like > >> reflection using pixel shaders. Ugh. Sounds complicated. > >> > >> I'll settle for a basic system that uses the technique described in > >> the book for now, but obviously for production desktop use if you want > >> to use a trusted graphics path then the issue of compositing will need > >> to be addressed. > >> > >> The trusted channel to the keyboard seemed more fleshed out, there was > >> a long discussion of how to handle laptop keyboards (as they aren't > >> usb devices like on a desktop) although I don't remember the exact > >> details of how you authenticate that the keyboard is a real hardware > >> keyboard and not an emulation. > > > > > |
From: Mike H. <mi...@pl...> - 2008-07-16 15:05:45
|
On Wed, Jul 16, 2008 at 2:32 PM, Martin Thiim <ma...@th...> wrote: > Ok I found the TOC for the book and it looks very interesting. I'm wondering > if it is Intel's / TCG's "vision" that trusted graphics can be realized with > current hardware or if it is to make use of some to-be-announced graphics > hardware of the future. Maybe this is clear from the book you mention. The book makes very little about concrete implementation clear unfortunately. It does describe the late launch inter-cpu protocols in detail but little else - it's very much a conceptual overview (it does an ok job of that mind you). > If you take Intel's TXT, the MLE will have full control of the computing > environment. Hence, it should be able to seize complete control of the > graphics cards and also have control over what (if any) other software can > access the display. Yes in theory. In practice that sounds rather hard. There's a lot of state tied up in modern graphics drivers. The way I think it's intended to work - at least if I understand TGTT right - is that the main untrusted OS sets up a window, and then tells the hardware to use a trusted surface to display to it. Presumably the driver would configure the clip-lists for the trusted surface appropriately to ensure that overlapping windows operate correctly, etc. The protected domain can then use a trusted path signal (eg, sealed photo, colourful border or whatever) to prove to the user that it's in control of the channel. So basically there's minimal disruption to the main OS and the MVMM doesn't really get involved with graphics at all, except to mediate the pagetable/nodma setup process. > So the question is if access to the graphics hardware can be > blocked from the untrusted mode? My understanding is that the MVMM can block or allow whatever it likes from the untrusted OS, however, the larger it gets the more likely there are to be flaws, so it's better to keep the MVMM as small as possible. I assume there's also some non-trivial context switch overhead there. > At least theoretically the trusted driver would be able to completely control > utilization of the graphics resources (including textures, z-plane etc.) but > I don't know if it is feasible performance-wise. The MVMM doesn't know the hardware interface, it'd have to reverse engineer what the untrusted OS was doing back out of the DirectX/GL command stream. Sounds hard and slow, especially considering programmable shaders. This is why I think it's a better idea to let the untrusted OS handle graphics. It already has the right software and state. The protected domain just has to splat pixels into some region of memory and then the GFX card working with the untrusted domain does the rest. > The framebuffer would have to be protected from DMA transfers - the TXT chipset registers could be used > for this purpose. The biggest problem is that you need to have a trusted > graphics driver and that as things are now will be hardware dependent. Yeah you'd have to ensure that nothing is able to leave vram whilst the trusted surface is in operation - if an app in the untrusted OS wanted to read the framebuffer or use a shader that writes back to main memory, it'd get an error unless it unlinked the trusted surface first. Ouch. Sigh. Roll on Singularity. All this would be much easier if only we could rewrite every program from scratch ;) |
From: Hal F. <hal...@gm...> - 2008-07-16 17:45:01
|
In the VMM space there has long been competition from the microkernel camp, exemplified by L4. Microkernels have some advantages and some disadvantages compared to VMMs, but they are an alternative that might be considered for Tboot style trusted computing. There is a cool L4 demo of a secure window manager that takes only 1500 lines of code in the TCB, called Nitpicker. The paper is here, http://os.inf.tu-dresden.de/papers_ps/feske-nitpicker.pdf , and you can download a demo CD with that and some other projects from http://demo.tudos.org/ . Nitpicker allows multiple OS's to be running, each putting up windows on the screen. One OS is in the front and its windows are shown differently from the others. I believe it does succeed in keeping each OS's window contents secret from the others. The big weakness IMO in these TC concepts is the size of the Trusted Computing Base. The bigger the TCB, the more likely it is buggy, and that the foundation of your security is weak. Something like this approach seems to give a large bang for the buck in terms of keeping TCB size down. I'm not sure exactly what they're for, but the TPM chip has one or more General Purpose I/O pins which can be read/written by software. Presently the TPM specs define the use of one of these pins, from the PC Client Implementation for BIOS Specification, https://www.trustedcomputinggroup.org/specs/PCClient/TCG_PCClientImplementationforBIOS_1-20_1-00.pdf : "Currently the only defined usage of the GPIO is for use by the GPIO-Express-00 pin, which allows software to control an enabling of a feature of PCI Express using the TCS_EN pin of the PCI Express Root Complex per the PCI Express Trusted Configuration Space ECR. This enabling is not always required by the platform's specific architecture and design, but if this signal is required, it must be implemented as described in this section. The PC Client TPM Interface Specification maps the value of the least significant bit of TPM_NV_INDEX_GPIO_00 data to the GPIO-Express-00 pin. This bit will be called the GPIO-Express-00 bit for documentation purposes." I'm not clear on what all this means, but apparently this I/O pin is mapped into some feature of the PCI bus, something called the Trusted Configuration Space. I don't know if the PCI specs would shed significant light on what this can be used for. Hal Finney |
From: Cihula, J. <jos...@in...> - 2008-07-16 19:00:53
|
The early versions of Intel(R) Trusted Execution Technology (TXT), at that time called LaGrande Technology, included trusted input and output as well as a NoDMA table for DMA protection. As we continued to develop TXT and work with the ecosystem, several things changed. We were able to have VT-d available in time to be used with TXT, and since it provided a more general mechanism for DMA protection, it was a better choice than the NoDMA table. Trusted I/O was dropped for several reasons. The original trusted output was a simple framebuffer-based overlay that could be controlled by the MLE and was always on top of any other display elements. This would not integrate well (visually or otherwise) with the composited UIs that were becoming available (e.g. Vista). Trusted input was also challenging from a usability perspective when things like notebook docking stations were factored in (i.e. it was technically possible but might require a keyboard to be plugged into a certain port). VT-d gives software the ability to provide trusted I/O, albeit with its own set of restrictions. Using VT-d one could either create a UI VM that managed all of the UI and provided windows/regions to other VMs (ala Nitpicker) or it could be used to do fullscreen switching between VMs. Likewise for input, VT-d can be used to assign a USB keyboard/mouse to a trusted VM either temporarily or permanently. That said, we are still looking at ways to implement trusted I/O that can overcome the various limitations of the original approach as well as that of using VT-d. I hope this helps explain some of the discrepancies you find in our earlier material with what we have today. Joe -----Original Message----- From: tbo...@li... [mailto:tbo...@li...] On Behalf Of Mike Hearn Sent: Wednesday, July 16, 2008 8:06 AM To: Martin Thiim Cc: tbo...@li... Subject: Re: [tboot-devel] Buying a machine that will actually work with TXT On Wed, Jul 16, 2008 at 2:32 PM, Martin Thiim <ma...@th...> wrote: > Ok I found the TOC for the book and it looks very interesting. I'm wondering > if it is Intel's / TCG's "vision" that trusted graphics can be realized with > current hardware or if it is to make use of some to-be-announced graphics > hardware of the future. Maybe this is clear from the book you mention. The book makes very little about concrete implementation clear unfortunately. It does describe the late launch inter-cpu protocols in detail but little else - it's very much a conceptual overview (it does an ok job of that mind you). > If you take Intel's TXT, the MLE will have full control of the computing > environment. Hence, it should be able to seize complete control of the > graphics cards and also have control over what (if any) other software can > access the display. Yes in theory. In practice that sounds rather hard. There's a lot of state tied up in modern graphics drivers. The way I think it's intended to work - at least if I understand TGTT right - is that the main untrusted OS sets up a window, and then tells the hardware to use a trusted surface to display to it. Presumably the driver would configure the clip-lists for the trusted surface appropriately to ensure that overlapping windows operate correctly, etc. The protected domain can then use a trusted path signal (eg, sealed photo, colourful border or whatever) to prove to the user that it's in control of the channel. So basically there's minimal disruption to the main OS and the MVMM doesn't really get involved with graphics at all, except to mediate the pagetable/nodma setup process. > So the question is if access to the graphics hardware can be > blocked from the untrusted mode? My understanding is that the MVMM can block or allow whatever it likes from the untrusted OS, however, the larger it gets the more likely there are to be flaws, so it's better to keep the MVMM as small as possible. I assume there's also some non-trivial context switch overhead there. > At least theoretically the trusted driver would be able to completely control > utilization of the graphics resources (including textures, z-plane etc.) but > I don't know if it is feasible performance-wise. The MVMM doesn't know the hardware interface, it'd have to reverse engineer what the untrusted OS was doing back out of the DirectX/GL command stream. Sounds hard and slow, especially considering programmable shaders. This is why I think it's a better idea to let the untrusted OS handle graphics. It already has the right software and state. The protected domain just has to splat pixels into some region of memory and then the GFX card working with the untrusted domain does the rest. > The framebuffer would have to be protected from DMA transfers - the TXT chipset registers could be used > for this purpose. The biggest problem is that you need to have a trusted > graphics driver and that as things are now will be hardware dependent. Yeah you'd have to ensure that nothing is able to leave vram whilst the trusted surface is in operation - if an app in the untrusted OS wanted to read the framebuffer or use a shader that writes back to main memory, it'd get an error unless it unlinked the trusted surface first. Ouch. Sigh. Roll on Singularity. All this would be much easier if only we could rewrite every program from scratch ;) ------------------------------------------------------------------------ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ tboot-devel mailing list tbo...@li... https://lists.sourceforge.net/lists/listinfo/tboot-devel |
From: Mike H. <mi...@pl...> - 2008-07-17 07:40:47
|
> The early versions of Intel(R) Trusted Execution Technology (TXT), at > that time called LaGrande Technology, included trusted input and output > as well as a NoDMA table for DMA protection. Good. The NoDMA table always seemed like a kludge to me :) > As we continued to develop > TXT and work with the ecosystem, several things changed. We were able > to have VT-d available in time to be used with TXT OK. I don't know what VT-d is. I'll have to investigate more I guess. > VT-d gives software the ability to provide trusted I/O, albeit with its > own set of restrictions. Using VT-d one could either create a UI VM > that managed all of the UI and provided windows/regions to other VMs > (ala Nitpicker) or it could be used to do fullscreen switching between > VMs. Likewise for input, VT-d can be used to assign a USB > keyboard/mouse to a trusted VM either temporarily or permanently. Yes, to be honest despite the issues with compositing both of these alternatives sound like a _downgrade_. Nobody is going to want to lose their operating systems window management. What can you tell us about the state of the current trusted IO research? Have you talked to nVidia/ATI about doing trusted surfaces in a way that's compatible with OpenGL/Direct3D compositing? My idea of a trusted Firefox rather relies on trusted gfx channels rather heavily :-( > I hope this helps explain some of the discrepancies you find in our > earlier material with what we have today. Yeah, thanks, although to be frank the state of the TXT documentation is rather sparse. The book is/was as good as it gets as far as I can tell, so even just one web page somewhere describing the changes since then (mid 2006?) would be a great thing to have. Otherwise everybody outside your team is going to be left in the dark. thanks -mike |
From: Hal F. <hal...@gm...> - 2008-07-18 18:11:32
|
Here's an article about the new laptops coming out with TXT support: http://www.betanews.com/article/Centrino_2_platform_wipes_the_slate_clean_for_vendors_midrange_notebooks/1216162477 The only ones explicitly mentioning trusted platform support are the Acer TravelMate 6493 and the Toshiba Tecra M10 and A10 models. However it's possible that some of the others will as well - from what Joseph said, I guess you can just look for the vPro keyword. One other point Mike, I assume you are aware of Intel's page which has the latest information on TXT: http://www.intel.com/technology/security/ This has the latest spec, which goes into a lot more detail than the book, but basically will show the differences between what was planned and what is currently implemented. I agree that it would be nice to know about future directions and plans as well. As far as VT-d, the DMA virtualization technology, I would still be worried about the attack described here: http://www.links.org/?p=330 Apparently it is easy to overwrite firmware on certain peripheral cards, allowing malicious software running in a VM to inject malware into the card. Then when a different VM is running, and VT-d is programmed to allow DMA into that VM's addressing space, the malware can activate and steal or overwrite data that was supposed to be protected against the 1st VM. Unless we can identify and limit access to all peripheral cards with reprogrammable firmware, it is going to be very hard to defend against this kind of attack. Hal Finney |
From: Martin T. <ma...@th...> - 2008-07-19 09:39:15
|
Hello, It's a very interesting attack you mention. However, it doesn't seem to be restricted to virtualization or even trusted computing. The consequence is that if an untrusted program was ever in the past allowed to execute on the computer with direct access to the hardware, it could insert a threat that will persist even across reboots. Furthermore, the change may not be detectable by any antivirus program and will not be reflected in the PCR's of either the static or dynamic root of trust. This might already be happening today... I think in practice this means that external hardware can never be allowed to do to/from memory areas containing (unencrypted) secrets, and I also think this was the original idea behind TXT. But as far as I can see, these types of attack means that it is difficult to by with current graphics hardware for even "a poor man's trusted graphics" - how can you trust a graphics card that could be running any firmware? For special applications you might be able to say to a customer "Only use hardware from this list of trusted hardware that will only accept signed firmware updates etc. - open the computer casing and verify that all your hardware is on this list" which would be easy in the sense that it wouldn't require the definition of new standards etc. However, for the general consumer it might not seem so elegant. Here it seems the way to go is for the graphics card to have endorsement keys/certificates. From there, there would be two routes to go: Either you need a mechanism in the chipset that can enforce something like "This DMA buffer can be accessed only by the CPU and device X on the PCI Express bus". I don't know enough about PCI Express / chipsets to say if it would be possible to enforce such a policy. Or you need a mechanism for negotiating an encryption key with the graphics card. All DMA buffers could then be end-to-end encrypted & MAC'en (using GCM or something similar) and the buffers could thus be freely exposed to all hardware. This might also guard against other kinds of hardware-based attacks (bus snooping etc.). When you have that the next step is to define the mechanism that would make it possible for trusted and untrusted software to share the same screen. Best regards, Martin Thiim On 7/18/08, Hal Finney <hal...@gm...> wrote: > Here's an article about the new laptops coming out with TXT support: > > > http://www.betanews.com/article/Centrino_2_platform_wipes_the_slate_clean_for_vendors_midrange_notebooks/1216162477 > > The only ones explicitly mentioning trusted platform support are the > Acer TravelMate 6493 and the Toshiba Tecra M10 and A10 models. However > it's possible that some of the others will as well - from what Joseph > said, I guess you can just look for the vPro keyword. > > One other point Mike, I assume you are aware of Intel's page which has > the latest information on TXT: > > http://www.intel.com/technology/security/ > > This has the latest spec, which goes into a lot more detail than the > book, but basically will show the differences between what was planned > and what is currently implemented. I agree that it would be nice to > know about future directions and plans as well. > > As far as VT-d, the DMA virtualization technology, I would still be > worried about the attack described here: > > http://www.links.org/?p=330 > > Apparently it is easy to overwrite firmware on certain peripheral > cards, allowing malicious software running in a VM to inject malware > into the card. Then when a different VM is running, and VT-d is > programmed to allow DMA into that VM's addressing space, the malware > can activate and steal or overwrite data that was supposed to be > protected against the 1st VM. Unless we can identify and limit access > to all peripheral cards with reprogrammable firmware, it is going to > be very hard to defend against this kind of attack. > > Hal Finney > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > tboot-devel mailing list > tbo...@li... > https://lists.sourceforge.net/lists/listinfo/tboot-devel > |
From: Jonathan M. M. <jon...@cm...> - 2008-10-03 12:22:42
|
Hal Finney wrote: > When Trusted Execution was announced, 3 models of computers were > identified as supporting it: The HP Compaq dc7800, Dell OptiPlex 755 > PC, and the Lenovo ThinkCentre M57p. I don't know of any others that > have been added to that list since then. > Does anybody know whether the HP or Lenovo systems include a reset button? At least the Ultra Slim Form Factor Optiplex 755s have no reset button, meaning that debugging a system hang requires a power cycle that clears LT.ERRORCODE, making debugging substantially more difficult. Alternatively, does anybody know another way to trigger a reset on one of these systems? I'm told that there is a CMOS reset byte, and that it may be possible to write a value to it that causes the "soft" power button on the Optiplex to cause a reset instead of a power off. I have not investigated this yet, as I'd rather just get a different machine. Thanks, -Jon |
From: Jonathan M. M. <jon...@cm...> - 2008-10-09 17:18:02
|
fyi... It seems that the HP Compaq dc7800 does _not_ include a reset button either. -Jon Jonathan M. McCune wrote: > Hal Finney wrote: >> When Trusted Execution was announced, 3 models of computers were >> identified as supporting it: The HP Compaq dc7800, Dell OptiPlex 755 >> PC, and the Lenovo ThinkCentre M57p. I don't know of any others that >> have been added to that list since then. >> > > Does anybody know whether the HP or Lenovo systems include a reset > button? At least the Ultra Slim Form Factor Optiplex 755s have no reset > button, meaning that debugging a system hang requires a power cycle that > clears LT.ERRORCODE, making debugging substantially more difficult. > > > Alternatively, does anybody know another way to trigger a reset on one > of these systems? I'm told that there is a CMOS reset byte, and that it > may be possible to write a value to it that causes the "soft" power > button on the Optiplex to cause a reset instead of a power off. I have > not investigated this yet, as I'd rather just get a different machine. > > > Thanks, > -Jon > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > tboot-devel mailing list > tbo...@li... > https://lists.sourceforge.net/lists/listinfo/tboot-devel > |
From: Jonathan M. M. <jon...@cm...> - 2009-01-12 21:03:53
|
Hal Finney wrote: > When Trusted Execution was announced, 3 models of computers were > identified as supporting it: The HP Compaq dc7800, Dell OptiPlex 755 > PC, and the Lenovo ThinkCentre M57p. I don't know of any others that > have been added to that list since then. > I tried the latest tboot on a Lenovo M57p and it fails to boot. The relevant errors seem to be that the BIOS data version is 1 and tboot requires 2 or greater (error log below). I have updated the machine to the latest BIOS revision "2rj957a" with no luck. Any ideas? Thanks, -Jon TBOOT: ******************* TBOOT ******************* TBOOT: 2009-01-05 16:33 -0500 111:e009b057d5b0 TBOOT: ********************************************* TBOOT: command line: logging=vga,serial,memory TBOOT: TPM is ready TBOOT: TPM nv_locked: FALSE TBOOT: TPM: get capability, return value = 00000002 TBOOT: failed to get actual policy size in TPM NV TBOOT: failed to read policy from TPM NV, using default TBOOT: policy: TBOOT: version: 2 TBOOT: policy_type: TB_POLTYPE_CONT_NON_FATAL TBOOT: hash_alg: TB_HALG_SHA1 TBOOT: policy_control: 00000001 (EXTEND_PCR17) TBOOT: num_entries: 2 TBOOT: policy entry[0]: TBOOT: mod_num: 0 TBOOT: pcr: none TBOOT: hash_type: TB_HTYPE_ANY TBOOT: num_hashes: 0 TBOOT: policy entry[1]: TBOOT: mod_num: any TBOOT: pcr: 19 TBOOT: hash_type: TB_HTYPE_ANY TBOOT: num_hashes: 0 TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return = 00000002 TBOOT: Error: write TPM error: 0x2. TBOOT: no policy in TPM NV. TBOOT: IA32_FEATURE_CONTROL_MSR: 0000ff07 TBOOT: CPU is SMX-capable TBOOT: CPU is VMX-capable TBOOT: SMX is enabled TBOOT: TXT chipset and all needed capabilities present TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return = 00000002 TBOOT: Error: write TPM error: 0x2. TBOOT: LT.ERRORCODE=0 TBOOT: LT.ESTS=0 TBOOT: unsupported BIOS data version (1) TBOOT: TPM: write nv 20000002, offset 00000000, 00000004 bytes, return = 00000002 TBOOT: Error: write TPM error: 0x2. TBOOT: TPM: access reg release locality timeout TBOOT: shutdown_system() called for shutdown_type: TB_SHUTDOWN_HALT |