Changes in Makefile

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

Fri, 25 Oct 2024 10:34:32 +0000

s390/pkey: Add new pkey handler module pkey-uvThis new pkey handler module supports the conversion ofUltravisor retrievable secrets to protected keys.The new module pkey-uv.ko is able to retrieve and verifyprotected keys backed up by the Ultravisor layer which isonly available within protected execution environment.The module is only automatically loaded if there is theUV CPU feature flagged as available. Additionally on moduleinit there is a check for protected execution environmentand for UV supporting retrievable secrets. Also if the kernelis not running as a protected execution guest, the moduleunloads itself with errno ENODEV.The pkey UV module currently supports these Ultravisorsecrets and is able to retrieve a protected key for theseUV 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_ED448Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Signed-off-by: Heiko Carstens List of files: /linux-6.15/drivers/s390/crypto/Makefile

8fcc231c - s390/pkey: Introduce pkey base with handler registry and handler modules

Thu, 22 Aug 2024 09:32:19 +0000

s390/pkey: Introduce pkey base with handler registry and handler modulesIntroduce 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 pkeybase code and the pkey customer (that is currently the pkey api codefetches a handler via pkey handler registry functions and calls theunified handler functions via the pkey base handler functions.As a result the pkey-cca, pkey-ep11 and pkey-pckmo modules getindependent from each other and it becomes possible to write newhandlers which offer another kind of implementation without implicitdependencies to other handler implementations and/or kernel devicedrivers.For each of these 4 kernel modules there is an individual Kconfigentry: CONFIG_PKEY for the base and api, CONFIG_PKEY_CCA for the PKEYCCA support handler, CONFIG_PKEY_EP11 for the EP11 support handler andCONFIG_PKEY_PCKMO for the pckmo support. The both CEX related handlermodules (PKEY CCA and PKEY EP11) have a dependency to the zcrypt apiof the zcrypt device driver.Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Signed-off-by: Vasily Gorbik List of files: /linux-6.15/drivers/s390/crypto/Makefile

86fbf5e2 - s390/pkey: Rework and split PKEY kernel module code

Thu, 22 Aug 2024 09:32:17 +0000

s390/pkey: Rework and split PKEY kernel module codeThis is a huge rework of all the pkey kernel module code.The goal is to split the code into individual parts witha 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.cThe CCA, EP11 and PCKMO code may be seen as "handlers" witha similar calling interface. The new header file pkey_base.hdeclares this calling interface. The remaining code inpkey_api.c handles the ioctl, the pkey module things and the"handler" independent code on top of the calling interfaceinvoking the handlers.This regrouping of the code will be the base for a realpkey kernel module split into a pkey base module which actsas a dispatcher and handler modules providing their service.Signed-off-by: Harald Freudenberger Reviewed-by: Holger Dengler Signed-off-by: Vasily Gorbik List of files: /linux-6.15/drivers/s390/crypto/Makefile

12376084 - s390/ap: modularize ap bus

Mon, 19 Feb 2024 17:10:19 +0000

s390/ap: modularize ap busThere is no hard requirement to have the ap bus statically in thekernel, 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 List of files: /linux-6.15/drivers/s390/crypto/Makefile

5ac8c724 - s390/zcrypt: remove CEX2 and CEX3 device drivers

Wed, 28 Jun 2023 10:36:08 +0000

s390/zcrypt: remove CEX2 and CEX3 device driversRemove the legacy device driver code for CEX2 and CEX3 cards.The last machines which are able to handle CEX2 crypto cardsare z10 EC first available 2008 and z10 BC first available 2009.The last machines able to handle a CEX3 crypto card arez196 first available 2010 and z114 first available 2011.Please note that this does not imply to drop CEX2 and CEX3support in general. With older kernels on hardware up to theaforementioned machine models these crypto cards will getsupport by IBM.The removal of the CEX2 and CEX3 device drivers code opens upsome simplifications, for example support for crypto cardswithout rng support can be removed also.Signed-off-by: Harald Freudenberger Acked-by: Heiko Carstens Signed-off-by: Heiko Carstens List of files: /linux-6.15/drivers/s390/crypto/Makefile

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

Fri, 30 Aug 2019 14:07:08 +0000

s390/zcrypt: add new low level ep11 functions support fileThis patch introduces two new files which provide somelow 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 List of files: /linux-6.15/drivers/s390/crypto/Makefile

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

Tue, 11 Jun 2019 09:16:56 +0000

s390/zcrypt: move cca misc functions to new code fileRework of the pkey code. Moved all the cca generic codeaway from pkey_api.c into a new file zcrypt_ccamisc.c.This new file is now part of the zcrypt device driverand exports a bunch of cca functions to pkey and maybe 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 List of files: /linux-6.15/drivers/s390/crypto/Makefile

ee410de8 - s390/zcrypt: zcrypt device driver cleanup

Thu, 04 Oct 2018 13:30:24 +0000

s390/zcrypt: zcrypt device driver cleanupSome 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 List of files: /linux-6.15/drivers/s390/crypto/Makefile

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

Tue, 25 Sep 2018 23:16:20 +0000

s390: vfio-ap: register matrix device with VFIO mdev frameworkRegisters the matrix device created by the VFIO AP devicedriver with the VFIO mediated device framework.Registering the matrix device will create the sysfsstructures needed to create mediated matrix deviceseach of which will be used to configure the AP matrixfor a guest and connect it to the VFIO AP device driver.Registering the matrix device with the VFIO mediated deviceframework will create the following sysfs structures:/sys/devices/vfio_ap/matrix/...... [mdev_supported_types]......... [vfio_ap-passthrough]............ createTo create a mediated device for the AP matrix device, write a UUIDto the create file: uuidgen > createA symbolic link to the mediated device's directory will be created in thedevices 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 createdin 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 List of files: /linux-6.15/drivers/s390/crypto/Makefile

1fde5734 - s390: vfio-ap: base implementation of VFIO AP device driver

Tue, 25 Sep 2018 23:16:19 +0000

s390: vfio-ap: base implementation of VFIO AP device driverIntroduces a new AP device driver. This device driveris built on the VFIO mediated device framework. The frameworkprovides sysfs interfaces that facilitate passthroughaccess by guests to devices installed on the linux host.The VFIO AP device driver will serve two purposes:1. Provide the interfaces to reserve AP devices for exclusive use by KVM guests. This is accomplished by unbinding the devices to be reserved for guest usage from the zcrypt device driver and binding them to the VFIO AP device driver.2. Implements the functions, callbacks and sysfs attribute interfaces required to create one or more VFIO mediated devices each of which will be used to configure the AP matrix for a guest and serve as a file descriptor for facilitating communication between QEMU and the VFIO AP device driver.When the VFIO AP device driver is initialized:* It registers with the AP bus for control of type 10 (CEX4 and newer) AP queue devices. This limitation was imposed due to: 1. A desire to keep the code as simple as possible; 2. Some older models are no longer supported by the kernel and others are getting close to end of service. 3. A lack of older systems on which to test older devices. The probe and remove callbacks will be provided to support the binding/unbinding of AP queue devices to/from the VFIO AP device driver.* Creates a matrix device, /sys/devices/vfio_ap/matrix, to serve as the parent of the mediated devices created, one for each guest, and to hold the APQNs of the AP devices bound to the VFIO AP device driver.Signed-off-by: Tony Krowiak Reviewed-by: Halil Pasic Tested-by: Michael Mueller Tested-by: Farhan Ali Acked-by: David Hildenbrand Reviewed-by: Cornelia Huck Message-Id: <20180925231641.4954-5-akrowiak@linux.vnet.ibm.com>Signed-off-by: Christian Borntraeger List of files: /linux-6.15/drivers/s390/crypto/Makefile

b2441318 - License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Wed, 01 Nov 2017 14:07:57 +0000

License cleanup: add SPDX GPL-2.0 license identifier to files with no licenseMany source files in the tree are missing licensing information, whichmakes it harder for compliance tools to determine the correct license.By default all files without license information are under the defaultlicense of the kernel, which is GPL version 2.Update the files which contain no license information with the 'GPL-2.0'SPDX license identifier. The SPDX identifier is a legally bindingshorthand, which can be used instead of the full boiler plate text.This patch is based on work done by Thomas Gleixner and Kate Stewart andPhilippe Ombredanne.How this work was done:Patches were generated and checked against linux-4.14-rc6 for a subset ofthe use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information,Further patches will be generated in subsequent months to fix up caseswhere non-standard license headers were used, and references to licensehad to be inferred by heuristics based on keywords.The analysis to determine which SPDX License Identifier to be applied toa file was done in a spreadsheet of side by side results from of theoutput of two independent scanners (ScanCode & Windriver) producing SPDXtag:value files created by Philippe Ombredanne. Philippe prepared thebase worksheet, and did an initial spot review of a few 1000 files.The 4.13 kernel was the starting point of the analysis with 60,537 filesassessed. Kate Stewart did a file by file comparison of the scannerresults in the spreadsheet to determine which SPDX license identifier(s)to be applied to the file. She confirmed any determination that was notimmediately clear with lawyers working with the Linux Foundation.Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines).All documentation files were explicitly excluded.The following heuristics were used to determine which SPDX licenseidentifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time.In total, over 70 hours of logged manual review was done on thespreadsheet to determine the SPDX license identifiers to apply to thesource files by Kate, Philippe, Thomas and, in some cases, confirmationby lawyers working with the Linux Foundation.Kate also obtained a third independent scan of the 4.13 code base fromFOSSology, and compared selected files where the other two scannersdisagreed against that SPDX file, to see if there was new insights. TheWindriver scanner is based on an older version of FOSSology in part, sothey are related.Thomas did random spot checks in about 500 files from the spreadsheetsfor the uapi headers and agreed with SPDX license identifier in thefiles he inspected. For the non-uapi files Thomas did random spot checksin about 15000 files.In initial set of patches against 4.14-rc6, 3 files were found to havecopy/paste license identifier errors, and have been fixed to reflect thecorrect identifier.Additionally Philippe spent 10 hours this week doing a detailed manualinspection and review of the 12,461 patched files from the initial patchversion early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correctThis produced a worksheet with 20 files needing minor correction. Thisworksheet was then exported into 3 different .csv files for thedifferent types of files to be modified.These .csv files were then reviewed by Greg. Thomas wrote a script toparse the csv files and add the proper SPDX tag to the file, in theformat that the file expected. This script was further refined by Gregbased on the output to detect more types of files automatically and todistinguish between header and source .c files (which need differentcomment types.) Finally Greg ran the script using the .csv files togenerate the patches.Reviewed-by: Kate Stewart Reviewed-by: Philippe Ombredanne Reviewed-by: Thomas Gleixner Signed-off-by: Greg Kroah-Hartman List of files: /linux-6.15/drivers/s390/crypto/Makefile

