** Description changed: SRU Justification: ================== [Impact] * Unable to maintain control-only crypto domains * The communication to control-only domains does not work in any way. * And depending on the setup (lowest numerical domain is control-only) the TKE does not see the crypto card at all. [Fix] * 7379e652797c0b9b5f6caea1576f2dff9ce6a708 7379e65 "s390/zcrypt: Fix wrong dispatching for control domain CPRBs" * Backport: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1832624/+attachment/5271392/+files/s390 -zcrypt-Fix-wrong-dispatching-for-control-domain.patch [Test Case] * Configure a control-only domain to the activation profile of LPAR A * Configure a control-and-usage domain to the activation profile of LPAR B * Try to communicate to LPAR A with the control-only domain (e.g. trying to read or set master key) [Regression Potential] * The regression potential can be considered as moderate since this is purely s390x specific * and again limited to CryptoExpress adapter cards. * It only occurs if crypto domains are configured as control-only or better control-only in combination with control-and-usage. * The majority of configurations is control-and-usage, since this offers more flexibility and covers more use cases. - [Other Info] * Problem was found during tests at IBM and is a so called 'preventive fix' - * The given patch is supposed to fis this issue and became upstream + * The given patch is supposed to fix this issue and became upstream accepted with kernel 5.2-rc3. * It applies cleanly to disco master-next while cherry-picking, but needs the the backport (from comment #3) for bionic's master-next kernel 4.15. + + * Once target kernel 5.2 has landed in Eoan, it will be in Eoan, too. __________ Description: kernel: Fix wrong dispatching for control domain CPRBs Symptom: Unable to maintain control-only crypto domains Problem: LPARs may have control-only crypto domains assigned. Such a domain can be controlled (for example master keys can be set) but can't be used for regualar crypto load (usage). A crypto domain may be assigned for control-and-usage to only one active LPAR. But the very same domain may be assigned for control-only to one or more other LPARs. However, trying to communicate in any way with a control-only crypto domain did not work. So a simple query for the state of the master keys on a control-only domain failed and the TKE does not even show this domain. Even worse, when the lowest domain (in a numerically sense) is a control-only domain, the TKE does not even see the crypto cards at all. Solution: This fix introduces some code which checks if an CCA CPRB is addressing a control-only domain. If that's the case and there is a default control-and-usage domain available the CPRB is send to this other domain instead. The target domain field within the CPRB is untouched and the crypto card firmware code detects this working-as-designed mismatch and does the right job and addresses the control domain. Reproduction: 1. Add a control-only domain to the crypto configuration of an LPAR and re-activate the LPAR. 2. Connect the TKE the LPAR and try to visit the master key verification patterns of this control-only domain. 3. Will fail without the fix, will succeed with the fix. Component: kernel Upstream-ID: 7379e652797c0b9b5f6caea1576f2dff9ce6a708 This fix is requested for 19.10 but should also be applied to 18.04 and 19.04
-- 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/1832624 Title: [UBUNTU] kernel: Fix wrong dispatching for control domain CPRBs Status in Ubuntu on IBM z Systems: In Progress Status in linux package in Ubuntu: New Bug description: SRU Justification: ================== [Impact] * Unable to maintain control-only crypto domains * The communication to control-only domains does not work in any way. * And depending on the setup (lowest numerical domain is control-only) the TKE does not see the crypto card at all. [Fix] * 7379e652797c0b9b5f6caea1576f2dff9ce6a708 7379e65 "s390/zcrypt: Fix wrong dispatching for control domain CPRBs" * Backport: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1832624/+attachment/5271392/+files/s390 -zcrypt-Fix-wrong-dispatching-for-control-domain.patch [Test Case] * Configure a control-only domain to the activation profile of LPAR A * Configure a control-and-usage domain to the activation profile of LPAR B * Try to communicate to LPAR A with the control-only domain (e.g. trying to read or set master key) [Regression Potential] * The regression potential can be considered as moderate since this is purely s390x specific * and again limited to CryptoExpress adapter cards. * It only occurs if crypto domains are configured as control-only or better control-only in combination with control-and-usage. * The majority of configurations is control-and-usage, since this offers more flexibility and covers more use cases. [Other Info] * Problem was found during tests at IBM and is a so called 'preventive fix' * The given patch is supposed to fix this issue and became upstream accepted with kernel 5.2-rc3. * It applies cleanly to disco master-next while cherry-picking, but needs the the backport (from comment #3) for bionic's master-next kernel 4.15. * Once target kernel 5.2 has landed in Eoan, it will be in Eoan, too. __________ Description: kernel: Fix wrong dispatching for control domain CPRBs Symptom: Unable to maintain control-only crypto domains Problem: LPARs may have control-only crypto domains assigned. Such a domain can be controlled (for example master keys can be set) but can't be used for regualar crypto load (usage). A crypto domain may be assigned for control-and-usage to only one active LPAR. But the very same domain may be assigned for control-only to one or more other LPARs. However, trying to communicate in any way with a control-only crypto domain did not work. So a simple query for the state of the master keys on a control-only domain failed and the TKE does not even show this domain. Even worse, when the lowest domain (in a numerically sense) is a control-only domain, the TKE does not even see the crypto cards at all. Solution: This fix introduces some code which checks if an CCA CPRB is addressing a control-only domain. If that's the case and there is a default control-and-usage domain available the CPRB is send to this other domain instead. The target domain field within the CPRB is untouched and the crypto card firmware code detects this working-as-designed mismatch and does the right job and addresses the control domain. Reproduction: 1. Add a control-only domain to the crypto configuration of an LPAR and re-activate the LPAR. 2. Connect the TKE the LPAR and try to visit the master key verification patterns of this control-only domain. 3. Will fail without the fix, will succeed with the fix. Component: kernel Upstream-ID: 7379e652797c0b9b5f6caea1576f2dff9ce6a708 This fix is requested for 19.10 but should also be applied to 18.04 and 19.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1832624/+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
