F39 proposal: Register EC2 Cloud Images with uefi-preferred AMI flag (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/CloudEC2UEFIPreferred
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 == A new feature of EC2 is to be able to register AMIs with a boot mode of `uefi-preferred` rather than picking one of `bios` or `uefi`. In EC2, aarch64 has always been UEFI, while x86-64 started out as BIOS only and some instance types have recently begun to support booting in UEFI mode. Previously, an AMI had to pick if it was UEFI or BIOS. With `uefi-preferred` it allows an AMI to launch with whatever firmware stack is available for the instance type, preferring UEFI when UEFI is an option.
This proposal is to register the Fedora EC2 images with `uefi-preferred`, having the effect of switching to booting in UEFI mode on x86-64 in EC2 where available.
== Owner == * Name: [[User:Trawets| Stewart Smith]] [[User:Davdunc| David Duncan]] * Email: trawets@amazon.com
== Detailed Description == Some features of some EC2 instance types (such as secure boot) are only available in UEFI mode. There is also the standard set of advantages of UEFI over BIOS. All aarch64 instance types in EC2 have always been UEFI, while all x86-64 instance types were historically all BIOS. Recently, some x86-64 instance types have started to support UEFI mode. This was originally implemented as an option for instance launches and AMI registration. An AMI could state that it should be booted in UEFI mode. An AMI registered for UEFI would *not* boot on BIOS-only instance types. This meant that if you wanted to make available an OS that could boot on all instance types, you'd need a trio of AMIs: aarch64 UEFI, x86-64 BIOS, and x86-64 UEFI.
With the `uefi-preferred` boot mode, one AMI registered for x86-64 will boot on UEFI where possible, but also boot BIOS if the instance type doesn't support UEFI.
By registering Fedora AMIs with this boot mode, EC2 features that require UEFI (such as Secure Boot and NitroTPM) will be able to be used in Fedora, while still maintaining compatibility with BIOS only instance types.
== Feedback == We have started registering Amazon Linux 2023 AMIs with this boot mode, albeit quite late in the development cycle of AL2023 due to the timing of when the `uefi-preferred` boot mode flag was added to EC2.
== Benefit to Fedora == UEFI is becoming more ubiquitous amongst hardware, and operating under UEFI inside EC2 unlocks an increasing number of features such as Secure Boot and NitroTPM. The benefit for Fedora is a more uniform experience across cloud and non-cloud environments, simplifying the boot and runtime software stack.
== Scope == * Proposal owners:
* Modify the AMI registration call to include `uefi-preferred`, verifying that Fedora AMIs are assembled correctly for booting under UEFI.
* Other developers: No changes needed by other developers
* Release engineering: N/A
* Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
== How To Test == Once the AMI is registered, verify that the parameter is set, and that instances can be launched for each instance type. Normal testing should cover this.
== User Experience == Users will be able to use features in EC2 that require UEFI such as Secure Boot and NitroTPM.
== 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)
== Documentation == * https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ami-boot.html * https://docs.aws.amazon.com/cli/latest/reference/ec2/register-image.html
== Release Notes == EC2 images are now registered with the `uefi-preferred` boot mode, thus boot in UEFI mode where possible.
Ben Cotton bcotton@redhat.com writes:
https://fedoraproject.org/wiki/Changes/CloudEC2UEFIPreferred
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 == A new feature of EC2 is to be able to register AMIs with a boot mode of `uefi-preferred` rather than picking one of `bios` or `uefi`. In EC2, aarch64 has always been UEFI, while x86-64 started out as BIOS only and some instance types have recently begun to support booting in UEFI mode. Previously, an AMI had to pick if it was UEFI or BIOS. With `uefi-preferred` it allows an AMI to launch with whatever firmware stack is available for the instance type, preferring UEFI when UEFI is an option.
This proposal is to register the Fedora EC2 images with `uefi-preferred`, having the effect of switching to booting in UEFI mode on x86-64 in EC2 where available.
== Owner ==
- Name: [[User:Trawets| Stewart Smith]] [[User:Davdunc| David Duncan]]
- Email: trawets@amazon.com
== Detailed Description == Some features of some EC2 instance types (such as secure boot) are only available in UEFI mode. There is also the standard set of advantages of UEFI over BIOS. All aarch64 instance types in EC2 have always been UEFI, while all x86-64 instance types were historically all BIOS. Recently, some x86-64 instance types have started to support UEFI mode. This was originally implemented as an option for instance launches and AMI registration. An AMI could state that it should be booted in UEFI mode. An AMI registered for UEFI would *not* boot on BIOS-only instance types. This meant that if you wanted to make available an OS that could boot on all instance types, you'd need a trio of AMIs: aarch64 UEFI, x86-64 BIOS, and x86-64 UEFI.
With the `uefi-preferred` boot mode, one AMI registered for x86-64 will boot on UEFI where possible, but also boot BIOS if the instance type doesn't support UEFI.
By registering Fedora AMIs with this boot mode, EC2 features that require UEFI (such as Secure Boot and NitroTPM) will be able to be used in Fedora, while still maintaining compatibility with BIOS only instance types.
== Feedback == We have started registering Amazon Linux 2023 AMIs with this boot mode, albeit quite late in the development cycle of AL2023 due to the timing of when the `uefi-preferred` boot mode flag was added to EC2.
== Benefit to Fedora == UEFI is becoming more ubiquitous amongst hardware, and operating under UEFI inside EC2 unlocks an increasing number of features such as Secure Boot and NitroTPM. The benefit for Fedora is a more uniform experience across cloud and non-cloud environments, simplifying the boot and runtime software stack.
On behalf of the Fedora bootloader maintainers, thank you for this change.
Be well, --Robbie
On Fri, Mar 24, 2023 at 11:24 AM Robbie Harwood rharwood@redhat.com wrote:
Ben Cotton bcotton@redhat.com writes:
https://fedoraproject.org/wiki/Changes/CloudEC2UEFIPreferred
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 == A new feature of EC2 is to be able to register AMIs with a boot mode of `uefi-preferred` rather than picking one of `bios` or `uefi`. In EC2, aarch64 has always been UEFI, while x86-64 started out as BIOS only and some instance types have recently begun to support booting in UEFI mode. Previously, an AMI had to pick if it was UEFI or BIOS. With `uefi-preferred` it allows an AMI to launch with whatever firmware stack is available for the instance type, preferring UEFI when UEFI is an option.
This proposal is to register the Fedora EC2 images with `uefi-preferred`, having the effect of switching to booting in UEFI mode on x86-64 in EC2 where available.
== Owner ==
- Name: [[User:Trawets| Stewart Smith]] [[User:Davdunc| David Duncan]]
- Email: trawets@amazon.com
== Detailed Description == Some features of some EC2 instance types (such as secure boot) are only available in UEFI mode. There is also the standard set of advantages of UEFI over BIOS. All aarch64 instance types in EC2 have always been UEFI, while all x86-64 instance types were historically all BIOS. Recently, some x86-64 instance types have started to support UEFI mode. This was originally implemented as an option for instance launches and AMI registration. An AMI could state that it should be booted in UEFI mode. An AMI registered for UEFI would *not* boot on BIOS-only instance types. This meant that if you wanted to make available an OS that could boot on all instance types, you'd need a trio of AMIs: aarch64 UEFI, x86-64 BIOS, and x86-64 UEFI.
With the `uefi-preferred` boot mode, one AMI registered for x86-64 will boot on UEFI where possible, but also boot BIOS if the instance type doesn't support UEFI.
By registering Fedora AMIs with this boot mode, EC2 features that require UEFI (such as Secure Boot and NitroTPM) will be able to be used in Fedora, while still maintaining compatibility with BIOS only instance types.
== Feedback == We have started registering Amazon Linux 2023 AMIs with this boot mode, albeit quite late in the development cycle of AL2023 due to the timing of when the `uefi-preferred` boot mode flag was added to EC2.
== Benefit to Fedora == UEFI is becoming more ubiquitous amongst hardware, and operating under UEFI inside EC2 unlocks an increasing number of features such as Secure Boot and NitroTPM. The benefit for Fedora is a more uniform experience across cloud and non-cloud environments, simplifying the boot and runtime software stack.
On behalf of the Fedora bootloader maintainers, thank you for this change.
This is something we've been pushing across our cloud partners since I made our images support both boot modes.
I'm really happy to finally take the next step to prefer UEFI on AWS.
There's still a long tail of partners to work with on moving to UEFI, so we'll still maintain BIOS support for the time being, but it's being worked on.
-
Ben Cotton -
Neal Gompa -
Robbie Harwood