UEFI Secure Boot sprint report

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

UEFI Secure Boot sprint report

Tollef Fog Heen-3

People from the FTP team, kernel team and DSA, as well as other
interested individuals met in Fulda, Germany for a sprint with the goal
of deciding and implementing the workflow for Secure Boot.

Participants
------------
* Ansgar Burchardt
* Joerg Jaspert
* Luke W. Faraone
* Ben Hutchings
* Tollef Fog Heen
* Helen Koike
* Philipp Hahn
* Julien Cristau [remote]
* Steve McIntyre [remote]

We had a long discussion about what requirements we had for the
signing process, whether that could happen inline in the regular build
process, if a human needed to be involved in the signing and how to
best handle embargoed builds.

In the end, we decided to have a signing service which will construct
a source package based on a "template" package and a list of files to
sign and upload this to be processed by the normal buildd and dak
processes. The signing service will also have an audit log which makes
it public what was signed and when.

Once this was agreed and various corner cases ironed out, we started
implementing the signing service, and the necessary changes in the
Linux kernel package, dak, fwupdate, shim and grub. The source for the
signing service can be found at
https://salsa.debian.org/ftp-team/code-signing.

By the end of the sprint, we were able to:
- generate a signing template for Linux kernel modules
- generate a signing template for shim
- generate a signing template for fwupdate
- have DAK detect such signing template packages automatically and
  generate a request for signing
- run the code of the signing box by hand to generate the source code
  packages containing the generated signatures

We're still missing (partially or completely):
- generate a signing template for GRUB2
- have DAK accept those generated source-only uploads

Acknowledgements
-------------------------
the sprint has been possible thanks to:
- the Office Factory for hosting us,
- donations to the Debian project for covering travel and
  accommodation costs for the sprint,
- Dropbox for sponsoring Luke's travel and accomodations,
- Technische Universität Dresden for sponsoring Ansgar's travel and
  accomodations, and
- Univention GmbH for sponsoring Philipp's travel and accomodations,

--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Reply | Threaded
Open this post in threaded view
|

Re: UEFI Secure Boot sprint report

Ian Jackson-2
Tollef Fog Heen writes ("UEFI Secure Boot sprint report"):
> In the end, we decided to have a signing service which will construct
> a source package based on a "template" package and a list of files to
> sign and upload this to be processed by the normal buildd and dak
> processes. The signing service will also have an audit log which makes
> it public what was signed and when.

Thanks for the update.

> Once this was agreed and various corner cases ironed out, we started
> implementing the signing service, and the necessary changes in the
> Linux kernel package, dak, fwupdate, shim and grub. The source for the
> signing service can be found at
> https://salsa.debian.org/ftp-team/code-signing.

One small point: Do you think tht the source for the signing service
is part of the source for the signed output ?  If so it probably needs
to be in the Debian archive, not just on salsa.  Sorry if this is
inconvenient.

> By the end of the sprint, we were able to:
> - generate a signing template for Linux kernel modules
> - generate a signing template for shim
> - generate a signing template for fwupdate
> - have DAK detect such signing template packages automatically and
>   generate a request for signing
> - run the code of the signing box by hand to generate the source code
>   packages containing the generated signatures

Thanks for your work.

Regards,
Ian.

Reply | Threaded
Open this post in threaded view
|

Re: UEFI Secure Boot sprint report

Tollef Fog Heen
]] Ian Jackson

> > Once this was agreed and various corner cases ironed out, we started
> > implementing the signing service, and the necessary changes in the
> > Linux kernel package, dak, fwupdate, shim and grub. The source for the
> > signing service can be found at
> > https://salsa.debian.org/ftp-team/code-signing.
>
> One small point: Do you think tht the source for the signing service
> is part of the source for the signed output ?  If so it probably needs
> to be in the Debian archive, not just on salsa.  Sorry if this is
> inconvenient.

Not any more than sbuild, buildd and wanna-build is part of the source
for buildd-signed packages in the archive, so my initial answer is no.
That said, it would be trivial to package, so somebody could easily
upload it to the archive.

--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Reply | Threaded
Open this post in threaded view
|

Re: UEFI Secure Boot sprint report

