*countable infinities only

Seth Johnson seth.p.johnson at gmail.com
Mon Jun 25 22:29:51 UTC 2012


On Mon, Jun 25, 2012 at 2:48 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Mon, Jun 25, 2012 at 2:37 PM, Chris Murphy <lists at colorremedies.com> wrote:
>> I'm reading they're going to use a modified Intel efilinux, not writing a new boot loader. And that they will not require either signed kernel or kernel modules.
>
> Thats my understanding.
>
>> So what's the point of Secure Pre-Boot?
>
> Making Ubuntu work on the hardware people have. Which is the
> justification given here why Fedora needed to adopt crytographic
> signing of the kernel/drivers/etc.
>
> I think this all would have been a much simpler matter if it wasn't
> being described as essential for keeping Fedora operable on the
> computers of the common folk.
>
> Of course, users who want more aggressive secureboot would be free to
> replace the keys in their system with ones which only sign bootloaders
> which are more thoroughly locked down…  but I don't see evidence of
> the demand. (can you point to some?)


It would appear that right now, it's a matter of a political
necessity, unforeseen by the general population, though vaguely
bugging the free software development community.

I would agree there's not much demonstrated demand, but if we wait til
the worst apprehensions come true, we will be at a disadvantage.  The
general population does not experience the problem that free software
developers can more readily anticipate.


>> I think for at least 9 months now the idea of a strictly pre-boot implementation of Secure Boot is possible, but meaningless to the point of "WTF, why bother?" with the effort required. It's like building a bridge that's 80% complete, and therefore 100% useless.
>
> And the kernel hands off control to a init/systemd which is unsigned—
> which can be rooted and exploit a vulnerable kernel to prevent
> updates.  It's like building a bridge that is _10%_ complete, and
> therefore 100% useless. :)
>
> … the amount of critical userspace code that runs before updates can
> be processed is enormous and the kernel and bootloader is just a tiny
> fraction of that.  Why not build the 100% bridge that actually
> provides a remotely secured platform? Because it's incompatible with
> software freedom.

I don't see this.  If you choose an authority and can put their keys
into your own box, then you're good until that authority is
compromised.  This, if I am tracking this correctly, is the
infrastructure part of the solution.  You just have to get out in
front with the trusted authority.  I would think that if FSF provided
keys, that would be pretty trustworthy, though for the following
reason I actually don't think they should be out front with this part,
because they would clearly be targetted, and we wouldn't want that to
happen until there was a developed market in trust authorities.  It
would not, of course, assure that all "content" and code could be
processed freely, but it would create the context in which we could
demonstrate that the authorities that provide palladiated "content"
and code are restricting people's capacity to compute.  Keep up
providing authorities that assure software freedom -- do the whack a
mole bit if necessary -- and that context will be the context that
demonstrates to the people at large that there are people out there
that have truly fully-functional computers and they want to have that
too.

This is not inconsistent with software freedom. You're going to have a
root key.  If it's your own, you can't do much unless you buy into the
englobulators' signing regime; if you want to do more, you have to
create some sort of collaborative context that uses a common trusted
key.  We might have lots of little groups like that, but they will not
be able to stand up against the political norms we can easily
anticipate being established if we do not come to terms with how to
make software freedom viable while using Secure Boot our own selves.
So to me that clearly indicates a *political* need for developers who
want to keep their freedom, to get out in front and *create* a market
in trusted authorities.  If your idea of software freedom is
decentralized in some sort of resolutely individualistic way, you'll
be locked out by the larger forces.  That's why it's necessary to get
out in front ad establish the infrastructure, and get people offering
lots of trust authorities, start trying to conceptualize that market
and how and whether it would be competitive.

This is the way I see the situation; I feel that I step a bit beyond
my expertise or comprehension as I describe it, so somebody please
tell me if my conception misses anything.  I defer to Jay usually for
this very reason.  So have at it: let me know what you see when you
see me explain this piece of the puzzle.  :-)


Seth


> Central control is Microsoft's strength, not
> Fedora's.
> --
> devel mailing list
> devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel


More information about the devel mailing list