user/sven/linux.git/drivers/s390/crypto/Makefile, branch master

s390/pkey: Add new pkey handler module pkey-uv

2024-10-29T10:17:18Z

This new pkey handler module supports the conversion of Ultravisor retrievable secrets to protected keys. The new module pkey-uv.ko is able to retrieve and verify protected keys backed up by the Ultravisor layer which is only available within protected execution environment. The module is only automatically loaded if there is the UV CPU feature flagged as available. Additionally on module init there is a check for protected execution environment and for UV supporting retrievable secrets. Also if the kernel is not running as a protected execution guest, the module unloads itself with errno ENODEV. The pkey UV module currently supports these Ultravisor secrets and is able to retrieve a protected key for these UV secret types: - UV_SECRET_AES_128 - UV_SECRET_AES_192 - UV_SECRET_AES_256 - UV_SECRET_AES_XTS_128 - UV_SECRET_AES_XTS_256 - UV_SECRET_HMAC_SHA_256 - UV_SECRET_HMAC_SHA_512 - UV_SECRET_ECDSA_P256 - UV_SECRET_ECDSA_P384 - UV_SECRET_ECDSA_P521 - UV_SECRET_ECDSA_ED25519 - UV_SECRET_ECDSA_ED448 Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Signed-off-by: Heiko Carstens

s390/pkey: Introduce pkey base with handler registry and handler modules

2024-08-29T20:56:34Z

