[gentoo-dev] UEFI secure boot and Gentoo

[gentoo-dev] UEFI secure boot and Gentoo

[Greg KH]

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?

Minor details like, "do we have a 'company' that can pay Microsoft to
sign our bootloader?" is one aspect from the non-technical side that I've
been wondering about.

thanks,

greg k-h

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Arun Raghavan]

On 15 June 2012 09:58, Greg KH <gregkh@gentoo.org> 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?

> Minor details like, "do we have a 'company' that can pay Microsoft to
> sign our bootloader?" is one aspect from the non-technical side that I've
> been wondering about.

Sounds like something the Gentoo Foundation could do.
-- 
Arun Raghavan
http://arunraghavan.net/
(Ford_Prefect | Gentoo) & (arunsr | GNOME)

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Greg KH]

On Fri, Jun 15, 2012 at 10:15:28AM +0530, Arun Raghavan wrote:
> On 15 June 2012 09:58, Greg KH <gregkh@gentoo.org> 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.

Although all BIOSes will have the option to turn secure boot off, I
think it is something that we might not want to require for Gentoo to
work properly on those machines.

Also, some people might really want to sign their own bootloader and
kernel, and kernel modules (myself included), so just getting that basic
infrastructure in place is going to take some work, no matter who ends
up signing the first-stage bootloader blob.

Oh, and on the first-stage bootloader front, I already know of 2 simple,
and open source, examples that will work for Linux, so getting something
like that signed might not be very tough.  It's the "where does the
chain-of-trust stop" question that gets tricky...

> > Minor details like, "do we have a 'company' that can pay Microsoft to
> > sign our bootloader?" is one aspect from the non-technical side that I've
> > been wondering about.
> 
> Sounds like something the Gentoo Foundation could do.

Can they do that?  I haven't been paying attention to if we are really a
legal entity still or not, sorry.

greg k-h

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Arun Raghavan]

On 15 June 2012 10:26, Greg KH <gregkh@gentoo.org> wrote:
> On Fri, Jun 15, 2012 at 10:15:28AM +0530, Arun Raghavan wrote:
>> On 15 June 2012 09:58, Greg KH <gregkh@gentoo.org> 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.
>
> Although all BIOSes will have the option to turn secure boot off, I
> think it is something that we might not want to require for Gentoo to
> work properly on those machines.
>
> Also, some people might really want to sign their own bootloader and
> kernel, and kernel modules (myself included), so just getting that basic
> infrastructure in place is going to take some work, no matter who ends
> up signing the first-stage bootloader blob.

I hadn't thought of that. I imagine the hardened team might be
interested in making such infrastructure easily available as well.

> Oh, and on the first-stage bootloader front, I already know of 2 simple,
> and open source, examples that will work for Linux, so getting something
> like that signed might not be very tough.  It's the "where does the
> chain-of-trust stop" question that gets tricky...

For validating the chain of trust, it might be useful to make it
possible for anyone to generate the same bootloader and verify the
hashes themselves. For the truly paranoid maybe a signed stage3 +
portage snapshot to generate the bootloader image from scratch.

>> > Minor details like, "do we have a 'company' that can pay Microsoft to
>> > sign our bootloader?" is one aspect from the non-technical side that I've
>> > been wondering about.
>>
>> Sounds like something the Gentoo Foundation could do.
>
> Can they do that?  I haven't been paying attention to if we are really a
> legal entity still or not, sorry.

I believe so, but quantumsummers is likely the best person to confirm.

-- 
Arun Raghavan
http://arunraghavan.net/
(Ford_Prefect | Gentoo) & (arunsr | GNOME)

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Matthew Thode]

[-- Attachment #1: Type: text/plain, Size: 2791 bytes --]

On 06/15/2012 12:24 AM, Arun Raghavan wrote:
> On 15 June 2012 10:26, Greg KH <gregkh@gentoo.org> wrote:
>> On Fri, Jun 15, 2012 at 10:15:28AM +0530, Arun Raghavan wrote:
>>> On 15 June 2012 09:58, Greg KH <gregkh@gentoo.org> 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.
>>
>> Although all BIOSes will have the option to turn secure boot off, I
>> think it is something that we might not want to require for Gentoo to
>> work properly on those machines.
>>
>> Also, some people might really want to sign their own bootloader and
>> kernel, and kernel modules (myself included), so just getting that basic
>> infrastructure in place is going to take some work, no matter who ends
>> up signing the first-stage bootloader blob.
> 
> I hadn't thought of that. I imagine the hardened team might be
> interested in making such infrastructure easily available as well.
> 
>> Oh, and on the first-stage bootloader front, I already know of 2 simple,
>> and open source, examples that will work for Linux, so getting something
>> like that signed might not be very tough.  It's the "where does the
>> chain-of-trust stop" question that gets tricky...
> 
> For validating the chain of trust, it might be useful to make it
> possible for anyone to generate the same bootloader and verify the
> hashes themselves. For the truly paranoid maybe a signed stage3 +
> portage snapshot to generate the bootloader image from scratch.
> 
>>>> Minor details like, "do we have a 'company' that can pay Microsoft to
>>>> sign our bootloader?" is one aspect from the non-technical side that I've
>>>> been wondering about.
>>>
>>> Sounds like something the Gentoo Foundation could do.
>>
>> Can they do that?  I haven't been paying attention to if we are really a
>> legal entity still or not, sorry.
> 
> I believe so, but quantumsummers is likely the best person to confirm.
> 
I've already taken a look at some of this, I think our best bet is to
figure out how to use efi_stub and simply sign the kernel itself (since
it can run directly from uefi now).

-- 
-- Matthew Thode (prometheanfire)




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Eray Aslan]

[-- Attachment #1: Type: text/plain, Size: 933 bytes --]

On 2012-06-15 7:56 AM, Greg KH wrote:
> Distributing a first-stage bootloader blob, that is signed by Microsoft,
> or someone, seems to be the only way to easily handle this.

Fedora agrees:
http://mjg59.dreamwidth.org/12368.html

Other distros haven't decided yet afaik although there have been some
discussions.

> Also, some people might really want to sign their own bootloader and
> kernel, and kernel modules (myself included)

Yes, that is the goal we should try to achieve, i.e. to give the option
to our users to sign all the way to userland.

> Oh, and on the first-stage bootloader front, I already know of 2 simple,
> and open source, examples that will work for Linux, so getting something
> like that signed might not be very tough.  It's the "where does the
> chain-of-trust stop" question that gets tricky...

Exactly.  Do you have any concrete proposals?

-- 
Eray Aslan <eras@gentoo.org>


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 898 bytes --]

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1201 bytes --]

On Thu, 14 Jun 2012 21:56:04 -0700
Greg KH <gregkh@gentoo.org> wrote:

> On Fri, Jun 15, 2012 at 10:15:28AM +0530, Arun Raghavan wrote:
> > On 15 June 2012 09:58, Greg KH <gregkh@gentoo.org> 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?

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?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 2040 bytes --]

Am 15.06.2012 09:26, schrieb Michał Górny:
> On Thu, 14 Jun 2012 21:56:04 -0700
> Greg KH <gregkh@gentoo.org> wrote:
> 
>> On Fri, Jun 15, 2012 at 10:15:28AM +0530, Arun Raghavan wrote:
>>> On 15 June 2012 09:58, Greg KH <gregkh@gentoo.org> 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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Richard Farina]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/15/2012 03:49 AM, Florian Philipp wrote:
> Am 15.06.2012 09:26, schrieb Michał Górny:
>> On Thu, 14 Jun 2012 21:56:04 -0700
>> Greg KH <gregkh@gentoo.org> wrote:
>>
>>> On Fri, Jun 15, 2012 at 10:15:28AM +0530, Arun Raghavan wrote:
>>>> On 15 June 2012 09:58, Greg KH <gregkh@gentoo.org> 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.

Being all about choice I have to agree that as long as we have both bin
and normal kernels there is nothing wrong with that.  However, dear god,
with how many kernels we have won't this get really expensive really
fast?  Even just signing gentoo-sources and hardened-sources would cost
a fortune considering both change weekly if not daily. So that puts us
to signing just stable releases and damn users who want secure boot and
a recent kernel or need a custom patch?  This all seems like a huge step
in the wrong direction to me, at the very least the amount of effort for
this is near insurmountable in my eyes.

- -Zero

> 
> [1] http://mjg59.dreamwidth.org/12368.html
> 
> Regards,
> Florian Philipp
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJP2u0hAAoJEKXdFCfdEflKtPMP/3qpZ5klkvOnOfMm3anccpEm
Zlo8T28+VwEjqt8m0hq/fWNteu4PbvzagD/jFLXym/OEW3w0XDFC8HI/JzbRVicT
GAiv3s1zHV0yX/MzIeuSqDG+KnXJhuGige52Nxy2dyC8Ryq0kwOX90rHu2wXU8Z/
RQPuJgxf2Z34qBVNsZKHcH7caxcCUhHK+JmYwIE+hd4Y7vw1YjM49PAxLIQnhRvN
lEQJt8lhyHzOzI7eScbQEtWRlGBRL/mtIoEkJa3iQb84hO9yfgAmxW512kZ4u5ZJ
x8NVXaBPx6KmwdCugrryYNKMVSAUCvt08f2mPGOS2tyF3eFVcfUL3ZAzaN0Fdl+q
0nTgkq5LW0wwLB9woujuxrz949SL+g/JTH2clKZVQdwCX5w4Bt7KCeqKg6+eRhsB
+9JoBZ9RYbmLQF5S+gjOuo/71Zds1IKtZIOcWp1jOdktph7udcCEvwJeQbAkK5jP
rqT0jEhsTOy1RPIDBTXwLsV6/urKNCwit4nsoD+ZGHZ2GXL+OunheXJDFgfrGevD
5ownuPxa6WwLLtCd7S+6SgkcC65jamycs44IjKhoQXtsZUYOj6uBhlVIQymLFVsU
r/ZeiOAilxiSP9QwTtZAohsninXQwIGxPbhwTrGp765uzalQoWzoz/Bop3IXdMgU
jvY5FSvLQ9Da7RKrxC5W
=XcZB
-----END PGP SIGNATURE-----

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 3452 bytes --]

Am 15.06.2012 10:06, schrieb Richard Farina:
> On 06/15/2012 03:49 AM, Florian Philipp wrote:
>> Am 15.06.2012 09:26, schrieb Michał Górny:
>>> On Thu, 14 Jun 2012 21:56:04 -0700
>>> Greg KH <gregkh@gentoo.org> wrote:
>>>
>>>> On Fri, Jun 15, 2012 at 10:15:28AM +0530, Arun Raghavan wrote:
>>>>> On 15 June 2012 09:58, Greg KH <gregkh@gentoo.org> 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.
> 
> Being all about choice I have to agree that as long as we have both bin
> and normal kernels there is nothing wrong with that.  However, dear god,
> with how many kernels we have won't this get really expensive really
> fast?  Even just signing gentoo-sources and hardened-sources would cost
> a fortune considering both change weekly if not daily. So that puts us
> to signing just stable releases and damn users who want secure boot and
> a recent kernel or need a custom patch?  This all seems like a huge step
> in the wrong direction to me, at the very least the amount of effort for
> this is near insurmountable in my eyes.
> 
> -Zero
> 
> 
>> [1] http://mjg59.dreamwidth.org/12368.html
> 
>> Regards,
>> Florian Philipp
> 

No, it won't be expensive. Please read the link in my message on how
Fedora do it:

1. You pay 99$ *once* as a registration fee. After that, you can sign as
much as you want.

2. In order to avoid the hassle of the actual authentication process for
signing code, Fedora simply signs a stage-1 boot loader which then
verifies all further stages against a custom Fedora key. This key also
has to be secure but it means they can use their own, automated tool
chain for signing kernel and grub builds.

Regards,
Florian Philipp


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Greg KH]

On Fri, Jun 15, 2012 at 09:49:01AM +0200, Florian Philipp wrote:
> Am 15.06.2012 09:26, schrieb Michał Górny:
> > On Thu, 14 Jun 2012 21:56:04 -0700 Greg KH <gregkh@gentoo.org> wrote:
> >> On Fri, Jun 15, 2012 at 10:15:28AM +0530, Arun Raghavan wrote:
> >>> On 15 June 2012 09:58, Greg KH <gregkh@gentoo.org> 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.

Fedora's blob will not boot your unsigned-with-fedoras-key kernel, so
redistributing it will not help anyone :(

greg k-h

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 1479 bytes --]

Am 16.06.2012 01:59, schrieb Greg KH:
> On Fri, Jun 15, 2012 at 09:49:01AM +0200, Florian Philipp wrote:
>> Am 15.06.2012 09:26, schrieb Michał Górny:
>>> On Thu, 14 Jun 2012 21:56:04 -0700 Greg KH <gregkh@gentoo.org> wrote:
>>>> On Fri, Jun 15, 2012 at 10:15:28AM +0530, Arun Raghavan wrote:
>>>>> On 15 June 2012 09:58, Greg KH <gregkh@gentoo.org> 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.
> 
> Fedora's blob will not boot your unsigned-with-fedoras-key kernel, so
> redistributing it will not help anyone :(
> 

I meant along with Fedora's kernel, signed binary modules and so forth.
The whole kernel space.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] UEFI secure boot and Gentoo

[gregkh]

