Changes in Makefile

00807191 - s390/crc32: expose CRC32 functions through lib

Mon, 02 Dec 2024 01:08:34 +0000

s390/crc32: expose CRC32 functions through libMove the s390 CRC32 assembly code into the lib directory and wire it upto the library interface. This allows it to be used without goingthrough the crypto API. It remains usable via the crypto API too viathe shash algorithms that use the library interface. Thus all thearch-specific "shash" code becomes unnecessary and is removed.Note: to see the diff from arch/s390/crypto/crc32-vx.c toarch/s390/lib/crc32-glue.c, view this commit with 'git show -M10'.Reviewed-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20241202010844.144356-10-ebiggers@kernel.orgSigned-off-by: Eric Biggers List of files: /linux-6.15/arch/s390/crypto/Makefile

c3dcb058 - s390/crypto: Add hardware acceleration for HMAC modes

Wed, 07 Aug 2024 16:06:29 +0000

s390/crypto: Add hardware acceleration for HMAC modesAdd new shash exploiting the HMAC hardware accelerations for SHA224,SHA256, SHA384 and SHA512 introduced with message-security assistextension 11.Reviewed-by: Harald Freudenberger Signed-off-by: Holger Dengler Signed-off-by: Vasily Gorbik List of files: /linux-6.15/arch/s390/crypto/Makefile

9592eef7 - random: remove CONFIG_ARCH_RANDOM

Tue, 05 Jul 2022 18:48:41 +0000

random: remove CONFIG_ARCH_RANDOMWhen RDRAND was introduced, there was much discussion on whether itshould be trusted and how the kernel should handle that. Initially, twomechanisms cropped up, CONFIG_ARCH_RANDOM, a compile time switch, and"nordrand", a boot-time switch.Later the thinking evolved. With a properly designed RNG, using RDRANDvalues alone won't harm anything, even if the outputs are malicious.Rather, the issue is whether those values are being *trusted* to be goodor not. And so a new set of options were introduced as the realones that people use -- CONFIG_RANDOM_TRUST_CPU and "random.trust_cpu".With these options, RDRAND is used, but it's not always credited. So inthe worst case, it does nothing, and in the best case, maybe it helps.Along the way, CONFIG_ARCH_RANDOM's meaning got sort of pulled into thecenter and became something certain platforms force-select.The old options don't really help with much, and it's a bit odd to havespecial handling for these instructions when the kernel can deal finewith the existence or untrusted existence or broken existence ornon-existence of that CPU capability.Simplify the situation by removing CONFIG_ARCH_RANDOM and using theordinary asm-generic fallback pattern instead, keeping the two optionsthat are actually used. For now it leaves "nordrand" for now, as theremoval of that will take a different route.Acked-by: Michael Ellerman Acked-by: Catalin Marinas Acked-by: Borislav Petkov Acked-by: Heiko Carstens Acked-by: Greg Kroah-Hartman Signed-off-by: Jason A. Donenfeld List of files: /linux-6.15/arch/s390/crypto/Makefile

b087dfab - s390/crypto: add SIMD implementation for ChaCha20

Thu, 04 Nov 2021 14:58:51 +0000

s390/crypto: add SIMD implementation for ChaCha20Add an implementation of the ChaCha20 stream cipher (see e.g. RFC 7539)that makes use of z13's vector instruction set extension.The original implementation is by Andy Polyakov which isadapted for kernel use.Four to six blocks are processed in parallel resulting in a performancegain for inputs >= 256 bytes.chacha20-generic1 operation in 622 cycles (256 bytes)1 operation in 2346 cycles (1024 bytes)chacha20-s3901 operation in 218 cycles (256 bytes)1 operation in 647 cycles (1024 bytes)Cc: Andy Polyakov Reviewed-by: Harald Freudenberger Signed-off-by: Patrick Steuer Signed-off-by: Heiko Carstens List of files: /linux-6.15/arch/s390/crypto/Makefile

3c2eb6b7 - s390/crypto: Support for SHA3 via CPACF (MSA6)

Wed, 14 Aug 2019 12:56:54 +0000

