- 30 5月, 2019 1 次提交
-
-
由 Harald Freudenberger 提交于
This patch fixes a complain about possible sleep during spinlock aquired "BUG: sleeping function called from invalid context at include/crypto/algapi.h:426" for the ctr(aes) and ctr(des) s390 specific ciphers. Instead of using a spinlock this patch introduces a mutex which is save to be held in sleeping context. Please note a deadlock is not possible as mutex_trylock() is used. Signed-off-by: NHarald Freudenberger <freude@linux.ibm.com> Reported-by: NJulian Wiedmann <jwi@linux.ibm.com> Cc: stable@vger.kernel.org Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
-
- 18 4月, 2019 1 次提交
-
-
由 Herbert Xu 提交于
This patch forbids the use of 2-key 3DES (K1 == K3) in FIPS mode. Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 25 1月, 2019 1 次提交
-
-
由 Eric Biggers 提交于
CRYPTO_TFM_REQ_WEAK_KEY confuses newcomers to the crypto API because it sounds like it is requesting a weak key. Actually, it is requesting that weak keys be forbidden (for algorithms that have the notion of "weak keys"; currently only DES and XTS do). Also it is only one letter away from CRYPTO_TFM_RES_WEAK_KEY, with which it can be easily confused. (This in fact happened in the UX500 driver, though just in some debugging messages.) Therefore, make the intent clear by renaming it to CRYPTO_TFM_REQ_FORBID_WEAK_KEYS. Signed-off-by: NEric Biggers <ebiggers@google.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 24 11月, 2017 2 次提交
-
-
由 Greg Kroah-Hartman 提交于
Now that the SPDX tag is in all arch/s390/crypto/ files, that identifies the license in a specific and legally-defined manner. So the extra GPL text wording can be removed as it is no longer needed at all. This is done on a quest to remove the 700+ different ways that files in the kernel describe the GPL license text. And there's unneeded stuff like the address (sometimes incorrect) for the FSF which is never needed. No copyright headers or other non-license-description text was removed. Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
-
由 Greg Kroah-Hartman 提交于
It's good to have SPDX identifiers in all files to make it easier to audit the kernel tree for correct licenses. Update the arch/s390/crypto/ files with the correct SPDX license identifier based on the license text in the file itself. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This work is based on a script and data from Thomas Gleixner, Philippe Ombredanne, and Kate Stewart. Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Kate Stewart <kstewart@linuxfoundation.org> Cc: Philippe Ombredanne <pombredanne@nexb.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
-
- 31 1月, 2017 1 次提交
-
-
由 Matthew Rosato 提交于
Triple-DES implementations will soon be required to check for uniqueness of keys with fips mode enabled. Add checks to ensure none of the 3 keys match. Signed-off-by: NMatthew Rosato <mjrosato@linux.vnet.ibm.com> Signed-off-by: NHarald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
-
- 29 8月, 2016 5 次提交
-
-
由 Martin Schwidefsky 提交于
The double while loops of the CTR mode encryption / decryption functions are overly complex for little gain. Simplify the functions to a single while loop at the cost of an additional memcpy of a few bytes for every 4K page worth of data. Adapt the other crypto functions to make them all look alike. Reviewed-by: NHarald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
-
由 Martin Schwidefsky 提交于
The CPACF code makes some assumptions about the availablity of hardware support. E.g. if the machine supports KM(AES-256) without chaining it is assumed that KMC(AES-256) with chaining is available as well. For the existing CPUs this is true but the architecturally correct way is to check each CPACF functions on its own. This is what the query function of each instructions is all about. Reviewed-by: NHarald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
-
由 Martin Schwidefsky 提交于
The aes and the des module register multiple crypto algorithms dependent on the availability of specific CPACF instructions. To simplify the deregistration with crypto_unregister_alg add an array with pointers to the successfully registered algorithms and use it for the error handling in the init function and in the module exit function. Reviewed-by: NHarald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
-
由 Martin Schwidefsky 提交于
The CPACF instructions can complete with three different condition codes: CC=0 for successful completion, CC=1 if the protected key verification failed, and CC=3 for partial completion. The inline functions will restart the CPACF instruction for partial completion, this removes the CC=3 case. The CC=1 case is only relevant for the protected key functions of the KM, KMC, KMAC and KMCTR instructions. As the protected key functions are not used by the current code, there is no need for any kind of return code handling. Reviewed-by: NHarald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
-
由 Martin Schwidefsky 提交于
Use a separate define for the decryption modifier bit instead of duplicating the function codes for encryption / decrypton. In addition use an unsigned type for the function code. Reviewed-by: NHarald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
-
- 16 4月, 2016 1 次提交
-
-
由 Martin Schwidefsky 提交于
The CPACF instructions are going be used in KVM as well, move the defines and the inline functions from arch/s390/crypt/crypt_s390.h to arch/s390/include/asm. Rename the header to cpacf.h and replace the crypt_s390_xxx names with cpacf_xxx. While we are at it, cleanup the header as well. The encoding for the CPACF operations is odd, there is an enum for each of the CPACF instructions with the hardware function code in the lower 8 bits of each entry and a software defined number for the CPACF instruction in the upper 8 bits. Remove the superfluous software number and replace the enums with simple defines. The crypt_s390_func_available() function tests for the presence of a specific CPACF operations. The new name of the function is cpacf_query and it works slightly different than before. It gets passed an opcode of an CPACF instruction and a function code for this instruction. The facility_mask parameter is gone, the opcode is used to find the correct MSA facility bit to check if the CPACF instruction itself is available. If it is the query function of the given instruction is used to test if the requested CPACF operation is present. Acked-by: NDavid Hildenbrand <dahi@linux.vnet.ibm.com> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
-
- 22 7月, 2015 1 次提交
-
-
由 Hendrik Brueckner 提交于
Use the module_cpu_feature_match() module init function to add an module alias based on required CPU features. The modules are automatically loaded on hardware that supports the required CPU features. Signed-off-by: NHendrik Brueckner <brueckner@linux.vnet.ibm.com> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
-
- 24 11月, 2014 1 次提交
-
-
由 Kees Cook 提交于
This prefixes all crypto module loading with "crypto-" so we never run the risk of exposing module auto-loading to userspace via a crypto API, as demonstrated by Mathias Krause: https://lkml.org/lkml/2013/3/4/70Signed-off-by: NKees Cook <keescook@chromium.org> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 08 5月, 2014 1 次提交
-
-
由 Harald Freudenberger 提交于
An additional testcase found an issue with the last series of patches applied: the fallback solution may not save the iv value after operation. This very small fix just makes sure the iv is copied back to the walk/desc struct. Cc: <stable@vger.kernel.org> # 3.14+ Signed-off-by: NHarald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 30 1月, 2014 2 次提交
-
-
由 Harald Freudenberger 提交于
In s390 des and 3des ctr mode there is one preallocated page used to speed up the en/decryption. This page is not protected against concurrent usage and thus there is a potential of data corruption with multiple threads. The fix introduces locking/unlocking the ctr page and a slower fallback solution at concurrency situations. Cc: stable@vger.kernel.org Signed-off-by: NHarald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Harald Freudenberger 提交于
In s390 des and des3_ede cbc mode the iv value is not protected against concurrency access and modifications from another running en/decrypt operation which is using the very same tfm struct instance. This fix copies the iv to the local stack before the crypto operation and stores the value back when done. Cc: stable@vger.kernel.org Signed-off-by: NHarald Freudenberger <freude@linux.vnet.ibm.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 20 12月, 2013 1 次提交
-
-
由 Daniel Borkmann 提交于
Replace remaining occurences (just as we did in crypto/) under arch/*/crypto/ that make use of memcmp() for comparing keys or authentication tags for usage with crypto_memneq(). It can simply be used as a drop-in replacement for the normal memcmp(). Signed-off-by: NDaniel Borkmann <dborkman@redhat.com> Cc: James Yonan <james@openvpn.net> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 23 11月, 2012 1 次提交
-
-
由 Jan Glauber 提交于
Remove the BUG_ON's that check for failure or incomplete results of the s390 hardware crypto instructions. Rather report the errors as -EIO to the crypto layer. Signed-off-by: NJan Glauber <jang@linux.vnet.ibm.com> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
-
- 01 8月, 2012 1 次提交
-
-
由 Jussi Kivilinna 提交于
Initialization of cra_list is currently mixed, most ciphers initialize this field and most shashes do not. Initialization however is not needed at all since cra_list is initialized/overwritten in __crypto_register_alg() with list_add(). Therefore perform cleanup to remove all unneeded initializations of this field in 'arch/s390/crypto/' Cc: Gerald Schaefer <gerald.schaefer@de.ibm.com> Cc: linux-s390@vger.kernel.org Signed-off-by: NJussi Kivilinna <jussi.kivilinna@mbnet.fi> Signed-off-by: NJan Glauber <jang@linux.vnet.ibm.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 20 7月, 2012 1 次提交
-
-
由 Heiko Carstens 提交于
Remove the file name from the comment at top of many files. In most cases the file name was wrong anyway, so it's rather pointless. Also unify the IBM copyright statement. We did have a lot of sightly different statements and wanted to change them one after another whenever a file gets touched. However that never happened. Instead people start to take the old/"wrong" statements to use as a template for new files. So unify all of them in one go. Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
-
- 04 5月, 2011 3 次提交
-
-
由 Gerald Schaefer 提交于
This patch adds System z hardware acceleration support for AES, DES and 3DES in CTR mode. The hardware support is available starting with System z196. Signed-off-by: NGerald Schaefer <gerald.schaefer@de.ibm.com> Signed-off-by: NJan Glauber <jang@linux.vnet.ibm.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Jan Glauber 提交于
Remove a stale file left over from 1efbd15c and and cleanup the DES code a bit to make it easier to add new code. Signed-off-by: NJan Glauber <jang@linux.vnet.ibm.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Jan Glauber 提交于
The specification which crypto facility is required for an algorithm is added as a parameter to the availability check which is done before an algorithm is registered. With this change it is easier to add new algorithms that require different facilities. Signed-off-by: NJan Glauber <jang@linux.vnet.ibm.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 21 5月, 2010 2 次提交
-
-
由 Jan Glauber 提交于
Get rid of the des_s390 specific key check module and use the generic DES weak key check instead. Also use the generic DES header and remove the weak key check in 3DES mode, as RFC2451 mentions that the DES weak keys are not relevant for 3DES. Signed-off-by: NJan Glauber <jang@linux.vnet.ibm.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Jan Glauber 提交于
des_s390 implements support for 3DES with a 128 bit key. This mode is probably not used anywhere, less secure than 3DES with a 192 bit key and not implemented in the generic des version. Removing this mode seems to be low risk and will ease maintenance of the code. Signed-off-by: NJan Glauber <jang@linux.vnet.ibm.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 18 6月, 2009 1 次提交
-
-
由 Jarod Wilson 提交于
Just started running fips cavs test vectors through an s390x system for giggles, and discovered that I missed patching s390's arch-specific des3 implementation w/an earlier des3 patch to permit weak keys. This change adds the same flag tweaks as ad79cdd7 (crypto: des3_ede - permit weak keys unless REQ_WEAK_KEY set) for s390's des3 implementation, yields expected test results now. Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 17 4月, 2008 1 次提交
-
-
由 Heiko Carstens 提交于
Not very helpful when code dies in "init". See also http://lkml.org/lkml/2008/3/26/557 . Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
-
- 06 2月, 2007 1 次提交
-
-
由 Jan Glauber 提交于
This patch moves the config options for the s390 crypto instructions to the standard "Hardware crypto devices" menu. In addition some cleanup has been done: use a flag for supported keylengths, add a warning about machien limitation, return ENOTSUPP in case the hardware has no support, remove superfluous printks and update email addresses. Signed-off-by: NJan Glauber <jan.glauber@de.ibm.com> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
-
- 21 9月, 2006 4 次提交
-
-
由 Herbert Xu 提交于
This patch removes obsolete block operations of the simple cipher type from drivers. These were preserved so that existing users can make a smooth transition. Now that the transition is complete, they are no longer needed. Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Herbert Xu 提交于
This patch adds block cipher algorithms for S390. Once all users of the old cipher type have been converted the existing CBC/ECB non-block cipher operations will be removed. Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Herbert Xu 提交于
Accelerated versions of crypto algorithms must carry a distinct driver name and priority in order to distinguish themselves from their generic counter- part. Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
由 Herbert Xu 提交于
Now that the tfm is passed directly to setkey instead of the ctx, we no longer need to pass the &tfm->crt_flags pointer. This patch also gets rid of a few unnecessary checks on the key length for ciphers as the cipher layer guarantees that the key length is within the bounds specified by the algorithm. Rather than testing dia_setkey every time, this patch does it only once during crypto_alloc_tfm. The redundant check from crypto_digest_setkey is also removed. Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 26 6月, 2006 1 次提交
-
-
由 Herbert Xu 提交于
Up until now algorithms have been happy to get a context pointer since they know everything that's in the tfm already (e.g., alignment, block size). However, once we have parameterised algorithms, such information will be specific to each tfm. So the algorithm API needs to be changed to pass the tfm structure instead of the context pointer. This patch is basically a text substitution. The only tricky bit is the assembly routines that need to get the context pointer offset through asm-offsets.h. Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
-
- 15 1月, 2006 2 次提交
-
-
由 Jan Glauber 提交于
Provide ECB and CBC encrypt / decrypt functions to crypto API to speed up our hardware accelerated DES implementation. This new functions allow the crypto API to call ECB / CBC directly with large blocks in difference to the old functions that were calles with algorithm block size (8 bytes for DES). This is up to factor 10 faster than our old hardware implementation :) Signed-off-by: NJan Glauber <jan.glauber@de.ibm.com> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
由 Jan Glauber 提交于
Beautify the s390 in-kernel-crypto des code. Signed-off-by: NJan Glauber <jan.glauber@de.ibm.com> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 07 1月, 2006 1 次提交
-
-
由 Jan Glauber 提交于
Replace all references to z990 by s390 in the in-kernel crypto files in arch/s390/crypto. The code is not specific to a particular machine (z990) but to the s390 platform. Big diff, does nothing.. Signed-off-by: NJan Glauber <jan.glauber@de.ibm.com> Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-