On Fri, Jun 15, 2012 at 09:26:07AM +0200, Michał Górny wrote:
> On Thu, 14 Jun 2012 21:56:04 -0700
> Greg KH <gregkh@gentoo.org> wrote:
> 
> > On Fri, Jun 15, 2012 at 10:15:28AM +0530, Arun Raghavan wrote:
> > > On 15 June 2012 09:58, Greg KH <gregkh@gentoo.org> 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?
> 
> 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?

It is uncertian at the moment what the requirements are, I'm trying to
nail this down.  But, in order to protect all other companies, I imagine
they are going to be pretty restrictive, otherwise it really makes no
sense at all to have this in the first place.

greg k-h

[gentoo-dev] Re: UEFI secure boot and Gentoo

[Duncan]

Arun Raghavan posted on Fri, 15 Jun 2012 10:15:28 +0530 as excerpted:

> 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?

As I said in my first reply, for x86/amd64 at least, MS is mandating a 
user-unlock option.  That would leave the bootloader fully unsigned, but 
it would let users keep building their own.

But for arm, last I read MS is mandating no-user-unlock. There, a signed 
blob first-stage bootloader is likely to be mandatory, tho in reality 
that platform has always lacked the user-end base standard support and 
flexibility of x86, so it's not like they're losing it.  But if the 
entire market moves toward arm as some are predicting...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Ben de Groot]

On 15 June 2012 12:45, Arun Raghavan <ford_prefect@gentoo.org> wrote:
> On 15 June 2012 09:58, Greg KH <gregkh@gentoo.org> wrote:
>> So, anyone been thinking about this?  I have, and it's not pretty.
>>
>> Minor details like, "do we have a 'company' that can pay Microsoft to
>> sign our bootloader?" is one aspect from the non-technical side that I've
>> been wondering about.
>
> Sounds like something the Gentoo Foundation could do.

I'm certainly not the only one who would be averse to paying Microsoft
any ransom money.

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Matthew Finkel]

[-- Attachment #1: Type: text/plain, Size: 755 bytes --]

On Fri, Jun 15, 2012 at 1:03 AM, Ben de Groot <yngwin@gentoo.org> wrote:

> On 15 June 2012 12:45, Arun Raghavan <ford_prefect@gentoo.org> wrote:
> > On 15 June 2012 09:58, Greg KH <gregkh@gentoo.org> wrote:
> >> So, anyone been thinking about this?  I have, and it's not pretty.
> >>
> >> Minor details like, "do we have a 'company' that can pay Microsoft to
> >> sign our bootloader?" is one aspect from the non-technical side that
> I've
> >> been wondering about.
> >
> > Sounds like something the Gentoo Foundation could do.
>
> I'm certainly not the only one who would be averse to paying Microsoft
> any ransom money.


Last I heard Verisign was handling the signing certs, but that also doesn't
mean MS isn't getting a cut of the profit.


- Matt

[-- Attachment #2: Type: text/html, Size: 1303 bytes --]

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Arun Raghavan]

On 15 June 2012 10:33, Ben de Groot <yngwin@gentoo.org> wrote:
> On 15 June 2012 12:45, Arun Raghavan <ford_prefect@gentoo.org> wrote:
>> On 15 June 2012 09:58, Greg KH <gregkh@gentoo.org> wrote:
>>> So, anyone been thinking about this?  I have, and it's not pretty.
>>>
>>> Minor details like, "do we have a 'company' that can pay Microsoft to
>>> sign our bootloader?" is one aspect from the non-technical side that I've
>>> been wondering about.
>>
>> Sounds like something the Gentoo Foundation could do.
>
> I'm certainly not the only one who would be averse to paying Microsoft
> any ransom money.

And our refusal to pay for the signing affects precisely nobody except
for our users, who will have to jump through an extra hoop to make
their system work.

On the flip side, having a simple way to use this infrastructure means
that people who care about security can get a chain of trust from the
firmware to the kernel (heck, maybe even userspace one day). This is
something that is worth having as well.
-- 
Arun Raghavan
http://arunraghavan.net/
(Ford_Prefect | Gentoo) & (arunsr | GNOME)

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Ben de Groot]

On 15 June 2012 13:24, Arun Raghavan <ford_prefect@gentoo.org> wrote:
> On 15 June 2012 10:33, Ben de Groot <yngwin@gentoo.org> wrote:
>> On 15 June 2012 12:45, Arun Raghavan <ford_prefect@gentoo.org> wrote:
>>> On 15 June 2012 09:58, Greg KH <gregkh@gentoo.org> wrote:
>>>> So, anyone been thinking about this?  I have, and it's not pretty.
>>>>
>>>> Minor details like, "do we have a 'company' that can pay Microsoft to
>>>> sign our bootloader?" is one aspect from the non-technical side that I've
>>>> been wondering about.
>>>
>>> Sounds like something the Gentoo Foundation could do.
>>
>> I'm certainly not the only one who would be averse to paying Microsoft
>> any ransom money.
>
> And our refusal to pay for the signing affects precisely nobody except
> for our users, who will have to jump through an extra hoop to make
> their system work.
>
> On the flip side, having a simple way to use this infrastructure means
> that people who care about security can get a chain of trust from the
> firmware to the kernel (heck, maybe even userspace one day). This is
> something that is worth having as well.

I agree that security is a worthwhile goal. I just don't trust Microsoft.

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Richard Farina]

On 06/15/2012 03:12 AM, Ben de Groot wrote:
> On 15 June 2012 13:24, Arun Raghavan <ford_prefect@gentoo.org> wrote:
>> On 15 June 2012 10:33, Ben de Groot <yngwin@gentoo.org> wrote:
>>> On 15 June 2012 12:45, Arun Raghavan <ford_prefect@gentoo.org> wrote:
>>>> On 15 June 2012 09:58, Greg KH <gregkh@gentoo.org> wrote:
>>>>> So, anyone been thinking about this?  I have, and it's not pretty.
>>>>>
>>>>> Minor details like, "do we have a 'company' that can pay Microsoft to
>>>>> sign our bootloader?" is one aspect from the non-technical side that I've
>>>>> been wondering about.
>>>>
>>>> Sounds like something the Gentoo Foundation could do.
>>>
>>> I'm certainly not the only one who would be averse to paying Microsoft
>>> any ransom money.
>>
>> And our refusal to pay for the signing affects precisely nobody except
>> for our users, who will have to jump through an extra hoop to make
>> their system work.
>>
>> On the flip side, having a simple way to use this infrastructure means
>> that people who care about security can get a chain of trust from the
>> firmware to the kernel (heck, maybe even userspace one day). This is
>> something that is worth having as well.
> 
> I agree that security is a worthwhile goal. I just don't trust Microsoft.
> 
It's more of a "pay us or your system can't boot" that I'm opposed to.
Saying "I just don't trust Microsoft" is second to "I just don't trust
corporations that extort money from me just so I can boot".  I don't
care who we are paying, I'm offended by the idea.  If users can't build
their own fully functional boot loader that's an issue.

I'm all for the signed "work-around signatures" idea as it is the least
objectionable... if such a thing is even possible.

-Zero

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 2767 bytes --]

Am 15.06.2012 09:58, schrieb Richard Farina:
> On 06/15/2012 03:12 AM, Ben de Groot wrote:
>> On 15 June 2012 13:24, Arun Raghavan <ford_prefect@gentoo.org> wrote:
>>> On 15 June 2012 10:33, Ben de Groot <yngwin@gentoo.org> wrote:
>>>> On 15 June 2012 12:45, Arun Raghavan <ford_prefect@gentoo.org> wrote:
>>>>> On 15 June 2012 09:58, Greg KH <gregkh@gentoo.org> wrote:
>>>>>> So, anyone been thinking about this?  I have, and it's not pretty.
>>>>>>
>>>>>> Minor details like, "do we have a 'company' that can pay Microsoft to
>>>>>> sign our bootloader?" is one aspect from the non-technical side that I've
>>>>>> been wondering about.
>>>>>
>>>>> Sounds like something the Gentoo Foundation could do.
>>>>
>>>> I'm certainly not the only one who would be averse to paying Microsoft
>>>> any ransom money.
>>>
>>> And our refusal to pay for the signing affects precisely nobody except
>>> for our users, who will have to jump through an extra hoop to make
>>> their system work.
>>>
>>> On the flip side, having a simple way to use this infrastructure means
>>> that people who care about security can get a chain of trust from the
>>> firmware to the kernel (heck, maybe even userspace one day). This is
>>> something that is worth having as well.
>>
>> I agree that security is a worthwhile goal. I just don't trust Microsoft.
>>
> It's more of a "pay us or your system can't boot" that I'm opposed to.
> Saying "I just don't trust Microsoft" is second to "I just don't trust
> corporations that extort money from me just so I can boot".  I don't
> care who we are paying, I'm offended by the idea.  If users can't build
> their own fully functional boot loader that's an issue.
> 
> I'm all for the signed "work-around signatures" idea as it is the least
> objectionable... if such a thing is even possible.
> 
> -Zero
> 

It is the most objectionable idea *I* can think of. Most importantly
because it puts the Dev who volunteers to prove his or her identity to
Verisign into a huge legal risk:

Secure Boot is designed to prevent root kits. And whether you like it or
not, it achieves this goal since it is a well designed system with few
potential flaws. That means providing signature work-arounds which
include your actual real name and other identifiable records (as they
have to contain your public key) makes you an accessory to computer crimes.

Besides, it wouldn't work long. They can blacklist keys. This isn't a
half-arsed pseudo-secure system like DVD-CSS or WEP. We cannot break it
in a 10 minute mailing list discussion. We have to play by the rules or
don't play at all. Everything else will require years or decades of
research.

Regards,
Florian Philipp

Regards,
Florian Philipp


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Walter Dnes]

On Fri, Jun 15, 2012 at 10:37:02AM +0200, Florian Philipp wrote

> Besides, it wouldn't work long. They can blacklist keys.

  Question... how would "blacklisting" work on linux machines?  Let's
say Joe Blow gets a signing key and then passes it around.  I can see
that if you want to build an executable (*.exe) to run under Windows,
you'll run into problems if the monthly MS Windows Update kills that
specific key.

  How could MS do anything to linux users who used the key to get their
machine running?  All I can think of is that the blacklisted keys would
be added to some encrypted table in the UEFI in future versions of the
UEFI/BIOS.  Oh yeah, remember to *NOT* do unnecessary firmware updates
to your UEFI/BIOS.

  As for a signed 1st-stage bootloader, is it just me, or is nobody else
concerned/paranoid about MS sticking their binary code on my machine?
We used to laugh at Sony rootkits, but that's what we could be looking
at here.

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Rich Freeman]

On Fri, Jun 15, 2012 at 7:32 AM, Walter Dnes <waltdnes@waltdnes.org> wrote:
>  Question... how would "blacklisting" work on linux machines?  Let's
> say Joe Blow gets a signing key and then passes it around.  I can see
> that if you want to build an executable (*.exe) to run under Windows,
> you'll run into problems if the monthly MS Windows Update kills that
> specific key.

I took the time to read the MS Hardware Certification guide.  I
haven't read the full UEFI spec though it is referenced to it.  It
sounds like UEFI has a provision for revocation, and that includes an
area of flash to store revoked keys.  So, if you booted the device on
Windows, then Windows could download a list of keys MS doesn't like,
and then since Windows is trusted by the firmware it could add those
keys to the flash.  Then on a reboot the firmware would no longer boot
those keys in secure mode.

So, the revocation is non-volatile, and doesn't require a firmware
update.  Of course, if you never run Windows on the device then it
probably won't get the update.  It wasn't 100% clear, but it sounds
like a full factory reset of the firmware might clear these revoked
keys out (it definitely is supposed to clear out any custom keys you
load).

After reading up it seems to me that the best bet for somebody who
wants free as in freedom is to just run in custom mode and load their
own keys.

The MS document leaves a lot of policy questions unanswered though.
The vendor has to trust the MS key, and has to secure their root keys.
 However, they can trust any number of keys, and nothing is said about
those keys having to be secure.  It seems like that is a loophole that
would be rapidly closed in practice if a vendor got "out of line."

For ARM users are up the creek unless they can get the vendor to
include their keys, or get a signature from somebody whose keys are
included.  ARM lacks the ability to use custom mode, which means you
can't load your own keys, and it can't disable secure boot.

Then again, all of this is only as good as the implementation.  My
current Android phone used just about all the tricks in the spec
(flash is locked by bootloader, no downgrading, and so on).  However,
in the case of my phone messing with the power supply can reset the
flash controller before it resets the CPU, unlocking it and allowing a
rooted device to flash the bootloader.  However, the UEFI specs
themselves seem secure, and you can't count on every piece of hardware
having an exploit.

I think that anybody that really cares about security should be
running in custom mode anyway, and should just re-sign anything they
want to run.  Custom mode lets you clear every single key in the
system from the vendor on down, and gives you the ability to ensure
the system only boots stuff you want it to.  The MS spec does require
a full factory reset to restore the original keys, though if you're
using secure boot and TPM you could ensure that your hard drive
becomes unreadable if this is done (unless the TPM has some backdoor
and your vendor is complicit in accessing it).  I don't have a problem
with secure boot, and obviously to use it any pre-loaded OS has to
have pre-loaded keys.  What I don't like is the way certain companies
are getting privileged in the process.  If a full factory reset
unlocked the machine, letting the first CD you boot from restore that
OS vendor's keys or whatever, then then that would be more neutral.
The whole bit about not allowing users to load their keys on ARM is
obviously objectionable - I'm fine with ensuring security by making
the user go into the pre-boot firmware, but the computer owner should
have the final say.

