tboot-devel — Developer support

[tboot-devel] Roadmap for trusted IO

[Mike H. <mi...@pl...>]

Hiya,

Given that the general plan for TXT/Trusted Computing in general has
been published for ~6 years now, does Intel plan to publish a more
detailed roadmap for the technology?

In particular I'm interested in whether anybody is working on trusted
IO (graphics/keyboard) today, and if not, what has to be completed
first before it is.

This is because most of the use cases for TXT I can think of require
trusted IO in some way. After all, securely doing a calculation is
great but if the input or output to that calculation can be controlled
by the attacker, it's suddenly much less useful. I understand that VT
has some kind of support for virtualized network devices, so I guess a
MLE could have its own suite of network drivers, but network IO seems
to be one of the few things that *can* be done without special
support, by simply requiring the untrusted main OS to relay TCP/IP
packets secured with SSL. That allows for a DoS but not any other form
of tampering, which seems sufficient for most applications.

The trick is that you don't want to have to ship a set of known-good
drivers with every secure application/VM. Relying on VESA is just
going to result in a crappy user experience. That means the untrusted
main OS should be in charge of setting up and configuring nearly
everything except the trusted channel itself, then there needs to be
some protocol between the main untrusted OS and the secure VM to
finish off the last stage.

Random thought-stream from somebody who doesn't know much:

1) Main untrusted OS runs some kind of host program, which creates a
window, grabs some empty pages large enough for the framebuffer within
it, and then binds that memory to a texture. It records the physical
base address in RAM of this texture memory.

2) Untrusted host program gives away that memory to the trusted VM via
the MVMM, which ensures that now only the trusted VM can read/write to
it (and via vt-d the video card as well). It also tells the trusted VM
what the physical base address previously recorded is.

3) Trusted VM can now scribble into this framebuffer. When it's done
drawing, it context switches back to the untrusted OS which then asks
the video card to reload the texture ID given the physical base
address in RAM. There's no API to do this today in graphics drivers
because it's a useless thing, but it could be added quite easily IIUC.
Having refreshed the contents of VRAM the untrusted OS can
recomposit/rerender the screen in whatever way it likes.

4) This completes the trusted channel, without the need for
cryptography. For a trusted path, the app can unseal an image
personally selected by the user and present it to them as proof of
authenticity.

This approach is simple but has one huge problem - the untrusted OS
can simply read back the contents of VRAM like it would when taking a
screenshot, and there are the secure pixels. To stop this requires
hardware changes. There are two approaches:

1) Simple and cheap: when the video card is in "secure mode", forbid
reading back anything from vRAM into system RAM. Taking a screenshot
results in a failure or a black bitmap.
2) An S-Buffer: more complicated but more flexible. Allocate a matrix
such that each on-screen pixel has a bit. If that pixel has been
touched by the rendering of a secure texture, flip the S-Buffer bit.
When reading back from vRAM pixels with the s-buffer bit flipped are
black.

How can the trusted VM know the texture is secure? A simple
vendor-neutral hardware protocol is agreed on (reading/writing an IO
port or whatever) to indicate this. Maybe you'd write the physical
base address, size in pages, wait a few hundred microseconds, read
back the answer. The main OS driver is responsible for actually making
the texture secure in the first place, but the trusted VM can verify
that. The software knows it's talking to real hardware because the VMM
was measured.

What do you guys think?

Re: [tboot-devel] RE : TXT and kvm : conflict ?

[Cihula, J. <jos...@in...>]

