** 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 + 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. + + __________ + 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. + 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. + 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. + 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 fis 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. __________ 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