Rich

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 4376 bytes --]

Am 15.06.2012 14:01, schrieb Rich Freeman:
> On Fri, Jun 15, 2012 at 7:32 AM, Walter Dnes <waltdnes@waltdnes.org> wrote:
>>  Question... how would "blacklisting" work on linux machines?  Let's
>> say Joe Blow gets a signing key and then passes it around.  I can see
>> that if you want to build an executable (*.exe) to run under Windows,
>> you'll run into problems if the monthly MS Windows Update kills that
>> specific key.
> 
> I took the time to read the MS Hardware Certification guide.  I
> haven't read the full UEFI spec though it is referenced to it.  It
> sounds like UEFI has a provision for revocation, and that includes an
> area of flash to store revoked keys.  So, if you booted the device on
> Windows, then Windows could download a list of keys MS doesn't like,
> and then since Windows is trusted by the firmware it could add those
> keys to the flash.  Then on a reboot the firmware would no longer boot
> those keys in secure mode.
> 
> So, the revocation is non-volatile, and doesn't require a firmware
> update.

Besides, even if there was no update mechanism, it wouldn't help us.
Even if our key was only blacklisted in the next generation of
mainboards, what would we have gained? We cannot purposefully break the
system every time a new mainboard is released.

>  Of course, if you never run Windows on the device then it
> probably won't get the update.

From skimming the UEFI specs it sounds like there are similar tools for
Linux under development.

>  It wasn't 100% clear, but it sounds
> like a full factory reset of the firmware might clear these revoked
> keys out (it definitely is supposed to clear out any custom keys you
> load).
> 
> After reading up it seems to me that the best bet for somebody who
> wants free as in freedom is to just run in custom mode and load their
> own keys.
> 
> The MS document leaves a lot of policy questions unanswered though.
> The vendor has to trust the MS key, and has to secure their root keys.
>  However, they can trust any number of keys, and nothing is said about
> those keys having to be secure.  It seems like that is a loophole that
> would be rapidly closed in practice if a vendor got "out of line."
> 
> For ARM users are up the creek unless they can get the vendor to
> include their keys, or get a signature from somebody whose keys are
> included.  ARM lacks the ability to use custom mode, which means you
> can't load your own keys, and it can't disable secure boot.
> 
> Then again, all of this is only as good as the implementation.  My
> current Android phone used just about all the tricks in the spec
> (flash is locked by bootloader, no downgrading, and so on).  However,
> in the case of my phone messing with the power supply can reset the
> flash controller before it resets the CPU, unlocking it and allowing a
> rooted device to flash the bootloader.  However, the UEFI specs
> themselves seem secure, and you can't count on every piece of hardware
> having an exploit.
> 
> I think that anybody that really cares about security should be
> running in custom mode anyway, and should just re-sign anything they
> want to run.  Custom mode lets you clear every single key in the
> system from the vendor on down, and gives you the ability to ensure
> the system only boots stuff you want it to.  The MS spec does require
> a full factory reset to restore the original keys, though if you're
> using secure boot and TPM you could ensure that your hard drive
> becomes unreadable if this is done (unless the TPM has some backdoor
> and your vendor is complicit in accessing it).  I don't have a problem
> with secure boot, and obviously to use it any pre-loaded OS has to
> have pre-loaded keys.  What I don't like is the way certain companies
> are getting privileged in the process.  If a full factory reset
> unlocked the machine, letting the first CD you boot from restore that
> OS vendor's keys or whatever, then then that would be more neutral.
> The whole bit about not allowing users to load their keys on ARM is
> obviously objectionable - I'm fine with ensuring security by making
> the user go into the pre-boot firmware, but the computer owner should
> have the final say.
> 

Yeah, the ARM policy is a pretty obvious "don't root the phone" attempt.

Regards,
Florian Philipp


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Maxim Kammerer]

On Fri, Jun 15, 2012 at 3:01 PM, Rich Freeman <rich0@gentoo.org> wrote:
> I think that anybody that really cares about security should be
> running in custom mode anyway, and should just re-sign anything they
> want to run.  Custom mode lets you clear every single key in the
> system from the vendor on down, and gives you the ability to ensure
> the system only boots stuff you want it to.

I have several questions, that hopefully someone familiar with UEFI
Secure Boot is able to answer. If I understand UEFI correctly, the
user will need to not just re-sign bootloaders, but also the
OS-neutral drivers (e.g., UEFI GOP), which are hardware-specific, and
will be probably signed with Microsoft keys, since the hardware vendor
would otherwise need to implement expensive key security measures — is
that correct? If the user does not perform this procedure (due to its
complexity and/or lack of tools automating the process), is it
possible for an externally connected device to compromise the system
by supplying a Microsoft-signed blob directly to the UEFI firmware,
circumventing the (Linux) OS? Is it possible to develop an automatic
re-signing tool — i.e., does the API support all needed features
(listing / extracting drivers, revoking keys, adding keys, etc.)?

-- 
Maxim Kammerer
Liberté Linux: http://dee.su/liberte

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Greg KH]

On Sat, Jun 16, 2012 at 12:22:24PM +0300, Maxim Kammerer wrote:
> On Fri, Jun 15, 2012 at 3:01 PM, Rich Freeman <rich0@gentoo.org> wrote:
> > I think that anybody that really cares about security should be
> > running in custom mode anyway, and should just re-sign anything they
> > want to run.  Custom mode lets you clear every single key in the
> > system from the vendor on down, and gives you the ability to ensure
> > the system only boots stuff you want it to.
> 
> I have several questions, that hopefully someone familiar with UEFI
> Secure Boot is able to answer. If I understand UEFI correctly, the
> user will need to not just re-sign bootloaders, but also the
> OS-neutral drivers (e.g., UEFI GOP), which are hardware-specific, and
> will be probably signed with Microsoft keys, since the hardware vendor
> would otherwise need to implement expensive key security measures — is
> that correct?

Huh?  No, why would a user need to resign the UEFI drivers?  Those
"live" in the BIOS and are only used to get the machine up and running
in UEFI space, before UEFI hands the control off to the bootloader it
has verified is signed with a correct key.

> If the user does not perform this procedure (due to its
> complexity and/or lack of tools automating the process), is it
> possible for an externally connected device to compromise the system
> by supplying a Microsoft-signed blob directly to the UEFI firmware,
> circumventing the (Linux) OS?

Again, what?  Please explain.

> Is it possible to develop an automatic
> re-signing tool — i.e., does the API support all needed features
> (listing / extracting drivers, revoking keys, adding keys, etc.)?

What API?  The signing tool is public, and no, it doesn't add keys,
that's up to the BIOS to do, not the userspace tool.

confused,

greg k-h

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Maxim Kammerer]

On Sun, Jun 17, 2012 at 8:03 PM, Greg KH <gregkh@gentoo.org> wrote:
> Huh?  No, why would a user need to resign the UEFI drivers?  Those
> "live" in the BIOS and are only used to get the machine up and running
> in UEFI space, before UEFI hands the control off to the bootloader it
> has verified is signed with a correct key.

Is that always the case? E.g., kernel's efifb module uses the EFI
console driver, similarly to legacy BIOS's VESA interface. It is
possible that in the future more OS-usable EFI drivers will become
commonplace, especially for non-performance-critical periphery
interaction (sensors, etc.). Architecture-independent EFI bytecode
drivers apparently don't have OS interface now, but this could change
as well.

>> If the user does not perform this procedure (due to its
>> complexity and/or lack of tools automating the process), is it
>> possible for an externally connected device to compromise the system
>> by supplying a Microsoft-signed blob directly to the UEFI firmware,
>> circumventing the (Linux) OS?
>
> Again, what?  Please explain.

I am thinking about a possibility where a “rogue” device can upload
its driver directly to the UEFI firmware. I don't see something like
that in the UEFI spec, but perhaps the firmware can support such
behavior outside the spec. E.g., many 3G network tokens support
presenting themselves as network devices or as storage media on the
USB bus (sys-apps/usb_modeswitch deals with that). The reason they do
that is for the OS to install the network driver from the storage
media “representation”. Now, imagine that the OS defers handling of
unfamiliar network devices to the UEFI network driver (as it might do
with unfamiliar video cards and UEFI GOP). It makes sense that UEFI
firmware vendors would support a similar mechanism of loading
(possibly EBC) UEFI drivers from the network device. Why not — the
drivers will be signed, and UEFI can verify the signatures.

So it seems to me that UEFI, because of its complexity and multitude
of features, may provide an OS-circumventing attack vector, which can
only be dealt with by revoking (probably Microsoft) keys in UEFI
firmware, and re-signing only the necessary drivers with a custom key.
Compromising major player's certificates is a real possibility — e.g.,
see http://www.pcpro.co.uk/news/security/375169/could-us-cyberspies-have-moles-inside-microsoft.

> What API?  The signing tool is public, and no, it doesn't add keys,
> that's up to the BIOS to do, not the userspace tool.

So the re-signing mentioned above must be done in a tedious manual
process? Or can some automatic tool be developed (not necessary
userspace, it can be an EFI app)?

-- 
Maxim Kammerer
Liberté Linux: http://dee.su/liberte

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Ben de Groot]

On 15 June 2012 15:58, Richard Farina <sidhayn@gmail.com> wrote:
> On 06/15/2012 03:12 AM, Ben de Groot wrote:
>> On 15 June 2012 13:24, Arun Raghavan <ford_prefect@gentoo.org> wrote:
>>> On 15 June 2012 10:33, Ben de Groot <yngwin@gentoo.org> wrote:
>>>> On 15 June 2012 12:45, Arun Raghavan <ford_prefect@gentoo.org> wrote:
>>>>> On 15 June 2012 09:58, Greg KH <gregkh@gentoo.org> wrote:
>>>>>> So, anyone been thinking about this?  I have, and it's not pretty.
>>>>>>
>>>>>> Minor details like, "do we have a 'company' that can pay Microsoft to
>>>>>> sign our bootloader?" is one aspect from the non-technical side that I've
>>>>>> been wondering about.
>>>>>
>>>>> Sounds like something the Gentoo Foundation could do.
>>>>
>>>> I'm certainly not the only one who would be averse to paying Microsoft
>>>> any ransom money.
>>>
>>> And our refusal to pay for the signing affects precisely nobody except
>>> for our users, who will have to jump through an extra hoop to make
>>> their system work.
>>>
>>> On the flip side, having a simple way to use this infrastructure means
>>> that people who care about security can get a chain of trust from the
>>> firmware to the kernel (heck, maybe even userspace one day). This is
>>> something that is worth having as well.
>>
>> I agree that security is a worthwhile goal. I just don't trust Microsoft.
>>
> It's more of a "pay us or your system can't boot" that I'm opposed to.

That's why I called it ransom money. I'm very opposed to that too.

But if we're talking about security and a chain of trust, then Microsoft
has no place in that either.

> Saying "I just don't trust Microsoft" is second to "I just don't trust
> corporations that extort money from me just so I can boot".  I don't
> care who we are paying, I'm offended by the idea.  If users can't build
> their own fully functional boot loader that's an issue.
>
> I'm all for the signed "work-around signatures" idea as it is the least
> objectionable... if such a thing is even possible.
>
> -Zero
>



-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Greg KH]

On Fri, Jun 15, 2012 at 01:03:24PM +0800, Ben de Groot wrote:
> On 15 June 2012 12:45, Arun Raghavan <ford_prefect@gentoo.org> wrote:
> > On 15 June 2012 09:58, Greg KH <gregkh@gentoo.org> wrote:
> >> So, anyone been thinking about this?  I have, and it's not pretty.
> >>
> >> Minor details like, "do we have a 'company' that can pay Microsoft to
> >> sign our bootloader?" is one aspect from the non-technical side that I've
> >> been wondering about.
> >
> > Sounds like something the Gentoo Foundation could do.
> 
> I'm certainly not the only one who would be averse to paying Microsoft
> any ransom money.

Sorry, it's really Verisign, although I imagine you still feel the same :)

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Greg KH]

On Thu, Jun 14, 2012 at 09:28:10PM -0700, Greg KH 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?
> 
> Minor details like, "do we have a 'company' that can pay Microsoft to
> sign our bootloader?" is one aspect from the non-technical side that I've
> been wondering about.

Oh, and for those that don't know, I did a lot of UEFI secure boot work
in the past at SUSE, and should be soon a member of the UEFI
"organization" through my work at the Linux Foundation, so I do have a
basic grasp of the issues involved, and have a chance to get changes
made, if needed, and possible, to the spec itself.

greg k-h

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Philip Webb]

120614 Greg KH 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?
> Minor details like, "do we have a 'company' that can pay Microsoft
> to sign our bootloader?" is one aspect from the non-technical side.
> I did a lot of UEFI secure boot work in the past at SUSE
> and should be soon a member of the UEFI "organization"
> through my work at the Linux Foundation, so I do have a basic grasp
> of the issues involved and have a chance to get changes made,
> if needed and possible, to the spec itself.

