Hi Herbert,
you see the reported problem by simply using
sa.salg_mask = 0x;
Note, I am not fully sure about whether CRYPTO_AF_ALG_ALLOWED_MASK and
CRYPTO_AF_ALG_ALLOWED_TYPE have the correct value. But I think that all
that user space should reach is potentially the ASYNC flag and the
ci
From: Eric Biggers
The comment in gf128mul_x8_ble() was copy-and-pasted from gf128mul.h and
makes no sense in the new context. Remove it.
Cc: Harsh Jain
Signed-off-by: Eric Biggers
---
crypto/gf128mul.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/crypto/gf128mul.c b/crypto/gf128mul.
From: Eric Biggers
If the rfc7539 template was instantiated with a hash algorithm with
digest size larger than 16 bytes (POLY1305_DIGEST_SIZE), then the digest
overran the 'tag' buffer in 'struct chachapoly_req_ctx', corrupting the
subsequent memory, including 'cryptlen'. This caused a crash dur
On Mon, Nov 27, 2017 at 10:56:47AM -0800, syzbot wrote:
> syzbot will keep track of this bug report.
> Once a fix for this bug is committed, please reply to this email with:
> #syz fix: exact-commit-title
> If you want to test a patch for this bug, please reply with:
> #syz test: git://repo/address
On Wed, Nov 29, 2017 at 01:24:38AM -0800, Eric Biggers wrote:
>
> The bug is that the skcipher_walk API doesn't set the IV for zero-length
> inputs,
> while some algorithms (e.g. ChaCha20) access the IV even if the input is
> zero-length. So it was dereferencing a pointer which came from uniniti
On Mon, Dec 04, 2017 at 07:57:01AM -0800, syzbot wrote:
> syzbot will keep track of this bug report.
> Once a fix for this bug is committed, please reply to this email with:
> #syz fix: exact-commit-title
> If you want to test a patch for this bug, please reply with:
> #syz test: git://repo/address
On Thu, Nov 30, 2017 at 12:44:01PM -0800, syzbot wrote:
> syzbot will keep track of this bug report.
> Once a fix for this bug is committed, please reply to this email with:
> #syz fix: exact-commit-title
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-s
On Mon, Dec 04, 2017 at 01:53:51PM +0100, Łukasz Stelmach wrote:
> Add nodes for the True Random Number Generator found in Samsung Exynos
> 5250+ SoCs.
>
> Signed-off-by: Łukasz Stelmach
> ---
> arch/arm/boot/dts/exynos5.dtsi| 5 +
> arch/arm/boot/dts/exynos5250.dtsi | 5 +
> arch/ar
> On 08.12.2017, at 03:51, Jason A. Donenfeld wrote:
>
> Hi Eric,
>
> Nice to see more use of ChaCha20. However...
>
> Can we skip over the "sort of worse than XTS, but not having _real_
> authentication sucks anyway in either case, so whatever" and move
> directly to, "linux finally supports
On Mon, Dec 11, 2017 at 3:06 PM, Łukasz Stelmach wrote:
> Cc: Marek Szyprowski , Bartlomiej Zolnierkiewicz
>
>
> Hardware operations like reading random numbers and setting a seed need
> to be conducted in a single thread. Therefore a mutex is required to
> prevent multiple threads (processes) f
On Mon, Dec 11, 2017 at 3:06 PM, Łukasz Stelmach wrote:
> Cc: Marek Szyprowski , Bartlomiej Zolnierkiewicz
>
Same as in 1/4 and 2/4.
>
> Reseed PRNG after reading 65 kB of randomness. Although this may reduce
> performance, in most cases the loss is not noticeable.
You missed the comment abou
On Mon, Dec 11, 2017 at 3:06 PM, Łukasz Stelmach wrote:
> Cc: Marek Szyprowski , Bartlomiej Zolnierkiewicz
>
This should not appear here.
>
> Use memcpy_fromio() instead of custom exynos_rng_copy_random() function
> to retrieve generated numbers from the registers of PRNG.
>
> Rearrange the lo
On Mon, Dec 11, 2017 at 3:06 PM, Łukasz Stelmach wrote:
> Cc: Marek Szyprowski , Bartlomiej Zolnierkiewicz
>
>
> Add support for PRNG in Exynos5250+ SoCs.
>
> Signed-off-by: Łukasz Stelmach
> ---
> .../bindings/crypto/samsung,exynos-rng4.txt| 4 ++-
> drivers/crypto/exynos-rng.c
Hi Arnd,
This issue was reported a few days ago, and Herbert applied the patch 2
minutes before you send the mail (see
[https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg29762.html]).
Anyway, thank you for reporting this.
Fabien
On 11/12/17 12:47, Arnd Bergmann wrote:
> Building t
Cc: Marek Szyprowski , Bartlomiej Zolnierkiewicz
Hardware operations like reading random numbers and setting a seed need
to be conducted in a single thread. Therefore a mutex is required to
prevent multiple threads (processes) from accessing the hardware at the
same time.
The sequence of mutex_
Cc: Marek Szyprowski , Bartlomiej Zolnierkiewicz
Reseed PRNG after reading 65 kB of randomness. Although this may reduce
performance, in most cases the loss is not noticeable.
Reseeding of a PRNG does not increase entropy, but it helps preventing
backtracking the internal state of the device fr
Hello,
This is a series of patches for exynos-rng driver I've decided to
create after adding support for Exynos5250+ chips. They do not
strictly depend on each other, but I think it is better to send them
as a single patch-set.
The driver requires appropriate DT configuration introduced in
h
Cc: Marek Szyprowski , Bartlomiej Zolnierkiewicz
Use memcpy_fromio() instead of custom exynos_rng_copy_random() function
to retrieve generated numbers from the registers of PRNG.
Rearrange the loop around cpu_relax(). In a loop with while() at the
beginning and the cpu_relax() removed the retry
Cc: Marek Szyprowski , Bartlomiej Zolnierkiewicz
Add support for PRNG in Exynos5250+ SoCs.
Signed-off-by: Łukasz Stelmach
---
.../bindings/crypto/samsung,exynos-rng4.txt| 4 ++-
drivers/crypto/exynos-rng.c| 32 --
2 files changed, 33 insert
Passing the register value by reference here leads a large amount of stack being
used when CONFIG_KASAN is enabled:
drivers/crypto/qat/qat_common/qat_hal.c: In function
'qat_hal_exec_micro_inst.constprop':
drivers/crypto/qat/qat_common/qat_hal.c:963:1: error: the frame size of 1792
bytes is larg
On Fri, Dec 08, 2017 at 11:50:37AM +0100, Stephan Müller wrote:
> Hi Herbert,
>
> This patch would go on top of 7d2c3f54e6f646887d019faa45f35d6fe9fe82ce
> "crypto: af_alg - remove locking in async callback" found in Linus' tree
> which is not yet in the cryptodev-2.6 tree.
>
> In addition, this p
On Fri, Dec 01, 2017 at 05:51:02PM +0100, Kamil Konieczny wrote:
> Add myself as co-maintainer for Samsung Security SubSystem driver.
> I have added major functionality to the driver [hash acceleration],
> I have access to documentation and to hardware for testing, I can
> also dedicate some of my
Building the stm32 crypto suport as a loadable module causes a build
failure from a simple typo:
drivers/crypto/stm32/stm32-cryp.c:1035:25: error: 'sti_dt_ids' undeclared here
(not in a function); did you mean 'stm32_dt_ids'?
This renames the reference to point to the correct symbol.
Fixes: 9e0
On Thu, Nov 30, 2017 at 12:04:33PM +0100, Corentin Labbe wrote:
> This patch fix the following build failure:
> CC [M] drivers/crypto/stm32/stm32-cryp.o
> In file included from drivers/crypto/stm32/stm32-cryp.c:11:0:
> drivers/crypto/stm32/stm32-cryp.c:1049:25: error: 'sti_dt_ids' undeclared
>
On Thu, Nov 30, 2017 at 02:11:44PM +, Colin King wrote:
> From: Colin Ian King
>
> Variables adap, pi and cntrl are assigned but are never read, hence
> they are redundant and can be removed.
>
> Cleans up various clang build warnings.
>
> Signed-off-by: Colin Ian King
Patch applied. Tha
On Thu, Nov 30, 2017 at 02:23:54PM +, Colin King wrote:
> From: Colin Ian King
>
> In the case where skb->ip_summed != CHECKSUM_PARTIAL then cntrl contains
> garbage value and this is possibly being bit-wise or'd and stored into
> cpl->ctrl1. Fix this by initializing cntrl to zero.
>
> Clea
On Thu, Nov 30, 2017 at 11:26:14AM +, Colin King wrote:
> From: Colin Ian King
>
> The cryptd_max_cpu_qlen module parameter is local to the source and does
> not need to be in global scope, so make it static.
>
> Cleans up sparse warning:
> crypto/cryptd.c:35:14: warning: symbol 'cryptd_max_
On Thu, Nov 30, 2017 at 11:32:08AM +, Colin King wrote:
> From: Colin Ian King
>
> The arrays sgl_ent_len and dsgl_ent_len are local to the source and do
> not need to be in global scope, so make them static. Also re-format the
> declarations to match the following round_constant array declar
On Thu, Nov 30, 2017 at 01:39:27PM +0100, Sebastian Andrzej Siewior wrote:
> mcryptd_enqueue_request() grabs the per-CPU queue struct and protects
> access to it with disabled preemption. Then it schedules a worker on the
> same CPU. The worker in mcryptd_queue_worker() guards access to the same
>
On Wed, Nov 29, 2017 at 12:02:23PM +0100, Stephan Müller wrote:
> The wait for data is a non-atomic operation that can sleep and therefore
> potentially release the socket lock. The release of the socket lock
> allows another thread to modify the context data structure. The waiting
> operation for
On Wed, Nov 29, 2017 at 01:18:57AM -0800, Eric Biggers wrote:
> From: Eric Biggers
>
> All the ChaCha20 algorithms as well as the ARM bit-sliced AES-XTS
> algorithms call skcipher_walk_virt(), then access the IV (walk.iv)
> before checking whether any bytes need to be processed (walk.nbytes).
>
On Tue, Nov 28, 2017 at 06:48:08PM +0200, Horia Geantă wrote:
> Fix below warnings on ARMv7 by using %zu for printing size_t values:
>
> drivers/crypto/caam/caamalg_qi.c: In function aead_edesc_alloc:
> drivers/crypto/caam/caamalg_qi.c:417:17: warning: format %lu expects argument
> of type long u
On Tue, Nov 28, 2017 at 12:06:06AM +0100, Vasyl Gomonovych wrote:
> Fix ptr_ret.cocci warnings:
> arch/arm/crypto/aes-neonbs-glue.c:184:1-3: WARNING: PTR_ERR_OR_ZERO can be
> used
> arch/arm/crypto/aes-neonbs-glue.c:261:1-3: WARNING: PTR_ERR_OR_ZERO can be
> used
>
> Use PTR_ERR_OR_ZERO rather t
On Sun, Nov 26, 2017 at 12:16:46AM +0100, Hauke Mehrtens wrote:
> This fixes a typo in the CRYPTO_KPP dependency of CRYPTO_ECDH.
>
> Fixes: 3c4b23901a0c ("crypto: ecdh - Add ECDH software support")
> Cc: # v4.8+
> Signed-off-by: Hauke Mehrtens
Patch applied. Thanks.
--
Email: Herbert Xu
Home
On Thu, Nov 30, 2017 at 10:09:32AM +, Gilad Ben-Yossef wrote:
> The performance of some aead tfm providers is affected by
> the amount of parallelism possible with the processing.
>
> Introduce an async aead concurrent multiple buffer
> processing speed test to be able to test performance of s
This patch frees the request private data even if its handling failed,
as it would never be freed otherwise.
Fixes: 1b44c5a60c13 ("crypto: inside-secure - add SafeXcel EIP197 crypto engine
driver")
Suggested-by: Ofer Heifetz
Signed-off-by: Antoine Tenart
---
drivers/crypto/inside-secure/safexc
From: Ofer Heifetz
When an invalidation request is needed we currently override the context
.send and .handle_result helpers. This is wrong as under high load other
requests can already be queued and overriding the context helpers will
make them execute the wrong .send and .handle_result function
Hi Herbert,
This series is a set of 4 fixes on the Inside Secure SafeXcel crypto
engine driver. The series will be followed by another non-fix one.
This is based on v4.15-rc3.
Thanks,
Antoine
Since v3:
- Added one patch to only update areq->result on final operations.
- Fixed two coding sty
This patches update the SafeXcel driver to stop using the crypto
ahash_request result field for partial results (i.e. on updates).
Instead the driver local safexcel_ahash_req state field is used, and
only on final operations the ahash_request result buffer is updated.
Fixes: 1b44c5a60c13 ("crypto:
This patch makes use of the SKCIPHER_REQUEST_ON_STACK and
AHASH_REQUEST_ON_STACK helpers to allocate enough memory to contain both
the crypto request structures and their embedded context (__ctx).
Fixes: 1b44c5a60c13 ("crypto: inside-secure - add SafeXcel EIP197 crypto engine
driver")
Suggested-b
On Mon, Dec 11, 2017 at 08:49:57AM +0100, Antoine Tenart wrote:
>
> So this patch is indeed fixing an issue, which should probably not be
> there in the first place. I guess you recommend using a buffer local to
> the driver instead, and only update areq->request on completion (final).
That's one
On Fri, Dec 08, 2017 at 03:20:40PM +, Horia Geantă wrote:
> On 10/12/2017 6:20 PM, Herbert Xu wrote:
> > On Fri, Oct 06, 2017 at 03:04:31PM +0200, Christophe Leroy wrote:
> >> This serie fixes and improves the talitos crypto driver.
> >>
> >> First 6 patchs are fixes of failures reported by the
Hi,
I'll send a v4 soon as there are two coding style issues in the series.
I'll also include a new patch to only update the areq->result buffer on
final operations (this will fix the issue I was trying to fix with "only
update the result buffer when provided").
Sorry for the noise.
Antoine
On
From: Ofer Heifetz
When an invalidation request is needed we currently override the context
.send and .handle_result helpers. This is wrong as under high load other
requests can already be queued and overriding the context helpers will
make them execute the wrong .send and .handle_result function
Hi Herbert,
This series is a set of 4 fixes on the Inside Secure SafeXcel crypto
engine driver. The series will be followed by another non-fix one.
This is based on v4.15-rc3.
Thanks,
Antoine
Since v2:
- Removed the patch only update the result buffer when provided.
Since v1:
- Removed the
This patch frees the request private data even if its handling failed,
as it would never be freed otherwise.
Fixes: 1b44c5a60c13 ("crypto: inside-secure - add SafeXcel EIP197 crypto engine
driver")
Suggested-by: Ofer Heifetz
Signed-off-by: Antoine Tenart
---
drivers/crypto/inside-secure/safexc
This patch makes use of the SKCIPHER_REQUEST_ON_STACK and
AHASH_REQUEST_ON_STACK helpers to allocate enough memory to contain both
the crypto request structures and their embedded context (__ctx).
Fixes: 1b44c5a60c13 ("crypto: inside-secure - add SafeXcel EIP197 crypto engine
driver")
Suggested-b
47 matches
Mail list logo