e80d4af0 - s390/pkey: Introduce pkey kernel module

Wed, 02 Nov 2016 13:37:20 +0000

s390/pkey: Introduce pkey kernel moduleThis patch introcudes a new kernel module pkey which is providingprotected key handling and management functions. The pkey API isavailable within the kernel for other s390 specific code to createand manage protected keys. Additionally the functions are exportedto user space via IOCTL calls. The implementation makes extensiveuse of functions provided by the zcrypt device driver. Forgenerating protected keys from secure keys there is also a CEXcoprocessor card needed.Signed-off-by: Harald Freudenberger Signed-off-by: Martin Schwidefsky List of files: /linux-6.15/drivers/s390/crypto/Makefile

e28d2af4 - s390/zcrypt: add multi domain support

Thu, 25 Aug 2016 09:16:03 +0000

s390/zcrypt: add multi domain supportCurrently the ap infrastructure only supports one domain at a time.This feature extends the generic cryptographic device driver tosupport multiple cryptographic domains simultaneously.There are now card and queue devices on the AP bus with independentcard and queue drivers. The new /sys layout is as follows:/sys/bus/ap devices . -> ../../../devices/ap/card/. ... card -> ../../../devices/ap/card ... drivers card card -> ../../../../devices/ap/card queue . -> ../../../../devices/ap/card/. .../sys/devices/ap card . driver -> ../../../../bus/ap/drivers/queue ... driver -> ../../../bus/ap/drivers/card ...The two digit field is the card number, the four digit field is the queue number and is the name of the device driver,e.g. "cex4".For compatability /sys/bus/ap/card for the old layout has to exist,including the attributes that used to reside there.With additional contributions from Harald Freudenberger andMartin Schwidefsky.Signed-off-by: Ingo Tuchscherer Signed-off-by: Martin Schwidefsky List of files: /linux-6.15/drivers/s390/crypto/Makefile