Does this affect those of us who build our own machines ?
Is there likely to be any Gentoo user
who is reluctant to change the default BIOS setting ?
How can UEFI be required for Arm without running into anti-trust ?
How far is this basically a problem for those in the USA,
the rest of us having a different attitude to security issues ?

-- 
========================,,============================================
SUPPORT     ___________//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT    `-O----------O---'   purslowatchassdotutorontodotca

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Greg KH]

On Fri, Jun 15, 2012 at 01:48:05AM -0400, Philip Webb wrote:
> 120614 Greg KH 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?
> > Minor details like, "do we have a 'company' that can pay Microsoft
> > to sign our bootloader?" is one aspect from the non-technical side.
> > I did a lot of UEFI secure boot work in the past at SUSE
> > and should be soon a member of the UEFI "organization"
> > through my work at the Linux Foundation, so I do have a basic grasp
> > of the issues involved and have a chance to get changes made,
> > if needed and possible, to the spec itself.
> 
> Does this affect those of us who build our own machines ?

Yes, it will be on your new motherboard in a matter of months.

> Is there likely to be any Gentoo user
> who is reluctant to change the default BIOS setting ?

Probably lots.

> How can UEFI be required for Arm without running into anti-trust ?

Different countries have different rules here.

> How far is this basically a problem for those in the USA,
> the rest of us having a different attitude to security issues ?

Everyone in all countries are going to have to deal with this, as all
motherboard manufacturers are going to be supporting this by the end of
this year at the latest, due to the Windows 8 requirements.

greg k-h

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Philip Webb]

120615 Greg KH wrote:
> On Fri, Jun 15, 2012 at 01:48:05AM -0400, Philip Webb wrote:
>> Does this affect those of us who build our own machines ?
> Yes, it will be on your new motherboard in a matter of months.

I am going to build a new machine some time in the next  12 mth ,
but it looks as if all I will have to do is reset the BIOS ,
which I'm likely to have to do for other features in any case.

>> Is there likely to be any Gentoo user
>> who is reluctant to change the default BIOS setting ?
> Probably lots.

That surprises me, but we'll find out.

>> How can UEFI be required for Arm without running into anti-trust ?
> Different countries have different rules here.

Discussion + news items in the press do suggest
that it's not anti-trust as long as it's not benefitting  1  company.
Anyway, I'm not likely to be using ARM, let alone jailbreaking it.

>> How far is this basically a problem for those in the USA,
>> the rest of us having a different attitude to security issues ?
> Everyone in all countries are going to have to deal with this,
> as all motherboard manufacturers are going to be supporting this
> by the end of 2012 at the latest, due to the Windows 8 requirements.

As with other similar issues in the past,
we can expect the EU antitrust people to take a close look at it
& they may start demanding that computers are easily unlockable,
if not actually required to be sold with UEFI disabled by default.
Despite current scare stories out of London & New York,
the EU is by no means finished as a political entity
& no-one in USA should assume the EU will follow their lead
or even that Canada will, despite our current Conservative government.

I see a need for careful thought at Gentoo, but no need for panic.

Thanks for your horse's mouth (smile).

-- 
========================,,============================================
SUPPORT     ___________//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT    `-O----------O---'   purslowatchassdotutorontodotca

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Matthew Thode]

[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]

On 06/14/2012 11:45 PM, Greg KH wrote:
> On Thu, Jun 14, 2012 at 09:28:10PM -0700, Greg KH 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?
>>
>> Minor details like, "do we have a 'company' that can pay Microsoft to
>> sign our bootloader?" is one aspect from the non-technical side that I've
>> been wondering about.
> 
> Oh, and for those that don't know, I did a lot of UEFI secure boot work
> in the past at SUSE, and should be soon a member of the UEFI
> "organization" through my work at the Linux Foundation, so I do have a
> basic grasp of the issues involved, and have a chance to get changes
> made, if needed, and possible, to the spec itself.
> 
> greg k-h
> 
One of these days I'd like to pick your brain about some hardened UEFI
interactions I've seen (with pipacs watching).

-- 
-- Matthew Thode (prometheanfire)




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Greg KH]

On Fri, Jun 15, 2012 at 04:35:28PM -0500, Matthew Thode wrote:
> One of these days I'd like to pick your brain about some hardened UEFI
> interactions I've seen (with pipacs watching).

Sure, be glad to talk about this anytime.

[gentoo-dev] Re: UEFI secure boot and Gentoo

[Duncan]

Greg KH posted on Thu, 14 Jun 2012 21:28:10 -0700 as excerpted:

> 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?
> 
> Minor details like, "do we have a 'company' that can pay Microsoft to
> sign our bootloader?" is one aspect from the non-technical side that
> I've been wondering about.

I've been following developments and wondering a bit about this myself.

I had concluded that at least for x86/amd64, where MS is mandating a user 
controlled disable-signed-checking option, gentoo shouldn't have a 
problem.  Other than updating the handbook to accommodate UEFI, 
presumably along with the grub2 stabilization, I believe we're fine as if 
a user can't figure out how to disable that option on their (x86/amd64) 
platform, they're hardly likely to be a good match for gentoo in any case.

ARM and etc could be more problematic since MS is mandating no-unlock 
there, last I read.  I have no clue how they can get away with that anti-
trust-wise, but anyway...  But I honestly don't know enough about other 
than x86/amd64 platforms to worry about it, personally.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: UEFI secure boot and Gentoo

[Matthew Finkel]

[-- Attachment #1: Type: text/plain, Size: 1953 bytes --]

On Fri, Jun 15, 2012 at 12:50 AM, Duncan <1i5t5.duncan@cox.net> wrote:

> Greg KH posted on Thu, 14 Jun 2012 21:28:10 -0700 as excerpted:
>
> > 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?
> >
> > Minor details like, "do we have a 'company' that can pay Microsoft to
> > sign our bootloader?" is one aspect from the non-technical side that
> > I've been wondering about.
>
> I've been following developments and wondering a bit about this myself.
>
> I had concluded that at least for x86/amd64, where MS is mandating a user
> controlled disable-signed-checking option, gentoo shouldn't have a
> problem.  Other than updating the handbook to accommodate UEFI,
> presumably along with the grub2 stabilization, I believe we're fine as if
> a user can't figure out how to disable that option on their (x86/amd64)
> platform, they're hardly likely to be a good match for gentoo in any case.
>
> ARM and etc could be more problematic since MS is mandating no-unlock
> there, last I read.  I have no clue how they can get away with that anti-
> trust-wise, but anyway...  But I honestly don't know enough about other
> than x86/amd64 platforms to worry about it, personally.
>

For the short term, we don't have many options beside either adding to the
documentation that the User needs to disable UEFI or wipe the current valid
keys and adding their own (Devs may need to make sure there's a way to do
this on the livecd). Of course there's the third option of everyone
purchasing a key from Verisign but....

As for non-x86 systems, Gentoo is in between a rock and a hard place. I
hope there will be a similar mechanism for the user to implement their own
valid key chain and remove Microsofts, but who knows. The the devs and we
need to decide on a uniform way of handling this situation.

- Matt

[-- Attachment #2: Type: text/html, Size: 2524 bytes --]

Re: [gentoo-dev] Re: UEFI secure boot and Gentoo

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 1628 bytes --]

Am 15.06.2012 06:50, schrieb Duncan:
> Greg KH posted on Thu, 14 Jun 2012 21:28:10 -0700 as excerpted:
> 
>> 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?
>>
>> Minor details like, "do we have a 'company' that can pay Microsoft to
>> sign our bootloader?" is one aspect from the non-technical side that
>> I've been wondering about.
> 
> I've been following developments and wondering a bit about this myself.
> 
> I had concluded that at least for x86/amd64, where MS is mandating a user 
> controlled disable-signed-checking option, gentoo shouldn't have a 
> problem.  Other than updating the handbook to accommodate UEFI, 
> presumably along with the grub2 stabilization, I believe we're fine as if 
> a user can't figure out how to disable that option on their (x86/amd64) 
> platform, they're hardly likely to be a good match for gentoo in any case.
> 

As a user, I'd still like to have the chance of using Secure Boot with
Gentoo since it _really_ increases security. Even if it means I can no
longer build my own kernel.

> ARM and etc could be more problematic since MS is mandating no-unlock 
> there, last I read.  I have no clue how they can get away with that anti-
> trust-wise, but anyway...  But I honestly don't know enough about other 
> than x86/amd64 platforms to worry about it, personally.
> 

I guess anti-trust is not an issue since MS is not even close to having
a monopoly in ARM.

Regards,
Florian Philipp


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] Re: UEFI secure boot and Gentoo

[Walter Dnes]

On Fri, Jun 15, 2012 at 09:54:12AM +0200, Florian Philipp wrote

> I guess anti-trust is not an issue since MS is not even close to having
> a monopoly in ARM.

  Will you be able to get an ARM machine without their UEFI?  If MS
ever gets huge in the ARM arena, and 95% of ARM cpus go into Windows
machines, how many companies will make cpus for the remaining 5%.
Remember how MS strongarmed OEMs into a "Windows tax"?

-- 
Walter Dnes <waltdnes@waltdnes.org>

Re: [gentoo-dev] Re: UEFI secure boot and Gentoo

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 926 bytes --]

Am 15.06.2012 14:28, schrieb Walter Dnes:
> On Fri, Jun 15, 2012 at 09:54:12AM +0200, Florian Philipp wrote
> 
>> I guess anti-trust is not an issue since MS is not even close to having
>> a monopoly in ARM.
> 
>   Will you be able to get an ARM machine without their UEFI?  If MS
> ever gets huge in the ARM arena, and 95% of ARM cpus go into Windows
> machines, how many companies will make cpus for the remaining 5%.
> Remember how MS strongarmed OEMs into a "Windows tax"?
> 

When MS gets a strong hold in ARM, they will have to face the same
antitrust measures they face on x86 and their policy will likely have to
change.

I don't say its a nice outlook. The whole antitrust system is reactive
and takes years to have any effect.

But until then (if it ever happens)? Support other big players in ARM,
don't buy Nokia/Windows phones, hope for the best. The usual ...

Regards,
Florian Philipp


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] Re: UEFI secure boot and Gentoo

[Steev Klimaszewski]

Just picking a random response to reply to.  I'm not speaking
officially, however, I'm pretty sure we at Genesi aren't going to pay
Microsoft in order to boot our own boards.  

Re: [gentoo-dev] Re: UEFI secure boot and Gentoo

[Greg KH]

On Sat, Jun 16, 2012 at 06:37:41PM -0500, Steev Klimaszewski wrote:
> Just picking a random response to reply to.  I'm not speaking
> officially, however, I'm pretty sure we at Genesi aren't going to pay
> Microsoft in order to boot our own boards.

If you don't want your boards to be Windows 8 certified, then you are
fine.  Otherwise, you have to follow their guidelines, which I don't
think requires paying them any money if you want to run Windows 8.

Also, as these are "your own boards", you control the BIOS, so you don't
even have to implement UEFI, or, if you do, you can control what keys
are installed in the BIOS by default.

So I don't understand the issue here, please explain.

greg k-h

Re: [gentoo-dev] Re: UEFI secure boot and Gentoo

[Dale]

Greg KH wrote:
> On Sat, Jun 16, 2012 at 06:37:41PM -0500, Steev Klimaszewski wrote:
>> Just picking a random response to reply to.  I'm not speaking
>> officially, however, I'm pretty sure we at Genesi aren't going to pay
>> Microsoft in order to boot our own boards.
> If you don't want your boards to be Windows 8 certified, then you are
> fine.  Otherwise, you have to follow their guidelines, which I don't
> think requires paying them any money if you want to run Windows 8.
>
> Also, as these are "your own boards", you control the BIOS, so you don't
> even have to implement UEFI, or, if you do, you can control what keys
> are installed in the BIOS by default.
>
> So I don't understand the issue here, please explain.
>
> greg k-h
>
> .
>


I'm glad you said that.  If I was going to have to pay M$ to run Linux,
I was thinking of shooting them with laser eyes or something.  I have no
plans to ever support M$ in any shape, form or fashion.  Period.   

Thing is, they will likely try to make it so you can't disable it
eventually.  Some politician will try to make it a law if nothing else. 
After all, politicians are clueless anyway.  Reminds me of chickens and
it raining.  :/ 

Dale

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!

Miss the compile output?  Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"

Re: [gentoo-dev] Re: UEFI secure boot and Gentoo

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1476 bytes --]

On Fri, 15 Jun 2012 09:54:12 +0200
Florian Philipp <lists@binarywings.net> wrote:

> Am 15.06.2012 06:50, schrieb Duncan:
> > Greg KH posted on Thu, 14 Jun 2012 21:28:10 -0700 as excerpted:
> > 
> >> 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?
> >>
> >> Minor details like, "do we have a 'company' that can pay Microsoft
> >> to sign our bootloader?" is one aspect from the non-technical side
> >> that I've been wondering about.
> > 
> > I've been following developments and wondering a bit about this
> > myself.
> > 
> > I had concluded that at least for x86/amd64, where MS is mandating
> > a user controlled disable-signed-checking option, gentoo shouldn't
> > have a problem.  Other than updating the handbook to accommodate
> > UEFI, presumably along with the grub2 stabilization, I believe
> > we're fine as if a user can't figure out how to disable that option
> > on their (x86/amd64) platform, they're hardly likely to be a good
> > match for gentoo in any case.
> > 
> 
> As a user, I'd still like to have the chance of using Secure Boot with
> Gentoo since it _really_ increases security. Even if it means I can no
> longer build my own kernel.

