** Description changed: + SRU Justification: + ================== + + [Impact] + + * A qeth device on a DPM-managed (HMC) IBM Z machine does not obtain its + MAC address for layer2 OSD interfaces from the OSA Network Adapter, + instead it uses a random MAC address. + + * This can cause connectivity issues in environments where reliable and + pre-determined MAC addresses are required, ie. when doing network + configuration based on DHCP. + + [Fix] + + * Backport 1: https://launchpadlibrarian.net/481647649/0001-s390-qeth- + improve-fallback-to-random-MAC-address.patch + + * Backport 2: https://launchpadlibrarian.net/481647657/0002-s390-qeth- + utilize-virtual-MAC-for-Layer2-OSD-devices.patch + + [Test Case] + + * Bring up a qeth L2 OSD interface in DPM-managed (HMC) LPAR + + * Inspect the interface's MAC address. It should be the same as + displayed in the HMC DPM panels. + + * Due to the fact that a system is needed where the HMC is in DPM moce + (rather than in classic mode) this needs to be tested by IBM. + + [Regression Potential] + + * There is a certain risk for a regression, since OSA devices are the + standard netweork devices on s390x. + + * But static network configurations are still more popular for the + usually long running workload on s390x and not dynamic assignments. + + * On the other hand qeth devices are s390x only, so this will at least + not affect common code or code for other architectures. + + * The modifications are limited to drivers/s390/net/qeth_*. + + * The patches are upstream since quite a while, which speaks for their + stability. + + [Other Info] + + * The upstream patch 21b1702af12e "s390/qeth: improve fallback to random + MAC address" got upstream accepted with 4.18, hence is already in all + Ubuntu release that are newer than bionic + + * And the upstream patch b144b99fff69 "s390/qeth: utilize virtual MAC + for Layer2 OSD devices" got upstream accepted with 5.0, hence is also + already in all Ubuntu release that are newer than bionic. + + __________ + == Comment: #0 - Michael Ranweiler <mranw...@us.ibm.com> - 2020-04-22 14:44:31 == +++ This bug was initially created as a clone of Bug #184073 +++ This bug is a follow on to LP 1866909 to address a missing piece - only half the following patch was included in 5.4.0-24.28. The upstream patch has an additional fix but it?s not critical for GA. It can get included as part of bug fixes. It also affects only power. The patch("powerpc/ima: fix secure boot rules in ima arch policy") is posted to linux-integrity and linuxppc-dev mailing list (https://lore.kernel.org/linux-integrity/1586549618-6106-1-git-send- email-na...@linux.ibm.com/T/#u) If there are any issues identified during further testing, they will get opened as separate issue to be addressed later. Thanks & Regards, - - Nayna + - Nayna == Comment: #4 - Michael Ranweiler <mranw...@us.ibm.com> - 2020-05-11 02:23:35 == Updated posting: https://lore.kernel.org/linux-integrity/1588342612-14532-1-git-send- email-na...@linux.ibm.com/T/#u
** Description changed: SRU Justification: ================== [Impact] - * A qeth device on a DPM-managed (HMC) IBM Z machine does not obtain its - MAC address for layer2 OSD interfaces from the OSA Network Adapter, - instead it uses a random MAC address. + * Currently the kernel module appended signature is verified twice + (finit_module) - once by the module_sig_check() and again by IMA. - * This can cause connectivity issues in environments where reliable and - pre-determined MAC addresses are required, ie. when doing network - configuration based on DHCP. + * To prevent this the powerpc secure boot rules define an IMA + architecture specific policy rule only if CONFIG_MODULE_SIG_FORCE is not + enabled. + + * But this doesn't take the ability into account of enabling + "sig_enforce" at the boot command line (module.sig_enforce=1). + + * Including the IMA module appraise rule results in failing the + finit_module syscall, unless the module signing public key is loaded + onto the IMA keyring. + + * This patch fixes secure boot policy rules to be based on + CONFIG_MODULE_SIG instead. [Fix] - * Backport 1: https://launchpadlibrarian.net/481647649/0001-s390-qeth- - improve-fallback-to-random-MAC-address.patch - - * Backport 2: https://launchpadlibrarian.net/481647657/0002-s390-qeth- - utilize-virtual-MAC-for-Layer2-OSD-devices.patch + * fa4f3f56ccd28ac031ab275e673ed4098855fed4 fa4f3f56ccd2 "powerpc/ima: + Fix secure boot rules in ima arch policy" [Test Case] - * Bring up a qeth L2 OSD interface in DPM-managed (HMC) LPAR + * Perform a secure boot on a powerpc system with 'module.sig_enforce=1' + set at the boot command. - * Inspect the interface's MAC address. It should be the same as - displayed in the HMC DPM panels. + * If the IMA module appraise rule is included, the finit_module syscall + will fail (unless the module signing public key got loaded onto the IMA + keyring) without having the patch in place. - * Due to the fact that a system is needed where the HMC is in DPM moce - (rather than in classic mode) this needs to be tested by IBM. + * The verificatiob needs to be done by the IBM Power team. [Regression Potential] - * There is a certain risk for a regression, since OSA devices are the - standard netweork devices on s390x. + * There is (always) a certain regression risk with having code changes, + especially in the secure boot area. - * But static network configurations are still more popular for the - usually long running workload on s390x and not dynamic assignments. + * But this patch is limited to the powerpc platform and will not affect + any other architecture. - * On the other hand qeth devices are s390x only, so this will at least - not affect common code or code for other architectures. + * It got discussed at https://lore.kernel.org/r/1588342612-14532-1-git-send-email-na...@linux.ibm.com + before it became finally upstream accepted with kernel 5.7-rc7. - * The modifications are limited to drivers/s390/net/qeth_*. + * The secure boot code itself wasn't really touched, rather than it's basis for execution. + The IMA policy rule for module appraisal is now added only if 'CONFIG_MODULE_SIG' is not enabled (instead of CONFIG_MODULE_SIG_FORCE). + Hence the change is very limited and straightforward. - * The patches are upstream since quite a while, which speaks for their - stability. + [Other] - [Other Info] - - * The upstream patch 21b1702af12e "s390/qeth: improve fallback to random - MAC address" got upstream accepted with 4.18, hence is already in all - Ubuntu release that are newer than bionic - - * And the upstream patch b144b99fff69 "s390/qeth: utilize virtual MAC - for Layer2 OSD devices" got upstream accepted with 5.0, hence is also - already in all Ubuntu release that are newer than bionic. - + * Since the patch got upstream with 5.7-rc7, it is already in groovy, hence this SRU is for focal only. __________ == Comment: #0 - Michael Ranweiler <mranw...@us.ibm.com> - 2020-04-22 14:44:31 == +++ This bug was initially created as a clone of Bug #184073 +++ This bug is a follow on to LP 1866909 to address a missing piece - only half the following patch was included in 5.4.0-24.28. The upstream patch has an additional fix but it?s not critical for GA. It can get included as part of bug fixes. It also affects only power. The patch("powerpc/ima: fix secure boot rules in ima arch policy") is posted to linux-integrity and linuxppc-dev mailing list (https://lore.kernel.org/linux-integrity/1586549618-6106-1-git-send- email-na...@linux.ibm.com/T/#u) If there are any issues identified during further testing, they will get opened as separate issue to be addressed later. Thanks & Regards, - Nayna == Comment: #4 - Michael Ranweiler <mranw...@us.ibm.com> - 2020-05-11 02:23:35 == Updated posting: https://lore.kernel.org/linux-integrity/1588342612-14532-1-git-send- email-na...@linux.ibm.com/T/#u -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1877955 Title: Fix for secure boot rules in IMA arch policy on powerpc Status in The Ubuntu-power-systems project: Incomplete Status in linux package in Ubuntu: Incomplete Bug description: SRU Justification: ================== [Impact] * Currently the kernel module appended signature is verified twice (finit_module) - once by the module_sig_check() and again by IMA. * To prevent this the powerpc secure boot rules define an IMA architecture specific policy rule only if CONFIG_MODULE_SIG_FORCE is not enabled. * But this doesn't take the ability into account of enabling "sig_enforce" at the boot command line (module.sig_enforce=1). * Including the IMA module appraise rule results in failing the finit_module syscall, unless the module signing public key is loaded onto the IMA keyring. * This patch fixes secure boot policy rules to be based on CONFIG_MODULE_SIG instead. [Fix] * fa4f3f56ccd28ac031ab275e673ed4098855fed4 fa4f3f56ccd2 "powerpc/ima: Fix secure boot rules in ima arch policy" [Test Case] * Perform a secure boot on a powerpc system with 'module.sig_enforce=1' set at the boot command. * If the IMA module appraise rule is included, the finit_module syscall will fail (unless the module signing public key got loaded onto the IMA keyring) without having the patch in place. * The verificatiob needs to be done by the IBM Power team. [Regression Potential] * There is (always) a certain regression risk with having code changes, especially in the secure boot area. * But this patch is limited to the powerpc platform and will not affect any other architecture. * It got discussed at https://lore.kernel.org/r/1588342612-14532-1-git-send-email-na...@linux.ibm.com before it became finally upstream accepted with kernel 5.7-rc7. * The secure boot code itself wasn't really touched, rather than it's basis for execution. The IMA policy rule for module appraisal is now added only if 'CONFIG_MODULE_SIG' is not enabled (instead of CONFIG_MODULE_SIG_FORCE). Hence the change is very limited and straightforward. [Other] * Since the patch got upstream with 5.7-rc7, it is already in groovy, hence this SRU is for focal only. __________ == Comment: #0 - Michael Ranweiler <mranw...@us.ibm.com> - 2020-04-22 14:44:31 == +++ This bug was initially created as a clone of Bug #184073 +++ This bug is a follow on to LP 1866909 to address a missing piece - only half the following patch was included in 5.4.0-24.28. The upstream patch has an additional fix but it?s not critical for GA. It can get included as part of bug fixes. It also affects only power. The patch("powerpc/ima: fix secure boot rules in ima arch policy") is posted to linux-integrity and linuxppc-dev mailing list (https://lore.kernel.org/linux-integrity/1586549618-6106-1-git-send- email-na...@linux.ibm.com/T/#u) If there are any issues identified during further testing, they will get opened as separate issue to be addressed later. Thanks & Regards, - Nayna == Comment: #4 - Michael Ranweiler <mranw...@us.ibm.com> - 2020-05-11 02:23:35 == Updated posting: https://lore.kernel.org/linux-integrity/1588342612-14532-1-git-send- email-na...@linux.ibm.com/T/#u To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1877955/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
