RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2027505 - Signing Stream for Secure Boot
Summary: Signing Stream for Secure Boot
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: distribution
Version: CentOS Stream
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Brian Stinson
QA Contact: Release Test Team
URL:
Whiteboard:
: 2052755 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-11-29 20:39 UTC by Mike Rochefort
Modified: 2022-03-23 03:43 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-03-23 03:43:40 UTC
Type: Enhancement
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-104203 0 None None None 2021-11-29 20:41:29 UTC

Description Mike Rochefort 2021-11-29 20:39:20 UTC
At the current point in time it doesn't appear CentOS Stream 9 supports Secure Boot. I haven't been able to test against physical hardware, but with VMs using edk2-ovmf firmwares trying to use Secure Boot drops into the MOK key enrollment every time.

Reproducable VM methods for above behavior (ISO from 2021.11.18):
- Secure Boot on by default
  - Secure Boot VM (OVMF_CODE.secboot.fd) with c9s ISO
- Simulate SB off then turning on
  - UEFI VM (OVMF_CODE.fd) with c9s ISO
  - Attach the qcow image to a SecBoot VM

I think the platform should be shipping basic and fundamental features such as this at this point in its development life. Especially so with the Stream 9 announcement due out very soon and RHEL 9 Beta already supporting Secure Boot.

https://lists.centos.org/pipermail/centos-promo/2021-November/003595.html

Comment 1 Brian Stinson 2022-02-10 01:28:52 UTC
*** Bug 2052755 has been marked as a duplicate of this bug. ***

Comment 2 Brian Stinson 2022-02-17 21:24:02 UTC
https://composes.stream.centos.org/production/CentOS-Stream-9-20220217.0/ contains signed kernel and grub2 builds that should result in a Secureboot enabled system.

Comment 3 Jesper Reenberg 2022-02-17 23:31:42 UTC
Confirmed that the dvd1 is booting with secure boot and installs in my vmware environment.  Thanks Brian.

Comment 4 Stefan Krüger 2022-02-18 19:42:43 UTC
Say I have C9S already installed, what minimum grub2 and kernel version do I need to be able to enable Secure Boot on next boot?

Comment 5 Neal Gompa 2022-02-22 01:36:15 UTC
Is the centos-sb-certs package supposed to be missing from the composes? It seems weird that it's missing...

Comment 6 Brian Stinson 2022-02-22 02:26:58 UTC
(In reply to stadtkind2 from comment #4)
> Say I have C9S already installed, what minimum grub2 and kernel version do I
> need to be able to enable Secure Boot on next boot?

kernel-5.14.0-60.el9 and grub2-2.06-21.el9 are in the Feb 17th compose. Later versions should continue to boot

(In reply to Neal Gompa from comment #5)
> Is the centos-sb-certs package supposed to be missing from the composes? It
> seems weird that it's missing...

The centos-sb-certs subpackage is an implementation detail for the buildsystem and won't be shipped in a consumer facing repo. We plan to add downloadable/copy-pastable public certs to this page https://centos.org/keys/

Comment 7 Neal Gompa 2022-02-22 02:43:36 UTC
(In reply to Brian Stinson from comment #6)
> (In reply to Neal Gompa from comment #5)
> > Is the centos-sb-certs package supposed to be missing from the composes? It
> > seems weird that it's missing...
> 
> The centos-sb-certs subpackage is an implementation detail for the
> buildsystem and won't be shipped in a consumer facing repo. We plan to add
> downloadable/copy-pastable public certs to this page https://centos.org/keys/

Since it became a build dependency for the kernel package last week[1], I'm not sure it still makes sense to *not* ship it.

[1]: https://gitlab.com/redhat/centos-stream/rpms/kernel/-/commit/48a069db186838a7fdde11fa81ab5b963d3ac7fa

Comment 8 Brian Stinson 2022-02-22 02:57:12 UTC
(In reply to Neal Gompa from comment #7)
> (In reply to Brian Stinson from comment #6)
> > (In reply to Neal Gompa from comment #5)
> > > Is the centos-sb-certs package supposed to be missing from the composes? It
> > > seems weird that it's missing...
> > 
> > The centos-sb-certs subpackage is an implementation detail for the
> > buildsystem and won't be shipped in a consumer facing repo. We plan to add
> > downloadable/copy-pastable public certs to this page https://centos.org/keys/
> 
> Since it became a build dependency for the kernel package last week[1], I'm
> not sure it still makes sense to *not* ship it.
> 
> [1]:
> https://gitlab.com/redhat/centos-stream/rpms/kernel/-/commit/
> 48a069db186838a7fdde11fa81ab5b963d3ac7fa

We do need to add the equivalent package to CBS as a dummy for now until we can get proper SIG certs added. Otherwise, you can satisfy that dependency by pointing at the actual buildroot in koji.

Comment 9 Neal Gompa 2022-02-22 03:35:03 UTC
Is there something we can ship for people to use locally (i.e. not in the Koji environments)?

Comment 10 Pat Riehecky 2022-02-22 14:38:35 UTC
Being able to do local 'mock' builds of a kernel to test patches is a useful workflow to support.

Comment 11 Brian Stinson 2022-02-22 15:04:23 UTC
We want to encourage use of the buildroot where it makes sense. We'll probably end up documenting this for some of these cases:

# With centpkg installed from EPEL
koji -p stream mock-config --arch x86_64 --tag c9s-build

Comment 12 Neal Gompa 2022-02-22 15:49:14 UTC
(In reply to Brian Stinson from comment #11)
> We want to encourage use of the buildroot where it makes sense. We'll
> probably end up documenting this for some of these cases:
> 
> # With centpkg installed from EPEL
> koji -p stream mock-config --arch x86_64 --tag c9s-build

This seems unnecessarily painful for files that people should be able to have locally anyway. Why don't you want the certs package published? We publish GPG keys in a package so that local verification is possible, and having the certs package published enables the same kind of verification.

And prior to the switch to the package, they were included in the kernel SRPM. So I don't understand why it's a problem to publish the package. They don't contain the private keys, only the public certs.

Comment 14 Brian Stinson 2022-03-23 03:43:40 UTC
(In reply to Neal Gompa from comment #12)
> (In reply to Brian Stinson from comment #11)
> > We want to encourage use of the buildroot where it makes sense. We'll
> > probably end up documenting this for some of these cases:
> > 
> > # With centpkg installed from EPEL
> > koji -p stream mock-config --arch x86_64 --tag c9s-build
> 
> This seems unnecessarily painful for files that people should be able to
> have locally anyway. Why don't you want the certs package published? We
> publish GPG keys in a package so that local verification is possible, and
> having the certs package published enables the same kind of verification.
> 
> And prior to the switch to the package, they were included in the kernel
> SRPM. So I don't understand why it's a problem to publish the package. They
> don't contain the private keys, only the public certs.

We'll be including {redhat,centos}-sb-certs in CRB. Here's the bug that will actually make that happen: https://bugzilla.redhat.com/show_bug.cgi?id=2057686

Since secureboot is functional in CentOS Stream 9, we can close this bz.


Note You need to log in before you can comment on or make changes to this bug.