It doesn't. It's just a very long wooden fence; you just didn't find
the hole yet.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Re: UEFI secure boot and Gentoo

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 1637 bytes --]

Am 16.06.2012 19:51, schrieb Michał Górny:
> On Fri, 15 Jun 2012 09:54:12 +0200
> Florian Philipp <lists@binarywings.net> wrote:
> 
>> Am 15.06.2012 06:50, schrieb Duncan:
>>> Greg KH posted on Thu, 14 Jun 2012 21:28:10 -0700 as excerpted:
>>>
>>>> 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?
>>>>
>>>> Minor details like, "do we have a 'company' that can pay Microsoft
>>>> to sign our bootloader?" is one aspect from the non-technical side
>>>> that I've been wondering about.
>>>
>>> I've been following developments and wondering a bit about this
>>> myself.
>>>
>>> I had concluded that at least for x86/amd64, where MS is mandating
>>> a user controlled disable-signed-checking option, gentoo shouldn't
>>> have a problem.  Other than updating the handbook to accommodate
>>> UEFI, presumably along with the grub2 stabilization, I believe
>>> we're fine as if a user can't figure out how to disable that option
>>> on their (x86/amd64) platform, they're hardly likely to be a good
>>> match for gentoo in any case.
>>>
>>
>> As a user, I'd still like to have the chance of using Secure Boot with
>> Gentoo since it _really_ increases security. Even if it means I can no
>> longer build my own kernel.
> 
> It doesn't. It's just a very long wooden fence; you just didn't find
> the hole yet.
> 

Oh come on! That's FUD and you know it. If not, did you even look at the
specs and working principle?

Regards,
Florian Philipp


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] Re: UEFI secure boot and Gentoo

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2019 bytes --]

On Sun, 17 Jun 2012 11:20:38 +0200
Florian Philipp <lists@binarywings.net> wrote:

> Am 16.06.2012 19:51, schrieb Michał Górny:
> > On Fri, 15 Jun 2012 09:54:12 +0200
> > Florian Philipp <lists@binarywings.net> wrote:
> > 
> >> Am 15.06.2012 06:50, schrieb Duncan:
> >>> Greg KH posted on Thu, 14 Jun 2012 21:28:10 -0700 as excerpted:
> >>>
> >>>> 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?
> >>>>
> >>>> Minor details like, "do we have a 'company' that can pay
> >>>> Microsoft to sign our bootloader?" is one aspect from the
> >>>> non-technical side that I've been wondering about.
> >>>
> >>> I've been following developments and wondering a bit about this
> >>> myself.
> >>>
> >>> I had concluded that at least for x86/amd64, where MS is mandating
> >>> a user controlled disable-signed-checking option, gentoo shouldn't
> >>> have a problem.  Other than updating the handbook to accommodate
> >>> UEFI, presumably along with the grub2 stabilization, I believe
> >>> we're fine as if a user can't figure out how to disable that
> >>> option on their (x86/amd64) platform, they're hardly likely to be
> >>> a good match for gentoo in any case.
> >>>
> >>
> >> As a user, I'd still like to have the chance of using Secure Boot
> >> with Gentoo since it _really_ increases security. Even if it means
> >> I can no longer build my own kernel.
> > 
> > It doesn't. It's just a very long wooden fence; you just didn't find
> > the hole yet.
> > 
> 
> Oh come on! That's FUD and you know it. If not, did you even look at
> the specs and working principle?

Could you answer the following question:

1. How does it increase security?
2. What happens if, say, your bootloader is compromised?
3. What happens if the machine signing the blobs is compromised?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Re: UEFI secure boot and Gentoo

[Greg KH]

On Sun, Jun 17, 2012 at 05:51:04PM +0200, Michał Górny wrote:
> On Sun, 17 Jun 2012 11:20:38 +0200
> Florian Philipp <lists@binarywings.net> wrote:
> 
> > Am 16.06.2012 19:51, schrieb Michał Górny:
> > > On Fri, 15 Jun 2012 09:54:12 +0200
> > > Florian Philipp <lists@binarywings.net> wrote:
> > > 
> > >> Am 15.06.2012 06:50, schrieb Duncan:
> > >>> Greg KH posted on Thu, 14 Jun 2012 21:28:10 -0700 as excerpted:
> > >>>
> > >>>> 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?
> > >>>>
> > >>>> Minor details like, "do we have a 'company' that can pay
> > >>>> Microsoft to sign our bootloader?" is one aspect from the
> > >>>> non-technical side that I've been wondering about.
> > >>>
> > >>> I've been following developments and wondering a bit about this
> > >>> myself.
> > >>>
> > >>> I had concluded that at least for x86/amd64, where MS is mandating
> > >>> a user controlled disable-signed-checking option, gentoo shouldn't
> > >>> have a problem.  Other than updating the handbook to accommodate
> > >>> UEFI, presumably along with the grub2 stabilization, I believe
> > >>> we're fine as if a user can't figure out how to disable that
> > >>> option on their (x86/amd64) platform, they're hardly likely to be
> > >>> a good match for gentoo in any case.
> > >>>
> > >>
> > >> As a user, I'd still like to have the chance of using Secure Boot
> > >> with Gentoo since it _really_ increases security. Even if it means
> > >> I can no longer build my own kernel.
> > > 
> > > It doesn't. It's just a very long wooden fence; you just didn't find
> > > the hole yet.
> > > 
> > 
> > Oh come on! That's FUD and you know it. If not, did you even look at
> > the specs and working principle?
> 
> Could you answer the following question:
> 
> 1. How does it increase security?

Non-signed bootloaders and kernels will not run.

> 2. What happens if, say, your bootloader is compromised?

And how would this happen?  Your bootloader would not run.

> 3. What happens if the machine signing the blobs is compromised?

So, who's watching the watchers, right?  Come on, this is getting
looney.

greg k-h

Re: [gentoo-dev] Re: UEFI secure boot and Gentoo

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 744 bytes --]

On Sun, 17 Jun 2012 09:55:35 -0700
Greg KH <gregkh@gentoo.org> wrote:

> On Sun, Jun 17, 2012 at 05:51:04PM +0200, Michał Górny wrote:
> > 2. What happens if, say, your bootloader is compromised?
> 
> And how would this happen?  Your bootloader would not run.

Yes. I'm asking what happens next. Is there an easy way to replace it?
Or is your computer bricked until you run some other bootloader to
replace the compromised one?

> > 3. What happens if the machine signing the blobs is compromised?
> 
> So, who's watching the watchers, right?  Come on, this is getting
> looney.

I'm just pointing out that this simply relies on trusting people. Much
like not having those signatures.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Re: UEFI secure boot and Gentoo

[Rich Freeman]

On Sun, Jun 17, 2012 at 1:06 PM, Michał Górny <mgorny@gentoo.org> wrote:
> On Sun, 17 Jun 2012 09:55:35 -0700
> Greg KH <gregkh@gentoo.org> wrote:
>
>> On Sun, Jun 17, 2012 at 05:51:04PM +0200, Michał Górny wrote:
>> > 2. What happens if, say, your bootloader is compromised?
>>
>> And how would this happen?  Your bootloader would not run.
>
> Yes. I'm asking what happens next. Is there an easy way to replace it?
> Or is your computer bricked until you run some other bootloader to
> replace the compromised one?

My understanding is that there are a few options here.

One is to simply re-image the system, either directly (as any vendor
does), or after booting off of removable media.  I'd have to re-read
the spec but some of those might not require signatures, and in any
case ones with valid signatures should be available.  You can of
course disable secure boot or go into custom mode as well which lets
you do whatever you want until you have the system back in a bootable
state.

If you're running Windows 8 I believe they plan to have a recovery
partition as well, which will be signed and bootable and which is
designed to recover the OS.

Rich

Re: [gentoo-dev] Re: UEFI secure boot and Gentoo

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 871 bytes --]

Am 17.06.2012 19:06, schrieb Michał Górny:
> On Sun, 17 Jun 2012 09:55:35 -0700
> Greg KH <gregkh@gentoo.org> wrote:
> 
>> On Sun, Jun 17, 2012 at 05:51:04PM +0200, Michał Górny wrote:
[...]
> 
>>> 3. What happens if the machine signing the blobs is compromised?
>>
>> So, who's watching the watchers, right?  Come on, this is getting
>> looney.
> 
> I'm just pointing out that this simply relies on trusting people. Much
> like not having those signatures.
> 

If you are so much worried about it, UEFI allows you to remove all keys
and just add your own. That way, only code signed by you will be executed.

And in the standard case, well, it is just as good (or bad) as the SSL
certificate business. It's not a perfect system but it is better than
having everyone using self-signed certificates or none at all.

Regards,
Florian Philipp


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] Re: UEFI secure boot and Gentoo

[Greg KH]

On Sun, Jun 17, 2012 at 07:06:16PM +0200, Michał Górny wrote:
> On Sun, 17 Jun 2012 09:55:35 -0700
> Greg KH <gregkh@gentoo.org> wrote:
> 
> > On Sun, Jun 17, 2012 at 05:51:04PM +0200, Michał Górny wrote:
> > > 2. What happens if, say, your bootloader is compromised?
> > 
> > And how would this happen?  Your bootloader would not run.
> 
> Yes. I'm asking what happens next. Is there an easy way to replace it?

I do not know, you need to test this on a UEFI secure boot system to see
what happens.

> Or is your computer bricked until you run some other bootloader to
> replace the compromised one?

Probably.

> > > 3. What happens if the machine signing the blobs is compromised?
> > 
> > So, who's watching the watchers, right?  Come on, this is getting
> > looney.
> 
> I'm just pointing out that this simply relies on trusting people. Much
> like not having those signatures.

Of course, this is life, and should not be anything "new" to you or
anyone else.

And before you get upset, do you trust the "people" who implemented the
firmware in your processor and I/O controllers?  This argument is not
one that is worth discussing.

greg k-h

Re: [gentoo-dev] Re: UEFI secure boot and Gentoo

[Matthew Finkel]

[-- Attachment #1: Type: text/plain, Size: 3506 bytes --]

On Sun, Jun 17, 2012 at 11:51 AM, Michał Górny <mgorny@gentoo.org> wrote:

> On Sun, 17 Jun 2012 11:20:38 +0200
> Florian Philipp <lists@binarywings.net> wrote:
>
> > Am 16.06.2012 19:51, schrieb Michał Górny:
> > > On Fri, 15 Jun 2012 09:54:12 +0200
> > > Florian Philipp <lists@binarywings.net> wrote:
> > >
> > >> Am 15.06.2012 06:50, schrieb Duncan:
> > >>> Greg KH posted on Thu, 14 Jun 2012 21:28:10 -0700 as excerpted:
> > >>>
> > >>>> 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?
> > >>>>
> > >>>> Minor details like, "do we have a 'company' that can pay
> > >>>> Microsoft to sign our bootloader?" is one aspect from the
> > >>>> non-technical side that I've been wondering about.
> > >>>
> > >>> I've been following developments and wondering a bit about this
> > >>> myself.
> > >>>
> > >>> I had concluded that at least for x86/amd64, where MS is mandating
> > >>> a user controlled disable-signed-checking option, gentoo shouldn't
> > >>> have a problem.  Other than updating the handbook to accommodate
> > >>> UEFI, presumably along with the grub2 stabilization, I believe
> > >>> we're fine as if a user can't figure out how to disable that
> > >>> option on their (x86/amd64) platform, they're hardly likely to be
> > >>> a good match for gentoo in any case.
> > >>>
> > >>
> > >> As a user, I'd still like to have the chance of using Secure Boot
> > >> with Gentoo since it _really_ increases security. Even if it means
> > >> I can no longer build my own kernel.
> > >
> > > It doesn't. It's just a very long wooden fence; you just didn't find
> > > the hole yet.
> > >
> >
> > Oh come on! That's FUD and you know it. If not, did you even look at
> > the specs and working principle?
>
> Could you answer the following question:
>
(Sorry to jump in on this Florian)

The real problem that surrounds this idea of security is that we need to
make
_a lot_ of assumptions about the code/programs we run. We _trust_ that the
code we compile is as secure as possible and does not implement any
"backdoors". If this is the case, then


> 1. How does it increase security?
>
This removed a few vectors of attack and ensures your computer is only
bootstrapped by and booted using software you think is safe. By using
any software we don't write, we make a lot of assumptions.

2. What happens if, say, your bootloader is compromised?
>
Same thing that would happen if the bootloader was compromised today.
We currently rely on trusting the maintainer, code review, community
review, etc.
Perhaps these efforts will need to be doubled now that any weak-link could
compromise the system.


> 3. What happens if the machine signing the blobs is compromised?
>
See above. But also, a compromised system wouldn't necessarily mean the
blobs would be compromised as well. In addition, ideally the priv-key would
be kept isolated to ensure a compromise would be extremely difficult.

My understanding is that it's not the case that UEFI will lock down a
system to
prevent a compromise from occurring, it's the fact that it reduces the
areas of attack
and/or makes the attacks extremely difficult to accomplish. This just adds
more
protection in hardware for kernel-space that SELinux, apparmor, etc provide
for userspace.

- Matt

[-- Attachment #2: Type: text/html, Size: 5094 bytes --]

Re: [gentoo-dev] Re: UEFI secure boot and Gentoo

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1346 bytes --]

On Sun, 17 Jun 2012 12:56:34 -0400
Matthew Finkel <matthew.finkel@gmail.com> wrote:

> On Sun, Jun 17, 2012 at 11:51 AM, Michał Górny <mgorny@gentoo.org>
> wrote:
> > 1. How does it increase security?
> >
> This removed a few vectors of attack and ensures your computer is only
> bootstrapped by and booted using software you think is safe. By using
> any software we don't write, we make a lot of assumptions.

I agree that it removes a few vectors of attack. But this doesn't
necessarily mean the system is more secure. It has one vulnerability
less but let's not get overenthusiastic.

I'm basically trying to point out that a single solution like that can
do more evil than good if people will believe it's perfect.

> > 3. What happens if the machine signing the blobs is compromised?
> >
> See above. But also, a compromised system wouldn't necessarily mean
> the blobs would be compromised as well. In addition, ideally the
> priv-key would be kept isolated to ensure a compromise would be
> extremely difficult.

In my opinion, if a toolchain is quietly compromised, everything built
on the particular machine can be compromised. And signed. I doubt that
someone will check bit-exact machine code of the toolchain
and operating system before starting to sign packages.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] Re: UEFI secure boot and Gentoo

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 2104 bytes --]

