** 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 Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1832624 Title: [UBUNTU] kernel: Fix wrong dispatching for control domain CPRBs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1832624/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