fc1d3f02 - s390/zcrypt: Move the ap bus into kernel

Thu, 25 Aug 2016 09:11:30 +0000

s390/zcrypt: Move the ap bus into kernelMove the ap bus into the kernel and make it general available.Additionally include the message types and the API layer as apreparation for the workload management facility.Signed-off-by: Ingo Tuchscherer Signed-off-by: Martin Schwidefsky List of files: /linux-6.15/drivers/s390/crypto/Makefile

121a868d - s390/zcrypt: Fix initialisation when zcrypt is built-in

Wed, 28 Oct 2015 10:06:08 +0000

s390/zcrypt: Fix initialisation when zcrypt is built-inap_bus and zcrypt_api assumed module information to always be presentand initialisation to be done in module loading order (symboldependencies). These assumptions don't hold if zcrypt is built-in;THIS_MODULE will be NULL in this case and init call order is linkerorder, i.e. Makefile order.Fix initialisation order by ordering the object files in the Makefileaccording to their dependencies, like the module loader would do.Fix message type registration by using a dedicated "name" field ratherthan piggy-backing on the module ("owner") information. There's nochange to the requirement that module name and msgtype name areidentical. The existing name macros are used.We don't need any special code for dealing with the drivers beingbuilt-in; the generic module support code already does the rightthing.Test results:1. CONFIG_MODULES=y, CONFIG_ZCRYPT=y KVM: boots, no /sys/bus/ap (expected) LPAR with CEX5: boots, /sys/bus/ap/devices/card*/type present2. CONFIG_MODULES=y, CONFIG_ZCRYPT=m=: KVM: boots, loading zcrypt_cex4 (and ap) fails (expected) LPAR with CEX5: boots, loading =zcrypt_cex4= succeeds, /sys/bus/ap/devices/card*/type present after explicit module loading3. CONFIG_MODULES unset, CONFIG_ZCRYPT=y: KVM: boots, no /sys/bus/ap (expected) LPAR with CEX5: boots, /sys/bus/ap/devices/card*/type presentNo further testing (user-space functionality) was done.Fixes: 3b6245fd303f ("s390/zcrypt: Separate msgtype implementation from card modules.")Signed-off-by: Sascha Silbe Signed-off-by: Martin Schwidefsky List of files: /linux-6.15/drivers/s390/crypto/Makefile

