From: Lil E. <Lil...@gm...> - 2008-11-12 13:16:05
|
Hi, I was wondering whats the status and/or roadmap for late launch with tboot, as I was looking at getting some kind of late launch to work? I do believe some people on this mailing list are working on a late launch proof of concept? What's the status there? thanks lIl -- GMX Download-Spiele: Preizsturz! Alle Puzzle-Spiele Deluxe über 60% billiger. http://games.entertainment.gmx.net/de/entertainment/games/download/puzzle/index.html |
From: Wang, S. <sha...@in...> - 2008-11-18 05:55:03
|
What do you mean of "late launch"? I assume it should not be "post launch". Shane Lil Evil wrote: > Hi, > > I was wondering whats the status and/or roadmap for late launch with > tboot, as I was looking at getting some kind of late launch to work? > I do believe some people on this mailing list are working on a late > launch proof of concept? > What's the status there? > > > thanks > lIl |
From: Lil E. <Lil...@gm...> - 2008-11-19 11:21:32
|
Well, but I don't care what else is running as long as my hypervsior (call it MLE or whatever you want) is measured. We only need assurance of a trusted hypervisor, the code running previously can be untrusted as long as it is sufficiently isolated from the rest. lIl -------- Original-Nachricht -------- > Datum: Wed, 19 Nov 2008 09:17:20 +0800 > Von: "Wang, Shane" <sha...@in...> > An: Lil Evil <Lil...@gm...> > Betreff: RE: [tboot-devel] late launch > Oh, but tboot targets at DRTM originally. > The machine runs at unmeasured environment first and calls getsec[senter] > to enter SINIT and measure untrusted tboot so as to build the root of > trust. > The only difference I can figure out is that tboot is close to the machine > reset. > Our method is simple since it is enough for SINIT to measure tboot only, > since only tboot is in the memory. Simple as it is, it is also a kind of > DRTM not static RTM. > > Anyway, with this mechanism, you can put your code after OS boots up. But > this will make measurement complex, since so many things are in the memory. > (I think this is what you want). Of course, that is also a kind of DRTM. > > You have to say both are all DRTM. How to implement, it is up to you:) > > Shane > > Lil Evil wrote: > > Hi Shane, > > > > Well, with late launch I meant, the DRTM allows the platform to > > perform a measured launch at any time. For instance, I have performed > > my normal unmeasured boot process and now I decided to start my MLE. > > > > I was looking for a PoC or similar projects which already worked on > > s.th. like this. > > Obviously tboot would not be the right project name for it. > > > > I started working on it, but I suppose it is not necessary to > > reinvent the wheel. > > I think I saw s.b. posting on the mailing list about it already.... > > > > thanks > > lIl > > > > -------- Original-Nachricht -------- > >> Datum: Tue, 18 Nov 2008 13:54:53 +0800 > >> Von: "Wang, Shane" <sha...@in...> > >> An: Lil Evil <Lil...@gm...>, "tbo...@li..." > >> <tbo...@li...> Betreff: Re: [tboot-devel] late > >> launch > > > >> What do you mean of "late launch"? > >> I assume it should not be "post launch". > >> > >> Shane > >> > >> Lil Evil wrote: > >>> Hi, > >>> > >>> I was wondering whats the status and/or roadmap for late launch with > >>> tboot, as I was looking at getting some kind of late launch to > >>> work? I do believe some people on this mailing list are working on > >>> a late launch proof of concept? What's the status there? > >>> > >>> > >>> thanks > >>> lIl > >> > >> > >> > ------------------------------------------------------------------------- > >> 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 -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger |
From: Cihula, J. <jos...@in...> - 2008-11-19 13:05:19
|
> From: Lil Evil [mailto:Lil...@gm...] > Sent: Wednesday, November 19, 2008 3:21 AM > > Well, but I don't care what else is running as long as my hypervsior (call it MLE or whatever > you want) is measured. > We only need assurance of a trusted hypervisor, the code running previously can be untrusted > as long as it is sufficiently isolated from the rest. > > lIl The only project I know of that is using Intel(R) TXT in a late launch (post-OS) model is Flicker (http://sparrow.ece.cmu.edu/group/flicker.html). It's author, Jonathan McCune, often posts here and could give you more details about it. The late launch model is where a DRTM provides the most value over a static root of trust, as it is not even really possible to extend the SRTM to this point for most OSes. Joe > > -------- Original-Nachricht -------- > > Datum: Wed, 19 Nov 2008 09:17:20 +0800 > > Von: "Wang, Shane" <sha...@in...> > > An: Lil Evil <Lil...@gm...> > > Betreff: RE: [tboot-devel] late launch > > > Oh, but tboot targets at DRTM originally. > > The machine runs at unmeasured environment first and calls getsec[senter] > > to enter SINIT and measure untrusted tboot so as to build the root of > > trust. > > The only difference I can figure out is that tboot is close to the machine > > reset. > > Our method is simple since it is enough for SINIT to measure tboot only, > > since only tboot is in the memory. Simple as it is, it is also a kind of > > DRTM not static RTM. > > > > Anyway, with this mechanism, you can put your code after OS boots up. But > > this will make measurement complex, since so many things are in the memory. > > (I think this is what you want). Of course, that is also a kind of DRTM. > > > > You have to say both are all DRTM. How to implement, it is up to you:) > > > > Shane > > > > Lil Evil wrote: > > > Hi Shane, > > > > > > Well, with late launch I meant, the DRTM allows the platform to > > > perform a measured launch at any time. For instance, I have performed > > > my normal unmeasured boot process and now I decided to start my MLE. > > > > > > I was looking for a PoC or similar projects which already worked on > > > s.th. like this. > > > Obviously tboot would not be the right project name for it. > > > > > > I started working on it, but I suppose it is not necessary to > > > reinvent the wheel. > > > I think I saw s.b. posting on the mailing list about it already.... > > > > > > thanks > > > lIl > > > > > > -------- Original-Nachricht -------- > > >> Datum: Tue, 18 Nov 2008 13:54:53 +0800 > > >> Von: "Wang, Shane" <sha...@in...> > > >> An: Lil Evil <Lil...@gm...>, "tbo...@li..." > > >> <tbo...@li...> Betreff: Re: [tboot-devel] late > > >> launch > > > > > >> What do you mean of "late launch"? > > >> I assume it should not be "post launch". > > >> > > >> Shane > > >> > > >> Lil Evil wrote: > > >>> Hi, > > >>> > > >>> I was wondering whats the status and/or roadmap for late launch with > > >>> tboot, as I was looking at getting some kind of late launch to > > >>> work? I do believe some people on this mailing list are working on > > >>> a late launch proof of concept? What's the status there? > > >>> > > >>> > > >>> thanks > > >>> lIl > > >> > > >> > > >> > > ------------------------------------------------------------------------- > > >> 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 > > -- > Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: > http://www.gmx.net/de/go/multimessenger > > ------------------------------------------------------------------------- > 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-11-20 16:33:30
|
> > The late launch model is where a DRTM provides the most value over a static > root of trust, as it is not even really possible to extend the SRTM to this > point for most OSes. What's the rationale for tboot not being a late launch project? My understanding was that the whole point of TXT was to enable late launch. |
From: Hal F. <hal...@gm...> - 2008-11-20 19:01:33
|
On Thu, Nov 20, 2008 at 8:33 AM, Mike Hearn <mi...@pl...> wrote: > What's the rationale for tboot not being a late launch project? My > understanding was that the whole point of TXT was to enable late launch. It seems that the problem with late launch is not so much launching something like tboot, it's what happens next. The simplest case would be to just abandon the original OS from which you performed the late launch, and to go ahead and do what tboot does now, measure and launch a VM monitor like Xen, which then launches a new set of VMs from scratch. But that doesn't give you any advantages over simply rebooting into today's tboot. Jon McCune's Flicker project does a late launch of a small executable program that performs secure functions for a relatively brief moment (a flicker of time, hence the name), and then tears down the secure environment and returns to the original OS. This has also required substantial work and research to accomplish, and seems to require OS specific code. A very ambitious possibility would be to encapsulate the state of the OS you were running before launching tboot, and to transfer it into a VM, allowing it to continue to run under a VMM launched by tboot. Ideally the user would hardly notice that the late launch had happened and that his OS had gone from running on the real hardware, to running in a VM managed by a measured VMM that tboot had started. I think this was the original idea of Microsoft's Palladium project, renamed NGSCB and then seemingly abandoned in the face of a firestorm of criticism. Clearly it would be extremely challenging to accomplish, and would very likely be OS specific. The "Blue Pill" project, http://bluepillproject.org/ , is a sort of root kit which does something similar, not using tboot but wrapping the OS in a VM and keeping it running, maybe without the user noticing. It could probably be modified to use tboot and might be a good starting point for this kind of late launch architecture. Hal Finney |
From: Cihula, J. <jos...@in...> - 2008-11-20 19:35:15
|
Well said. The tboot project's primary purpose is to be reference code for the use of Intel(R) TXT. And since TXT is mostly about launching a trusted environment, most of the code for its use is about preparing for and executing the launch. There is some subsequent code for verifying the launched environment. This aspect of TXT is not really dependent on early and late launch models--the same process is required for all uses of TXT. In addition to providing reference code, tboot is also a production-quality MLE (measured launched environment). This was done in order to provide a functioning, runable example of TXT use that could be integrated into products or deployments. For a variety of reasons, it is extremely valuable to have a practical, runable TXT "application". We wanted tboot to serve as an example of TXT use, not as a complete virtualization/separation kernel/high-security kernel/etc. solution. So tboot is designed to work in conjunction with a VMM (e.g. Xen) or OS (e.g. Linux) to provide the TXT-related security functionality. The VMM or OS is responsible for extending or maintaining the trusted environment that tboot launched it in. This is also why tboot is designed to be fairly VMM/OS agnostic and with minimal VMM/OS changes needed for full support (as opposed to being tightly integrated into it). And by releasing tboot with an open source license, we wanted to facilitate others who work in open source to apply TXT to their projects and release the results. Hopefully this will give the community a range of usage models that a single company like Intel could not have developed on its own. Joe P.S. We will be posting SINIT AC Modules for the new mobile and desktop systems very soon. > -----Original Message----- > From: Hal Finney [mailto:hal...@gm...] > Sent: Thursday, November 20, 2008 11:01 AM > To: Mike Hearn > Cc: Cihula, Joseph; tbo...@li...; Lil Evil > Subject: Re: [tboot-devel] late launch > > On Thu, Nov 20, 2008 at 8:33 AM, Mike Hearn <mi...@pl...> wrote: > > What's the rationale for tboot not being a late launch project? My > > understanding was that the whole point of TXT was to enable late launch. > > It seems that the problem with late launch is not so much launching > something like tboot, it's what happens next. > > The simplest case would be to just abandon the original OS from which > you performed the late launch, and to go ahead and do what tboot does > now, measure and launch a VM monitor like Xen, which then launches a > new set of VMs from scratch. But that doesn't give you any advantages > over simply rebooting into today's tboot. > > Jon McCune's Flicker project does a late launch of a small executable > program that performs secure functions for a relatively brief moment > (a flicker of time, hence the name), and then tears down the secure > environment and returns to the original OS. This has also required > substantial work and research to accomplish, and seems to require OS > specific code. > > A very ambitious possibility would be to encapsulate the state of the > OS you were running before launching tboot, and to transfer it into a > VM, allowing it to continue to run under a VMM launched by tboot. > Ideally the user would hardly notice that the late launch had happened > and that his OS had gone from running on the real hardware, to running > in a VM managed by a measured VMM that tboot had started. I think this > was the original idea of Microsoft's Palladium project, renamed NGSCB > and then seemingly abandoned in the face of a firestorm of criticism. > Clearly it would be extremely challenging to accomplish, and would > very likely be OS specific. The "Blue Pill" project, > http://bluepillproject.org/ , is a sort of root kit which does > something similar, not using tboot but wrapping the OS in a VM and > keeping it running, maybe without the user noticing. It could probably > be modified to use tboot and might be a good starting point for this > kind of late launch architecture. > > Hal Finney |
From: Jonathan M. M. <jon...@cm...> - 2008-11-20 19:58:23
|
Cihula, Joseph wrote: > In addition to providing reference code, tboot is also a production-quality MLE (measured launched environment). This was done in order to provide a functioning, runable example of TXT use that could be integrated into products or deployments. For a variety of reasons, it is extremely valuable to have a practical, runable TXT "application". > This was a tremendous help while getting Flicker off the ground using TXT. By my estimation, you guys have done a nice job demonstrating the various capabilities of TXT. I'm very happy that this list finds the Flicker project to be an interesting and compelling use of TXT. I have the tricky parts working with TXT, and hope to release some code in the coming weeks. If there is sufficient interest, I can create a SourceForge project. Hopefully this will make it easier to integrate bug-fixes, features, etc. Cheers, -Jon |