s390/crypto: Support for SHA3 via CPACF (MSA6)This patch introduces sha3 support for s390.- Rework the s390-specific SHA1 and SHA2 related code to provide the basis for SHA3.- Provide two new kernel modules sha3_256_s390 and sha3_512_s390 together with new kernel options.Signed-off-by: Joerg Schmidbauer Reviewed-by: Ingo Franzki Reviewed-by: Harald Freudenberger Signed-off-by: Heiko Carstens List of files: /linux-6.15/arch/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/arch/s390/crypto/Makefile

c4684f98 - s390/crypto: fix aes/paes Kconfig dependeny

Thu, 11 May 2017 15:15:54 +0000

s390/crypto: fix aes/paes Kconfig dependenyThe s390_paes and the s390_aes kernel module used just oneconfig symbol CONFIG_CRYPTO_AES. As paes has a dependencyto PKEY and this requires ZCRYPT the aes module also hada dependency to the zcrypt device driver which is not true.Fixed by introducing a new config symbol CONFIG_CRYPTO_PAESwhich has dependencies to PKEY and ZCRYPT. Removed thedependency for the aes module to ZCRYPT.Signed-off-by: Harald Freudenberger Signed-off-by: Martin Schwidefsky List of files: /linux-6.15/arch/s390/crypto/Makefile

4c637cd8 - s390/crypto: Provide s390 specific arch random functionality.

Fri, 17 Mar 2017 09:46:31 +0000

s390/crypto: Provide s390 specific arch random functionality.This patch introduces s390 specific arch random functionality.There exists a generic kernel API for arch specific randomnumber implementation (see include/linux/random.h). Herecomes the header file and a very small static code partimplementing the arch_random_* API based on the TRNGsubfunction coming with the reworked PRNG instruction.The arch random implementation hooks into the kernelinitialization and checks for availability of the TRNGfunction. In accordance to the arch random API all functionsreturn false if the TRNG is not available. Otherwise the newhigh quality entropy source provides fresh random on eachinvocation.The s390 arch random feature build is controlled viaCONFIG_ARCH_RANDOM. This config option located inarch/s390/Kconfig is enabled by default and appearsas entry "s390 architectural random number generation API"in the submenu "Processor type and features" for s390 builds.Signed-off-by: Harald Freudenberger Signed-off-by: Martin Schwidefsky List of files: /linux-6.15/arch/s390/crypto/Makefile

27937843 - s390/crypt: Add protected key AES module

Fri, 04 Nov 2016 10:57:15 +0000

s390/crypt: Add protected key AES moduleThis patch introduces a new in-kernel-crypto blockciphercalled 'paes' which implements AES with protected keys.The paes blockcipher can be used similar to the aesblockcipher but uses secure key material to derive theworking protected key and so offers an encryptionimplementation where never a clear key value is exposedin memory.The paes module is only available for the s390 platformproviding a minimal hardware support of CPACF enabledwith at least MSA level 3. Upon module initializationthese requirements are checked.Includes additional contribution from Harald Freudenberger.Signed-off-by: Martin Schwidefsky List of files: /linux-6.15/arch/s390/crypto/Makefile

f848dbd3 - s390/crc32-vx: add crypto API module for optimized CRC-32 algorithms

Tue, 28 Apr 2015 13:52:44 +0000

s390/crc32-vx: add crypto API module for optimized CRC-32 algorithmsAdd a crypto API module to access the vector extension based CRC-32implementations. Users can request the optimized implementation throughthe shash crypto API interface.Signed-off-by: Hendrik Brueckner Signed-off-by: Martin Schwidefsky List of files: /linux-6.15/arch/s390/crypto/Makefile

df1309ce - crypto: s390 - add System z hardware support for GHASH

Tue, 19 Apr 2011 19:29:18 +0000

crypto: s390 - add System z hardware support for GHASHThis patch adds System z hardware acceleration support for the GHASHalgorithm for GCM (Galois/Counter Mode).The hardware support is available beginning with System z196.Signed-off-by: Jan Glauber Signed-off-by: Gerald Schaefer Signed-off-by: Herbert Xu List of files: /linux-6.15/arch/s390/crypto/Makefile

1efbd15c - crypto: des_s390: use generic weak key check

Fri, 21 May 2010 12:04:46 +0000

