Changes in lrw.c

37d45180 - crypto: skcipher - Make skcipher_walk src.virt.addr const

Sat, 08 Mar 2025 12:53:13 +0000

crypto: skcipher - Make skcipher_walk src.virt.addr constMark the src.virt.addr field in struct skcipher_walk as a pointerto const data. This guarantees that the user won't modify the datawhich should be done through dst.virt.addr to ensure that flushingis done when necessary.Signed-off-by: Herbert Xu List of files: /linux-6.15/crypto/lrw.c

1ec0a8ab - crypto: lrw - Only access common skcipher fields on spawn

Tue, 03 Oct 2023 03:43:31 +0000

crypto: lrw - Only access common skcipher fields on spawnAs skcipher spawns may be of the type lskcipher, only the commonfields may be accessed. This was already the case but use thecorrect helpers to make this more obvious.Signed-off-by: Herbert Xu List of files: /linux-6.15/crypto/lrw.c

babb80b3 - crypto: lrw,xts - Replace strlcpy with strscpy

Tue, 20 Jun 2023 20:08:32 +0000

crypto: lrw,xts - Replace strlcpy with strscpystrlcpy() reads the entire source buffer first.This read may exceed the destination size limit.This is both inefficient and can lead to linear readoverflows if a source string is not NUL-terminated [1].In an effort to remove strlcpy() completely [2], replacestrlcpy() here with strscpy().Direct replacement is safe here since return value of -errnois used to check for truncation instead of sizeof(dest).[1] https://www.kernel.org/doc/html/latest/process/deprecated.html#strlcpy[2] https://github.com/KSPP/linux/issues/89Signed-off-by: Azeem Shaikh Reviewed-by: Kees Cook Signed-off-by: Herbert Xu List of files: /linux-6.15/crypto/lrw.c

255e48eb - crypto: api - Use data directly in completion function

Wed, 08 Feb 2023 05:58:44 +0000

crypto: api - Use data directly in completion functionThis patch does the final flag day conversion of all completionfunctions which are now all contained in the Crypto API.Signed-off-by: Herbert Xu List of files: /linux-6.15/crypto/lrw.c

f60bbbbe - crypto: lrw - Add dependency on ecb

Thu, 10 Feb 2022 02:31:13 +0000

crypto: lrw - Add dependency on ecbThe lrw template relies on ecb to work. So we need to declarea Kconfig dependency as well as a module softdep on it.Signed-off-by: Herbert Xu List of files: /linux-6.15/crypto/lrw.c

9332a9e7 - crypto: Replace HTTP links with HTTPS ones

Sun, 19 Jul 2020 16:49:59 +0000

crypto: Replace HTTP links with HTTPS onesRationale:Reduces attack surface on kernel devs opening the links for MITMas HTTPS traffic is much harder to manipulate.Deterministic algorithm:For each file: If not .svg: For each line: If doesn't contain `\bxmlns\b`: For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`: If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`: If both the HTTP and HTTPS versions return 200 OK and serve the same content: Replace HTTP with HTTPS.Signed-off-by: Alexander A. Klimov Signed-off-by: Herbert Xu List of files: /linux-6.15/crypto/lrw.c

e456ef6a - crypto: lrw - prefix function and struct names with "lrw"

Sat, 11 Jul 2020 03:36:49 +0000

