[18.04 FEAT] Sign POWER host/NV kernels

------- Comment From <email address hidden> 2017-07-10 16:49 EDT-------
Hi Canonical,

Here are some clarifications on the feature from the security team:

> To clarify, this feature is only asking for a change to the Ubuntu kernel build
> process to produce a signed kernel and no other development. They should be able
> to do that with sign-file and the existing UEFI shim key."

In support to a full secure boot up to the payload OS in 2018, a signed kernel will be very nice to have for 17.10. Will you be able to sign the Ubuntu kernel for the 17.10 release?

Regards,
Vicky

------- Comment From <email address hidden> 2017-07-13 16:51 EDT-------
Hi Canonical,

Please let me know if there are any concerns on signing the the Ubuntu kernel for the 17.10 release.

Thanks,
Vicky

------- Comment From <email address hidden> 2017-07-18 17:15 EDT-------
Is there any update that you can share at the moment?

apw is assigned this bug, kernel/foundations team will turn on the signing on the kernel and push it to a PPA for your testing. As for priority.. It is next on apw's list after he clears validations for the point release.

------- Comment From <email address hidden> 2017-07-20 14:16 EDT-------
Canonical please clarify. I was on a call with Andrew Cloke earlier today. He said this could be done but not done in time for 17.10 GA in October. It would happen after 17.10 GA.

------- Comment From <email address hidden> 2017-07-20 17:52 EDT-------
Canonical please clarify. I was on a call with Andrew Cloke earlier today. He said this could be done but not done in time for 17.10 GA in October. It would happen after 17.10 GA.

Work is ongoing to clarify the timeline for enabling signed Power kernels.

One open technical question from the Canonical side: can you confirm that the POWER firmware implementation will support embedded certificate chains as part of the vmlinux signature data? Our existing SecureBoot signing regime uses an on-line signing key which is chained to a our CA certificate, and it is the latter that we would normally provide for db.

It appears that the kmodsign tools support embedded certificates in the signature data, but we would like to confirm that the firmware implementation is also compatible with this.

