kernel.git/drivers/s390/crypto, branch linux-4.20.y

s390/zcrypt: fix specification exception on z196 during ap probe

2019-02-20T09:29:13Z

commit 8f9aca0c45322a807a343fc32f95f2500f83b9ae upstream. The older machines don't have the QCI instruction available. With support for up to 256 crypto cards the probing of each card has been extended to check card ids from 0 up to 255. For machines with QCI support there is a filter limiting the range of probed cards. The older machines (z196 and older) don't have this filter and so since support for 256 cards is in the driver all cards are probed. However, these machines also require to have the card id fit into 6 bits. Exceeding this limit results in a specification exception which happens on every kernel startup even when there is no crypto configured and used at all. This fix limits the range of probed crypto cards to 64 if there is no QCI instruction available to obey to the older ap architecture and so fixes the specification exceptions on z196 machines. Cc: stable@vger.kernel.org # v4.17+ Fixes: af4a72276d49 ("s390/zcrypt: Support up to 256 crypto adapters.") Signed-off-by: Harald Freudenberger Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman

s390/zcrypt: improve special ap message cmd handling

2019-02-12T19:02:13Z

[ Upstream commit be534791011100d204602e2e0496e9e6ce8edf63 ] There exist very few ap messages which need to have the 'special' flag enabled. This flag tells the firmware layer to do some pre- and maybe postprocessing. However, it may happen that this special flag is enabled but the firmware is unable to deal with this kind of message and thus returns with reply code 0x41. For example older firmware may not know the newest messages triggered by the zcrypt device driver and thus react with reject and the named reply code. Unfortunately this reply code is not known to the zcrypt error routines and thus default behavior is to switch the ap queue offline. This patch now makes the ap error routine aware of the reply code and so userspace is informed about the bad processing result but the queue is not switched to offline state any more. Signed-off-by: Harald Freudenberger Signed-off-by: Martin Schwidefsky Signed-off-by: Sasha Levin

s390/zcrypt: reinit ap queue state machine during device probe

2018-11-27T09:43:35Z

Until the vfio-ap driver came into live there was a well known agreement about the way how ap devices are initialized and their states when the driver's probe function is called. However, the vfio device driver when receiving an ap queue device does additional resets thereby removing the registration for interrupts for the ap device done by the ap bus core code. So when later the vfio driver releases the device and one of the default zcrypt drivers takes care of the device the interrupt registration needs to get renewed. The current code does no renew and result is that requests send into such a queue will never see a reply processed - the application hangs. This patch adds a function which resets the aq queue state machine for the ap queue device and triggers the walk through the initial states (which are reset and registration for interrupts). This function is now called before the driver's probe function is invoked. When the association between driver and device is released, the driver's remove function is called. The current implementation calls a ap queue function ap_queue_remove(). This invokation has been moved to the ap bus function to make the probe / remove pair for ap bus and drivers more symmetric. Fixes: 7e0bdbe5c21c ("s390/zcrypt: AP bus support for alternate driver(s)") Cc: stable@vger.kernel.org # 4.19+ Signed-off-by: Harald Freudenberger Reviewd-by: Tony Krowiak Reviewd-by: Martin Schwidefsky Signed-off-by: Martin Schwidefsky

Merge tag 'kvm-4.20-1' of git://git.kernel.org/pub/scm/virt/kvm/kvm

2018-10-26T00:57:35Z

Pull KVM updates from Radim Krčmář: "ARM: - Improved guest IPA space support (32 to 52 bits) - RAS event delivery for 32bit - PMU fixes - Guest entry hardening - Various cleanups - Port of dirty_log_test selftest PPC: - Nested HV KVM support for radix guests on POWER9. The performance is much better than with PR KVM. Migration and arbitrary level of nesting is supported. - Disable nested HV-KVM on early POWER9 chips that need a particular hardware bug workaround - One VM per core mode to prevent potential data leaks - PCI pass-through optimization - merge ppc-kvm topic branch and kvm-ppc-fixes to get a better base s390: - Initial version of AP crypto virtualization via vfio-mdev - Improvement for vfio-ap - Set the host program identifier - Optimize page table locking x86: - Enable nested virtualization by default - Implement Hyper-V IPI hypercalls - Improve #PF and #DB handling - Allow guests to use Enlightened VMCS - Add migration selftests for VMCS and Enlightened VMCS - Allow coalesced PIO accesses - Add an option to perform nested VMCS host state consistency check through hardware - Automatic tuning of lapic_timer_advance_ns - Many fixes, minor improvements, and cleanups" * tag 'kvm-4.20-1' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (204 commits) KVM/nVMX: Do not validate that posted_intr_desc_addr is page aligned Revert "kvm: x86: optimize dr6 restore" KVM: PPC: Optimize clearing TCEs for sparse tables x86/kvm/nVMX: tweak shadow fields selftests/kvm: add missing executables to .gitignore KVM: arm64: Safety check PSTATE when entering guest and handle IL KVM: PPC: Book3S HV: Don't use streamlined entry path on early POWER9 chips arm/arm64: KVM: Enable 32 bits kvm vcpu events support arm/arm64: KVM: Rename function kvm_arch_dev_ioctl_check_extension() KVM: arm64: Fix caching of host MDCR_EL2 value KVM: VMX: enable nested virtualization by default KVM/x86: Use 32bit xor to clear registers in svm.c kvm: x86: Introduce KVM_CAP_EXCEPTION_PAYLOAD kvm: vmx: Defer setting of DR6 until #DB delivery kvm: x86: Defer setting of CR2 until #PF delivery kvm: x86: Add payload operands to kvm_multiple_exception kvm: x86: Add exception payload fields to kvm_vcpu_events kvm: x86: Add has_payload and payload to kvm_queued_exception KVM: Documentation: Fix omission in struct kvm_vcpu_events KVM: selftests: add Enlightened VMCS test ...