crypto: lrw - prefix function and struct names with "lrw"Overly-generic names can cause problems like naming collisions,confusing crash reports, and reduced grep-ability. E.g. seecommit d099ea6e6fde ("crypto - Avoid free() namespace collision").Clean this up for the lrw template by prefixing the names with "lrw_".(I didn't use "crypto_lrw_" instead because that seems overkill.)Also constify the tfm context in a couple places.Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu List of files: /linux-6.15/crypto/lrw.c

7bcb2c99 - crypto: algapi - use common mechanism for inheriting flags

Fri, 10 Jul 2020 06:20:38 +0000

crypto: algapi - use common mechanism for inheriting flagsThe flag CRYPTO_ALG_ASYNC is "inherited" in the sense that when atemplate is instantiated, the template will have CRYPTO_ALG_ASYNC set ifany of the algorithms it uses has CRYPTO_ALG_ASYNC set.We'd like to add a second flag (CRYPTO_ALG_ALLOCATES_MEMORY) that gets"inherited" in the same way. This is difficult because the handling ofCRYPTO_ALG_ASYNC is hardcoded everywhere. Address this by: - Add CRYPTO_ALG_INHERITED_FLAGS, which contains the set of flags that have these inheritance semantics. - Add crypto_algt_inherited_mask(), for use by template ->create() methods. It returns any of these flags that the user asked to be unset and thus must be passed in the 'mask' to crypto_grab_*(). - Also modify crypto_check_attr_type() to handle computing the 'mask' so that most templates can just use this. - Make crypto_grab_*() propagate these flags to the template instance being created so that templates don't have to do this themselves.Make crypto/simd.c propagate these flags too, since it "wraps" anotheralgorithm, similar to a template.Based on a patch by Mikulas Patocka (https://lore.kernel.org/r/alpine.LRH.2.02.2006301414580.30526@file01.intranet.prod.int.rdu2.redhat.com).Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu List of files: /linux-6.15/crypto/lrw.c

1a263ae6 - gcc-10: avoid shadowing standard library 'free()' in crypto

Sat, 09 May 2020 22:58:04 +0000

gcc-10: avoid shadowing standard library 'free()' in cryptogcc-10 has started warning about conflicting types for a few newbuilt-in functions, particularly 'free()'.This results in warnings like: crypto/xts.c:325:13: warning: conflicting types for built-in function ‘free’; expected ‘void(void *)’ [-Wbuiltin-declaration-mismatch]because the crypto layer had its local freeing functions called'free()'.Gcc-10 is in the wrong here, since that function is marked 'static', andthus there is no chance of confusion with any standard library functionnamespace.But the simplest thing to do is to just use a different name here, andavoid this gcc mis-feature.[ Side note: gcc knowing about 'free()' is in itself not the mis-feature: the semantics of 'free()' are special enough that a compiler can validly do special things when seeing it. So the mis-feature here is that gcc thinks that 'free()' is some restricted name, and you can't shadow it as a local static function. Making the special 'free()' semantics be a function attribute rather than tied to the name would be the much better model ]Signed-off-by: Linus Torvalds List of files: /linux-6.15/crypto/lrw.c

d099ea6e - crypto - Avoid free() namespace collision

Thu, 30 Apr 2020 21:30:43 +0000

crypto - Avoid free() namespace collisiongcc-10 complains about using the name of a standard libraryfunction in the kernel, as we are not building with -ffreestanding:crypto/xts.c:325:13: error: conflicting types for built-in function 'free'; expected 'void(void *)' [-Werror=builtin-declaration-mismatch] 325 | static void free(struct skcipher_instance *inst) | ^~~~crypto/lrw.c:290:13: error: conflicting types for built-in function 'free'; expected 'void(void *)' [-Werror=builtin-declaration-mismatch] 290 | static void free(struct skcipher_instance *inst) | ^~~~crypto/lrw.c:27:1: note: 'free' is declared in header ''The xts and lrw cipher implementations run into this because they donot use the conventional namespaced function names.It might be better to rename all local functions in those files tohelp with things like 'ctags' and 'grep', but just renaming these twoavoids the build issue. I picked the more verbose crypto_xts_free()and crypto_lrw_free() names for consistency with several other driversthat do use namespaced function names.Fixes: f1c131b45410 ("crypto: xts - Convert to skcipher")Fixes: 700cb3f5fe75 ("crypto: lrw - Convert to skcipher")Signed-off-by: Arnd Bergmann Signed-off-by: Herbert Xu List of files: /linux-6.15/crypto/lrw.c

d5706310 - crypto: lrw - simplify error handling in create()

Wed, 26 Feb 2020 04:59:21 +0000

crypto: lrw - simplify error handling in create()Simplify the error handling in the LRW template's ->create() function bytaking advantage of crypto_drop_skcipher() now accepting (as a no-op) aspawn that hasn't been grabbed yet.Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu List of files: /linux-6.15/crypto/lrw.c

b9f76ddd - crypto: skcipher - pass instance to crypto_grab_skcipher()

Fri, 03 Jan 2020 03:58:45 +0000

crypto: skcipher - pass instance to crypto_grab_skcipher()Initializing a crypto_skcipher_spawn currently requires:1. Set spawn->base.inst to point to the instance.2. Call crypto_grab_skcipher().But there's no reason for these steps to be separate, and in fact thisunneeded complication has caused at least one bug, the one fixed bycommit 6db43410179b ("crypto: adiantum - initialize crypto_spawn::inst")So just make crypto_grab_skcipher() take the instance as an argument.To keep the function calls from getting too unwieldy due to this extraargument, also introduce a 'mask' variable into the affected placeswhich weren't already using one.Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu List of files: /linux-6.15/crypto/lrw.c

af5034e8 - crypto: remove propagation of CRYPTO_TFM_RES_* flags

Tue, 31 Dec 2019 03:19:38 +0000

crypto: remove propagation of CRYPTO_TFM_RES_* flagsThe CRYPTO_TFM_RES_* flags were apparently meant as a way to make the->setkey() functions provide more information about errors. But theseflags weren't actually being used or tested, and in many cases theyweren't being set correctly anyway. So they've now been removed.Also, if someone ever actually needs to start better distinguishing->setkey() errors (which is somewhat unlikely, as this has been unneededfor a long time), we'd be much better off just defining different returnvalues, like -EINVAL if the key is invalid for the algorithm vs.-EKEYREJECTED if the key was rejected by a policy like "no weak keys".That would be much simpler, less error-prone, and easier to test.So just remove CRYPTO_TFM_RES_MASK and all the unneeded logic thatpropagates these flags around.Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu List of files: /linux-6.15/crypto/lrw.c

20a0f976 - crypto: lrw - use correct alignmask

Thu, 30 May 2019 17:53:08 +0000

crypto: lrw - use correct alignmaskCommit c778f96bf347 ("crypto: lrw - Optimize tweak computation")incorrectly reduced the alignmask of LRW instances from'__alignof__(u64) - 1' to '__alignof__(__be32) - 1'.However, xor_tweak() and setkey() assume that the data and key,respectively, are aligned to 'be128', which has u64 alignment.Fix the alignmask to be at least '__alignof__(be128) - 1'.Fixes: c778f96bf347 ("crypto: lrw - Optimize tweak computation")Cc: # v4.20+Cc: Ondrej Mosnacek Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu List of files: /linux-6.15/crypto/lrw.c

2874c5fd - treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 152

Mon, 27 May 2019 06:55:01 +0000

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 152Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license as published by the free software foundation either version 2 of the license or at your option any later versionextracted by the scancode license scanner the SPDX license identifier GPL-2.0-or-laterhas been chosen to replace the boilerplate/reference in 3029 file(s).Signed-off-by: Thomas Gleixner Reviewed-by: Allison Randal Cc: linux-spdx@vger.kernel.orgLink: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.deSigned-off-by: Greg Kroah-Hartman List of files: /linux-6.15/crypto/lrw.c

c4741b23 - crypto: run initcalls for generic implementations earlier

Fri, 12 Apr 2019 04:57:42 +0000

crypto: run initcalls for generic implementations earlierUse subsys_initcall for registration of all templates and genericalgorithm implementations, rather than module_init. Then changecryptomgr to use arch_initcall, to place it before the subsys_initcalls.This is needed so that when both a generic and optimized implementationof an algorithm are built into the kernel (not loadable modules), thegeneric implementation is registered before the optimized one.Otherwise, the self-tests for the optimized implementation are unable toallocate the generic implementation for the new comparison fuzz tests.Note that on arm, a side effect of this change is that self-tests forgeneric implementations may run before the unaligned access handler hasbeen installed. So, unaligned accesses will crash the kernel. This isarguably a good thing as it makes it easier to detect that type of bug.Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu List of files: /linux-6.15/crypto/lrw.c

aec286cd - crypto: lrw - don't access already-freed walk.iv

Wed, 10 Apr 2019 06:46:29 +0000

crypto: lrw - don't access already-freed walk.ivIf the user-provided IV needs to be aligned to the algorithm'salignmask, then skcipher_walk_virt() copies the IV into a new alignedbuffer walk.iv. But skcipher_walk_virt() can fail afterwards, and thenif the caller unconditionally accesses walk.iv, it's a use-after-free.Fix this in the LRW template by checking the return value ofskcipher_walk_virt().This bug was detected by my patches that improve testmgr to fuzzalgorithms against their generic implementation. When the extraself-tests were run on a KASAN-enabled kernel, a KASAN use-after-freesplat occured during lrw(aes) testing.Fixes: c778f96bf347 ("crypto: lrw - Optimize tweak computation")Cc: # v4.20+Cc: Ondrej Mosnacek Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu List of files: /linux-6.15/crypto/lrw.c

b257b48c - crypto: lrw - Fix atomic sleep when walking skcipher

Mon, 15 Apr 2019 06:37:34 +0000

crypto: lrw - Fix atomic sleep when walking skcipherWhen we perform a walk in the completion function, we need to ensurethat it is atomic.Fixes: ac3c8f36c31d ("crypto: lrw - Do not use auxiliary buffer")Cc: Signed-off-by: Herbert Xu Acked-by: Ondrej Mosnacek Signed-off-by: Herbert Xu List of files: /linux-6.15/crypto/lrw.c

fd27b571 - crypto: lrw - fix rebase error after out of bounds fix

Sun, 30 Sep 2018 19:51:16 +0000

crypto: lrw - fix rebase error after out of bounds fixDue to an unfortunate interaction between commit fbe1a850b3b1("crypto: lrw - Fix out-of bounds access on counter overflow") andcommit c778f96bf347 ("crypto: lrw - Optimize tweak computation"),we ended up with a version of next_index() that always returns 127.Fixes: c778f96bf347 ("crypto: lrw - Optimize tweak computation")Signed-off-by: Ard Biesheuvel Reviewed-by: Ondrej Mosnacek Signed-off-by: Herbert Xu List of files: /linux-6.15/crypto/lrw.c

ac3c8f36 - crypto: lrw - Do not use auxiliary buffer

Thu, 13 Sep 2018 08:51:34 +0000

crypto: lrw - Do not use auxiliary bufferThis patch simplifies the LRW template to recompute the LRW tweaks fromscratch in the second pass and thus also removes the need to allocate adynamic buffer using kmalloc().As discussed at [1], the use of kmalloc causes deadlocks with dm-crypt.PERFORMANCE MEASUREMENTS (x86_64)Performed using: https://gitlab.com/omos/linux-crypto-benchCrypto driver used: lrw(ecb-aes-aesni)The results show that the new code has about the same performance as theold code. For 512-byte message it seems to be even slightly faster, butthat might be just noise.Before: ALGORITHM KEY (b) DATA (B) TIME ENC (ns) TIME DEC (ns) lrw(aes) 256 64 200 203 lrw(aes) 320 64 202 204 lrw(aes) 384 64 204 205 lrw(aes) 256 512 415 415 lrw(aes) 320 512 432 440 lrw(aes) 384 512 449 451 lrw(aes) 256 4096 1838 1995 lrw(aes) 320 4096 2123 1980 lrw(aes) 384 4096 2100 2119 lrw(aes) 256 16384 7183 6954 lrw(aes) 320 16384 7844 7631 lrw(aes) 384 16384 8256 8126 lrw(aes) 256 32768 14772 14484 lrw(aes) 320 32768 15281 15431 lrw(aes) 384 32768 16469 16293After: ALGORITHM KEY (b) DATA (B) TIME ENC (ns) TIME DEC (ns) lrw(aes) 256 64 197 196 lrw(aes) 320 64 200 197 lrw(aes) 384 64 203 199 lrw(aes) 256 512 385 380 lrw(aes) 320 512 401 395 lrw(aes) 384 512 415 415 lrw(aes) 256 4096 1869 1846 lrw(aes) 320 4096 2080 1981 lrw(aes) 384 4096 2160 2109 lrw(aes) 256 16384 7077 7127 lrw(aes) 320 16384 7807 7766 lrw(aes) 384 16384 8108 8357 lrw(aes) 256 32768 14111 14454 lrw(aes) 320 32768 15268 15082 lrw(aes) 384 32768 16581 16250[1] https://lkml.org/lkml/2018/8/23/1315Signed-off-by: Ondrej Mosnacek Signed-off-by: Herbert Xu List of files: /linux-6.15/crypto/lrw.c