Hideki Yamane-2
In reply to this post by Tollef Fog Heen-3
Hi,

> In the end, we decided to have a signing service which will construct
> a source package based on a "template" package and a list of files to
> sign and upload this to be processed by the normal buildd and dak
> processes. The signing service will also have an audit log which makes
> it public what was signed and when.

 I'm curious how this works.

 * source package was modified to generate <package>-$ARCH-signed-template
   binary package
 * dput it to repo and dak would pass to code sign service?
 * sign binary package??


 Please let know it or give an URL for it to help me to understand it,
 since I want to explain it on an article on Japanese tech magazine.


--
Regards,

 Hideki Yamane     henrich @ debian.org/iijmio-mail.jp

Reply | Threaded
Open this post in threaded view
|

Re: UEFI Secure Boot sprint report

Tollef Fog Heen
]] Hideki Yamane

> Hi,
>
> > In the end, we decided to have a signing service which will construct
> > a source package based on a "template" package and a list of files to
> > sign and upload this to be processed by the normal buildd and dak
> > processes. The signing service will also have an audit log which makes
> > it public what was signed and when.
>
>  I'm curious how this works.
>
>  * source package was modified to generate <package>-$ARCH-signed-template
>    binary package
>  * dput it to repo and dak would pass to code sign service?
>  * sign binary package??

The signing service is a source package builder.

I'll use linux as an example package.  It's uploaded to experimental and
builds the normal set of linux-image-* packages.  In addition, it builds
a package named linux-image-amd64-signed-template.  This matches a
filter on the dak side, so it is exposed in
https://incoming.debian.org/debian-buildd/project/external-signatures/requests.json
(+ .gpg for the signature) as «this needs to be signed».

The signing service polls that URL regularly, and when there is a new
package available, it is downloaded and unpacked into a temporary
directory.  It includes a manifest of what files from what packages need
to be signed.  Those packages are downloaded, the files in the manifest
are signed and the source package is built, signed and uploaded, to be
built by the regular buildds.

This allows us to both keep the key in a central place, having
reproducible builds, having an automated process and not having to
execute any code from the template package as part of the build.

I hope this explains it well enough, let me know if there's anything
unclear, I'm happy to explain further.

Cheers,
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Reply | Threaded
Open this post in threaded view
|

Re: Re: UEFI Secure Boot sprint report

Hideki Yamane-2
Hi,

 Thanks, your explanation is really helpful.


> The signing service is a source package builder.

 It build source package but its source package is based on built binary package?
 As I understand, singing to binary is necessary step.

1. source package
2. -> upload to dak
3. -> passed to buildd
4. -> binary package built
5. -> singing service pull those
6. -> source package built
7. -> dak, again
8. -> buildd, again
9. -> dak passes those to repo


 And in previous report

> We're still missing (partially or completely):
> - generate a signing template for GRUB2
> - have DAK accept those generated source-only uploads

 This is 7th step in above, right?


--
Regards,

 Hideki Yamane     henrich @ debian.org/iijmio-mail.jp

Reply | Threaded
Open this post in threaded view
|

Re: Re: UEFI Secure Boot sprint report

Ben Hutchings-3
On Mon, 2018-05-14 at 22:05 +0900, Hideki Yamane wrote:
> Hi,
>
>  Thanks, your explanation is really helpful.
>
>
> > The signing service is a source package builder.
>
>  It build source package but its source package is based on built binary package?
>  As I understand, singing to binary is necessary step.

Right.

> 1. source package
> 2. -> upload to dak
> 3. -> passed to buildd
> 4. -> binary package built

And one of those binary packages is a "template" for the source
package.  This is documented on the Etherpad, but in short it contains
an unpacked source package with everything except the signatures, plus
a configuration file specifying which binaries in which packages need
to be signed.

> 5. -> singing service pull those
> 6. -> source package built

This is the template source package plus all the (detached) signatures
that were specified in the configuration.

> 7. -> dak, again
> 8. -> buildd, again

Here there are build-dependencies on the previously built binaries, and
the build process adds the detached signatures to those binaries.

