| 2019-06-12 17:52:32 |
bugproxy |
bug |
|
|
added bug |
| 2019-06-12 17:52:34 |
bugproxy |
tags |
|
architecture-s39064 bugnameltc-178125 severity-high targetmilestone-inin1910 |
|
| 2019-06-12 17:52:35 |
bugproxy |
ubuntu: assignee |
|
Skipper Bug Screeners (skipper-screen-team) |
|
| 2019-06-12 17:52:38 |
bugproxy |
affects |
ubuntu |
linux (Ubuntu) |
|
| 2019-06-12 19:10:54 |
Andrew Cloke |
bug task added |
|
ubuntu-z-systems |
|
| 2019-06-12 19:11:03 |
Andrew Cloke |
ubuntu-z-systems: importance |
Undecided |
High |
|
| 2019-06-12 19:11:13 |
Andrew Cloke |
ubuntu-z-systems: assignee |
|
Canonical Kernel Team (canonical-kernel-team) |
|
| 2019-06-13 23:38:18 |
Terry Rudd |
bug |
|
|
added subscriber Terry Rudd |
| 2019-06-17 06:01:01 |
Frank Heimes |
ubuntu-z-systems: status |
New |
Triaged |
|
| 2019-06-18 04:15:51 |
Si Watt |
ubuntu-z-systems: status |
Triaged |
In Progress |
|
| 2019-06-18 13:59:34 |
bugproxy |
attachment added |
|
Here is a backport of the upstream patch. https://bugs.launchpad.net/bugs/1832624/+attachment/5271392/+files/s390-zcrypt-Fix-wrong-dispatching-for-control-domain.patch |
|
| 2019-06-26 07:29:24 |
Harald Freudenberger |
attachment added |
|
s390-zcrypt-Fix-wrong-dispatching-for-control-domain.ubuntu_bionic.patch https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1832624/+attachment/5273391/+files/s390-zcrypt-Fix-wrong-dispatching-for-control-domain.ubuntu_bionic.patch |
|
| 2019-06-26 08:21:08 |
Ubuntu Foundations Team Bug Bot |
tags |
architecture-s39064 bugnameltc-178125 severity-high targetmilestone-inin1910 |
architecture-s39064 bugnameltc-178125 patch severity-high targetmilestone-inin1910 |
|
| 2019-06-27 10:02:28 |
Frank Heimes |
description |
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 |
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 |
|
| 2019-06-27 10:39:54 |
Frank Heimes |
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 |
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 |
|
| 2019-06-27 12:27:50 |
Frank Heimes |
ubuntu-z-systems: status |
In Progress |
Triaged |
|
| 2019-06-27 14:00:59 |
Frank Heimes |
ubuntu-z-systems: status |
Triaged |
Confirmed |
|
| 2019-06-27 20:16:49 |
Frank Heimes |
linux (Ubuntu): status |
New |
In Progress |
|
| 2019-06-27 20:16:52 |
Frank Heimes |
ubuntu-z-systems: status |
Confirmed |
In Progress |
|
| 2019-07-01 09:19:14 |
Stefan Bader |
nominated for series |
|
Ubuntu Disco |
|
| 2019-07-01 09:19:14 |
Stefan Bader |
bug task added |
|
linux (Ubuntu Disco) |
|
| 2019-07-01 09:19:14 |
Stefan Bader |
nominated for series |
|
Ubuntu Bionic |
|
| 2019-07-01 09:19:14 |
Stefan Bader |
bug task added |
|
linux (Ubuntu Bionic) |
|
| 2019-07-01 09:19:26 |
Stefan Bader |
linux (Ubuntu Bionic): importance |
Undecided |
Medium |
|
| 2019-07-01 09:19:30 |
Stefan Bader |
linux (Ubuntu Disco): importance |
Undecided |
Medium |
|
| 2019-07-01 14:41:14 |
Kleber Sacilotto de Souza |
linux (Ubuntu Bionic): status |
New |
Fix Committed |
|
| 2019-07-01 14:41:18 |
Kleber Sacilotto de Souza |
linux (Ubuntu Disco): status |
New |
Fix Committed |
|
| 2019-07-02 09:04:41 |
Frank Heimes |
ubuntu-z-systems: status |
In Progress |
Fix Committed |
|
| 2019-07-03 11:01:58 |
Ubuntu Kernel Bot |
tags |
architecture-s39064 bugnameltc-178125 patch severity-high targetmilestone-inin1910 |
architecture-s39064 bugnameltc-178125 patch severity-high targetmilestone-inin1910 verification-needed-disco |
|
| 2019-07-03 13:07:26 |
Ubuntu Kernel Bot |
tags |
architecture-s39064 bugnameltc-178125 patch severity-high targetmilestone-inin1910 verification-needed-disco |
architecture-s39064 bugnameltc-178125 patch severity-high targetmilestone-inin1910 verification-needed-bionic verification-needed-disco |
|
| 2019-07-03 14:23:47 |
Frank Heimes |
tags |
architecture-s39064 bugnameltc-178125 patch severity-high targetmilestone-inin1910 verification-needed-bionic verification-needed-disco |
architecture-s39064 bugnameltc-178125 patch severity-high targetmilestone-inin1910 verification-done-bionic verification-done-disco |
|
| 2019-07-22 10:53:34 |
Launchpad Janitor |
linux (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2019-07-22 10:53:34 |
Launchpad Janitor |
cve linked |
|
2018-12126 |
|
| 2019-07-22 10:53:34 |
Launchpad Janitor |
cve linked |
|
2018-12127 |
|
| 2019-07-22 10:53:34 |
Launchpad Janitor |
cve linked |
|
2018-12130 |
|
| 2019-07-22 10:53:34 |
Launchpad Janitor |
cve linked |
|
2019-11085 |
|
| 2019-07-22 10:53:34 |
Launchpad Janitor |
cve linked |
|
2019-11091 |
|
| 2019-07-22 10:53:34 |
Launchpad Janitor |
cve linked |
|
2019-11815 |
|
| 2019-07-22 10:53:34 |
Launchpad Janitor |
cve linked |
|
2019-11833 |
|
| 2019-07-22 10:53:34 |
Launchpad Janitor |
cve linked |
|
2019-11884 |
|
| 2019-07-22 12:38:59 |
Frank Heimes |
linux (Ubuntu): status |
In Progress |
Fix Released |
|
| 2019-07-23 05:25:24 |
Launchpad Janitor |
linux (Ubuntu Disco): status |
Fix Committed |
Fix Released |
|
| 2019-07-23 05:46:50 |
Frank Heimes |
ubuntu-z-systems: status |
Fix Committed |
Fix Released |
|
| 2019-08-22 16:15:46 |
Ubuntu Kernel Bot |
tags |
architecture-s39064 bugnameltc-178125 patch severity-high targetmilestone-inin1910 verification-done-bionic verification-done-disco |
architecture-s39064 bugnameltc-178125 patch severity-high targetmilestone-inin1910 verification-done-bionic verification-done-disco verification-needed-xenial |
|
