When we looked in on Fedora's decision on
boot" a little over a year ago, the consensus seemed to be that
adding a feature that depended on a closed-source binary firmware blob ran
counter to the distribution's goals. Since then, that blob is in the
process of being added
into the BIOS of various systems—though it remains closed—and
the "tboot" (trusted boot hypervisor) package has been added to
Fedora. Those changes
might make it more attractive for Fedora to provide a way for users to enable it at
install time. But there is still resistance
to adding the feature, and it didn't make the cut for Fedora 16. It seems
likely to come up again for Fedora 17 or beyond, so it may well make its
way into the
distribution sooner or later.
Trusted boot is a way to use the Trusted Platform Module (TPM) hardware
that comes in many systems to only boot signed binaries. The
fear is that it will enable hardware vendors to lock down their
systems—by requiring binaries signed by their keys in order to
boot—but it could also be used to protect against various kinds of
malware. As with any hardware-based integrity scheme, it all
depends on who holds the keys.
Matthew Garrett opened the discussion on
fedora-devel, pointing to a proposed
feature on the Fedora wiki. That wiki page is fairly thin on details,
which is one of the things that sunk the proposal this time, but it
essentially proposes changing the anaconda installer to allow users to
choose trusted boot and to provide a way to change the GRUB configuration
to support it.
One of the first questions was about the benefit of the feature to Fedora.
Camilo Mesias asked about the use cases for
trusted boot. Daniel Walsh listed a number
The idea is to allow certain tools/machines to make judgments on how
"trusted" a machine is. For example you could set up a VPN server that
says I will only allow a machine that passes the "Trusted" test to join
my network. Another potential example would be to not allow a guest
machine to run on your host if its OS is not "Trusted" Or to have a
guest OS check to see if the Host Server is Trusted or stop running.
Several of those use cases rely on the "remote attestation" feature of
trusted boot, which means that a suitably configured system that has the
"proper" keys stored in the TPM can provide a signed cryptographic hash
corresponding to the kernel in use. There was some confusion in the thread
remote attestation means, but, beyond that, there are concerns that it
could be used to thwart users installing their own kernel, even on
free software OSes. As Gregory Maxwell put
If trusted boot in fedora is widely deployed, then $random_things may
demand I use a particular fedora kernel in order to access them. Both
[handicapping] my personal freedom to tinker with my own computer by
imposing new costs on it, and hampering the Fedora project by creating
additional friction against upgrades.
("Sorry, I can't upgrade to the new kernel to test that, because then
I won't be able to watch netflicks!")
A bigger problem might be that services start requiring some proprietary OS, rather
than a particular Fedora kernel. That would, of course, suit the
proprietary OS vendors just fine. But that could happen regardless of what
Fedora does. If requiring a Fedora kernel is important, services can
require that only approved kernels be used and require that users enable
trusted boot in order to access them. The more likely outcome under that
would leave Fedora
(and other Linux distributions) out in the cold, of course.
While the closed-source nature of the SINIT blob (aka SINIT AC), which is
the code that does the low-level integrity checking, worries
some, Intel is evidently adamant that the code remains closed. From a
practical standpoint, having the code wouldn't do much for users, as
Miloslav Trmač points out:
The purpose of the blob is to "measure" the system state; only the
blob (and hardware reset) is allowed to restart the "measuring"
process in the TPM. For this to work securely, the blob must be
signed by someone that the TPM itself trusts - otherwise an attacker
could replace the blob by something that lies about the system state.
So, from a standpoint of hacking, it doesn't matter - users won't have
the practical freedom to modify the blob anyway because they can't
From a standpoint of learning/sharing/review - I agree having the
source code would be very useful.
As was noted in the thread, we are already largely at the mercy of the
hardware and BIOS vendors with respect
to the code that runs on our systems.
The relatively recent System
Management Mode (SMM) additions to the BIOS are just one example. As Adam
Williamson put it:
Well, the fact that BIOSes aren't open source means that anyway. As far
as we the users are concerned, the BIOS is black box code which runs
with the ultimate in administrative privileges. It could be doing
_anything_ back there. SMM is a fairly standardized example of this,
sure, but there's no way we can really be sure our BIOS isn't doing a
zillion other 'bad things'.
But, the presence of Intel signing keys stored in the TPM, which is
required to verify the SINIT blob, may lead to some worrisome restrictions.
Björn Persson points out that there are
alternative, free software BIOS
implementations (e.g. Coreboot), but that it may be impossible to replace
I have never dared to try Coreboot
myself, for fear of destroying my motherboard, but in principle it's possible
to replace the BIOS in most current computers with a free implementation. It's
looking like the TPM makes it impossible to replace Sinit with a free
Aside from the technical issues, and concerns, the actual feature request
on the wiki didn't provide a whole lot of information about how the feature
would be used, and how it would be integrated into the Fedora install and
boot processes. What facilities would be present for remote attestation,
how they could be disabled by users, and what happens when a user tries to
boot an "untrusted" kernel are all left up in the air in the
feature proposal. It also didn't provide much in the way of justification
for why trusted boot would be useful to Fedora users. It is clear to some
could be useful, if users could create and install their own keys,
but the wiki page didn't really make that clear. That led to several
requests for more information to be added to the feature request.
The Fedora Engineering Steering Committee (FESCo) took up the request at
its June 27 meeting. The discussion in the
log of the meeting paralleled that of the mailing list to some extent.
The FESCo members seemed a bit puzzled by what exactly was being
proposed—and why it would be useful. As Kevin Fenzi (aka nirik)
said: "I think there's cool things we could use this for, but 'enable it now so we can do ~wave hands~ later' seems non ideal. Why not set it up to do something our users care about and _then_ enable it."
There was also some discussion of which pieces of Fedora needed changing
(anaconda and grubby being two obvious places that might require
modification). But the overall sense was that there just wasn't enough
meat in the proposal to add it as a Fedora feature. Fenzi is optimistic
that it could be done right for Fedora users, but it needs to be fleshed
Setup ways to check the fedora provided kernels. Offer users a way to not
boot on problems. Offer users a way to let them attest or decline to attest
that it was a valid boot. Allow users to load their policy or change
it. etc, the control should be in the users hands, and if this is a feature
we should be providing the users those tools.
So FESCo decided to decline the feature for Fedora 16, but agreed that
parties should continue working on it for possible inclusion down the road.
Any work that is done in anaconda, grubby, or elsewhere will have to be
negotiated between the trusted boot proponents and the other projects, as
there is no FESCo mandate for the feature. It would not be surprising to
see this feature come up again in six months or a year.
The TPM and "trusted computing" (aka "treacherous computing") evoke strong
reactions. While it is clear that they can be used in ways that
essentially lock users out of their own hardware, they could also be used
in ways that allow users to ensure the integrity of the code running on
those same systems. Like many technologies, trusted boot can be used for
good or ill.
If Fedora can provide ways for its users to take advantage of this
technology, without being taken advantage of, it will definitely be
something that some security-conscious users will benefit from. Intel's
secrecy with regard to the SINIT blob is somewhat troubling, but doesn't
change the closed-source BIOS problem all that much really. A bigger
problem for Fedora down the road may be trying to support users who enable
the feature but run into problems getting their Fedora (or custom-built)
kernels to boot. But, that's a problem for another day.
to post comments)