OT - Trusted Boot project in F16

[夜神 岩男]

On Thu, 2011-06-23 at 05:54 -0700, Joe Wulf wrote:
> Awesome post, JB.  Way cool.
> 
> Um another question come to mind, like, will such an OS still boot/work on Intel 
> (and AMD?) CPUs, say older ones, that don't have the TPM?
> 
> R,
> -Joe Wulf

TL;DR: Don't panic.

Some enlightening posts by Eric Paris which cover down on most folks'
primary concerns:

A broadish overview in response to the original post:
http://lists.fedoraproject.org/pipermail/devel/2011-June/153329.html

A response which covers the specific question about hardware that
doesn't support TXT/tboot asked at the beginning of this thread:
http://lists.fedoraproject.org/pipermail/devel/2011-June/153331.html

A post revealing a bit more about how non-essential this feature is from
the host system's perspective (in other words, why it will not affect
your self-rolled or alternative kernels & initrd images):
http://lists.fedoraproject.org/pipermail/devel/2011-June/153330.html

After a bit of looking (I was very concerned after reading the first
post) it seems this feature is primarily focused on providing
information to satisfy an external "trusted system y/n" type query by
matching a known kernel image hash which is expected by the requestor.
At the feature level it seems there isn't really any change other than
permitting trusted hardware to perform the hash check and verification.
If the hardware doesn't support the feature, tboot just doesn't run and
the system boots normally, if the feature is supported a hash is made of
the kernel image (regardless what the outcome is, in other words your
own kernels producing a different hash will boot normally, just having a
hash having been made silently somewhere) and the hash is stored to be
used upon request later without the user having to be involved.

So as a feature it seems it won't really change the user experience,
even for homebrewers.

If this is the way things are, this feature can be implemented unnoticed
by the user, hence the lack of major discussion on the user list. On the
other hand it will involve a lot of reworking on grubby to implement,
hence the need for a discussion on the devel list to determine of the
effort is worth it or not (it seems this is what the question is really
for).

-Iwao

PS: I have questions about this feature, but at this point they are
mostly on the level of "how is it guaranteed to be secure without a
third-party check against the hardware". The answer must be pretty
fascinating because I have yet to see a piece of "secure hardware" that
doesn't rely on third-party verification -- and the hardware function
can always be emulated in software which seems to at least partially
undermine the integrity of the check -- which is the whole point of the
feature. So technically I am intrigued to see if this really is secure
and how it works.