[Kernel-packages] [Bug 1832624] Re: [UBUNTU] kernel: Fix wrong dispatching for control domain CPRBs
This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed- xenial' to 'verification-done-xenial'. If the problem still exists, change the tag 'verification-needed-xenial' to 'verification-failed- xenial'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: verification-needed-xenial -- 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: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Fix Released Status in linux source package in Disco: Fix Released 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: ht
[Kernel-packages] [Bug 1832624] Re: [UBUNTU] kernel: Fix wrong dispatching for control domain CPRBs
** Changed in: ubuntu-z-systems Status: Fix Committed => Fix Released -- 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: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Fix Released Status in linux source package in Disco: Fix Released 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
[Kernel-packages] [Bug 1832624] Re: [UBUNTU] kernel: Fix wrong dispatching for control domain CPRBs
This bug was fixed in the package linux - 5.0.0-21.22 --- linux (5.0.0-21.22) disco; urgency=medium * linux: 5.0.0-21.22 -proposed tracker (LP: #1834902) * Disco update: 5.0.15 upstream stable release (LP: #1834529) - net: stmmac: Use bfsize1 in ndesc_init_rx_desc - Drivers: hv: vmbus: Remove the undesired put_cpu_ptr() in hv_synic_cleanup() - ubsan: Fix nasty -Wbuiltin-declaration-mismatch GCC-9 warnings - staging: greybus: power_supply: fix prop-descriptor request size - staging: wilc1000: Avoid GFP_KERNEL allocation from atomic context. - staging: most: cdev: fix chrdev_region leak in mod_exit - staging: most: sound: pass correct device when creating a sound card - ASoC: tlv320aic3x: fix reset gpio reference counting - ASoC: hdmi-codec: fix S/PDIF DAI - ASoC: stm32: sai: fix iec958 controls indexation - ASoC: stm32: sai: fix exposed capabilities in spdif mode - ASoC: stm32: sai: fix race condition in irq handler - ASoC:soc-pcm:fix a codec fixup issue in TDM case - ASoC:hdac_hda:use correct format to setup hda codec - ASoC:intel:skl:fix a simultaneous playback & capture issue on hda platform - ASoC: dpcm: prevent snd_soc_dpcm use after free - ASoC: nau8824: fix the issue of the widget with prefix name - ASoC: nau8810: fix the issue of widget with prefixed name - ASoC: samsung: odroid: Fix clock configuration for 44100 sample rate - ASoC: rt5682: Check JD status when system resume - ASoC: rt5682: fix jack type detection issue - ASoC: rt5682: recording has no sound after booting - ASoC: wm_adsp: Add locking to wm_adsp2_bus_error - clk: meson-gxbb: round the vdec dividers to closest - ASoC: stm32: dfsdm: manage multiple prepare - ASoC: stm32: dfsdm: fix debugfs warnings on entry creation - ASoC: cs4270: Set auto-increment bit for register writes - ASoC: dapm: Fix NULL pointer dereference in snd_soc_dapm_free_kcontrol - drm/omap: hdmi4_cec: Fix CEC clock handling for PM - IB/hfi1: Clear the IOWAIT pending bits when QP is put into error state - IB/hfi1: Eliminate opcode tests on mr deref - IB/hfi1: Fix the allocation of RSM table - MIPS: KGDB: fix kgdb support for SMP platforms. - ASoC: tlv320aic32x4: Fix Common Pins - drm/mediatek: Fix an error code in mtk_hdmi_dt_parse_pdata() - perf/x86/intel: Fix handling of wakeup_events for multi-entry PEBS - perf/x86/intel: Initialize TFA MSR - linux/kernel.h: Use parentheses around argument in u64_to_user_ptr() - iov_iter: Fix build error without CONFIG_CRYPTO - xtensa: fix initialization of pt_regs::syscall in start_thread - ASoC: rockchip: pdm: fix regmap_ops hang issue - drm/amdkfd: Add picasso pci id - drm/amdgpu: Adjust IB test timeout for XGMI configuration - drm/amdgpu: amdgpu_device_recover_vram always failed if only one node in shadow_list - drm/amd/display: fix cursor black issue - ASoC: cs35l35: Disable regulators on driver removal - objtool: Add rewind_stack_do_exit() to the noreturn list - slab: fix a crash by reading /proc/slab_allocators - drm/sun4i: tcon top: Fix NULL/invalid pointer dereference in sun8i_tcon_top_un/bind - virtio_pci: fix a NULL pointer reference in vp_del_vqs - RDMA/vmw_pvrdma: Fix memory leak on pvrdma_pci_remove - RDMA/hns: Fix bug that caused srq creation to fail - KEYS: trusted: fix -Wvarags warning - scsi: csiostor: fix missing data copy in csio_scsi_err_handler() - drm/mediatek: fix possible object reference leak - drm/mediatek: fix the rate and divder of hdmi phy for MT2701 - drm/mediatek: make implementation of recalc_rate() for MT2701 hdmi phy - drm/mediatek: remove flag CLK_SET_RATE_PARENT for MT2701 hdmi phy - drm/mediatek: using new factor for tvdpll for MT2701 hdmi phy - drm/mediatek: no change parent rate in round_rate() for MT2701 hdmi phy - ASoC: Intel: kbl: fix wrong number of channels - ASoC: stm32: sai: fix master clock management - ALSA: hda: Fix racy display power access - virtio-blk: limit number of hw queues by nr_cpu_ids - blk-mq: introduce blk_mq_complete_request_sync() - nvme: cancel request synchronously - nvme-fc: correct csn initialization and increments on error - nvmet: fix discover log page when offsets are used - platform/x86: pmc_atom: Drop __initconst on dmi table - NFSv4.1 fix incorrect return value in copy_file_range - perf/core: Fix perf_event_disable_inatomic() race - genirq: Prevent use-after-free and work list corruption - usb: dwc3: Allow building USB_DWC3_QCOM without EXTCON - usb: dwc3: Fix default lpm_nyet_threshold value - USB: serial: f81232: fix interrupt worker not stop - USB: cdc-acm: fix unthrottle races - usb-storage: Set virt_boundary_mask to avoid SG overflows - intel_th: pci: Add Comet Lake support - iio: adc: qcom-spmi-adc5: Fix of-based
[Kernel-packages] [Bug 1832624] Re: [UBUNTU] kernel: Fix wrong dispatching for control domain CPRBs
Changing "linux (Ubuntu)" to Fix Released, since the patch got upstream accepted with kernel 5.2 and kernel 5.2 landed in Eoan's release pocket. ** Changed in: linux (Ubuntu) Status: In Progress => Fix Released -- 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: Fix Committed Status in linux package in Ubuntu: Fix Released Status in linux source package in Bionic: Fix Released Status in linux source package in Disco: Fix Committed 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
[Kernel-packages] [Bug 1832624] Re: [UBUNTU] kernel: Fix wrong dispatching for control domain CPRBs
This bug was fixed in the package linux - 4.15.0-55.60 --- linux (4.15.0-55.60) bionic; urgency=medium * linux: 4.15.0-55.60 -proposed tracker (LP: #1834954) * Request backport of ceph commits into bionic (LP: #1834235) - ceph: use atomic_t for ceph_inode_info::i_shared_gen - ceph: define argument structure for handle_cap_grant - ceph: flush pending works before shutdown super - ceph: send cap releases more aggressively - ceph: single workqueue for inode related works - ceph: avoid dereferencing invalid pointer during cached readdir - ceph: quota: add initial infrastructure to support cephfs quotas - ceph: quota: support for ceph.quota.max_files - ceph: quota: don't allow cross-quota renames - ceph: fix root quota realm check - ceph: quota: support for ceph.quota.max_bytes - ceph: quota: update MDS when max_bytes is approaching - ceph: quota: add counter for snaprealms with quota - ceph: avoid iput_final() while holding mutex or in dispatch thread * QCA9377 isn't being recognized sometimes (LP: #1757218) - SAUCE: USB: Disable USB2 LPM at shutdown * hns: fix ICMP6 neighbor solicitation messages discard problem (LP: #1833140) - net: hns: fix ICMP6 neighbor solicitation messages discard problem - net: hns: fix unsigned comparison to less than zero * Fix occasional boot time crash in hns driver (LP: #1833138) - net: hns: Fix probabilistic memory overwrite when HNS driver initialized * use-after-free in hns_nic_net_xmit_hw (LP: #1833136) - net: hns: fix KASAN: use-after-free in hns_nic_net_xmit_hw() * hns: attempt to restart autoneg when disabled should report error (LP: #1833147) - net: hns: Restart autoneg need return failed when autoneg off * systemd 237-3ubuntu10.14 ADT test failure on Bionic ppc64el (test-seccomp) (LP: #1821625) - powerpc: sys_pkey_alloc() and sys_pkey_free() system calls - powerpc: sys_pkey_mprotect() system call * [UBUNTU] pkey: Indicate old mkvp only if old and curr. mkvp are different (LP: #1832625) - pkey: Indicate old mkvp only if old and current mkvp are different * [UBUNTU] kernel: Fix gcm-aes-s390 wrong scatter-gather list processing (LP: #1832623) - s390/crypto: fix gcm-aes-s390 selftest failures * System crashes on hot adding a core with drmgr command (4.15.0-48-generic) (LP: #1833716) - powerpc/numa: improve control of topology updates - powerpc/numa: document topology_updates_enabled, disable by default * Kernel modules generated incorrectly when system is localized to a non- English language (LP: #1828084) - scripts: override locale from environment when running recordmcount.pl * [UBUNTU] kernel: Fix wrong dispatching for control domain CPRBs (LP: #1832624) - s390/zcrypt: Fix wrong dispatching for control domain CPRBs * CVE-2019-11815 - net: rds: force to destroy connection if t_sock is NULL in rds_tcp_kill_sock(). * Sound device not detected after resume from hibernate (LP: #1826868) - drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled - drm/i915: Save the old CDCLK atomic state - drm/i915: Remove redundant store of logical CDCLK state - drm/i915: Skip modeset for cdclk changes if possible * Handle overflow in proc_get_long of sysctl (LP: #1833935) - sysctl: handle overflow in proc_get_long * Dell XPS 13 (9370) defaults to s2idle sleep/suspend instead of deep, NVMe drains lots of power under s2idle (LP: #1808957) - Revert "UBUNTU: SAUCE: pci/nvme: prevent WDC PC SN720 NVMe from entering D3 and being disabled" - Revert "UBUNTU: SAUCE: nvme: add quirk to not call disable function when suspending" - Revert "UBUNTU: SAUCE: pci: prevent Intel NVMe SSDPEKKF from entering D3" - Revert "SAUCE: nvme: add quirk to not call disable function when suspending" - Revert "SAUCE: pci: prevent sk hynix nvme from entering D3" - PCI: PM: Avoid possible suspend-to-idle issue - PCI: PM: Skip devices in D0 for suspend-to-idle - nvme-pci: Sync queues on reset - nvme: Export get and set features - nvme-pci: Use host managed power state for suspend * linux v4.15 ftbfs on a newer host kernel (e.g. hwe) (LP: #1823429) - selinux: use kernel linux/socket.h for genheaders and mdp * 32-bit x86 kernel 4.15.0-50 crash in vmalloc_sync_all (LP: #1830433) - x86/mm/pat: Disable preemption around __flush_tlb_all() - x86/mm: Drop usage of __flush_tlb_all() in kernel_physical_mapping_init() - x86/mm: Disable ioremap free page handling on x86-PAE - ioremap: Update pgtable free interfaces with addr - x86/mm: Add TLB purge to free pmd/pte page interfaces - x86/init: fix build with CONFIG_SWAP=n - x86/mm: provide pmdp_establish() helper - x86/mm: Use WRITE_ONCE() when setting PTEs * hinic: fix oops due to race in set_rx_mode (LP: #1832048) - hinic: fix a bug in set
[Kernel-packages] [Bug 1832624] Re: [UBUNTU] kernel: Fix wrong dispatching for control domain CPRBs
Due to comment #8 (where I got notified by IBM that it should be 'verified upfront' rather than 'upstream', which is a typo) I'm adjusting the tags to verified-done. ** Tags removed: verification-needed-bionic verification-needed-disco ** Tags added: verification-done-bionic verification-done-disco -- 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: Fix Committed Status in linux package in Ubuntu: In Progress Status in linux source package in Bionic: Fix Committed Status in linux source package in Disco: Fix Committed 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
[Kernel-packages] [Bug 1832624] Re: [UBUNTU] kernel: Fix wrong dispatching for control domain CPRBs
This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed- bionic' to 'verification-done-bionic'. If the problem still exists, change the tag 'verification-needed-bionic' to 'verification-failed- bionic'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: verification-needed-bionic -- 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: Fix Committed Status in linux package in Ubuntu: In Progress Status in linux source package in Bionic: Fix Committed Status in linux source package in Disco: Fix Committed 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:
[Kernel-packages] [Bug 1832624] Re: [UBUNTU] kernel: Fix wrong dispatching for control domain CPRBs
This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed- disco' to 'verification-done-disco'. If the problem still exists, change the tag 'verification-needed-disco' to 'verification-failed-disco'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: verification-needed-disco -- 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: Fix Committed Status in linux package in Ubuntu: In Progress Status in linux source package in Bionic: Fix Committed Status in linux source package in Disco: Fix Committed 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:
[Kernel-packages] [Bug 1832624] Re: [UBUNTU] kernel: Fix wrong dispatching for control domain CPRBs
** Changed in: ubuntu-z-systems Status: In Progress => Fix Committed -- 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: Fix Committed Status in linux package in Ubuntu: In Progress Status in linux source package in Bionic: Fix Committed Status in linux source package in Disco: Fix Committed 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
[Kernel-packages] [Bug 1832624] Re: [UBUNTU] kernel: Fix wrong dispatching for control domain CPRBs
Waiting to set 'linux (Ubuntu)' to Fix Committed or Fix Released until Eoan's target kernel 5.2 (or higher) hits the archive ... -- 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: In Progress Status in linux source package in Bionic: Fix Committed Status in linux source package in Disco: Fix Committed 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
[Kernel-packages] [Bug 1832624] Re: [UBUNTU] kernel: Fix wrong dispatching for control domain CPRBs
** Changed in: linux (Ubuntu Bionic) Status: New => Fix Committed ** Changed in: linux (Ubuntu Disco) Status: New => Fix Committed -- 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: In Progress Status in linux source package in Bionic: Fix Committed Status in linux source package in Disco: Fix Committed 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
[Kernel-packages] [Bug 1832624] Re: [UBUNTU] kernel: Fix wrong dispatching for control domain CPRBs
** Also affects: linux (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: linux (Ubuntu Bionic) Importance: Undecided => Medium ** Changed in: linux (Ubuntu Disco) Importance: Undecided => Medium -- 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: In Progress Status in linux source package in Bionic: New Status in linux source package in Disco: 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
[Kernel-packages] [Bug 1832624] Re: [UBUNTU] kernel: Fix wrong dispatching for control domain CPRBs
Kernel SRU request submitted: https://lists.ubuntu.com/archives/kernel-team/2019-June/thread.html#101687 ** Changed in: linux (Ubuntu) Status: New => In Progress ** Changed in: ubuntu-z-systems Status: Confirmed => In Progress -- 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: In Progress 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
[Kernel-packages] [Bug 1832624] Re: [UBUNTU] kernel: Fix wrong dispatching for control domain CPRBs
** Changed in: ubuntu-z-systems Status: Triaged => Confirmed -- 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: Confirmed 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
[Kernel-packages] [Bug 1832624] Re: [UBUNTU] kernel: Fix wrong dispatching for control domain CPRBs
** Changed in: ubuntu-z-systems Status: In Progress => Triaged -- 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: Triaged 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
[Kernel-packages] [Bug 1832624] Re: [UBUNTU] kernel: Fix wrong dispatching for control domain CPRBs
** 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 p
[Kernel-packages] [Bug 1832624] Re: [UBUNTU] kernel: Fix wrong dispatching for control domain CPRBs
** 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
[Kernel-packages] [Bug 1832624] Re: [UBUNTU] kernel: Fix wrong dispatching for control domain CPRBs
The new backport/patch applies nicely on the bionic-next tree - thx Harald! -- 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: 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
[Kernel-packages] [Bug 1832624] Re: [UBUNTU] kernel: Fix wrong dispatching for control domain CPRBs
** Tags added: patch -- 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: 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
[Kernel-packages] [Bug 1832624] Re: [UBUNTU] kernel: Fix wrong dispatching for control domain CPRBs
Here is a backport done against git clone git://kernel.ubuntu.com/ubuntu/ubuntu-bionic --branch master-next --single-branch Please note, I just did the technical backport without any compiler involvement or similar. However, as I am the owner of this code, it should apply and compile cleanly. regards Harald Freudenberger ** Patch 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 -- 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: 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
[Kernel-packages] [Bug 1832624] Re: [UBUNTU] kernel: Fix wrong dispatching for control domain CPRBs
** Changed in: ubuntu-z-systems Status: Triaged => In Progress -- 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: 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
[Kernel-packages] [Bug 1832624] Re: [UBUNTU] kernel: Fix wrong dispatching for control domain CPRBs
Commit ID got upstream accepted with kernel v5.2-rc3, so will be automatically part of 19.10, when target kernel 5.2 finally lands in eoan. Kernel SRU needed for 19.04 and 18.04. ** Changed in: ubuntu-z-systems Status: New => Triaged -- 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: Triaged Status in linux package in Ubuntu: New Bug 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 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
[Kernel-packages] [Bug 1832624] Re: [UBUNTU] kernel: Fix wrong dispatching for control domain CPRBs
** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: ubuntu-z-systems Importance: Undecided => High ** Changed in: ubuntu-z-systems Assignee: (unassigned) => Canonical Kernel Team (canonical-kernel-team) -- 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: New Status in linux package in Ubuntu: New Bug 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 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
