Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-dev
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-dev@g.o
From: Florian Philipp <lists@...>
Subject: Re: UEFI secure boot and Gentoo
Date: Fri, 15 Jun 2012 09:49:01 +0200
Am 15.06.2012 09:26, schrieb Michał Górny:
> On Thu, 14 Jun 2012 21:56:04 -0700
> Greg KH <gregkh@g.o> wrote:
> 
>> On Fri, Jun 15, 2012 at 10:15:28AM +0530, Arun Raghavan wrote:
>>> On 15 June 2012 09:58, Greg KH <gregkh@g.o> wrote:
>>>> So, anyone been thinking about this?  I have, and it's not pretty.
>>>>
>>>> Should I worry about this and how it affects Gentoo, or not worry
>>>> about Gentoo right now and just focus on the other issues?
>>>
>>> I think it at least makes sense to talk about it, and work out what
>>> we can and cannot do.
>>>
>>> I guess we're in an especially bad position since everybody builds
>>> their own bootloader. Is there /any/ viable solution that allows
>>> people to continue doing this short of distributing a first-stage
>>> bootloader blob?
>>
>> Distributing a first-stage bootloader blob, that is signed by
>> Microsoft, or someone, seems to be the only way to easily handle this.
> 
> Maybe we could get one such a blob for all distros/systems?
> 

I guess nothing prevents you from re-distributing Fedora's blob.

> Also, does this signature system have any restrictions on what is
> signed and what is not? In other words, will they actually sign a blob
> saying 'work-around signatures' on the top?
> 

They might sign it. I think it is just an automated process verified
with smartcards. The point is, they will also blacklist it as soon as
malware starts using it (or as soon as they are aware of the possibility).

It should also be noted that having a bootloader blob is not enough. You
have to do it like Fedora and sign the kernel and modules as well as
removing kernel features that could result in security breaches
(everything outlined in [1]). I don't see any reasonable way to do this
while allowing users to build their own kernel and third-party modules.

In the end, I think we'll need *-bin packages for everything running in
kernel-space.

[1] http://mjg59.dreamwidth.org/12368.html

Regards,
Florian Philipp

Attachment:
signature.asc (OpenPGP digital signature)
Replies:
Re: UEFI secure boot and Gentoo
-- Greg KH
Re: UEFI secure boot and Gentoo
-- Richard Farina
References:
UEFI secure boot and Gentoo
-- Greg KH
Re: UEFI secure boot and Gentoo
-- Arun Raghavan
Re: UEFI secure boot and Gentoo
-- Greg KH
Re: UEFI secure boot and Gentoo
-- Michał Górny
Navigation:
Lists: gentoo-dev: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: UEFI secure boot and Gentoo
Next by thread:
Re: UEFI secure boot and Gentoo
Previous by date:
Re: ebuild laziness and binpkg overhead
Next by date:
Re: ebuild laziness and binpkg overhead


Updated Jun 29, 2012

Summary: Archive of the gentoo-dev mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.