[Bug 1903289] [NEW] Power guest secure boot with static keys: GRUB2 portion

Launchpad Bug Tracker 1903289 at bugs.launchpad.net
Fri Nov 6 11:19:48 UTC 2020


You have been subscribed to a public bug:

== Comment: #2 - Daniel John Axtens <Daniel.Axtens1 at ibm.com> - 2020-11-05 19:50:03 ==
This bug covers the grub part of our LPAR Secure Boot design, which I'd like to propose for your 21.04 release. 

Background
==========

Please find attached an overall outline of the design.

Patches
=======

I've posted the 3 main parts of this feature to the grub mailing list:

 - Allowing grub to be signed with an appended signature to be verified by firmware: https://lists.gnu.org/archive/html/grub-devel/2020-08/msg00037.html
 - Teaching grub how to verify appended signatures on Linux kernels: https://lists.gnu.org/archive/html/grub-devel/2020-10/msg00152.html
 - Linking grub's verification to the secure boot status from firmware: https://lists.gnu.org/archive/html/grub-devel/2020-10/msg00048.html

(We do need one other piece just to increase the amount of memory grub
allocates for itself in as it starts. We have a couple of prototypes,
one which we've posted to the list and one which we haven't. The one
we've posted breaks booting of guests with 512MB of memory, which - as
far as I can tell - is still supported by Ubuntu, and indeed is the
default for guests created by uvtool. So we'll post an alternative to
the list shortly.)

Because of the grub development cycle, these patches will not be merged
upstream for 2.06. We are hoping, given the incredibly slow pace of grub
development and the number of out-of-tree patches that have
traditionally been required for UEFI secure-boot support, that you'd be
willing to carry these out of tree while we try to have them merged.

Next Steps
==========

We need the following information from you:

 - If you're willing to take grub changes, what tree would you like us
to backport our grub changes onto?  I imagine it's just the development
tree on launchpad, but I thought I'd check.

 - What keys would you like to use? As we are using static keys, we will
need to embed an x509 certificate for verifying grub in firmware. We
will need a production certificate, and we can also support test keys
while firmware is still in development. Either you can supply a test key
or you can use the existing 'imprint' keys that we are using. (Neither
will be supported in production firmware builds - this is just for
before we hit production firmware levels.)

 - The addition of a signed binary will make installing grub more
complicated, as grub-install (out of the box) will create and install an
unsigned binary. There's also likely implications for the installer.
What parts of this process do you need us to develop?


Building, Signing and Testing
=============================

If you would like to, you can experiment with this already using qemu
and SLOF, although our production solution will only support PFW.
Details are on the list: https://lists.gnu.org/archive/html/grub-
devel/2020-10/msg00048.html

A slightly more involved process is required for a fully generic distro-
friendly solution, we can share more details on that.

** Affects: grub2 (Ubuntu)
     Importance: Undecided
     Assignee: Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage)
         Status: New


** Tags: architecture-ppc64le bugnameltc-189098 severity-critical targetmilestone-inin2104
-- 
Power guest secure boot with static keys: GRUB2 portion
https://bugs.launchpad.net/bugs/1903289
You received this bug notification because you are a member of Ubuntu Foundations Bugs, which is subscribed to grub2 in Ubuntu.



More information about the foundations-bugs mailing list