------- Comment From <email address hidden> 2017-08-01 19:06 EDT-------
(In reply to comment #15)
> One open technical question from the Canonical side: can you confirm that
> the POWER firmware implementation will support embedded certificate chains
> as part of the vmlinux signature data? Our existing SecureBoot signing
> regime uses an on-line signing key which is chained to a our CA certificate,
> and it is the latter that we would normally provide for db.
>
> It appears that the kmodsign tools support embedded certificates in the
> signature data, but we would like to confirm that the firmware
> implementation is also compatible with this.

It seems that the Canonical CA should be added to the KEK and the "on-line signing key" should be added to the DB.

In our current SecureBoot design, the vmlinux embedded signature will be verified only against the DB certificate list. However, in order to add a certificate to DB, the certificate should be signed by any of the KEK entries. The PK will be used to authorize updates to the KEK certificate list.

This has been deployed to dogfood. I have uploaded a package which generates a signing object containing a ppc64el binary kernel. This built and published as expected. After much playing I managed to confirm it was indeed signed as expected and by the key included with the result.

We generated a archive Opal signing key. Uploaded a full set of tests to the primary archive. Reviewed the results for all of these. Looking good. This is ready to deply.

Deployment to production seems successful. I have uploaded a modified kernel to a PPA and built a signed kernel image from that. I am attaching that signed kernel and the public key component of the signing key for it. NOTE: this key is _not_ a final official canonical key it is a key for a PPA and for testing only.

There are two files:

  vmlinux-4.11.0-13-generic.opal.signed -- this is the bootable signed binary
  opal.x509 -- the DER format public key with which this binary is signed

Any testing, review appreciated. Please report back to this bug.

Thanks for the guidance regarding KEK vs. db. One further question, is it correct that the POWER implementation will be limited to 2048-bit RSA keys, the same as UEFI SecureBoot?

Does IBM have any feedback for us regarding the test kernel Andy provided?

We have generated an online signing key to be included in db for OPAL. In the absence of feedback about whether 4096-bit keys are supported, we have generated a 2048-bit key.

Our current plan for secure delivery of the public key to IBM is to deliver the keys in person to George next month. Does this timeline fit IBM's needs for receipt of the public keys? Does it meet your expectations for a trust path for the keys, or is there another protocol that should be used?

In your reply of August 1, you wrote:

> However, in order to add a certificate to DB, the certificate should be
> signed by any of the KEK entries. The PK will be used to authorize updates
> to the KEK certificate list.

Can you please clarify if this means you are expecting the db entry to be delivered as an x509 certificate issued by the CA key listed in KEK, or if it should be delivered according to the format defined in the UEFI spec for authenticated variable updates?

------- Comment From <email address hidden> 2017-09-07 19:41 EDT-------
(In reply to comment #25)
> Does IBM have any feedback for us regarding the test kernel Andy provided?
>

We're planning to test this month. We'll give feedback as soon as the test is completed. The tentative target will be Sept. 29 or sooner.

> Can you please clarify if this means you are expecting the db entry to be
> delivered as an x509 certificate issued by the CA key listed in KEK, or if
> it should be delivered according to the format defined in the UEFI spec for
> authenticated variable updates?

Our team needs to have some discussions before finalizing the expected format. We'll get back to you soon. Thanks!

On Thu, Sep 07, 2017 at 11:50:09PM -0000, bugproxy wrote:
> ------- Comment From <email address hidden> 2017-09-07 19:41 EDT-------
> (In reply to comment #25)
> > Does IBM have any feedback for us regarding the test kernel Andy provided?

> We're planning to test this month. We'll give feedback as soon as the
> test is completed. The tentative target will be Sept. 29 or sooner.

> > Can you please clarify if this means you are expecting the db entry to be
> > delivered as an x509 certificate issued by the CA key listed in KEK, or if
> > it should be delivered according to the format defined in the UEFI spec for
> > authenticated variable updates?

> Our team needs to have some discussions before finalizing the expected
> format. We'll get back to you soon. Thanks!

Thanks. Do you have a timeline for when you will have this decision?
While we have procedures in place for signing/revoking keys whenever
necessary in the event of a key compromise, ordinarily this KEK key is not
available for signing. We have a window when we will be able to do this
signing from September 25 to September 29 and after that we do not have a
window scheduled until next year, so it would be good to know before then
what format you need this signed key matter to be provided in.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

------- Comment From <email address hidden> 2017-09-08 13:05 EDT-------
(In reply to comment #27)
> (In reply to comment #25)
> > Does IBM have any feedback for us regarding the test kernel Andy provided?
> >
>
> We're planning to test this month. We'll give feedback as soon as the test
> is completed. The tentative target will be Sept. 29 or sooner.
>
>
> > Can you please clarify if this means you are expecting the db entry to be
> > delivered as an x509 certificate issued by the CA key listed in KEK, or if
> > it should be delivered according to the format defined in the UEFI spec for
> > authenticated variable updates?
>
> Our team needs to have some discussions before finalizing the expected
> format. We'll get back to you soon. Thanks!

Our team confirms that it should be delivered according to ESL format.

Attached is the ESL db update for Canonical's POWER SecureBoot signing key. It is signed with Canonical's KEK key, which will be provided to IBM out of band to ensure integrity of the delivery channel.

------- Comment From <email address hidden> 2017-09-27 16:47 EDT-------
(In reply to comment #30)
> Attached is the ESL db update for Canonical's POWER SecureBoot signing key.
> It is signed with Canonical's KEK key, which will be provided to IBM out of
> band to ensure integrity of the delivery channel.

Thanks Andy and Vorlon for the attached files. The kernel appended signature verified successfully.

We didn't test the Canonical-POWER-SB-20170926.esl.signed file yet.

Questions:

1) The certificate provided contains a 4096-bit key and it was signed using sha512WithRSAEncryption. We had no problem to use it to verify the kernel appended signature - the kernel crypto API supports 4096-bit RSA keys. However, we don't have much space in our keystore and that's why we prefer to use 2048-bit RSA keys, same as UEFI SecureBoot. Could the Canonical-POWER-SB-20170926.esl.signed file be regenerated to contain a certificate that contains a 2048-bit RSA key instead? The certificate would be signed using sha256WithRSAEncryption.

2) We will need to put in the KEK a certificate that can be used to verify the signed ESL db updates provided by Canonical. How does Canonical have provided that for UEFI SecureBoot? certificate, ESL (not signed, since PK is not provided by Canonical)?
Currently, we are working on the code that will validate/process the authenticated variable updates. We will probably start testing it by the end of this year.

Thanks,
Claudio

Hi Claudio,

> ------- Comment From <email address hidden> 2017-09-27 16:47 EDT-------
> (In reply to comment #30)
> > Attached is the ESL db update for Canonical's POWER SecureBoot signing key.
> > It is signed with Canonical's KEK key, which will be provided to IBM out of
> > band to ensure integrity of the delivery channel.

> Thanks Andy and Vorlon for the attached files. The kernel appended
> signature verified successfully.

> We didn't test the Canonical-POWER-SB-20170926.esl.signed file yet.

> Questions:

> 1) The certificate provided contains a 4096-bit key and it was signed
> using sha512WithRSAEncryption. We had no problem to use it to verify the
> kernel appended signature - the kernel crypto API supports 4096-bit RSA
> keys. However, we don't have much space in our keystore and that's why
> we prefer to use 2048-bit RSA keys, same as UEFI SecureBoot. Could the
> Canonical-POWER-SB-20170926.esl.signed file be regenerated to contain a
> certificate that contains a 2048-bit RSA key instead? The certificate
> would be signed using sha256WithRSAEncryption.

The opal.x509 attachment is a test key only; it is not the same as
Canonical-POWER-SB-20170926.esl.signed, which is our production 2048-bit
key.

> 2) We will need to put in the KEK a certificate that can be used to verify
> the signed ESL db updates provided by Canonical. How does Canonical have
> provided that for UEFI SecureBoot? certificate, ESL (not signed, since PK
> is not provided by Canonical)? Currently, we are working on the code that
> will validate/process the authenticated variable updates. We will
> probably start testing it by the end of this year.

The current plan is to deliver this KEK as a certificate via a secure
in-person channel to George Wilson. I assume once delivered, if you need
this in ESL form for loading that IBM can perform this transformation (since
the only way to turn it into a signed ESL would be via the PK, which we
don't have).

------- Comment From <email address hidden> 2017-10-04 17:33 EDT-------
I have received the KEK from Emily in person.

------- Comment From <email address hidden> 2017-10-04 18:16 EDT-------
BTW, I learned from Emily that Canonical plans to issue Power keys/certs separately from those for the x86 UEFI shim. So moving from SHA-512 to SHA-256 may not be much of a priority from a reuse point of view. If we need any key changes, it would be good to send them before or during next week while Emily will be in NY meeting with vorlon.

On Thu, Oct 05, 2017 at 01:52:46AM -0000, bugproxy wrote:
> ------- Comment From <email address hidden> 2017-10-04 17:33 EDT-------
> I have received the KEK from Emily in person.

> ------- Comment From <email address hidden> 2017-10-04 18:16 EDT-------

> BTW, I learned from Emily that Canonical plans to issue Power keys/certs
> separately from those for the x86 UEFI shim. So moving from SHA-512 to
> SHA-256 may not be much of a priority from a reuse point of view. If we
> need any key changes, it would be good to send them before or during next
> week while Emily will be in NY meeting with vorlon.

Yes, if you need the hash changed from SHA512 to SHA256 on the 2048-bit db
key, please let us know this week so that we can arrange to have a new ESL
signed.

We believe the Launchpad side of this is done, so closing this task.

Thanks For Catching/Noticing and making repairs an adjustments

On Mon, Apr 23, 2018, 10:51 AM Launchpad Bug Tracker <
<email address hidden>> wrote:

> ** Branch linked: lp:~ubuntu-core-dev/debian-installer/ubuntu
>
> --
> You received this bug notification because you are subscribed to
> Launchpad itself.
> Matching subscriptions: Anthony
> https://bugs.launchpad.net/bugs/1696154
>
> Title:
> [18.04 FEAT] Sign POWER host/NV kernels
>
> Status in Launchpad itself:
> Fix Released
> Status in The Ubuntu-power-systems project:
> Fix Committed
> Status in linux package in Ubuntu:
> Fix Committed
> Status in linux-signed package in Ubuntu:
> Fix Committed
>
> Bug description:
> Feature Description:
>
> Sign POWER host and NV kernels with sign-file in anticipation of POWER
> secure boot. Provide the associated certificate. Ideally it would
> be possible to reuse the UEFI shim private key and certificate used to
> sign and verify x86_64 kernels. More details to follow. Guest
> kernels will be addressed in a future separate feature request.
>
>
> Business Case:
>
> As a system administrator I want to verify the integrity of my kernels
> so that I can prevent malicious kernels from being executed.
>
> Use Case:
>
> Signed POWER kernels will be validated by OPAL as OpenPOWER systems
> boot when keys are properly installed and the system is booted in
> secure mode.
>
>
> Test Case:
>
> Sign and install a POWER kernel on an OpenPOWER machine with a
> firmware level that supports secure boot. Install a PK, distro KEK
> certificat, and distro DB certificate. Boot the system and verify
> that it will boot the kernel. Negative tests: Separately remove the
> signature, install an usigned kernel, and modify the kernel image and
> test that the kernel will not boot.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/launchpad/+bug/1696154/+subscriptions
>

This bug was fixed in the package linux - 4.15.0-19.20

---------------
linux (4.15.0-19.20) bionic; urgency=medium

  * linux: 4.15.0-19.20 -proposed tracker (LP: #1766021)

  * Kernel 4.15.0-15 breaks Dell PowerEdge 12th Gen servers (LP: #1765232)
    - Revert "blk-mq: simplify queue mapping & schedule with each possisble CPU"
    - Revert "genirq/affinity: assign vectors to all possible CPUs"

linux (4.15.0-18.19) bionic; urgency=medium

  * linux: 4.15.0-18.19 -proposed tracker (LP: #1765490)

  * [regression] Ubuntu 18.04:[4.15.0-17-generic #18] KVM Guest Kernel:
    meltdown: rfi/fallback displacement flush not enabled bydefault (kvm)
    (LP: #1765429)
    - powerpc/pseries: Fix clearing of security feature flags

  * signing: only install a signed kernel (LP: #1764794)
    - [Packaging] update to Debian like control scripts
    - [Packaging] switch to triggers for postinst.d postrm.d handling
    - [Packaging] signing -- switch to raw-signing tarballs
    - [Packaging] signing -- switch to linux-image as signed when available
    - [Config] signing -- enable Opal signing for ppc64el
    - [Packaging] printenv -- add signing options

  * [18.04 FEAT] Sign POWER host/NV kernels (LP: #1696154)
    - [Packaging] signing -- add support for signing Opal kernel binaries

  * Please cherrypick s390 unwind fix (LP: #1765083)
    - s390/compat: fix setup_frame32

  * Ubuntu 18.04 installer does not detect any IPR based HDD/RAID array [S822L]
    [ipr] (LP: #1751813)
    - d-i: move ipr to storage-core-modules on ppc64el

  * drivers/gpu/drm/bridge/adv7511/adv7511.ko missing (LP: #1764816)
    - SAUCE: (no-up) rename the adv7511 drm driver to adv7511_drm

  * Miscellaneous Ubuntu changes
    - [Packaging] Add linux-oem to rebuild test blacklist.

linux (4.15.0-17.18) bionic; urgency=medium

  * linux: 4.15.0-17.18 -proposed tracker (LP: #1764498)

  * Eventual OOM with profile reloads (LP: #1750594)
    - SAUCE: apparmor: fix memory leak when duplicate profile load

linux (4.15.0-16.17) bionic; urgency=medium

  * linux: 4.15.0-16.17 -proposed tracker (LP: #1763785)

  * [18.04] [bug] CFL-S(CNP)/CNL GPIO testing failed (LP: #1757346)
    - [Config]: Set CONFIG_PINCTRL_CANNONLAKE=y

  * [Ubuntu 18.04] USB Type-C test failed on GLK (LP: #1758797)
    - SAUCE: usb: typec: ucsi: Increase command completion timeout value

  * Fix trying to "push" an already active pool VP (LP: #1763386)
    - SAUCE: powerpc/xive: Fix trying to "push" an already active pool VP

  * hisi_sas: Revert and replace SAUCE patches w/ upstream (LP: #1762824)
    - Revert "UBUNTU: SAUCE: scsi: hisi_sas: export device table of v3 hw to
      userspace"
    - Revert "UBUNTU: SAUCE: scsi: hisi_sas: config for hip08 ES"
    - scsi: hisi_sas: modify some register config for hip08
    - scsi: hisi_sas: add v3 hw MODULE_DEVICE_TABLE()

  * Realtek card reader - RTS5243 [VEN_10EC&DEV_5260] (LP: #1737673)
    - misc: rtsx: Move Realtek Card Reader Driver to misc
    - updateconfigs for Realtek Card Reader Driver
    - misc: rtsx: Add support for RTS5260
    - misc: rtsx: Fix symbol clashes

  * Mellanox [mlx5] [bionic] UBSAN: Undefined behaviour in
    ./include/linux/net_dim.h (LP: #1...

This bug was fixed in the package linux-signed - 4.15.0-19.20

---------------
linux-signed (4.15.0-19.20) bionic; urgency=medium

  * Master version: 4.15.0-19.20

linux-signed (4.15.0-18.19+signed2) bionic; urgency=medium

  * Fix dbgsym package handling to work for the case where we have a
    bumped linux-signed version number.

linux-signed (4.15.0-18.19+signed1) bionic; urgency=medium

  * Fix the dbgsym packages to be correctly named as .ddeb instead of .deb
    so they are published to the right archive.

linux-signed (4.15.0-18.19) bionic; urgency=medium

  * Master version: 4.15.0-18.19

  * signing: only install a signed kernel (LP: #1764794)
    - switch to raw-signing tarball form
    - make control.stub master for packages built
    - [Config] tone down the output verbosity
    - switch to producing linux-image directly
    - propogate control information from -unsigned package
    - pull control files in from linux-unsigned
    - resync control files with master
    - introduce meta packages for the debug package
    - fix names of substvars files
    - propogate Recommends: and Provides: from unsigned package
    - fix Section: control records
    - do not produce lowlatency dbgsym package for ppc64el
    - move dbgsym packages to bottom of control file
    - ensure we apt-cache show against the exact version

  * [18.04 FEAT] Sign POWER host/NV kernels (LP: #1696154)
    - add Opal signing support and enable for ppc64el

linux-signed (4.15.0-17.18) bionic; urgency=medium

  * Master version: 4.15.0-17.18

linux-signed (4.15.0-16.17) bionic; urgency=medium

  * Master version: 4.15.0-16.17

 -- Seth Forshee <email address hidden> Sat, 21 Apr 2018 17:32:56 -0500