> 9. -> dak passes those to repo
>
>
>  And in previous report
>
> > We're still missing (partially or completely):
> > - generate a signing template for GRUB2
> > - have DAK accept those generated source-only uploads
>
>  This is 7th step in above, right?
The second point (have DAK accept ...) is part of step 7, yes.  It
seems to have been implemented now.

Ben.

--
Ben Hutchings
For every action, there is an equal and opposite criticism. - Harrison

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: UEFI Secure Boot sprint report

Hideki Yamane-2
Hi,

 Thanks for the clarification, Ben. Very helpful.

On Mon, 14 May 2018 15:35:50 +0100
Ben Hutchings <[hidden email]> wrote:
> The second point (have DAK accept ...) is part of step 7, yes.  It
> seems to have been implemented now.

 Then, remaining blocker is only template for GRUB2?


--
Regards,

 Hideki Yamane     henrich @ debian.org/iijmio-mail.jp

Reply | Threaded
Open this post in threaded view
|

Re: UEFI Secure Boot sprint report

Ben Hutchings-3
On Tue, 2018-05-15 at 11:07 +0900, Hideki Yamane wrote:

> Hi,
>
>  Thanks for the clarification, Ben. Very helpful.
>
> On Mon, 14 May 2018 15:35:50 +0100
> Ben Hutchings <[hidden email]> wrote:
> > The second point (have DAK accept ...) is part of step 7, yes.  It
> > seems to have been implemented now.
>
>  Then, remaining blocker is only template for GRUB2?
For testing purposes, I think so.  I don't know whether GRUB implements
the policy we want at the moment.

We'll still need a "flag day" on which the signing service, and all
packages that get signed, switch to production signing keys.

Ben.

--
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: UEFI Secure Boot sprint report

Hideki Yamane-2
Hi,

On Tue, 15 May 2018 03:32:26 +0100
Ben Hutchings <[hidden email]> wrote:
> > > The second point (have DAK accept ...) is part of step 7, yes.  It
> > > seems to have been implemented now.
> >
> >  Then, remaining blocker is only template for GRUB2?
>
> For testing purposes, I think so.  I don't know whether GRUB implements
> the policy we want at the moment.

 Is there any issue to apply such policy to grub2 package, or just not
 discussed yet?

--
Regards,

 Hideki Yamane     henrich @ debian.org/iijmio-mail.jp

Reply | Threaded
Open this post in threaded view
|

Re: UEFI Secure Boot sprint report

Colin Watson
On Tue, May 15, 2018 at 11:46:00AM +0900, Hideki Yamane wrote:

> On Tue, 15 May 2018 03:32:26 +0100
> Ben Hutchings <[hidden email]> wrote:
> > > > The second point (have DAK accept ...) is part of step 7, yes.  It
> > > > seems to have been implemented now.
> > >
> > >  Then, remaining blocker is only template for GRUB2?
> >
> > For testing purposes, I think so.  I don't know whether GRUB implements
> > the policy we want at the moment.
>
>  Is there any issue to apply such policy to grub2 package, or just not
>  discussed yet?

Either nobody's tried to discuss it with me yet or I missed the email.
Feel free to (preferably in the form of a patch I can review :-) ).

--
Colin Watson                                       [[hidden email]]

Reply | Threaded
Open this post in threaded view
|

Re: UEFI Secure Boot sprint report

Steve McIntyre
On Tue, May 15, 2018 at 04:16:22AM +0100, Colin Watson wrote:

>On Tue, May 15, 2018 at 11:46:00AM +0900, Hideki Yamane wrote:
>> On Tue, 15 May 2018 03:32:26 +0100
>> Ben Hutchings <[hidden email]> wrote:
>> > > > The second point (have DAK accept ...) is part of step 7, yes.  It
>> > > > seems to have been implemented now.
>> > >
>> > >  Then, remaining blocker is only template for GRUB2?
>> >
>> > For testing purposes, I think so.  I don't know whether GRUB implements
>> > the policy we want at the moment.
>>
>>  Is there any issue to apply such policy to grub2 package, or just not
>>  discussed yet?
>
>Either nobody's tried to discuss it with me yet or I missed the email.
>Feel free to (preferably in the form of a patch I can review :-) ).