Introduce pkey base kernel code with a simple pkey handler registry. Regroup the pkey code into these kernel modules: - pkey is the pkey api supporting the ioctls, sysfs and in-kernel api. Also the pkey base code which offers the handler registry and handler wrapping invocation functions is integrated there. This module is automatically loaded in via CPU feature if the MSA feature is available. - pkey-cca is the CCA related handler code kernel module a offering CCA specific implementation for pkey. This module is loaded in via MODULE_DEVICE_TABLE when a CEX[4-8] card becomes available. - pkey-ep11 is the EP11 related handler code kernel module offering an EP11 specific implementation for pkey. This module is loaded in via MODULE_DEVICE_TABLE when a CEX[4-8] card becomes available. - pkey-pckmo is the PCKMO related handler code kernel module. This module is loaded in via CPU feature if the MSA feature is available, but on init a check for availability of the pckmo instruction is performed. The handler modules register via a pkey_handler struct at the pkey base code and the pkey customer (that is currently the pkey api code fetches a handler via pkey handler registry functions and calls the unified handler functions via the pkey base handler functions. As a result the pkey-cca, pkey-ep11 and pkey-pckmo modules get independent from each other and it becomes possible to write new handlers which offer another kind of implementation without implicit dependencies to other handler implementations and/or kernel device drivers. For each of these 4 kernel modules there is an individual Kconfig entry: CONFIG_PKEY for the base and api, CONFIG_PKEY_CCA for the PKEY CCA support handler, CONFIG_PKEY_EP11 for the EP11 support handler and CONFIG_PKEY_PCKMO for the pckmo support. The both CEX related handler modules (PKEY CCA and PKEY EP11) have a dependency to the zcrypt api of the zcrypt device driver. Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Signed-off-by: Vasily Gorbik

s390/pkey: Rework and split PKEY kernel module code

2024-08-29T20:56:33Z

This is a huge rework of all the pkey kernel module code. The goal is to split the code into individual parts with a dedicated calling interface: - move all the sysfs related code into pkey_sysfs.c - all the CCA related code goes to pkey_cca.c - the EP11 stuff has been moved to pkey_ep11.c - the PCKMO related code is now in pkey_pckmo.c The CCA, EP11 and PCKMO code may be seen as "handlers" with a similar calling interface. The new header file pkey_base.h declares this calling interface. The remaining code in pkey_api.c handles the ioctl, the pkey module things and the "handler" independent code on top of the calling interface invoking the handlers. This regrouping of the code will be the base for a real pkey kernel module split into a pkey base module which acts as a dispatcher and handler modules providing their service. Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Signed-off-by: Vasily Gorbik

s390/ap: modularize ap bus

2024-04-09T15:29:56Z

There is no hard requirement to have the ap bus statically in the kernel, so add an option to compile it as module. Cc: Tony Krowiak Cc: Halil Pasic Signed-off-by: Holger Dengler Reviewed-by: Harald Freudenberger Reviewed-by: Anthony Krowiak Signed-off-by: Alexander Gordeev

s390/zcrypt: remove CEX2 and CEX3 device drivers

2023-07-24T10:12:22Z

Remove the legacy device driver code for CEX2 and CEX3 cards. The last machines which are able to handle CEX2 crypto cards are z10 EC first available 2008 and z10 BC first available 2009. The last machines able to handle a CEX3 crypto card are z196 first available 2010 and z114 first available 2011. Please note that this does not imply to drop CEX2 and CEX3 support in general. With older kernels on hardware up to the aforementioned machine models these crypto cards will get support by IBM. The removal of the CEX2 and CEX3 device drivers code opens up some simplifications, for example support for crypto cards without rng support can be removed also. Signed-off-by: Harald Freudenberger Acked-by: Heiko Carstens Signed-off-by: Heiko Carstens

s390/zcrypt: add new low level ep11 functions support file

2020-01-30T12:07:55Z

This patch introduces two new files which provide some low level functions to interact with EP11 crypto cards: ep11_get_card_info() sends an EP11 query module info CPRB to the addressed card, processes the returning reply and exposes some of the information returned in the new ep11_card_info struct. ep11_get_domain_info() sends an EP11 query domain info CPRB to the addressed card/queue, processes the returning reply and exposes some of the information returned in the new ep11_domain_info struct. Signed-off-by: Harald Freudenberger Signed-off-by: Vasily Gorbik

s390/zcrypt: move cca misc functions to new code file

2019-07-29T16:14:17Z

Rework of the pkey code. Moved all the cca generic code away from pkey_api.c into a new file zcrypt_ccamisc.c. This new file is now part of the zcrypt device driver and exports a bunch of cca functions to pkey and may be called from other kernel modules as well. The pkey ioctl API is unchanged. Signed-off-by: Harald Freudenberger Reviewed-by: Ingo Franzki Signed-off-by: Vasily Gorbik

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/zcrypt: zcrypt device driver cleanup

2018-10-09T09:21:35Z

Some cleanup in the s390 zcrypt device driver: - Removed fragments of pcixx crypto card code. This code can't be reached anymore because the hardware detection function does not recognize crypto cards < CEX2 since commit f56545430736 ("s390/zcrypt: Introduce QACT support for AP bus devices.") - Rename of some files and driver names which where still reflecting pcixx support to cex2a/cex2c. - Removed all the zcrypt version strings in the file headers. There is only one place left - the zcrypt.h header file is now the only place for zcrypt device driver version info. - Zcrypt version pump up from 2.2.0 to 2.2.1. Signed-off-by: Harald Freudenberger Signed-off-by: Martin Schwidefsky

s390: vfio-ap: register matrix device with VFIO mdev framework

2018-09-26T18:45:51Z

Registers the matrix device created by the VFIO AP device driver with the VFIO mediated device framework. Registering the matrix device will create the sysfs structures needed to create mediated matrix devices each of which will be used to configure the AP matrix for a guest and connect it to the VFIO AP device driver. Registering the matrix device with the VFIO mediated device framework will create the following sysfs structures: /sys/devices/vfio_ap/matrix/ ...... [mdev_supported_types] ......... [vfio_ap-passthrough] ............ create To create a mediated device for the AP matrix device, write a UUID to the create file: uuidgen > create A symbolic link to the mediated device's directory will be created in the devices subdirectory named after the generated $uuid: /sys/devices/vfio_ap/matrix/ ...... [mdev_supported_types] ......... [vfio_ap-passthrough] ............ [devices] ............... [$uuid] A symbolic link to the mediated device will also be created in the vfio_ap matrix's directory: /sys/devices/vfio_ap/matrix/[$uuid] Signed-off-by: Tony Krowiak Reviewed-by: Halil Pasic Reviewed-by: Cornelia Huck Tested-by: Michael Mueller Tested-by: Farhan Ali Message-Id: <20180925231641.4954-6-akrowiak@linux.vnet.ibm.com> Signed-off-by: Christian Borntraeger