Re: [PATCH] crypto-jitterentropy: Delete unnecessary checks before the function call kzfree
Am Mittwoch, 24. Juni 2015, 10:48:19 schrieb Dan Carpenter: Hi Dan, The other NULL assignment isn't useful either. Also If entropy_collector is NULL then we would oops calling kzfree(entropy_collector-mem); ^^ Dereference. I don't understand the patch that you sent. We shouldn't be introducing jent_zalloc() or jent_zfree(). Why are you adding abstractions there? The one C file should have no dependencies on any kernel header files. Thus, all links to kernel functions are wrapped. Quite bad ones as well. What would you suggest to change? Thanks. Ciao Stephan -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto-jitterentropy: Delete unnecessary checks before the function call kzfree
Ah. I should have read the whole thread. I sort of assumed we were just adding abstractions for the fun of it (because I have worked in staging for too long). regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] random: add random_initialized command line param
On Tue 2015-06-23 23:47:33, Stephan Mueller wrote: Am Dienstag, 23. Juni 2015, 22:44:11 schrieb Pavel Machek: Hi Pavel, On Mon 2015-05-18 18:25:25, Stephan Mueller wrote: Make the threshold at which the output entropy pools are considered to be initialized configurable via a kernel command line option. The current integer value of 128 bits is a good default value. However, some user groups may want to use different values. For example, the SOGIS group now requires 125 bits at least (BSI, the participant at that group used to require 100 bits). NIST moved from 80 bits to 112 bits starting with 2014. It is therefore to be expected that in the future, this threshold may increase for different user groups. Speaking of random and kernel parameters... should we add random=hex digits parameter to pass entropy from bootloader to the kernel? Everybody can see that string. How do you think that way of providing entropy is protected? Only local users, not remote attackers. And yes, we should probably censor the command line for this use. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto-jitterentropy: Delete unnecessary checks before the function call kzfree
The other NULL assignment isn't useful either. Also If entropy_collector is NULL then we would oops calling kzfree(entropy_collector-mem); ^^ Dereference. I don't understand the patch that you sent. We shouldn't be introducing jent_zalloc() or jent_zfree(). Why are you adding abstractions there? Quite bad ones as well. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] keys: Use non-conflicting variable name
arm64:allmodconfig fails to build as follows.
In file included from include/acpi/platform/aclinux.h:74:0,
from include/acpi/platform/acenv.h:173,
from include/acpi/acpi.h:56,
from include/linux/acpi.h:37,
from ./arch/arm64/include/asm/dma-mapping.h:21,
from include/linux/dma-mapping.h:86,
from include/linux/skbuff.h:34,
from include/crypto/algapi.h:18,
from crypto/asymmetric_keys/rsa.c:16:
include/linux/ctype.h:15:12: error: expected ‘;’, ‘,’ or ‘)’
before numeric constant
#define _X 0x40 /* hex digit */
^
crypto/asymmetric_keys/rsa.c:123:47: note: in expansion of macro ‘_X’
static int RSA_I2OSP(MPI x, size_t xLen, u8 **_X)
^
crypto/asymmetric_keys/rsa.c: In function ‘RSA_verify_signature’:
crypto/asymmetric_keys/rsa.c:256:2: error:
implicit declaration of function ‘RSA_I2OSP’
The problem is caused by an unrelated include file change, resulting in
the inclusion of ctype.h on arm64. This in turn causes the local variable
_X to conflict with macro _X used in ctype.h.
Fixes: b6197b93fa4b (arm64 : Introduce support for ACPI _CCA object)
Cc: Suthikulpanit, Suravee suravee.suthikulpa...@amd.com
Signed-off-by: Guenter Roeck li...@roeck-us.net
---
crypto/asymmetric_keys/rsa.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/crypto/asymmetric_keys/rsa.c b/crypto/asymmetric_keys/rsa.c
index 459cf97a75e2..508b57b77474 100644
--- a/crypto/asymmetric_keys/rsa.c
+++ b/crypto/asymmetric_keys/rsa.c
@@ -120,7 +120,7 @@ static int RSAVP1(const struct public_key *key, MPI s, MPI
*_m)
/*
* Integer to Octet String conversion [RFC3447 sec 4.1]
*/
-static int RSA_I2OSP(MPI x, size_t xLen, u8 **_X)
+static int RSA_I2OSP(MPI x, size_t xLen, u8 **pX)
{
unsigned X_size, x_size;
int X_sign;
@@ -147,7 +147,7 @@ static int RSA_I2OSP(MPI x, size_t xLen, u8 **_X)
return -EBADMSG;
}
- *_X = X;
+ *pX = X;
return 0;
}
--
2.1.0
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: testmgr - don't print info about missing test for gcm-aes-aesni
Am Mittwoch, 24. Juni 2015, 07:14:22 schrieb Tadeusz Struk:
Hi Tadeusz,
Don't print info about missing test for the internal
helper __driver-gcm-aes-aesni
Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com
---
crypto/testmgr.c |3 +++
1 file changed, 3 insertions(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 975e1ea..ad4c3e3 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -2056,6 +2056,9 @@ static const struct alg_test_desc alg_test_descs[] = {
.alg = __driver-ecb-twofish-avx,
.test = alg_test_null,
}, {
+ .alg = __driver-gcm-aes-aesni,
+ .test = alg_test_null,
Wouldn't fips_allowed = 1 be needed here?
+ }, {
.alg = __ghash-pclmulqdqni,
.test = alg_test_null,
.fips_allowed = 1,
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Ciao
Stephan
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Crypto Update for 4.2
On Tue, Jun 23, 2015 at 07:11:19PM -0700, Linus Torvalds wrote: On Mon, Jun 22, 2015 at 1:44 AM, Herbert Xu herb...@gondor.apana.org.au wrote: Here is the crypto update for 4.2: Hmm. I noticed a new annoyance: I get this at bootup: [ +0.001504] alg: No test for __gcm-aes-aesni (__driver-gcm-aes-aesni) This is indeed bogus and I'll make sure it disappears. [ +0.002233] alg: aead: setkey failed on test 1 for rfc4106-gcm-aesni: flags=0 This however is a real bug. It looks like aesni is somehow broken and is failing on setkey. I'll look into it. in general, I'm not at all convinced that the crypto tests make sense. I absolutely destest that horrid testmgr.h file that is 32 _thousand_ lines of noise. And now it's apparently complaining about a missing test, so that nasty mess will presumably grow. Could you not make the test infrastructure be something that gets run in user space? I too think the current testmgr model has reached its limit. However, it has been quite useful in catching bugs like the one you saw which may otherwise result in hard-to-track-down bugs in other subsystems such as IPsec or disk encryption. What I was planning to do is to instead bundle the test vectors with the algorithms themselves. So for each algorithm we would have the test vectors in the canonical C implementation which then would be used to test every other implmenetation of that algorithm. The test code could similarly be distributed out to the individual types, e.g., RNG tests would go into rng.c, hash tests into ahash.c, etc. When this is done there would be no central repository of testing information anymore. Cheers, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] crypto: aesni - fix failing setkey for rfc4106-gcm-aesni
rfc4106(gcm(aes)) uses cbc(aes) to generate hash key. cbc(aes) needs chainiv, but the chainiv gets initialized after aesni_intel when both are statically linked so the setkey fails. This patch forces aesni_intel to be initialized after chainiv. Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com --- arch/x86/crypto/aesni-intel_glue.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/crypto/aesni-intel_glue.c b/arch/x86/crypto/aesni-intel_glue.c index ebcb981d..cb630a8 100644 --- a/arch/x86/crypto/aesni-intel_glue.c +++ b/arch/x86/crypto/aesni-intel_glue.c @@ -1537,7 +1537,7 @@ static void __exit aesni_exit(void) crypto_fpu_exit(); } -module_init(aesni_init); +late_initcall(aesni_init); module_exit(aesni_exit); MODULE_DESCRIPTION(Rijndael (AES) Cipher Algorithm, Intel AES-NI instructions optimized); -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 00/14] crypto: add a new driver for Marvell's CESA
[Re: [PATCH v7 00/14] crypto: add a new driver for Marvell's CESA] On 22/06/2015 (Mon 15:59) Herbert Xu wrote: On Mon, Jun 22, 2015 at 09:23:36AM +0200, Boris Brezillon wrote: Hi Herbert, On Sun, 21 Jun 2015 16:27:17 +0800 Herbert Xu herb...@gondor.apana.org.au wrote: On Sun, Jun 21, 2015 at 10:24:18AM +0200, Boris Brezillon wrote: Indeed. Here is a patch fixing that. I think you should just kill COMPILE_TEST instead of adding ARM. The following patch is killing the COMPILE_TEST dependency. Patch applied. Just a heads up, this driver is still killing a couple of linux-next builds today and for the past few days. drivers/crypto/mv_cesa.c:1037:2: error: implicit declaration of function 'of_get_named_gen_pool' [-Werror=implicit-function-declaration] http://kisskb.ellerman.id.au/kisskb/buildresult/12448851/ http://kisskb.ellerman.id.au/kisskb/buildresult/12448776/ Missing dependency on CONFIG_OF_blah presumably. Paul. -- -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 00/14] crypto: add a new driver for Marvell's CESA
Hello Paul, On Thu, Jun 25, 2015 at 2:00 AM, Paul Gortmaker paul.gortma...@windriver.com wrote: [Re: [PATCH v7 00/14] crypto: add a new driver for Marvell's CESA] On 22/06/2015 (Mon 15:59) Herbert Xu wrote: On Mon, Jun 22, 2015 at 09:23:36AM +0200, Boris Brezillon wrote: Hi Herbert, On Sun, 21 Jun 2015 16:27:17 +0800 Herbert Xu herb...@gondor.apana.org.au wrote: On Sun, Jun 21, 2015 at 10:24:18AM +0200, Boris Brezillon wrote: Indeed. Here is a patch fixing that. I think you should just kill COMPILE_TEST instead of adding ARM. The following patch is killing the COMPILE_TEST dependency. Patch applied. Just a heads up, this driver is still killing a couple of linux-next builds today and for the past few days. drivers/crypto/mv_cesa.c:1037:2: error: implicit declaration of function 'of_get_named_gen_pool' [-Werror=implicit-function-declaration] http://kisskb.ellerman.id.au/kisskb/buildresult/12448851/ http://kisskb.ellerman.id.au/kisskb/buildresult/12448776/ Missing dependency on CONFIG_OF_blah presumably. I haven't looked at the series but linux/genalloc.h has a stub of_get_named_gen_pool() function if CONFIG_OF is not enabled [0]. So it seems that the problem is rather that the header is not being included in some file. Paul. -- Best regards, Javier [0]: http://lxr.free-electrons.com/source/include/linux/genalloc.h#L131 -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] crypto: testmgr - don't print info about missing test for gcm-aes-aesni
Hi Stephan,
On 06/24/2015 07:44 AM, Stephan Mueller wrote:
}, {
+ .alg = __driver-gcm-aes-aesni,
+ .test = alg_test_null,
Wouldn't fips_allowed = 1 be needed here?
Yes, you are right. I will send a v2 soon.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] crypto: testmgr - don't print info about missing test for gcm-aes-aesni
Don't print info about missing test for the internal
helper __driver-gcm-aes-aesni
changes in v2:
- marked test as fips allowed
Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com
---
crypto/testmgr.c |4
1 file changed, 4 insertions(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 975e1ea..d0a42bd 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -2056,6 +2056,10 @@ static const struct alg_test_desc alg_test_descs[] = {
.alg = __driver-ecb-twofish-avx,
.test = alg_test_null,
}, {
+ .alg = __driver-gcm-aes-aesni,
+ .test = alg_test_null,
+ .fips_allowed = 1,
+ }, {
.alg = __ghash-pclmulqdqni,
.test = alg_test_null,
.fips_allowed = 1,
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/13] dmaengine: Introduce dma_request_slave_channel_compat_reason()
On Mon, Jun 22, 2015 at 02:31:00PM +0300, Peter Ujfalusi wrote: On 06/12/2015 03:58 PM, Vinod Koul wrote: Sorry this slipped thru I was away for a week anyways ;) Thinking about it again, I think we should coverge to two APIs and mark the legacy depracuated and look to convert folks and phase that out Currently, w/o this series we have these APIs: /* to be used with DT/ACPI */ dma_request_slave_channel(dev, name) /* NULL on failure */ dma_request_slave_channel_reason(dev, name) /* error code on failure */ /* Legacy mode only - no DT/ACPI lookup */ dma_request_channel(mask, fn, fn_param) /* NULL on failure */ /* to be used with DT/ACPI or legacy boot */ dma_request_slave_channel_compat(mask, fn, fn_param, dev, name) /* NULL on failure */ To request _any_ channel to be used for memcpy one has to use dma_request_channel(mask, NULL, NULL); If I did not missed something. I dont think so :) As we need different types of parameters for DT/ACPI and legacy (non DT/ACPI lookup) and the good API names are already taken, we might need to settle: /* to be used with DT/ACPI */ dma_request_slave_channel(dev, name) /* error code on failure */ - Convert users to check IS_ERR_OR_NULL() instead against NULL - Mark dma_request_slave_channel_reason() deprecated and convert the current users /* to be used with DT/ACPI or legacy boot */ dma_request_slave_channel_compat(mask, fn, fn_param, dev, name) /* error code on failure */ - Convert users to check IS_ERR_OR_NULL() instead against NULL - Do not try legacy mode if either OF or ACPI failed because of real error Should we keep the filter fn and an API for this, I am still not too sure about that part. Anyway users should be on DT/ACPI. if someone wants filter then let them use dma_request_channel() /* Legacy mode only - no DT/ACPI lookup */ dma_request_channel_legacy(mask, fn, fn_param) /* error code on failure */ - convert users of dma_request_channel() - mark dma_request_channel() deprecated Why should we create a new API, how about marking dma_request_channel() as legacy and generic memcpy API and let other users be migrated? /* to be used to get a channel for memcpy for example */ dma_request_any_channel(mask) /* error code on failure */ - Convert current dma_request_channel(mask, NULL, NULL) users I know, any of the other function could be prepared to handle this when parameters are missing, but it is a bit cleaner to have separate API for this. Though it has merits but adds another API. We cna have internal _dma_request_xxx API where parameters are missing and clean but to users single API might be a better idea It would be nice to find another name for the dma_request_slave_channel_compat() so with the new name we could have chance to rearrange the parameters: (dev, name, mask, fn, fn_param) We would end up with the following APIs, all returning with error code on failure: dma_request_slave_channel(dev, name); dma_request_channel_legacy(mask, fn, fn_param); dma_request_slave_channel_compat(mask, fn, fn_param, dev, name); dma_request_any_channel(mask); This is good idea but still we end up with 4 APIs. Why not just converge to two API, one legacy + memcpy + filer fn and one untimate API for slave? Internally we may have 4 APIs for cleaner handling... Thoughts... ?? -- ~Vinod -- To unsubscribe from this list: send the line unsubscribe linux-crypto in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