b96a9e51 - s390/zcrypt: remove support for PCICC and PCICA cards

Mon, 14 Sep 2015 15:28:26 +0000

s390/zcrypt: remove support for PCICC and PCICA cardsRemove the code for really old crypt cards, PCICC and PCICA.These cards have been out of service for several years.Reviewd-by: Ingo Tuchscherer Signed-off-by: Martin Schwidefsky List of files: /linux-6.15/drivers/s390/crypto/Makefile

1e2076f4 - s390/zcrypt: Add support for CEX4 crypto card

Tue, 28 Aug 2012 14:48:29 +0000

s390/zcrypt: Add support for CEX4 crypto cardNew zcrypt module supports IBM CryptoExpress 4 cards.Signed-off-by: Holger Dengler Signed-off-by: Martin Schwidefsky List of files: /linux-6.15/drivers/s390/crypto/Makefile

5e55a488 - s390/zcrypt: Separate msgtype implementation from card modules.

Tue, 28 Aug 2012 14:45:36 +0000

s390/zcrypt: Separate msgtype implementation from card modules.Msgtype implementations are now separated from card specific modulesand can be dynamically registered. Existing msgtype implementationsare restructured in modules.Signed-off-by: Holger Dengler Signed-off-by: Martin Schwidefsky List of files: /linux-6.15/drivers/s390/crypto/Makefile

35424f63 - [S390] Remove monolithic build option for zcrypt driver.

Sun, 11 Mar 2012 15:59:36 +0000

[S390] Remove monolithic build option for zcrypt driver.Remove the option to build a single module z90crypt that containsap bus, request router and card drivers.Signed-off-by: Holger Dengler Signed-off-by: Martin Schwidefsky List of files: /linux-6.15/drivers/s390/crypto/Makefile

fe3a1be5 - [S390] zcrypt driver Makefile, Kconfig and monolithic build.

Wed, 20 Sep 2006 13:58:34 +0000

[S390] zcrypt driver Makefile, Kconfig and monolithic build.The Makefile and Kconfig changes should be obvious. The monolithicbuild option is there to create an old-style z90crypt module forbackward compatability to older distributions.Signed-off-by: Ralph Wuerthner Signed-off-by: Martin Schwidefsky List of files: /linux-6.15/drivers/s390/crypto/Makefile