Am 17.06.2012 19:10, schrieb Michał Górny:
> On Sun, 17 Jun 2012 12:56:34 -0400
> Matthew Finkel <matthew.finkel@gmail.com> wrote:
> 
>> On Sun, Jun 17, 2012 at 11:51 AM, Michał Górny <mgorny@gentoo.org>
>> wrote:
>>> 1. How does it increase security?
>>>
>> This removed a few vectors of attack and ensures your computer is only
>> bootstrapped by and booted using software you think is safe. By using
>> any software we don't write, we make a lot of assumptions.
> 
> I agree that it removes a few vectors of attack. But this doesn't
> necessarily mean the system is more secure. It has one vulnerability
> less but let's not get overenthusiastic.
> 
> I'm basically trying to point out that a single solution like that can
> do more evil than good if people will believe it's perfect.
> 

I think I now understand your train of thought. But I don't think anyone
implied that Secure Boot solves each and every security issue. What it
does, however, is impose new hurdles for malware authors. Therefore I
don't see a reason not to use it as long as the inconveniences and
limitations it imposes are acceptable for my particular use case.

>>> 3. What happens if the machine signing the blobs is compromised?
>>>
>> See above. But also, a compromised system wouldn't necessarily mean
>> the blobs would be compromised as well. In addition, ideally the
>> priv-key would be kept isolated to ensure a compromise would be
>> extremely difficult.
> 
> In my opinion, if a toolchain is quietly compromised, everything built
> on the particular machine can be compromised. And signed. I doubt that
> someone will check bit-exact machine code of the toolchain
> and operating system before starting to sign packages.
> 

Just because you cannot rule out bugs doesn't mean you shouldn't use
security enhancing systems. Don't tell me you open telnet for root
access to your machines just because you cannot rule out the chance that
SSH is compromised or someone compromised the SSH source code you
downloaded from the Gentoo mirrors.

Regards,
Florian Philipp


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] Re: UEFI secure boot and Gentoo

[Sascha Cunz]

[...]

> It doesn't. It's just a very long wooden fence; you just didn't find
> the hole yet.

Given the fact that the keys in the BIOS must somehow get there and it must 
also be able to update them (how to revoke or add keys else?).

Unless this is completely done in hardware, there must be a software doing it. 
Software can - by design - be reverse engineered; in some countries even 
legally without any further agreement or license.

So, you can sign, encrypt, obfuscate or use some other foobar-mechanism on 
this blob of software - at some point it must be readable from the processor, 
so you have to provide the mechanisms to verify signs, undo encryption etc 
somewhere (either in hardware or another software).

Even if you somehow manage to embed all of this in the hardware stack, it 
would still require some kind of interface to get updated / revoked keys to 
operate on.

It's not a matter of *if this can* be broken by someone who cares, it's a 
matter of *how long does it take* for someone who cares to break it.

In the end, this is just another kind of "seems to be secure for a day or 
two". Admittedly a complex one - but there will always be a "kid in a garage" 
that is able to set everyone else out of business.

SaCu

Re: [gentoo-dev] Re: UEFI secure boot and Gentoo

[Rich Freeman]

On Sun, Jun 17, 2012 at 1:34 PM, Sascha Cunz <sascha-ml@babbelbox.org> wrote:
>
> Given the fact that the keys in the BIOS must somehow get there and it must
> also be able to update them (how to revoke or add keys else?).

Based on what I've read the keys are stored in flash.  The flash
module itself is protected.  There are a number of ways to implement
something like this fairly securely.  The simplest is to have an
unprotected area of the flash that the OS can write to.  Upon bootup
the firmware looks in this area for a signed message.  If the message
is signed by a trusted source, then the firmware interprets it as
instructions to update itself, add/remove keys, or whatever.  Then
before booting the OS the firmware sets the protect flag on the
protected area of flash that is only unset by a hardware reset.

The only software exploit against something like this is to find a bug
in the code that inspects the flash (overflow/etc) to trick it into
running an unsigned blob.  There are also hardware attacks, like
bypassing flash protection hardware, directly accessing flash, or
controlling what shows up on the data bus when the CPU tries to read
the firmware.  Any of these can be made fairly difficult, and extreme
case being how modern gaming consoles work (flash embedded in CPU, and
so on).

>
> Unless this is completely done in hardware, there must be a software doing it.
> Software can - by design - be reverse engineered; in some countries even
> legally without any further agreement or license.

With the scheme above no software need be distributed that contains
any information useful for anything other than a replay attack.  The
blob would be signed prior to distribution.  You could read the code
that loads it into the flash, but that need not be kept secret.  You
can load whatever you want into the flash and it won't matter unless
it is signed.

If the hardware is fancy enough you could even update settings without
having to reboot, and again unless the hardware isn't done right
you're not going to be able to get around it without tapping
busses/etc.

Rich

Re: [gentoo-dev] Re: UEFI secure boot and Gentoo

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 2741 bytes --]

Am 17.06.2012 19:34, schrieb Sascha Cunz:
> [...]
> 
>> It doesn't. It's just a very long wooden fence; you just didn't find
>> the hole yet.
> 
> Given the fact that the keys in the BIOS must somehow get there and it must 
> also be able to update them (how to revoke or add keys else?).
> 
> Unless this is completely done in hardware, there must be a software doing it. 
> Software can - by design - be reverse engineered; in some countries even 
> legally without any further agreement or license.
> 
> So, you can sign, encrypt, obfuscate or use some other foobar-mechanism on 
> this blob of software - at some point it must be readable from the processor, 
> so you have to provide the mechanisms to verify signs, undo encryption etc 
> somewhere (either in hardware or another software).
> 
> Even if you somehow manage to embed all of this in the hardware stack, it 
> would still require some kind of interface to get updated / revoked keys to 
> operate on.
> 
> It's not a matter of *if this can* be broken by someone who cares, it's a 
> matter of *how long does it take* for someone who cares to break it.
> 
> In the end, this is just another kind of "seems to be secure for a day or 
> two". Admittedly a complex one - but there will always be a "kid in a garage" 
> that is able to set everyone else out of business.
> 
> SaCu
> 

Okay, a few points here:

First: On an abstract level, the key innovation in Secure Boot and
driver signing is that it establishes a trust relationship between
platform owner and platform firmware (using a so called Platform Key) as
well as trust between operating system and platform firmware (using Key
Exchange Keys).

Under the assumption that the implementation is correct, nothing on the
operating system level can inject drivers, boot loaders or whatever else
into the firmware unless it is properly signed. The platform will not
allow anything unless it is bit-by-bit verified to come from the
platform owner or a trusted third party. The recommended algorithms for
signing and verifying code are SHA-256 and RSA-2048. Good luck breaking
that in "a day or two"!

Second point: Secure Boot is not designed to protect against an attacker
with physical access to the machine. So you can leave your soldering
iron and memory stick at home when you try to prove that Secure Boot can
be broken.

Third point: Of course Secure Boot will be broken! A mainboard maker
will screw up, there will be a bug in the specs or RSA will be broken.
And when one of these happens, it will be fixed. Plain and simple. We
didn't abandon SSL just because version 1 and 2 were broken. Why should
we abandon Secure Boot?

Regards,
Florian Philipp


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] Re: UEFI secure boot and Gentoo

[Sascha Cunz]

On Sunday, 17. June 2012 20:00:51 Florian Philipp wrote:
> Am 17.06.2012 19:34, schrieb Sascha Cunz:
> > [...]
> > 
> >> It doesn't. It's just a very long wooden fence; you just didn't find
> >> the hole yet.
> > 
> > Given the fact that the keys in the BIOS must somehow get there and it
> > must
> > also be able to update them (how to revoke or add keys else?).
> > 
> > Unless this is completely done in hardware, there must be a software doing
> > it. Software can - by design - be reverse engineered; in some countries
> > even legally without any further agreement or license.
> > 
> > So, you can sign, encrypt, obfuscate or use some other foobar-mechanism on
> > this blob of software - at some point it must be readable from the
> > processor, so you have to provide the mechanisms to verify signs, undo
> > encryption etc somewhere (either in hardware or another software).
> > 
> > Even if you somehow manage to embed all of this in the hardware stack, it
> > would still require some kind of interface to get updated / revoked keys
> > to
> > operate on.
> > 
> > It's not a matter of *if this can* be broken by someone who cares, it's a
> > matter of *how long does it take* for someone who cares to break it.
> > 
> > In the end, this is just another kind of "seems to be secure for a day or
> > two". Admittedly a complex one - but there will always be a "kid in a
> > garage" that is able to set everyone else out of business.
> > 
> > SaCu
> 
> Okay, a few points here:
> 
> First: On an abstract level, the key innovation in Secure Boot and
> driver signing is that it establishes a trust relationship between
> platform owner and platform firmware (using a so called Platform Key) as
> well as trust between operating system and platform firmware (using Key
> Exchange Keys).

You've said yourself, that "some removable media might not require signatures" 
in order to boot. Well, if that is the case, then isn't this defeating the 
whole point of Secure Boot at that stage?

> Under the assumption that the implementation is correct, nothing on the
> operating system level can inject drivers, boot loaders or whatever else
> into the firmware unless it is properly signed. The platform will not
> allow anything unless it is bit-by-bit verified to come from the
> platform owner or a trusted third party. The recommended algorithms for
> signing and verifying code are SHA-256 and RSA-2048. Good luck breaking
> that in "a day or two"!
> 
> Second point: Secure Boot is not designed to protect against an attacker
> with physical access to the machine. So you can leave your soldering
> iron and memory stick at home when you try to prove that Secure Boot can
> be broken.

I was under the impression that it should at least help in that scenario. 
OTOH, if it takes a compromised system or physical access to the machine in 
order to manipulate the boot sequence, then I no longer understand what the 
boot sequence in such a system must be protected against (Assuming that the 
primary reason for boot sequence manipulation is to later on compromise the 
system).

> Third point: Of course Secure Boot will be broken! A mainboard maker
> will screw up, there will be a bug in the specs or RSA will be broken.
> And when one of these happens, it will be fixed. Plain and simple. We
> didn't abandon SSL just because version 1 and 2 were broken. Why should
> we abandon Secure Boot?

"Plain and simple" here probably means, that all (at least many) sold system 
up to that date are downgraded to "unsecure". Not every user out there is 
reachable by any channel telling that it is just now a hard requirement to 
update the system - and even getting the message to the user won't cause 100% 
of the reached users to go that upgrade path.

SaCu

Re: [gentoo-dev] Re: UEFI secure boot and Gentoo

[Graham Murray]

Sascha Cunz <sascha-ml@babbelbox.org> writes:

> You've said yourself, that "some removable media might not require signatures" 
> in order to boot. Well, if that is the case, then isn't this defeating the 
> whole point of Secure Boot at that stage?

Not necessarily. As has been stated previously, secure boot is not
intended to protect against an attacker who has physical access. So even
if allowing boot from removable media, it does protect against malware
which corrupts/infects the hard drive boot image.

Re: [gentoo-dev] Re: UEFI secure boot and Gentoo

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 4776 bytes --]

Am 17.06.2012 20:56, schrieb Sascha Cunz:
> On Sunday, 17. June 2012 20:00:51 Florian Philipp wrote:
>> Am 17.06.2012 19:34, schrieb Sascha Cunz:
>>> [...]
>>>
>>>> It doesn't. It's just a very long wooden fence; you just didn't find
>>>> the hole yet.
>>>
>>> Given the fact that the keys in the BIOS must somehow get there and it
>>> must
>>> also be able to update them (how to revoke or add keys else?).
>>>
>>> Unless this is completely done in hardware, there must be a software doing
>>> it. Software can - by design - be reverse engineered; in some countries
>>> even legally without any further agreement or license.
>>>
>>> So, you can sign, encrypt, obfuscate or use some other foobar-mechanism on
>>> this blob of software - at some point it must be readable from the
>>> processor, so you have to provide the mechanisms to verify signs, undo
>>> encryption etc somewhere (either in hardware or another software).
>>>
>>> Even if you somehow manage to embed all of this in the hardware stack, it
>>> would still require some kind of interface to get updated / revoked keys
>>> to
>>> operate on.
>>>
>>> It's not a matter of *if this can* be broken by someone who cares, it's a
>>> matter of *how long does it take* for someone who cares to break it.
>>>
>>> In the end, this is just another kind of "seems to be secure for a day or
>>> two". Admittedly a complex one - but there will always be a "kid in a
>>> garage" that is able to set everyone else out of business.
>>>
>>> SaCu
>>
>> Okay, a few points here:
>>
>> First: On an abstract level, the key innovation in Secure Boot and
>> driver signing is that it establishes a trust relationship between
>> platform owner and platform firmware (using a so called Platform Key) as
>> well as trust between operating system and platform firmware (using Key
>> Exchange Keys).
> 
> You've said yourself, that "some removable media might not require signatures" 
> in order to boot. Well, if that is the case, then isn't this defeating the 
> whole point of Secure Boot at that stage?
> 