Below [JC2] (sorry but Outlook 2007 doesn't quote well):

-----Original Message-----
From: tbo...@li... [mailto:tbo...@li...] On Behalf Of Courtay Olivier
Sent: Thursday, September 11, 2008 6:09 AM
To: tbo...@li...
Subject: [tboot-devel] RE : TXT and kvm : conflict ?

Hello,

my response bellow quoted by [OC]

-----Original Message-----
From: tbo...@li...
[mailto:tbo...@li...] On Behalf Of Courtay
Olivier
Sent: Wednesday, September 10, 2008 5:57 AM
To: tbo...@li...
Subject: [tboot-devel] TXT and kvm : conflict ?

Hello,

I have successfully installed tboot on a Dell Optiplex 755 (E8500).
VMM and dom0 verification is OK.

One question.
In TBOOT log I have:

TBOOT: dom0 is verified.
TBOOT: succeeded.
TBOOT: invalid module #

What is this invalid module ?

[JC]  Older versions of tboot displayed this during policy processing,
even though there was not an error.  What changeset are you using?

[OC] Ok, I use the tboot-20080613. I can provide log of my TBOOT if you want.

[JC2] I think this is harmless in that version.  But I would suggest using the latest code from the mercurial repo.

 
I have not yet tested sealed process.

[JC]  FYI, your TPM will need to have an owner and you should have
created the SRK with the null auth (use '-z' flag to tpm_takeownership).

[OC] Ok, I will test that.


I have a problem.
When Trusted Execution is deactivated on BIOS , kvm run normally.
But when I activate TXT, the module load failed (Error: Operation not
supported).
In the kernel log, I have :"kvm: disable by bios"

Is there a conflict between TXT and KVM?

[JC]  This is a security feature.  When you enabled both TXT and VT,
BIOS set the bit in the IA32_FEATURE_CONTROL MSR that means that VT can
only be used after a TXT launch has occurred.  This is to prevent
installation of malicious VT-based rootkits.  If you want to use VT w/o
doing a TXT launch, disable TXT in BIOS and leave VT enabled.

[OC] Ok, I will contact KVM to know if they will support TXT like XEN.
There is two part for this support:
- Intel => be able to launch KVM 
- KVM => not use the E820 unusable memory
That's right ?

[JC2]  We are currently working on support tboot for Linux, which will give us KVM support as well.  We have all of the code working and are going through a Linux code patch review before posting to LKML.

Thank you
Olivier,

-------------------------------------------------------------------------
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

[tboot-devel] RE : TXT and kvm : conflict ?

[Courtay O. <Oli...@th...>]

Hello,

my response bellow quoted by [OC]

-----Original Message-----
From: tbo...@li...
[mailto:tbo...@li...] On Behalf Of Courtay
Olivier
Sent: Wednesday, September 10, 2008 5:57 AM
To: tbo...@li...
Subject: [tboot-devel] TXT and kvm : conflict ?

Hello,

I have successfully installed tboot on a Dell Optiplex 755 (E8500).
VMM and dom0 verification is OK.

One question.
In TBOOT log I have:

TBOOT: dom0 is verified.
TBOOT: succeeded.
TBOOT: invalid module #

What is this invalid module ?

[JC]  Older versions of tboot displayed this during policy processing,
even though there was not an error.  What changeset are you using?

[OC] Ok, I use the tboot-20080613. I can provide log of my TBOOT if you want.

 
I have not yet tested sealed process.

[JC]  FYI, your TPM will need to have an owner and you should have
created the SRK with the null auth (use '-z' flag to tpm_takeownership).

[OC] Ok, I will test that.


I have a problem.
When Trusted Execution is deactivated on BIOS , kvm run normally.
But when I activate TXT, the module load failed (Error: Operation not
supported).
In the kernel log, I have :"kvm: disable by bios"

Is there a conflict between TXT and KVM?

[JC]  This is a security feature.  When you enabled both TXT and VT,
BIOS set the bit in the IA32_FEATURE_CONTROL MSR that means that VT can
only be used after a TXT launch has occurred.  This is to prevent
installation of malicious VT-based rootkits.  If you want to use VT w/o
doing a TXT launch, disable TXT in BIOS and leave VT enabled.

[OC] Ok, I will contact KVM to know if they will support TXT like XEN.
There is two part for this support:
- Intel => be able to launch KVM 
- KVM => not use the E820 unusable memory
That's right ?

Thank you
Olivier,

Re: [tboot-devel] TXT and kvm : conflict ?

[Cihula, J. <jos...@in...>]

Below:

-----Original Message-----
From: tbo...@li...
[mailto:tbo...@li...] On Behalf Of Courtay
Olivier
Sent: Wednesday, September 10, 2008 5:57 AM
To: tbo...@li...
Subject: [tboot-devel] TXT and kvm : conflict ?

Hello,

I have successfully installed tboot on a Dell Optiplex 755 (E8500).
VMM and dom0 verification is OK.

One question.
In TBOOT log I have:

TBOOT: dom0 is verified.
TBOOT: succeeded.
TBOOT: invalid module #

What is this invalid module ?

[JC]  Older versions of tboot displayed this during policy processing,
even though there was not an error.  What changeset are you using?

 
I have not yet tested sealed process.

[JC]  FYI, your TPM will need to have an owner and you should have
created the SRK with the null auth (use '-z' flag to tpm_takeownership).

I have a problem.
When Trusted Execution is deactivated on BIOS , kvm run normally.
But when I activate TXT, the module load failed (Error: Operation not
supported).
In the kernel log, I have :"kvm: disable by bios"

Is there a conflict between TXT and KVM?

[JC]  This is a security feature.  When you enabled both TXT and VT,
BIOS set the bit in the IA32_FEATURE_CONTROL MSR that means that VT can
only be used after a TXT launch has occurred.  This is to prevent
installation of malicious VT-based rootkits.  If you want to use VT w/o
doing a TXT launch, disable TXT in BIOS and leave VT enabled.

Thank you.

Olivier

------------------------------------------------------------------------
-
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

[tboot-devel] TXT and kvm : conflict ?

[Courtay O. <Oli...@th...>]

Hello,

I have successfully installed tboot on a Dell Optiplex 755 (E8500).
VMM and dom0 verification is OK.

One question.
In TBOOT log I have:

TBOOT: dom0 is verified.
TBOOT: succeeded.
TBOOT: invalid module #

What is this invalid module ?

I have not yet tested sealed process.

I have a problem.
When Trusted Execution is deactivated on BIOS , kvm run normally.
But when I activate TXT, the module load failed (Error: Operation not supported).
In the kernel log, I have :"kvm: disable by bios"

Is there a conflict between TXT and KVM?

Thank you.

Olivier

Re: [tboot-devel] Nehalem and TXT roadmap

[Cihula, J. <jos...@in...>]

Martin,

 

Intel(r) TXT is one of the component of the vPro(tm) brand, beginning
with this year's client platforms.  So any vPro client (mobile or
desktop) this year will have TXT.  We did not have any TXT-specific
sessions at this Fall's IDF, though we did have a panel discussion on
Trusted Computing, which included a lot of discussion about TXT.

 