At / shortly after the sprint, Philipp (in CC) had patches basically
ready for grub2, but he seems to have gone quiet. <prod>

--
Steve McIntyre, Cambridge, UK.                                [hidden email]
You lock the door
And throw away the key
There's someone in my head but it's not me

Reply | Threaded
Open this post in threaded view
|

Re: UEFI Secure Boot sprint report

Philipp Hahn
Moin,

Am 15.05.2018 um 11:41 schrieb Steve McIntyre:

> On Tue, May 15, 2018 at 04:16:22AM +0100, Colin Watson wrote:
>> On Tue, May 15, 2018 at 11:46:00AM +0900, Hideki Yamane wrote:
>>> On Tue, 15 May 2018 03:32:26 +0100 Ben Hutchings <[hidden email]> wrote:
>>>>>> The second point (have DAK accept ...) is part of step 7, yes.  It
>>>>>> seems to have been implemented now.
>>>>>
>>>>>  Then, remaining blocker is only template for GRUB2?
>>>>
>>>> For testing purposes, I think so.  I don't know whether GRUB implements
>>>> the policy we want at the moment.

@benh: you meat to *only* boot signed stuff and not fall back to
disabling SB before booting an unsigned kernel?
That should be addressed by
<https://salsa.debian.org/pmhahn/grub/commit/fe06193ff5a36ee6aa6a6cab12f4651b6290d91b>

>>>  Is there any issue to apply such policy to grub2 package, or just not
>>>  discussed yet?
>>
>> Either nobody's tried to discuss it with me yet or I missed the email.
>> Feel free to (preferably in the form of a patch I can review :-) ).
>
> At / shortly after the sprint, Philipp (in CC) had patches basically
> ready for grub2, but he seems to have gone quiet. <prod>

I was busy working on our release, which took all my time.
And I'm not subscribed to debian-project.

My last work it at <https://salsa.debian.org/pmhahn/grub/tree/signing>.
In the week after the sprint I worked on GRUB2 and got it so far to have
the signed amd64 package - so at the time of writing the sprint report
GRUB2 was already ready.

I haven't yet found time to setup an UEFI-SB test environment to check
that everything works.

I haven't yet tested any other architecture != amd64.

@Colin: Please have a look at said repository above.
What I'm currently unsure about is that amd64 has those ia32 packages as
well - it should work but also untested.
My reading is that those are required for dual booting?

Philipp

Reply | Threaded
Open this post in threaded view
|

Re: UEFI Secure Boot sprint report

Ben Hutchings-3
On Wed, 2018-05-16 at 10:05 +0200, Philipp Hahn wrote:

> Moin,
>
> Am 15.05.2018 um 11:41 schrieb Steve McIntyre:
> > On Tue, May 15, 2018 at 04:16:22AM +0100, Colin Watson wrote:
> > > On Tue, May 15, 2018 at 11:46:00AM +0900, Hideki Yamane wrote:
> > > > On Tue, 15 May 2018 03:32:26 +0100 Ben Hutchings <[hidden email]> wrote:
> > > > > > > The second point (have DAK accept ...) is part of step 7, yes.  It
> > > > > > > seems to have been implemented now.
> > > > > >
> > > > > >  Then, remaining blocker is only template for GRUB2?
> > > > >
> > > > > For testing purposes, I think so.  I don't know whether GRUB implements
> > > > > the policy we want at the moment.
>
> @benh: you meat to *only* boot signed stuff and not fall back to
> disabling SB before booting an unsigned kernel?
> That should be addressed by
> <https://salsa.debian.org/pmhahn/grub/commit/fe06193ff5a36ee6aa6a6cab12f4651b6290d91b>
I think that's what we agreed, yes.

[...]
> I haven't yet found time to setup an UEFI-SB test environment to check
> that everything works.
[...]

It's fairly easy to do with OVMF; this blog entry summarises the
process:
https://www.decadent.org.uk/ben/blog/experiments-with-signed-kernels-and-modules-in-debian.html

Ben.

--
Ben Hutchings
Teamwork is essential - it allows you to blame someone else.

signature.asc (849 bytes) Download Attachment