[Desktop-packages] [Bug 1978890] Re: FIPS/OEM installation compatibility is unclear to the end-user
I'd (personally) be much more on board with a warning vs a hard block as well. The GRUB_FLAVOUR_ORDER issue was met with some resistance by both the FIPs team and the OEM team. From what I gathered, GRUB_FLAVOUR_ORDER was originally implement for the FIPS kernel, but later leveraged by OEM. The OEM supersede was preferred by the OEM team, as OEM packages are intended to be temporary (and only for critical functionality issues) until adopted upstream, after which they are intended to be removed (?). The argument from the FIPs side more leans towards the `forced` OEM installs. This falls outside of the UA client's responsibility though, as it can trigger before or after ua enablement via ubuntu-drivers- common. I'd agree that we'd want a definitive decision on preferred preference before pulling the trigger on the UA changes though. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to ubuntu-drivers-common in Ubuntu. https://bugs.launchpad.net/bugs/1978890 Title: FIPS/OEM installation compatibility is unclear to the end-user Status in subiquity package in Ubuntu: In Progress Status in ubiquity package in Ubuntu: New Status in ubuntu-advantage-tools package in Ubuntu: New Status in ubuntu-drivers-common package in Ubuntu: New Status in update-manager package in Ubuntu: New Bug description: [Overall Summary] Converting to cover all oem/fips compatibility issues with ua/installers/update-manager. These projects are mostly silo'd, so when they all converge it creates a confusing and frustrating experience for the user. At it's core, the problem is that both fips and oem us GRUB_FLAVOUR_ORDER to select the preferred kernel to boot from, disregarding versioning. The main issues are: 1. ubuntu-drivers should not attempt to `oem-ify` a `fipsified` machine 2. ua tool should not attempt to `fipsify` an oem machine 3. subiquity should mention that drivers page is potentially making machine realtime & fips incompatible Below are some reproducible examples of issues: --- (Subiquity installer case) [Summary] A recent change to the subiquity snap adds support for installing oem drivers at time of instance install. If the user installs these packages, then attempts to install the fips packages post-install, fips will install as expected, but the system will always boot to the oem kernel. [Expected Behavior] Messaging should clearly indicate that installing the oem packages will make the environment incompatible with fips/RT kernel/ etc. [Observed Behavior] Subiquity just offers additional drivers, without clarifying the compatibility complications. [Replication Steps] (Using Dell Inc. Precision 7920 Tower/060K5C) 1. Install from current focal ISO 2. Confirm driver installation on the oem gui page 3. Install ua client/fips 4. Reboot 5. Observe kernel version (oem) --- (update-manager case) [Summary] A feature was added to allow for post-install enablement for oem-enabled devices via update manager: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1908050 While this works great for some situations, it can lead to users unexpectedly installing the oem meta package + associated kernel, overwriting an existing fips installation, as the "Improved hardware support" bundle may not be noticed when operating update-manager [Expected Behavior] For non linux-generic running installs, the post-install oem enablement functionality should not trigger, nor should it add the additional repositories to the client's sources.list.d. [Observed Behavior] sources.list.d is updated and "Improved hardware support" is allowed as an option in update-manager, which leads to clients unexpectedly losing compliance in fips environments. [Replication Steps] (Using Dell Inc. Precision 7920 Tower/060K5C) 1. Install from current focal ISO 2. Attach a ua subscription 3. Enable the fips-updates service 4. Reboot the system, login the desktop and wait for a while. The notification will pop up and it will show "Improved hardware support" on the certified machines that has the OEM metapackage support. 5. Click through the update-manager prompt and install the oem packages 6. Reboot check fips status oem's config in /etc/default/grub.d/* does not have a number prefix, and thus will always override 99-ubuntu-fips.cfg when calling update- grub. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1978890/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1978890] Re: FIPS/OEM installation compatibility is unclear to the end-user
> "Third-party drivers should not be installed on systems that will be used for FIPS or the real-time kernel." This may be sufficient. We're already talking about a fairly extreme edge case here. The footprint of hardware that triggers the ubuntu- drivers criteria that also is intended to use FIPS later is already quite small. If we ever add additional packages that leverage GRUB_FLAVOUR_ORDER in the future, we could add information as needed? The subiquity piece of this is likely the smallest part. The `aggressive` installs of the oem packages in already-configured desktop instances via update-manager is the bigger headache.( i.e. running fips fine, then oem packages `randomly` install, and I lose compliance without being aware.) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to ubuntu-drivers-common in Ubuntu. https://bugs.launchpad.net/bugs/1978890 Title: FIPS/OEM installation compatibility is unclear to the end-user Status in subiquity package in Ubuntu: Incomplete Status in ubiquity package in Ubuntu: New Status in ubuntu-advantage-tools package in Ubuntu: New Status in ubuntu-drivers-common package in Ubuntu: New Status in update-manager package in Ubuntu: New Bug description: [Overall Summary] Converting to cover all oem/fips compatibility issues with ua/installers/update-manager. These projects are mostly silo'd, so when they all converge it creates a confusing and frustrating experience for the user. At it's core, the problem is that both fips and oem us GRUB_FLAVOUR_ORDER to select the preferred kernel to boot from, disregarding versioning. The main issues are: 1. ubuntu-drivers should not attempt to `oem-ify` a `fipsified` machine 2. ua tool should not attempt to `fipsify` an oem machine 3. subiquity should mention that drivers page is potentially making machine realtime & fips incompatible Below are some reproducible examples of issues: --- (Subiquity installer case) [Summary] A recent change to the subiquity snap adds support for installing oem drivers at time of instance install. If the user installs these packages, then attempts to install the fips packages post-install, fips will install as expected, but the system will always boot to the oem kernel. [Expected Behavior] Messaging should clearly indicate that installing the oem packages will make the environment incompatible with fips/RT kernel/ etc. [Observed Behavior] Subiquity just offers additional drivers, without clarifying the compatibility complications. [Replication Steps] (Using Dell Inc. Precision 7920 Tower/060K5C) 1. Install from current focal ISO 2. Confirm driver installation on the oem gui page 3. Install ua client/fips 4. Reboot 5. Observe kernel version (oem) --- (update-manager case) [Summary] A feature was added to allow for post-install enablement for oem-enabled devices via update manager: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1908050 While this works great for some situations, it can lead to users unexpectedly installing the oem meta package + associated kernel, overwriting an existing fips installation, as the "Improved hardware support" bundle may not be noticed when operating update-manager [Expected Behavior] For non linux-generic running installs, the post-install oem enablement functionality should not trigger, nor should it add the additional repositories to the client's sources.list.d. [Observed Behavior] sources.list.d is updated and "Improved hardware support" is allowed as an option in update-manager, which leads to clients unexpectedly losing compliance in fips environments. [Replication Steps] (Using Dell Inc. Precision 7920 Tower/060K5C) 1. Install from current focal ISO 2. Attach a ua subscription 3. Enable the fips-updates service 4. Reboot the system, login the desktop and wait for a while. The notification will pop up and it will show "Improved hardware support" on the certified machines that has the OEM metapackage support. 5. Click through the update-manager prompt and install the oem packages 6. Reboot check fips status oem's config in /etc/default/grub.d/* does not have a number prefix, and thus will always override 99-ubuntu-fips.cfg when calling update- grub. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1978890/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1978890] Re: FIPS/OEM installation compatibility is unclear to the end-user
The issue arises with any package leveraging the GRUB_FLAVOUR_ORDER cfg. While originally requested by the FIPS team to ensure the env didn't accidentally boot to -generic, it was later implemented by the oem packages to ensure the oem kernel was preferred. The fact that it prefers oem when both are installed is only due to the cfg file names. Subiquity just offers to install the oem packages if ubuntu-drivers finds a match on the hardware. The issue here is "Hey would you like to install some special hardware enablement drivers?" isn't necessarily indicative that you would no longer be able to install fips. This should more clearly convey what's happening here. This issue has a capture of the some of the pages I'm talking about: https://github.com/canonical/subiquity/pull/1196 -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to ubuntu-drivers-common in Ubuntu. https://bugs.launchpad.net/bugs/1978890 Title: FIPS/OEM installation compatibility is unclear to the end-user Status in subiquity package in Ubuntu: Incomplete Status in ubiquity package in Ubuntu: New Status in ubuntu-advantage-tools package in Ubuntu: New Status in ubuntu-drivers-common package in Ubuntu: New Status in update-manager package in Ubuntu: New Bug description: [Overall Summary] Converting to cover all oem/fips compatibility issues with ua/installers/update-manager. These projects are mostly silo'd, so when they all converge it creates a confusing and frustrating experience for the user. At it's core, the problem is that both fips and oem us GRUB_FLAVOUR_ORDER to select the preferred kernel to boot from, disregarding versioning. The main issues are: 1. ubuntu-drivers should not attempt to `oem-ify` a `fipsified` machine 2. ua tool should not attempt to `fipsify` an oem machine 3. subiquity should mention that drivers page is potentially making machine realtime & fips incompatible Below are some reproducible examples of issues: --- (Subiquity installer case) [Summary] A recent change to the subiquity snap adds support for installing oem drivers at time of instance install. If the user installs these packages, then attempts to install the fips packages post-install, fips will install as expected, but the system will always boot to the oem kernel. [Expected Behavior] Messaging should clearly indicate that installing the oem packages will make the environment incompatible with fips/RT kernel/ etc. [Observed Behavior] Subiquity just offers additional drivers, without clarifying the compatibility complications. [Replication Steps] (Using Dell Inc. Precision 7920 Tower/060K5C) 1. Install from current focal ISO 2. Confirm driver installation on the oem gui page 3. Install ua client/fips 4. Reboot 5. Observe kernel version (oem) --- (update-manager case) [Summary] A feature was added to allow for post-install enablement for oem-enabled devices via update manager: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1908050 While this works great for some situations, it can lead to users unexpectedly installing the oem meta package + associated kernel, overwriting an existing fips installation, as the "Improved hardware support" bundle may not be noticed when operating update-manager [Expected Behavior] For non linux-generic running installs, the post-install oem enablement functionality should not trigger, nor should it add the additional repositories to the client's sources.list.d. [Observed Behavior] sources.list.d is updated and "Improved hardware support" is allowed as an option in update-manager, which leads to clients unexpectedly losing compliance in fips environments. [Replication Steps] (Using Dell Inc. Precision 7920 Tower/060K5C) 1. Install from current focal ISO 2. Attach a ua subscription 3. Enable the fips-updates service 4. Reboot the system, login the desktop and wait for a while. The notification will pop up and it will show "Improved hardware support" on the certified machines that has the OEM metapackage support. 5. Click through the update-manager prompt and install the oem packages 6. Reboot check fips status oem's config in /etc/default/grub.d/* does not have a number prefix, and thus will always override 99-ubuntu-fips.cfg when calling update- grub. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1978890/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
[Desktop-packages] [Bug 1978890] Re: FIPS/OEM installation compatibility is unclear to the end-user
** Summary changed: - Post-Install enablement of OEM-enabled devices will overwrite FIPs + FIPS/OEM installation compatibility is unclear to the end-user ** Description changed: + [Overall Summary] + + Converting to cover all oem/fips compatibility issues with + ua/installers/update-manager. These projects are mostly silo'd, so when + they all converge it creates a confusing and frustrating experience for + the user. + + At it's core, the problem is that both fips and oem us + GRUB_FLAVOUR_ORDER to select the preferred kernel to boot from, + disregarding versioning. + + The main issues are: + 1. ubuntu-drivers should not attempt to `oem-ify` a `fipsified` machine + 2. ua tool should not attempt to `fipsify` an oem machine + 3. subiquity should mention that drivers page is potentially making machine realtime & fips incompatible + + + Below are some reproducible examples of issues: + + --- + (Subiquity installer case) [Summary] - A feature was added to allow for post-install enablement for oem-enabled devices via update manager: + A recent change to the subiquity snap adds support for installing oem drivers at time of instance install. If the user installs these packages, then attempts to install the fips packages post-install, fips will install as expected, but the system will always boot to the oem kernel. + + [Expected Behavior] + Messaging should clearly indicate that installing the oem packages will make the environment incompatible with fips/RT kernel/ etc. + + [Observed Behavior] + Subiquity just offers additional drivers, without clarifying the compatibility complications. + + [Replication Steps] + (Using Dell Inc. Precision 7920 Tower/060K5C) + 1. Install from current focal ISO + 2. Confirm driver installation on the oem gui page + 3. Install ua client/fips + 4. Reboot + 5. Observe kernel version (oem) + + --- + (update-manager case) + [Summary] + A feature was added to allow for post-install enablement for oem-enabled devices via update manager: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1908050 While this works great for some situations, it can lead to users unexpectedly installing the oem meta package + associated kernel, overwriting an existing fips installation, as the "Improved hardware support" bundle may not be noticed when operating update-manager [Expected Behavior] For non linux-generic running installs, the post-install oem enablement functionality should not trigger, nor should it add the additional repositories to the client's sources.list.d. [Observed Behavior] sources.list.d is updated and "Improved hardware support" is allowed as an option in update-manager, which leads to clients unexpectedly losing compliance in fips environments. [Replication Steps] (Using Dell Inc. Precision 7920 Tower/060K5C) 1. Install from current focal ISO 2. Attach a ua subscription 3. Enable the fips-updates service 4. Reboot the system, login the desktop and wait for a while. The notification will pop up and it will show "Improved hardware support" on the certified machines that has the OEM metapackage support. 5. Click through the update-manager prompt and install the oem packages 6. Reboot check fips status - As the oem kernel is 5.14, it will be chosen over the fips 5.4 by - default. unattended-upgrades will eventually remove the fips kernel as - well, given enough time. + oem's config in /etc/default/grub.d/* does not have a number prefix, and + thus will always override 99-ubuntu-fips.cfg when calling update-grub. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to ubuntu-drivers-common in Ubuntu. https://bugs.launchpad.net/bugs/1978890 Title: FIPS/OEM installation compatibility is unclear to the end-user Status in subiquity package in Ubuntu: New Status in ubiquity package in Ubuntu: New Status in ubuntu-advantage-tools package in Ubuntu: New Status in ubuntu-drivers-common package in Ubuntu: New Status in update-manager package in Ubuntu: New Bug description: [Overall Summary] Converting to cover all oem/fips compatibility issues with ua/installers/update-manager. These projects are mostly silo'd, so when they all converge it creates a confusing and frustrating experience for the user. At it's core, the problem is that both fips and oem us GRUB_FLAVOUR_ORDER to select the preferred kernel to boot from, disregarding versioning. The main issues are: 1. ubuntu-drivers should not attempt to `oem-ify` a `fipsified` machine 2. ua tool should not attempt to `fipsify` an oem machine 3. subiquity should mention that drivers page is potentially making machine realtime & fips incompatible Below are some reproducible examples of issues: --- (Subiquity installer case) [Summary] A recent change to the subiquity snap adds support for installing oem drivers at time of instance install. If the user
[Desktop-packages] [Bug 1978890] Re: Post-Install enablement of OEM-enabled devices will overwrite FIPs
** Also affects: ubuntu-advantage-tools (Ubuntu) Importance: Undecided Status: New ** Also affects: subiquity (Ubuntu) Importance: Undecided Status: New ** Also affects: ubiquity (Ubuntu) Importance: Undecided Status: New ** Also affects: ubuntu-drivers-common (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to ubuntu-drivers-common in Ubuntu. https://bugs.launchpad.net/bugs/1978890 Title: Post-Install enablement of OEM-enabled devices will overwrite FIPs Status in subiquity package in Ubuntu: New Status in ubiquity package in Ubuntu: New Status in ubuntu-advantage-tools package in Ubuntu: New Status in ubuntu-drivers-common package in Ubuntu: New Status in update-manager package in Ubuntu: New Bug description: [Summary] A feature was added to allow for post-install enablement for oem-enabled devices via update manager: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1908050 While this works great for some situations, it can lead to users unexpectedly installing the oem meta package + associated kernel, overwriting an existing fips installation, as the "Improved hardware support" bundle may not be noticed when operating update-manager [Expected Behavior] For non linux-generic running installs, the post-install oem enablement functionality should not trigger, nor should it add the additional repositories to the client's sources.list.d. [Observed Behavior] sources.list.d is updated and "Improved hardware support" is allowed as an option in update-manager, which leads to clients unexpectedly losing compliance in fips environments. [Replication Steps] (Using Dell Inc. Precision 7920 Tower/060K5C) 1. Install from current focal ISO 2. Attach a ua subscription 3. Enable the fips-updates service 4. Reboot the system, login the desktop and wait for a while. The notification will pop up and it will show "Improved hardware support" on the certified machines that has the OEM metapackage support. 5. Click through the update-manager prompt and install the oem packages 6. Reboot check fips status As the oem kernel is 5.14, it will be chosen over the fips 5.4 by default. unattended-upgrades will eventually remove the fips kernel as well, given enough time. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1978890/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