No. If that was the case, then UEFI shouldn't allow deactivating Secure
Boot, should it? Secure Boot's primary purpose is to prevent malware
from installing itself into the bootloader or (by extension) the kernel
image.

>> Under the assumption that the implementation is correct, nothing on the
>> operating system level can inject drivers, boot loaders or whatever else
>> into the firmware unless it is properly signed. The platform will not
>> allow anything unless it is bit-by-bit verified to come from the
>> platform owner or a trusted third party. The recommended algorithms for
>> signing and verifying code are SHA-256 and RSA-2048. Good luck breaking
>> that in "a day or two"!
>>
>> Second point: Secure Boot is not designed to protect against an attacker
>> with physical access to the machine. So you can leave your soldering
>> iron and memory stick at home when you try to prove that Secure Boot can
>> be broken.
> 
> I was under the impression that it should at least help in that scenario. 
> OTOH, if it takes a compromised system or physical access to the machine in 
> order to manipulate the boot sequence, then I no longer understand what the 
> boot sequence in such a system must be protected against (Assuming that the 
> primary reason for boot sequence manipulation is to later on compromise the 
> system).
> 

Well, it does help, especially when you also prevent changing UEFI
settings with a password. However, there are so many variables and
possibilities when talking about attacks on physically accessible
systems, that you're usually screwed anyway.

Again, the point is that malware, even if it gets temporary access to
your system, even if it gets root access, cannot install itself into the
boot process. It cannot persist in kernel space.

>> Third point: Of course Secure Boot will be broken! A mainboard maker
>> will screw up, there will be a bug in the specs or RSA will be broken.
>> And when one of these happens, it will be fixed. Plain and simple. We
>> didn't abandon SSL just because version 1 and 2 were broken. Why should
>> we abandon Secure Boot?
> 
> "Plain and simple" here probably means, that all (at least many) sold system 
> up to that date are downgraded to "unsecure". Not every user out there is 
> reachable by any channel telling that it is just now a hard requirement to 
> update the system - and even getting the message to the user won't cause 100% 
> of the reached users to go that upgrade path.
> 

Yes, you are right here. But ultimately, any bugs will be fixed. Even if
it means waiting for the next device generation.

Regards,
Florian Philipp



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] Re: UEFI secure boot and Gentoo

[Rich Freeman]

On Sun, Jun 17, 2012 at 4:30 PM, Florian Philipp <lists@binarywings.net> wrote:
> Am 17.06.2012 20:56, schrieb Sascha Cunz:
>> I was under the impression that it should at least help in that scenario.
>> OTOH, if it takes a compromised system or physical access to the machine in
>> order to manipulate the boot sequence, then I no longer understand what the
>> boot sequence in such a system must be protected against (Assuming that the
>> primary reason for boot sequence manipulation is to later on compromise the
>> system).
>>
>
> Well, it does help, especially when you also prevent changing UEFI
> settings with a password. However, there are so many variables and
> possibilities when talking about attacks on physically accessible
> systems, that you're usually screwed anyway.

I'd view secure boot as complementary to TPM.

TPM keeps somebody with physical access from being able to access
important information on your computer, since that data would be
encrypted and the keys would not be surrendered by the TPM module
without a proper chain of trust.

TPM is potentially more secure, although it has a fatal flaw in that
if the OS is compromised then the keys can be obtained (since the OS
needs the keys to access the disk) and a trojan can be installed on
the bootloader.  That trojan is difficult to remove or even detect
even if you update your virus scanners/etc.  Secure boot keeps trojans
out of the early boot chain, making them easier to clean up once your
system is further updated.

Secure boot is also somewhat easier to implement, and a bit more
recoverable if things go wrong.  If you're using TPM and trusted grub
and all that, then if you mess up your trusted boot chain then you may
never get back the contents of your drive, unless you kept a copy of
various keys elsewhere.

Rich

Re: [gentoo-dev] Re: UEFI secure boot and Gentoo

[George Prowse]

[-- Attachment #1: Type: text/plain, Size: 151 bytes --]

The Reg has a story on this from a blog post by Red Hat. It may be worth a
read:

http://www.theregister.co.uk/2012/01/18/windows_8_linux_secure_boot/

[-- Attachment #2: Type: text/html, Size: 259 bytes --]

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Chí-Thanh Christopher Nguyễn]

Greg KH schrieb:
> 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?
> 
> Minor details like, "do we have a 'company' that can pay Microsoft to
> sign our bootloader?" is one aspect from the non-technical side that I've
> been wondering about.

For the current crop of hardware, it is probably sufficient to add a
paragraph to the handbook which tells the user to disable secure boot.

Getting users' self-compiled boot loaders signed with a Gentoo key is
probably infeasible.

If you have influence on UEFI secure boot spec, you could suggest that
they mandate a UI which lists all boot images known to the EFI boot
manager, and the user can easily whitelist both individual loaders and
the keys used to sign them.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Luca Barbato]

On 06/15/2012 06:57 AM, Chí-Thanh Christopher Nguyễn wrote:
> Greg KH schrieb:
>> 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?
>>
>> Minor details like, "do we have a 'company' that can pay Microsoft to
>> sign our bootloader?" is one aspect from the non-technical side that I've
>> been wondering about.
> 
> For the current crop of hardware, it is probably sufficient to add a
> paragraph to the handbook which tells the user to disable secure boot.
> 
> Getting users' self-compiled boot loaders signed with a Gentoo key is
> probably infeasible.
> 
> If you have influence on UEFI secure boot spec, you could suggest that
> they mandate a UI which lists all boot images known to the EFI boot
> manager, and the user can easily whitelist both individual loaders and
> the keys used to sign them.
> 

That would be a good compromise.


-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Rich Freeman]

On Fri, Jun 15, 2012 at 8:18 AM, Luca Barbato <lu_zero@gentoo.org> wrote:
> On 06/15/2012 06:57 AM, Chí-Thanh Christopher Nguyễn wrote:
>> If you have influence on UEFI secure boot spec, you could suggest that
>> they mandate a UI which lists all boot images known to the EFI boot
>> manager, and the user can easily whitelist both individual loaders and
>> the keys used to sign them.
>>
>
> That would be a good compromise.
>

Agreed, though MS is likely to be sensitive about how this is done.
One of their requirements:
System.Fundamentals.Firmware.UEFISecureBoot / 14:
Mandatory. No in-line mechanism is provided whereby a user can bypass
Secure Boot failures and boot anyway Signature verification override
during boot when Secure Boot is enabled is not allowed. A physically
present user override is not permitted for UEFI images that fail
signature verification during boot. If a user wants to boot an image
that does not pass signature verification, they must explicitly
disable Secure Boot on the target system.

Sounds like they want to make getting around signature issues a fairly
technical exercise.  This of course raises the barrier to loading
another OS, though to be fair the "Stuxnet wants to access your boot
sector - hit OK to allow or Cancel to not display the cute video your
friend sent you" options that are typical these days hasn't really
been very effective in keeping out malware.

Rich

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Greg KH]

On Fri, Jun 15, 2012 at 06:57:06AM +0200, Chí-Thanh Christopher Nguyễn wrote:
> If you have influence on UEFI secure boot spec, you could suggest that
> they mandate a UI which lists all boot images known to the EFI boot
> manager, and the user can easily whitelist both individual loaders and
> the keys used to sign them.

That has already been attempted, and it failed, so it will not happen,
sorry.

greg k-h

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 659 bytes --]

On Fri, 15 Jun 2012 16:56:52 -0700
Greg KH <gregkh@gentoo.org> wrote:

> On Fri, Jun 15, 2012 at 06:57:06AM +0200, Chí-Thanh Christopher
> Nguyễn wrote:
> > If you have influence on UEFI secure boot spec, you could suggest
> > that they mandate a UI which lists all boot images known to the EFI
> > boot manager, and the user can easily whitelist both individual
> > loaders and the keys used to sign them.
> 
> That has already been attempted, and it failed, so it will not happen,
> sorry.

We can still have some hope that EU is going to bounce this for a while
like they did with Internet Explorer.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Rich Freeman]

On Fri, Jun 15, 2012 at 12:28 AM, Greg KH <gregkh@gentoo.org> wrote:
> Should I worry about this and how it affects Gentoo, or not worry about
> Gentoo right now and just focus on the other issues?
>
> Minor details like, "do we have a 'company' that can pay Microsoft to
> sign our bootloader?" is one aspect from the non-technical side that I've
> been wondering about.

So, there are 22 posts already, so I'm going to try to cover a bunch
of topics in one post.  I've been thinking about this a fair bit.

1.  Speaking as an individual trustee...  The Gentoo Foundation
legally speaks for Gentoo, can sign contracts, and can write checks.
I don't really forsee any legal issues should we decide we want to
pursue any kinds of relationships with MS or other entities associated
with UEFI.  Obviously any decision to actually pursue this would not
be taken lightly.

2.  From what I've heard the cost of getting a key that would be
recognized by UEFI firmware is as low as a $99 one-time payment, and
we pay many times that for stuff like trademark registration,
corporate filing fees, not to mention hardware for infrastructure.
Cost is likely a non-issue.

3.  Freedom IS a big issue - my sense is that getting support from the
powers that be for UEFI comes with a lot of strings.  If we had a key
the easiest solution would be to just write a signed GRUB stage1 that
works exactly like the one we're all using, and it would load whatever
you want, linux or windows or Stuxnet or otherwise.  Once Malware
writers start embedding our bootloader in their stuff I assume that
the people issuing the keys will have the ability to revoke it (at
least for new hardware).

4.  Fedora is getting around #3 by making the whole thing a big
trusted infrastructure - signature chains for all the kernel-space
code.  That meshes well with their whole /usr move initiative - you
just have this big blog of stuff that you trust and never touch, and
you can be sure you're running genuine RedHat goodness, just like all
those iPhone users out there.  :)

5.  If somebody (perhaps under the umbrella of hardened) wanted to
create a Gentoo project around a fully trusted Gentoo I'd be
completely supportive of that.  It would take work.  In the spirit of
Gentoo we should allow anybody to build their own signed with their
own key, and perhaps we might have an official Gentoo-certified one
that we would sign and the Foundation would obtain the necessary UEFI
keys.  However, that should be viewed as more of a service, and not a
core offering - Gentoo will never depend on a piece of non-free
software or metadata (and I'd probably lump a signing key into that
category).  The same tools (minus the private keys) used to generate
any secure offering made by Gentoo should be available for users to
use and sign their own systems.

6.  At least on x86 users can either disable secure boot, or load
their own signing keys.  We should try to support both.  While the
full secure infrastructure of #5 will undoubtedly be a significant
effort we could at least have the handbook have a section on how to
sign your grub when building it and install it in a way that it can be
used to boot (installing the keys themselves might be
firmware-dependent, but to the extent that standards exist we can be
helpful).

7.  In general anybody who would be a happy Gentoo user should have no
issues with signing their own bootloader, or disabling secure boot.

8.  I think the bigger issue is with ARM, and I'm not personally clear
on what the exact policy is there.  That really strikes me as
antitrust, but MS might argue that on ARM they have no monopoly
(instead we have a bunch of different vendors who almost universally
lock down their hardware).  I can't really see how any solution that
didn't give the end-user the ability to run arbitrary code on their
machine could be called "Gentoo" so our ability to distribute signed
bootloaders there is going to be limited.  Maybe we create the ability
to sign your own as with x86, and make the users pay the $99 for their
own keys.  As long as individual users don't distribute their
"insecure" bootloaders they shouldn't be at risk of getting them
revoked.

Well, that's a lot, but those are my impressions.  In short I see this
as more of a speed-bump for x86, but a much more fundamental problem
for ARM.  Personally I never buy a general-purpose computing device
like a PC or smartphone unless I know in advance that I can gain full
control over it.  Hopefully that option will remain open to me a lot
longer.

I'd be personally interested in pointers to info on what the "powers
that be" do and don't allow with UEFI.  I've seen lots of
sky-is-falling blog entries and discussion but little in the way of
specs, and more importantly, policies.

Rich

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Florian Philipp]

[-- Attachment #1: Type: text/plain, Size: 713 bytes --]

Am 15.06.2012 12:14, schrieb Rich Freeman:
[...]

+1 for your assessment so far.

> 
> I'd be personally interested in pointers to info on what the "powers
> that be" do and don't allow with UEFI.  I've seen lots of
> sky-is-falling blog entries and discussion but little in the way of
> specs, and more importantly, policies.
> 
> Rich
> 

Specs and user manuals can be found here:
http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=EDK_II_User_Documentation

More detailed specs can be found on http://www.uefi.org
The UEFI Specification v. 2.3.1 contains details on Secure Boot.

I wasn't able to locate any official policies or best practices.

Regards,
Florian Philipp


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Luca Barbato]