As the '08 vPro platforms are not yet available, the only ones that
support TXT now are the Weybridge-based (Q35/X38 Express chipset)
systems.  Both the new mobile and desktop chipsets (codenames Cantiga
and Eaglelake; not sure what their official names will be) that will
come out in a few months will support TXT.

 

You are right that TXT requires a TPM on the platform.  The TPM could
either be discrete (a separate part as currently used) or integrated.
The new chipsets will include an integrated TPM, though it is up to the
system manufacturer to decided whether to enable it.

 

Joe

 

From: tbo...@li...
[mailto:tbo...@li...] On Behalf Of Martin
Thiim
Sent: Sunday, August 24, 2008 6:31 AM
To: tbo...@li...
Subject: [tboot-devel] Nehalem and TXT roadmap

 

Hello,

 

Unfortunately I wasn't able to attend the IDF but I understand there was
a lot of talk about Nehalem. Was there any talk about TXT in this
context? Is TXT supported by Nehalem and is there any enhancements to
the technology? Also, what chipsets supports TXT and does Intel plan to
ship any motherboards with those chipsets equipped for TXT? I suppose
the latter would be with a TPM onboard although there have been rumours
that future Intel chipsets will feature integrated TPM's (however it is
easy to see how a journalist could confuse chipset support for TXT/TPM
with an integrated TPM).

Perhaps some of the people from Intel could reveal a bit about Intel's
"roadmap" for TXT, both from the hardware and software side of things.
Thanks! :)

 

 

Best regards,

 

Martin Thiim

[tboot-devel] Nehalem and TXT roadmap

[Martin T. <ma...@th...>]

Hello,

Unfortunately I wasn't able to attend the IDF but I understand there was a
lot of talk about Nehalem. Was there any talk about TXT in this context? Is
TXT supported by Nehalem and is there any enhancements to the technology?
Also, what chipsets supports TXT and does Intel plan to ship any
motherboards with those chipsets equipped for TXT? I suppose the latter
would be with a TPM onboard although there have been rumours that future
Intel chipsets will feature integrated TPM's (however it is easy to see how
a journalist could confuse chipset support for TXT/TPM with an integrated
TPM).
Perhaps some of the people from Intel could reveal a bit about Intel's
"roadmap" for TXT, both from the hardware and software side of things.
Thanks! :)


Best regards,

Martin Thiim

Re: [tboot-devel] Enabling TXT causes panic

[Cihula, J. <jos...@in...>]

Can you please post your dmesg log.  I will try to reproduce it on my
system.

Joe

-----Original Message-----
From: tbo...@li...
[mailto:tbo...@li...] On Behalf Of John Hu
Sent: Thursday, August 14, 2008 2:11 PM
To: tbo...@li...
Subject: [tboot-devel] Enabling TXT causes panic

After upgrading to BIOS version 942 on the DQ35JO motherboard with a
Q9450, I'm running into problems even booting stock Ubuntu Linux. If
TXT is disabled everything works fine, but enabling TXT in the BIOS
causes Linux to panic during boot (in mwait_idle). Anyone else run
into this and know a workaround? I have TPM, VT, and VT-d enabled in
both instances.

John

------------------------------------------------------------------------
-
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

[tboot-devel] Enabling TXT causes panic

[John H. <joh...@gm...>]

After upgrading to BIOS version 942 on the DQ35JO motherboard with a
Q9450, I'm running into problems even booting stock Ubuntu Linux. If
TXT is disabled everything works fine, but enabling TXT in the BIOS
causes Linux to panic during boot (in mwait_idle). Anyone else run
into this and know a workaround? I have TPM, VT, and VT-d enabled in
both instances.

John

Re: [tboot-devel] Buying a machine that will actually work with TXT

[Martin T. <ma...@th...>]

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
>

Re: [tboot-devel] Buying a machine that will actually work with TXT

[Hal F. <hal...@gm...>]

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

Re: [tboot-devel] Buying a machine that will actually work with TXT

[Mike H. <mi...@pl...>]

> 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

Re: [tboot-devel] Buying a machine that will actually work with TXT

[Cihula, J. <jos...@in...>]

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

Re: [tboot-devel] Buying a machine that will actually work with TXT

[Hal F. <hal...@gm...>]

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

Re: [tboot-devel] Buying a machine that will actually work with TXT

[Mike H. <mi...@pl...>]

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 ;)

Re: [tboot-devel] Buying a machine that will actually work with TXT

[Martin T. <ma...@th...>]

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.
> >
> >
>

Re: [tboot-devel] Buying a machine that will actually work with TXT

[Mike H. <mi...@pl...>]

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.

Re: [tboot-devel] Buying a machine that will actually work with TXT

[Martin T. <ma...@th...>]

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
>

Re: [tboot-devel] Buying a machine that will actually work with TXT

[Cihula, J. <jos...@in...>]

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

Re: [tboot-devel] Buying a machine that will actually work with TXT

[Mike H. <mi...@pl...>]

> 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.

Re: [tboot-devel] Buying a machine that will actually work with TXT

[Cihula, J. <jos...@in...>]

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

Re: [tboot-devel] Buying a machine that will actually work with TXT

[Hal F. <hal...@gm...>]

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
>
>

[tboot-devel] Buying a machine that will actually work with TXT

[Mike H. <mi...@pl...>]

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

Re: [tboot-devel] Developer guide typos

[Jun K. <jun...@gm...>]

And on section D.3.1 (page 80), "LCP_POLICY_RECORD" should be read
"LCP_POLICY_LIST", rite?

Jun


On 6/16/08, Jun Koi <jun...@gm...> wrote:
> Hi,
>
>  I took a look, and found some typos in the Developer Guide. They
>  should be fixed in the next revision. See below:
>
>  Page 25 (section 2.2.4.3):
>     "Line 2-6" should be "Line 2-7"
>     "Line 7" should be "Line 8"
>
>  Page 26:
>     "Line 8" should be "Line 9"
>     "Line 9" should be "Line 10"
>     "Line 10" should be "Line 11"
>
>
>  Thanks,
>
> Jun
>

[tboot-devel] Developer guide typos

[Jun K. <jun...@gm...>]

Hi,

I took a look, and found some typos in the Developer Guide. They
should be fixed in the next revision. See below:

Page 25 (section 2.2.4.3):
    "Line 2-6" should be "Line 2-7"
    "Line 7" should be "Line 8"

Page 26:
    "Line 8" should be "Line 9"
    "Line 9" should be "Line 10"
    "Line 10" should be "Line 11"


Thanks,
Jun