From Fedora Project Wiki
(Created page with "<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name. This keeps all change proposals in the same namespace --> = Rebase grub2 to 2.12 <!-- The name of your change proposal --> = {{Change_Proposal_Banner}} == Summary == Rebase grub2 to 2.12 release in F40, same as in F41 and current rawhide. == Owner == <!-- For change proposals to qualify as self-contained, owners of all affected packages need to be includ...")
 
No edit summary
 
(One intermediate revision by the same user not shown)
Line 47: Line 47:


== Detailed Description ==
== Detailed Description ==
The embargo on 19 security vulnerabilities in the GRUB bootloader will be lifted on 18 February, and since F40 is still being maintained, the most robust way to address these is to backport the entire rebased GRUB 2.12 to F40. This 2.12 version is already in F41 and rawhide, so it is being tested by users, and is functioning well.
The embargo on 19 security vulnerabilities in the GRUB bootloader was lifted on 18 February, and since F40 is still being maintained, the most robust way to address these is to backport the entire rebased GRUB 2.12 to F40. This 2.12 version is already in F41 and rawhide, so it is being tested by users, and is functioning well.


While it could be possible to backport the 60+ CVE patches, as well as other upstream patches that would be necessary for compatibility, it would be necessary to first revert other patches that have already been applied to the current stable F40 GRUB, apply all of the CVE patches, then reapply the reverted patches. The result would be a lot of work that could easily result in mistakes, new issues, etc.
While it could be possible to backport the 60+ CVE patches, as well as other upstream patches that would be necessary for compatibility, it would be necessary to first revert other patches that have already been applied to the current stable F40 GRUB, apply all of the CVE patches, then reapply the reverted patches. The result would be a lot of work that could easily result in mistakes, new issues, etc.
Line 57: Line 57:


== Benefit to Fedora ==
== Benefit to Fedora ==
Cleaner and safer backport of CVE fixes and additional fixes introduced in the new release (taken from repo):
* GCC 13 support.
* GCC 13 support.
* clang 14 support.
* clang 14 support.
Line 105: Line 106:


== Scope ==
== Scope ==
* Proposal owners:
* Proposal owners: Marta Lewandowska, Nicolas Frayer
Marta Lewandowska
 
Nicolas Frayer
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->


Line 128: Line 126:


== Upgrade/compatibility impact ==
== Upgrade/compatibility impact ==
<!-- What happens to systems that have had a previous versions of Fedora installed and are updated to the version containing this change? Will anything require manual configuration or data migration? Will any existing functionality be no longer supported? -->
Newer Fedora versions already contain GRUB 2.12
 
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
 
== Early Testing (Optional) ==
<!-- This is an optional step for system-wide changes to avail of. If you would like to build an initial proof of concept of your change and have a member of Fedora QA help you write and/or run some initial basic tests on your code, please email tests@fedoraproject.org and include the link to your change proposal. This step is *optional*. -->
 
Do you require 'QA Blueprint' support? Y/N <!-- Optional Step for System-Wide Changes only -->


== How To Test ==
== How To Test ==
<!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this change implementation is expected to pass when it is done.  This can be based off of the above section if early testing has been completed. If it needs to be tested with different hardware or software configurations, indicate them.  The more specific you can be, the better the community testing can be.
Update your grub2 and report any regressions or other issues.
 
Remember that you are writing this how to for interested testers to use to check out your change implementation - documenting what you do for testing is OK, but it's much better to document what *I* can do to test your change.
 
A good "how to test" should answer these four questions:
 
0. What special hardware / data / etc. is needed (if any)?
1. How do I prepare my system to test this change? What packages
need to be installed, config files edited, etc.?
2. What specific actions do I perform to check that the change is
working like it's supposed to?
3. What are the expected results of those actions?
-->


<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- REQUIRED FOR SYSTEM WIDE CHANGES -->

Latest revision as of 21:29, 18 February 2025


Rebase grub2 to 2.12

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Summary

Rebase grub2 to 2.12 release in F40, same as in F41 and current rawhide.

Owner


Current status

  • Targeted release: Fedora Linux 40
  • Last updated: 2025-02-18
  • [<link to devel-announce post will be added by Wrangler> Announced]
  • [<will be assigned by the Wrangler> Discussion thread]
  • FESCo issue: <will be assigned by the Wrangler>
  • Tracker bug: <will be assigned by the Wrangler>
  • Release notes tracker: <will be assigned by the Wrangler>

Detailed Description

The embargo on 19 security vulnerabilities in the GRUB bootloader was lifted on 18 February, and since F40 is still being maintained, the most robust way to address these is to backport the entire rebased GRUB 2.12 to F40. This 2.12 version is already in F41 and rawhide, so it is being tested by users, and is functioning well.

While it could be possible to backport the 60+ CVE patches, as well as other upstream patches that would be necessary for compatibility, it would be necessary to first revert other patches that have already been applied to the current stable F40 GRUB, apply all of the CVE patches, then reapply the reverted patches. The result would be a lot of work that could easily result in mistakes, new issues, etc.

The cleanest approach is to backport the rebased GRUB, so as to have the same version of the bootloader in all currently maintained Fedora releases.

Feedback

Benefit to Fedora

Cleaner and safer backport of CVE fixes and additional fixes introduced in the new release (taken from repo):

  • GCC 13 support.
  • clang 14 support.
  • binutils 2.38 support.
  • Unification of EFI Linux kernel loader across architectures.
  • Transition to EFI Linux kernel stub loader for x86 architecture.
  • Initial support for Boot Loader Interface.
  • Support for dynamic GRUB runtime memory addition using firmware calls.
  • PCI and MMIO UARTs support.
  • SDL2 support.
  • LoongArch support.
  • TPM driver fixes.
  • Many filesystems fixes.
  • Many CVE and Coverity fixes.
  • Debugging support improvements.
  • Tests improvements.
  • Documentation improvements.
  • ...and tons of other fixes and cleanups...


Scope

  • Proposal owners: Marta Lewandowska, Nicolas Frayer
  • Other developers:
  • Policies and guidelines: N/A (not needed for this Change)
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with the Fedora Strategy:

Upgrade/compatibility impact

Newer Fedora versions already contain GRUB 2.12

How To Test

Update your grub2 and report any regressions or other issues.


User Experience

Dependencies

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No


Documentation

N/A (not a System Wide Change)

Release Notes