crypto: des_s390: use generic weak key checkGet rid of the des_s390 specific key check module and use the generic DESweak key check instead. Also use the generic DES header and remove theweak key check in 3DES mode, as RFC2451 mentions that the DES weak keysare not relevant for 3DES.Signed-off-by: Jan Glauber Signed-off-by: Herbert Xu List of files: /linux-6.15/arch/s390/crypto/Makefile

291dc7c0 - [CRYPTO] sha512: Hardware acceleration for s390

Thu, 06 Mar 2008 11:52:00 +0000

[CRYPTO] sha512: Hardware acceleration for s390Exploit the System z10 hardware acceleration for SHA512.Signed-off-by: Jan Glauber Signed-off-by: Herbert Xu List of files: /linux-6.15/arch/s390/crypto/Makefile

604973f1 - [CRYPTO] s390: Generic sha_update and sha_final

Thu, 06 Mar 2008 11:50:20 +0000

[CRYPTO] s390: Generic sha_update and sha_finalThe sha_{update|final} functions are similar for every sha variant.Since that is error-prone and redundant replace these functions bya shared generic implementation for s390.Signed-off-by: Jan Glauber Signed-off-by: Herbert Xu List of files: /linux-6.15/arch/s390/crypto/Makefile

1b278294 - [S390] Support for s390 Pseudo Random Number Generator

Mon, 05 Feb 2007 20:18:22 +0000

[S390] Support for s390 Pseudo Random Number GeneratorStarting with the z9 the CPU Cryptographic Assist Facility comes withan integrated Pseudo Random Number Generator. The generator createsrandom numbers by an algorithm similar to the ANSI X9.17 standard.The pseudo-random numbers can be accessed via a character device drivernode called /dev/prandom. Similar to /dev/urandom any amount of bytescan be read from the device without blocking.Signed-off-by: Jan Glauber Signed-off-by: Martin Schwidefsky List of files: /linux-6.15/arch/s390/crypto/Makefile

86aa9fc2 - [S390] move crypto options and some cleanup.

Mon, 05 Feb 2007 20:18:14 +0000

[S390] move crypto options and some cleanup.This patch moves the config options for the s390 crypto instructionsto the standard "Hardware crypto devices" menu. In addition somecleanup has been done: use a flag for supported keylengths, add awarning about machien limitation, return ENOTSUPP in case thehardware has no support, remove superfluous printks and updateemail addresses.Signed-off-by: Jan Glauber Signed-off-by: Martin Schwidefsky List of files: /linux-6.15/arch/s390/crypto/Makefile

bf754ae8 - [PATCH] s390: aes support

Fri, 06 Jan 2006 08:19:18 +0000

[PATCH] s390: aes supportAdd support for the hardware accelerated AES crypto algorithm.Signed-off-by: Jan Glauber Signed-off-by: Martin Schwidefsky Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds List of files: /linux-6.15/arch/s390/crypto/Makefile

0a497c17 - [PATCH] s390: sha256 support

Fri, 06 Jan 2006 08:19:18 +0000

[PATCH] s390: sha256 supportAdd support for the hardware accelerated sha256 crypto algorithm.Signed-off-by: Jan Glauber Signed-off-by: Martin Schwidefsky Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds List of files: /linux-6.15/arch/s390/crypto/Makefile

c1e26e1e - [PATCH] s390: in-kernel crypto rename

Fri, 06 Jan 2006 08:19:17 +0000

[PATCH] s390: in-kernel crypto renameReplace all references to z990 by s390 in the in-kernel crypto files inarch/s390/crypto. The code is not specific to a particular machine (z990) butto the s390 platform. Big diff, does nothing..Signed-off-by: Jan Glauber Signed-off-by: Martin Schwidefsky Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds List of files: /linux-6.15/arch/s390/crypto/Makefile

1da177e4 - Linux-2.6.12-rc2

Sat, 16 Apr 2005 22:20:36 +0000

Linux-2.6.12-rc2Initial git repository build. I'm not bothering with the full history,even though we have it. We can create a separate "historical" gitarchive of that later if we want to, and in the meantime it's about3.2GB when imported into git - space that would just make the earlygit days unnecessarily complicated, when we don't have a lot of goodinfrastructure for it.Let it rip! List of files: /linux-6.15/arch/s390/crypto/Makefile