Fixed issue reported by Dan Carpenter
410 if (adf_get_cfg_int(accel_dev, "Accelerator0",
411 ADF_ETRMGR_COALESCING_ENABLED_FORMAT,
412 bank_num, &coalesc_enabled) && coalesc_enabled)
This condition is reversed, so it only enables c
The order of the v1 patches is somewhat in order of "increasing scale",
reflecting my learning about the code. But if this unroll is okay,
it would probably make the most sense to reorder things so it's
first and then other changes can be made on top of the simpler code.
Given the unusual impleme
>> --- a/crypto/ansi_cprng.c
>> +++ b/crypto/ansi_cprng.c
>> @@ -51,9 +51,9 @@ struct prng_context {
>> unsigned char rand_data[DEFAULT_BLK_SZ];
>> unsigned char DT[DEFAULT_BLK_SZ];
>> unsigned char V[DEFAULT_BLK_SZ];
>> -u32 rand_read_pos; /* Offset into rand_data[] */
>> +
> I'm only ok with removing I if you can continue to be able to output it.
> given that I is listed as part of the test sequences that NIST provides,
> I'd like to be able to compare the values.
I can do that easily, but I can't print the *input* I, which
is the result of encrypting the previous D
> NACK
>
> The assumption that its not needed is incorrect. In fips mode its explicitly
> needed to validate that the rng isn't reproducing identical random data.
Please take a second look. The validation is still there; I fully
understand that and preserved that. (Well, I broke it later gettin
> Not sure what you're concerned about, or what you're even referencing.
Sorry for the confusion, but it's genuine. See below for what I think is
the solution.
> The shash_desc structure represents a discrete block of data that is
> being hashed. It can be updated with new data, reset, finalize
On 12/02/2014 08:49 AM, Tadeusz Struk wrote:
> On 12/02/2014 04:21 AM, Dan Carpenter wrote:
>> drivers/crypto/qat/qat_common/adf_transport.c
>>407 /* Enable IRQ coalescing always. This will allow to use
>>408 * the optimised flag and coalesc register.
>>409
> That is an old version. The updated version (published in 2005), and
> specified in the ansi_cprng.c file removes that language.
Oh! Thank you! I'm pretty sure I read the 1998 version.
In fact, apparently there's a 2010 version:
http://www.codesdownload.org/3761-ANSI-X9-TR-31-2010.html
I n
>> if (byte_count < DEFAULT_BLK_SZ) {
>> empty_rbuf:
>>- while (ctx->rand_data_valid < DEFAULT_BLK_SZ) {
>>- *ptr = ctx->rand_data[ctx->rand_data_valid];
>>- ptr++;
>>- byte_count--;
>>- ctx->rand_data_
On 12/02/2014 04:21 AM, Dan Carpenter wrote:
> drivers/crypto/qat/qat_common/adf_transport.c
>407 /* Enable IRQ coalescing always. This will allow to use
>408 * the optimised flag and coalesc register.
>409 * If it is disabled in the config file just use min
Hi,
algif_skcipher sends 127 sgl buffers for encryption regardless of how
many buffers acctually have data to process, where the few first with
valid len and the rest with zero len. This is not very eficient and may cause
problems when algs do something like this without checking the buff
lenght:
f
Hi,
On 12/02/2014 06:33 AM, Herbert Xu wrote:
> I think marking the end is useful. How about doing the marking
> and unmarking whenever sgl->cur is updated?
I have a v2 ready where I mark it based on the actual data.
Thanks
--
To unsubscribe from this list: send the line "unsubscribe linux-crypt
On Tue, Dec 02, 2014 at 03:43:13AM -0500, George Spelvin wrote:
> rand_read_pos is never more than 16, while there's only 1 flag
> bit allocated, so we can shrink the context a little.
>
> Signed-off-by: George Spelvin
> ---
> crypto/ansi_cprng.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 de
On Sun, Nov 30, 2014 at 06:03:43PM +0100, Julia Lawall wrote:
> From: Julia Lawall
>
> Memset on a local variable may be removed when it is called just before the
> variable goes out of scope. Using memzero_explicit defeats this
> optimization. A simplified version of the semantic patch that ma
On Sun, Nov 30, 2014 at 10:55:26AM +0100, Stephan Mueller wrote:
> When using the algif_skcipher, the following call sequence causess a
> re-initialization:
>
> 1. sendmsg with ALG_SET_OP and iov == NULL, iovlen == 0 (i.e
> initializing the cipher, but not sending data)
>
> 2. sendmsg with msg->m
On Tue, Dec 02, 2014 at 03:37:07AM -0500, George Spelvin wrote:
> It's also not necessary. We do have to change some debugging
> output.
>
> Signed-off-by: George Spelvin
> ---
> crypto/ansi_cprng.c | 39 ---
> 1 file changed, 20 insertions(+), 19 deletions(-
On Tue, Dec 02, 2014 at 03:35:50AM -0500, George Spelvin wrote:
> It's simply not necessary.
>
> Signed-off-by: George Spelvin
NACK
The assumption that its not needed is incorrect. In fips mode its explicitly
needed to validate that the rng isn't reproducing identical random data.
Neil
--
To
On Mon, Dec 01, 2014 at 07:03:00AM -0800, Tadeusz Struk wrote:
>
> Ok, I can look at the data, but do you think the idea with marking the
> end of data in TX sgl is worthwhile or should I just forget about it.
> Another question is - is an sgl with lots of empty buffers a valid input
> from an alg
On Tue, Dec 02, 2014 at 12:39:30AM -0500, George Spelvin wrote:
> > See Documentation/DocBook/crypto-API.tmpl in the cryptodev-2.6 tree.
> > There you will find tons of documentation (which will be merged during
> > 3.19-rc1)
>
> Yes, I've been reading that. It certainly helps a great deal, but
On Mon, Dec 01, 2014 at 11:55:18PM -0500, George Spelvin wrote:
> >> The other one, which I have to think *very* hard about, is whether
> >> using the same seed material as /dev/random in this much weaker
> >> cryptographic construction will introduce a flaw in *it*.
>
> > I have no idea what you
Hello Tadeusz Struk,
The patch a672a9dc872e: "crypto: qat - Intel(R) QAT transport code"
from Jun 5, 2014, leads to the following static checker warning:
drivers/crypto/qat/qat_common/adf_transport.c:412 adf_init_bank()
error: potentially using uninitialized 'coalesc_enabled'.
dr
I just realized that the memzero_explicit of ctx->rand_data_bytes[]
(a late addition, done just a few minutes before posting), while
it prevents backtracking, also totally breaks FIPS anti-repetition
checking.
So ignore that line (171 of the modified file). Sorry.
--
To unsubscribe from this lis
>From smuel...@chronox.de Tue Dec 02 08:57:23 2014
X-AuthUser: s...@eperm.de
From: Stephan Mueller
To: George Spelvin
Cc: herb...@gondor.apana.org.au, nhor...@tuxdriver.com,
linux-crypto@vger.kernel.org
Subject: Re: [PATCH 02/17] crypto: ansi_cprng - Eliminate ctx->last_rand_data
Date: Tue, 02 D
The larger seed with deterministic DT is still supported, but make the
default non-deterministically random, with fresh DT.
This must come after the patch that makes testmgr.c not depend on
the default seedsize to allocate its buffers, since it tests the
non-default (larger seed) case.
Signed-off
The current code stores three pointers to three arrays, and three lengths,
and the only thing it does with them is concatenate them.
This seems ridiculous. Just store one combined array and combined
length, and don't do any reformatting at run-time.
One questionable decision is the addition of c
crypto_rng_seedsize() isn't necessarily enough.
Also (while we're at it), dynamically allocate the result (in the
same buffer) as well.
Signed-off-by: George Spelvin
---
crypto/testmgr.c | 27 +--
1 file changed, 21 insertions(+), 6 deletions(-)
Much of this gets undone
Am Dienstag, 2. Dezember 2014, 03:35:50 schrieb George Spelvin:
Hi George,
>It's simply not necessary.
Can you please be a bit more verbose on why you think this is not
necessary?
Have you tested that change with reference test vectors -- what do
testmgr test vectors say?
>
>Signed-off-by: Ge
This is a separate patch so it may be considered separately.
I think it's in the spirit of the original ANSI specs, but opinions
are solicited.
Signed-off-by: George Spelvin
---
crypto/ansi_cprng.c | 9 +
1 file changed, 9 insertions(+)
I'm really not sure what people will think of this
It's just a union of various word sizes to address the buffer.
This achieves three things:
1) Aligns the buffers for (hopefully) slight performance benefit
2) Allows XOR to be done long-at-a-time
3) Prepares for later patches where I want int-at-a-time access
Signed-off-by: George Spelvin
---
cr
Except for the switch from triple DES to AES-128, this results in an
actual implementation of the X9.31 Appendix A.2.4 generator, which is
the same as the X9.17 Appendix C one.
If a DT seed value is provided, it is the same fully deterministic
algorithm it has always been. If DT is omitted (somet
It's more legible, and the code is 15 bytes smaller (i386).
Signed-off-by: George Spelvin
---
crypto/ansi_cprng.c | 87 -
1 file changed, 32 insertions(+), 55 deletions(-)
I'm not really sure why this was implemented this convoluted way
in the
The crypto is so slow that there's no point unrolling this function.
A simpler and clearer implementation will do just fine.
Also move all modification of rand_read_pos out of _get_more_prng_bytes;
that's variable belongs to the byte-at-a-time layer outside the
block-oriented primitive.
Signed-o
Add a few const annotations, use unsigned bytes consistently, and
make do_cont_test a bool.
Signed-off-by: George Spelvin
---
crypto/ansi_cprng.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/crypto/ansi_cprng.c b/crypto/ansi_cprng.c
index dff27a7a..6723a56
The PRNG_NEED_RESET flag forces a call to reset_prng_context(), so there's
no need to include one in cprng_init() at all. That allows considerable
simplification of reset_prng_context().
Signed-off-by: George Spelvin
---
crypto/ansi_cprng.c | 34 --
1 file change
rand_read_pos is never more than 16, while there's only 1 flag
bit allocated, so we can shrink the context a little.
Signed-off-by: George Spelvin
---
crypto/ansi_cprng.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
They're also reordered to avoid alignment holes.
diff --git a/cry
Am Dienstag, 2. Dezember 2014, 03:34:41 schrieb George Spelvin:
Hi George,
>It's more like rand_data_invalid (data which has already been output),
>so it's a pretty bad misnomer. But rand_data_pos is even better.
>
>Signed-off-by: George Spelvin
>---
> crypto/ansi_cprng.c | 25 +++--
There's no way to set it, so it's dead code.
Signed-off-by: George Spelvin
---
crypto/ansi_cprng.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
I really hope I'm reading this right!
diff --git a/crypto/ansi_cprng.c b/crypto/ansi_cprng.c
index 1a0ba6a3..93ed00f6 100644
So I can pass the "input" variable to it.
Signed-off-by: George Spelvin
---
crypto/ansi_cprng.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
I like to declare things const, and the lack of this in the prototype
causes compiler complaints.
diff --git a/crypto/ansi_cprng.c b/cry
It doesn't need a second input or a length parameter.
Signed-off-by: George Spelvin
---
crypto/ansi_cprng.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/crypto/ansi_cprng.c b/crypto/ansi_cprng.c
index 6b844f13..4856c84c7 100644
--- a/crypto/ansi_cprng.c
+++ b/
It's also not necessary. We do have to change some debugging
output.
Signed-off-by: George Spelvin
---
crypto/ansi_cprng.c | 39 ---
1 file changed, 20 insertions(+), 19 deletions(-)
diff --git a/crypto/ansi_cprng.c b/crypto/ansi_cprng.c
index c0a27288..6b84
It's simply not necessary.
Signed-off-by: George Spelvin
---
crypto/ansi_cprng.c | 28 +++-
1 file changed, 11 insertions(+), 17 deletions(-)
diff --git a/crypto/ansi_cprng.c b/crypto/ansi_cprng.c
index c9e1684b..c0a27288 100644
--- a/crypto/ansi_cprng.c
+++ b/crypto/ans
It's more like rand_data_invalid (data which has already been output),
so it's a pretty bad misnomer. But rand_data_pos is even better.
Signed-off-by: George Spelvin
---
crypto/ansi_cprng.c | 25 +++--
1 file changed, 11 insertions(+), 14 deletions(-)
diff --git a/crypto/an
Thank you all for your hospitality to my amateurish efforts.
Given that this all started with me reading the code in an attempt to
understand it, it is likely that some of the "problems" I address are
actually misunderstandings on my part. If all I get from this patch series
is some enlightenment
43 matches
Mail list logo
