Trusted Boot in Fedora

[Eric Paris]

On 06/22/2011 03:02 PM, Matthew Garrett wrote:
> http://fedoraproject.org/wiki/Features/Trusted_Boot is a proposed 
> feature for F16. We've traditionally had a hard objection to the 
> functionality because it required either the distribution or downloading 
> of binary code that ran on the host CPU, but it seems that there'll 
> shortly be systems that incorporate the appropriate sinit blob in their 
> BIOS, which is a boundary we've traditionally been fine with.

Such systems supposedly exist today.  I haven't tested them, but I
believe a number of the newer Dell systems already have the required
northbridge code in flash.  tboot will use the binary northbridge setup
blob that may be passed to it or it will try to use any blobs built into
the flash if it isn't given a blob by grub.  In the case that it doesn't
have the magic blob needed to set up the CPU and northbridge it just
won't execute the magic SENTER instruction.  magic!

> However, this is the kind of feature that has a pretty significant 
> impact on the distribution as a whole.

I actually think this is completely wrong.  It shouldn't have ANY distro
wide impact at all.

> Fesco decided that we should 
> probably have a broader discussion about the topic. The most obvious 
> issues are finding a sensible way to incorporate this into Anaconda, but 
> it's also then necessary to make sure that bootloader configuration is 
> updated appropriately.

Agreed.  These are exactly the parts that they need to do development.
Anaconda shouldn't really need changes, tboot is just a package that
needs installed.  I'm not sure why that's even a part of the feature
request.  If anaconda creates the initial grub.conf it might need some
work but that is the same issue as the next question.  Grubby is what
needs discussion and new code.  It will need to detect tboot is
installed and handle new grub type entries correctly.  I haven't seen
any code for this, but handling new formats of grub entries is what is
really needed here.

> Outside that, is there any other impact?

There shouldn't be.  Mind you if you want this to be useful for
something it's going to take more steps and layers on top, but just
booting into a measured launch environment should require no other steps.

> Does tboot perform any 
> verification of the kernels, and if so how is that configured?

tboot does no such thing.  By default tboot and the Intel Trusted
Execution Technology do nothing but measure and record information in a
reliable, immutable, verifiable way.  If one were to create and install
a launch control policy into their own TPM (using the lcp tools) then
that policy would be enforced at boot.  But this is not and should not
be a part of this feature request.  The TPM key management required to
update the lcp on kernel update just doesn't exist today in a practical
way.  Instead what we get from this is that tboot will 'measure', aka
take a cryptographic hash of the kernel and initrd, and put those into
the TPM before it launches the kernel.  Thus after the kernel starts
there is a method to verify that the hardware was in a known safe state
and to verify what the kernel's hash was at launched.

> Is the 
> expectation that an install configured with TXT will only boot trusted 
> kernels,

NO NO NO NO NO.  ANY mechanism that prevents users from using their own
system will require MANUAL intervention on the part of the user.  It's
possible to build such a box yourself, but If such a change is ever
suggested it should (and will be immediately by me) rejected.

> and if so what mechanism is used to verify the kernel?

tboot + the Intel Trusted Execution Technology hardware are what's used
to measure and launch the kernel.  If a launch control policy is
configured it will be used to decide if such a kernel should be
launched.  But there is NO way we should (or even could) EVER
automatically create an lcp.

> Is there 
> any further integration work that has to be performed for this to be 
> useful?

So much you cannot imagine  :)  At the moment they are just try to get a
system which is capable of measuring itself.  We already have kernel
functionality which can measure any files being accessed, but we have no
way to know what kernel was launched?  What good is a list of files if
you can't trust the guy creating that list?  This gets us that last
step, we have a way to know the state of the system and the
cryptographic hash representing the contents of the kernel (and initrd)
which was launched.  We don't have a way to USE this data.  Red Hat has
some long term goals on how to use this functionality in the enterprise
and the gov't has some ideas how to use it in their super secret
intelligence world.

Nothing about this should be a default.  Nothing about this should
affect users who don't turn it on.  Nothing about this should lock
people out of their own computers.

Does this help?

-Eric