s390/pkey: move pckmo subfunction available checks away from module init

2018-10-22T06:37:46Z

The init of the pkey module currently fails if the pckmo instruction or the subfunctions are not available. However, customers may restrict their LPAR to switch off exactly these functions and work with secure key only. So it is a valid case to have the pkey module active and use it for secure key to protected key transfer only. This patch moves the pckmo subfunction check from the pkey module init function into the internal function where the pckmo instruction is called. So now only on invocation of the pckmo instruction the check for the required subfunction is done. If not available EOPNOTSUPP is returned to the caller. The check for having the pckmo instruction available is still done during module init. This instruction came in with MSA 3 together with the basic set of kmc instructions needed to work with protected keys. Signed-off-by: Harald Freudenberger Reviewed-by: Ingo Franzki Signed-off-by: Martin Schwidefsky

s390/pkey: Load pkey kernel module automatically

2018-10-19T06:18:18Z

With the recent enhancements of the pkey kernel module, the pkey kernel module should be loaded automatically during system startup, if MSA is available. When used for swap device encryption with random protected keys, pkey must be loaded before /etc/crypttab is processed, otherwise the sysfs attributes to read the key from are not available. Signed-off-by: Ingo Franzki Reviewed-by: Hendrik Brueckner Reviewed-by: Harald Freudenberger Signed-off-by: Martin Schwidefsky

s390/zcrypt: fix broken zcrypt_send_cprb in-kernel api function

2018-10-15T10:16:57Z

With the new multi zcrypt device node support there came in a code rework which broke the in-kernel api function zcrypt_send_cprb(). This function is used by the pkey kernel module and as an effect, transforming a secure key into a protected key did not work any more. Signed-off-by: Harald Freudenberger Signed-off-by: Martin Schwidefsky

s390/pkey: Introduce new API for transforming key blobs

2018-10-10T05:37:19Z

Introduce a new ioctl API and in-kernel API to transform a variable length key blob of any supported type into a protected key. Transforming a secure key blob uses the already existing function pkey_sec2protk(). Transforming a protected key blob also verifies if the protected key is still valid. If not, -ENODEV is returned. Both APIs are described in detail in the header files arch/s390/include/asm/pkey.h and arch/s390/include/uapi/asm/pkey.h. Signed-off-by: Ingo Franzki Reviewed-by: Harald Freudenberger Reviewed-by: Hendrik Brueckner Signed-off-by: Martin Schwidefsky

s390/pkey: Introduce new API for random protected key verification

2018-10-10T05:37:18Z

Introduce a new ioctl API and in-kernel API to verify if a random protected key is still valid. A protected key is invalid when its wrapping key verification pattern does not match the verification pattern of the LPAR. Each time an LPAR is activated, a new LPAR wrapping key is generated and the wrapping key verification pattern is updated. Both APIs are described in detail in the header files arch/s390/include/asm/pkey.h and arch/s390/include/uapi/asm/pkey.h. Signed-off-by: Ingo Franzki Reviewed-by: Harald Freudenberger Reviewed-by: Hendrik Brueckner Signed-off-by: Martin Schwidefsky

s390/pkey: Add sysfs attributes to emit secure key blobs

2018-10-10T05:37:17Z

Add binary read-only sysfs attributes for the pkey module that can be used to read random ccadata secure keys from. Keys are read from these attributes using a cat-like interface. A typical use case for those keys is to encrypt a swap device using the paes cipher. During processing of /etc/crypttab, the random random ccadata secure key to encrypt the swap device is read from one of the attributes. The following attributes are added: ccadata/aes_128 ccadata/aes_192 ccadata/aes_256 ccadata/aes_128_xts ccadata/aes_256_xts Each attribute emits a secure key blob for the corresponding key size and cipher mode. Signed-off-by: Ingo Franzki Reviewed-by: Harald Freudenberger Reviewed-by: Hendrik Brueckner Signed-off-by: Martin Schwidefsky