On 06/15/2012 12:14 PM, Rich Freeman wrote:
> 5.  If somebody (perhaps under the umbrella of hardened) wanted to
> create a Gentoo project around a fully trusted Gentoo I'd be
> completely supportive of that.  It would take work.  In the spirit of
> Gentoo we should allow anybody to build their own signed with their
> own key, and perhaps we might have an official Gentoo-certified one
> that we would sign and the Foundation would obtain the necessary UEFI
> keys.  However, that should be viewed as more of a service, and not a
> core offering - Gentoo will never depend on a piece of non-free
> software or metadata (and I'd probably lump a signing key into that
> category).  The same tools (minus the private keys) used to generate
> any secure offering made by Gentoo should be available for users to
> use and sign their own systems.

If we want to try to get serious on 5, we could try to gather the
hardened/security people across distributions and setup the whole chain
to be parallel and cut deals with OEM to store this trust-chain keys
along with MS.

lu


-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Rich Freeman]

On Fri, Jun 15, 2012 at 8:22 AM, Luca Barbato <lu_zero@gentoo.org> wrote:
> If we want to try to get serious on 5, we could try to gather the
> hardened/security people across distributions and setup the whole chain
> to be parallel and cut deals with OEM to store this trust-chain keys
> along with MS.

Perhaps.  Since we're only talking about the kernel really and that
doesn't vary as much across distros, we might even be able to get
momentum for it.

You could create a standard "secure kernel" - probably as a patch set
initially but perhaps merged into mainline with a config option that
turns on key verification for loading modules.  Anybody could use that
to secure their own systems by using their own key in the
configuration.  The central body could prepare and sign binaries for
individual distros.  A distro would supply a kernel config file and
patch set and identifier for the upstream kernel to build against.
The central body would audit the patches and config for security,
build the kernel, and sign it, assessing a fee perhaps (likely cheap
for config-only, and expensive for extensive patches).  The costs need
not be all that high - if you assume that vanilla linux with the
config option turned on is good enough then you only have to check
that the option is set, blacklist "bad" settings, and verify patches.
They could revoke certs when security issues are found, by keeping a
history of what configs/versions got signed.

Users could load the signing key of this body into their custom
settings, or OEMs could be persuaded to include it.  The latter would
never be 100% effective unless a court ordered it.

Rich

Re: [gentoo-dev] UEFI secure boot and Gentoo

[G.Wolfe Woodbury]

On 06/15/2012 06:14 AM, Rich Freeman wrote:
> 8. I think the bigger issue is with ARM, and I'm not personally clear 
> on what the exact policy is there. That really strikes me as 
> antitrust, but MS might argue that on ARM they have no monopoly 
> (instead we have a bunch of different vendors who almost universally 
> lock down their hardware).
This requirement by M$ is applied to hardware that wants the "Certified 
for Windows 8" logo. If the OEMs don't care about windows 8 
certification, they can provide for UEIF secure boot disabling. Since it 
is a "voluntary" acceptance in return for granting a consumer-fooling 
certification, they get away with an anti-competetive practice.  They 
want to keep android off hardware used for Windows 8.
Always follow the money.

-- 
G.Wolfe Woodbury

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Greg KH]

On Fri, Jun 15, 2012 at 06:14:12AM -0400, Rich Freeman wrote:
> On Fri, Jun 15, 2012 at 12:28 AM, Greg KH <gregkh@gentoo.org> wrote:
> > Should I worry about this and how it affects Gentoo, or not worry about
> > Gentoo right now and just focus on the other issues?
> >
> > Minor details like, "do we have a 'company' that can pay Microsoft to
> > sign our bootloader?" is one aspect from the non-technical side that I've
> > been wondering about.
> 
> So, there are 22 posts already, so I'm going to try to cover a bunch
> of topics in one post.  I've been thinking about this a fair bit.
> 
> 1.  Speaking as an individual trustee...  The Gentoo Foundation
> legally speaks for Gentoo, can sign contracts, and can write checks.
> I don't really forsee any legal issues should we decide we want to
> pursue any kinds of relationships with MS or other entities associated
> with UEFI.  Obviously any decision to actually pursue this would not
> be taken lightly.

Great to know that this could work, if needed.

> 2.  From what I've heard the cost of getting a key that would be
> recognized by UEFI firmware is as low as a $99 one-time payment, and
> we pay many times that for stuff like trademark registration,
> corporate filing fees, not to mention hardware for infrastructure.
> Cost is likely a non-issue.

Yes, it's cheap.

> 3.  Freedom IS a big issue - my sense is that getting support from the
> powers that be for UEFI comes with a lot of strings.  If we had a key
> the easiest solution would be to just write a signed GRUB stage1 that
> works exactly like the one we're all using, and it would load whatever
> you want, linux or windows or Stuxnet or otherwise.  Once Malware
> writers start embedding our bootloader in their stuff I assume that
> the people issuing the keys will have the ability to revoke it (at
> least for new hardware).

Yes, we need to provide some way to "secure" our key, which might prove
impossible and foolish for Gentoo to even attempt, as it really wouldn't
work out for us.

> 4.  Fedora is getting around #3 by making the whole thing a big
> trusted infrastructure - signature chains for all the kernel-space
> code.  That meshes well with their whole /usr move initiative - you
> just have this big blog of stuff that you trust and never touch, and
> you can be sure you're running genuine RedHat goodness, just like all
> those iPhone users out there.  :)

The whole chain-of-trust is an interesting issue as the UEFI spec does
not require it at all, and some people on the UEFI committee have told
me that it is not required either.  But, others have.  Getting to the
root of this problem is something I'm trying to do, as it's a very
important one for anyone who is going to be trusting, and providing, a
key in the BIOS.

> 5.  If somebody (perhaps under the umbrella of hardened) wanted to
> create a Gentoo project around a fully trusted Gentoo I'd be
> completely supportive of that.  It would take work.  In the spirit of
> Gentoo we should allow anybody to build their own signed with their
> own key, and perhaps we might have an official Gentoo-certified one
> that we would sign and the Foundation would obtain the necessary UEFI
> keys.  However, that should be viewed as more of a service, and not a
> core offering - Gentoo will never depend on a piece of non-free
> software or metadata (and I'd probably lump a signing key into that
> category).  The same tools (minus the private keys) used to generate
> any secure offering made by Gentoo should be available for users to
> use and sign their own systems.

That would mean we would be in the business of creating binary packages,
which is a big change from what we have been doing all of these years,
and not to be taken lightly.

> 6.  At least on x86 users can either disable secure boot, or load
> their own signing keys.  We should try to support both.

Yes.

> While the full secure infrastructure of #5 will undoubtedly be a
> significant effort we could at least have the handbook have a section
> on how to sign your grub when building it and install it in a way that
> it can be used to boot (installing the keys themselves might be
> firmware-dependent, but to the extent that standards exist we can be
> helpful).

Yes.

> 
> 7.  In general anybody who would be a happy Gentoo user should have no
> issues with signing their own bootloader, or disabling secure boot.

We have not seen how most BIOSes will allow this to happen, so I can't
agree with this statement just yet.

> 8.  I think the bigger issue is with ARM, and I'm not personally clear
> on what the exact policy is there.  That really strikes me as
> antitrust, but MS might argue that on ARM they have no monopoly
> (instead we have a bunch of different vendors who almost universally
> lock down their hardware).  I can't really see how any solution that
> didn't give the end-user the ability to run arbitrary code on their
> machine could be called "Gentoo" so our ability to distribute signed
> bootloaders there is going to be limited.  Maybe we create the ability
> to sign your own as with x86, and make the users pay the $99 for their
> own keys.  As long as individual users don't distribute their
> "insecure" bootloaders they shouldn't be at risk of getting them
> revoked.

I'm not worried about ARM just yet, things are in play to make this
possibly a non-issue, but I can't say so for sure at this point in time.
Just be assured that people at ARM know about the problem and are
working to resolve it.

> Well, that's a lot, but those are my impressions.  In short I see this
> as more of a speed-bump for x86, but a much more fundamental problem
> for ARM.

It's a big speed-bump for x86, it's going to be a bunch of work and
documentation to get right.

> I'd be personally interested in pointers to info on what the "powers
> that be" do and don't allow with UEFI.  I've seen lots of
> sky-is-falling blog entries and discussion but little in the way of
> specs, and more importantly, policies.

You have pointers to the specs now, feel free to fall asleep while
reading them :)

thanks,

greg k-h

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Rich Freeman]

On Fri, Jun 15, 2012 at 7:55 PM, Greg KH <gregkh@gentoo.org> wrote:
> On Fri, Jun 15, 2012 at 06:14:12AM -0400, Rich Freeman wrote:
> The whole chain-of-trust is an interesting issue as the UEFI spec does
> not require it at all, and some people on the UEFI committee have told
> me that it is not required either.  But, others have.  Getting to the
> root of this problem is something I'm trying to do, as it's a very
> important one for anyone who is going to be trusting, and providing, a
> key in the BIOS.

It sounds like the UEFI committee isn't really the problem here.  You
can have a UEFI firmware as long as it follows the spec.  However, you
won't get the Windows logo certification if you don't follow the
Windows rules.

I would think they'd basically want a chain of trust for anything that
loads into kernel space.  Otherwise all a malware author has to do is
ship a signed linux kernel, have it boot a bash script that loads
their malware via an unsigned kernel module, and then at that point
they just intercept whatever they want to and then boot Windows,
discarding the rest of the linux kernel.

However, even the MS requirements say that an OEM can have other keys
as well, and nothing says that all of them need to be secure (other
than the root key).  If I published a keypair on the internet and
persuaded OEMs to include it as trusted, then in theory that would
pass the MS requirements as they are currently written, and would
render secure boot meaningless.

Rich

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Greg KH]

On Fri, Jun 15, 2012 at 08:41:47PM -0400, Rich Freeman wrote:
> On Fri, Jun 15, 2012 at 7:55 PM, Greg KH <gregkh@gentoo.org> wrote:
> > On Fri, Jun 15, 2012 at 06:14:12AM -0400, Rich Freeman wrote:
> > The whole chain-of-trust is an interesting issue as the UEFI spec does
> > not require it at all, and some people on the UEFI committee have told
> > me that it is not required either.  But, others have.  Getting to the
> > root of this problem is something I'm trying to do, as it's a very
> > important one for anyone who is going to be trusting, and providing, a
> > key in the BIOS.
> 
> It sounds like the UEFI committee isn't really the problem here.  You
> can have a UEFI firmware as long as it follows the spec.  However, you
> won't get the Windows logo certification if you don't follow the
> Windows rules.

That is exactly the case.

> I would think they'd basically want a chain of trust for anything that
> loads into kernel space.  Otherwise all a malware author has to do is
> ship a signed linux kernel, have it boot a bash script that loads
> their malware via an unsigned kernel module, and then at that point
> they just intercept whatever they want to and then boot Windows,
> discarding the rest of the linux kernel.

Yes, that is the problem we are facing.

> However, even the MS requirements say that an OEM can have other keys
> as well, and nothing says that all of them need to be secure (other
> than the root key).  If I published a keypair on the internet and
> persuaded OEMs to include it as trusted, then in theory that would
> pass the MS requirements as they are currently written, and would
> render secure boot meaningless.

The liability requirements for an OEM to accept a key into their BIOS,
that is something other than Microsoft's key (if there is even the room,
some bioses will not have extra room for lots of keys), is beyond
anything that any Linux company can afford, or is willing to accept.

greg k-h

Re: [gentoo-dev] UEFI secure boot and Gentoo

[Matthew Summers]

On Thu, Jun 14, 2012 at 11:28 PM, Greg KH <gregkh@gentoo.org> 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?
>
> Minor details like, "do we have a 'company' that can pay Microsoft to
> sign our bootloader?" is one aspect from the non-technical side that I've
> been wondering about.
>
> thanks,
>
> greg k-h
>

Pardon my ignorance, but will we be requires to sign the boot
loader/kernel on our install media for a Win8 machine to boot the iso?

--
Matthew W. Summers
Gentoo Foundation Inc.

[gentoo-dev] Re: UEFI secure boot and Gentoo

[Duncan]

Matthew Summers posted on Sat, 16 Jun 2012 18:52:31 -0500 as excerpted:

> Pardon my ignorance, but will we be requires to sign the boot
> loader/kernel on our install media for a Win8 machine to boot the iso?

This was one of the issues covered early on.  Unless it has changed, no.  
Booting external media (at least optical, not sure about USB-mass-
storage, etc) bypasses the required signing, so that much, at least, 
should be safe.

An initial proposal in fact would have required booting optical media in 
ordered to disable the sig-checks, etc, but AFAIK that was deemed too 
disruptive, particularly for netbooks and etc that don't normally have 
built-in optical media at all.

It's worth noting that EFI can switch back to legacy mode for such 
things, and it's possible this exception is connected to el-torrito 
optical disk booting, tho I'm not sure on that.  That's why I've 
specified optical, above.  Direct-partitioned and bootable USB media may 
not be included.  I'm sure GKH or others who have been following it 
closer can fill in the details.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman