Re: [PATCH 2/2] ath9k: disable RNG by default

Hi Stephan, For those less perfect noise source, can't pass the FIPS test. static int update_kernel_random(int random_step, unsigned char *buf, fips_ctx_t *fipsctx_in) { unsigned char *p; int fips; fips = fips_run_rng_test(fipsctx_in, buf); if (fips)

Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices

Henrique de Moraes Holschuh writes: > IMHO, this is mightly annoying to use from inside a rngd-like utility in > a race-free, safe way. It looks to me that ioctl() would be a much > better interface for everything but the "enabled" functionality (which > should be reported to

Re: [PATCH v3] KEYS: add SP800-56A KDF support for DH

On Sat, 6 Aug 2016, Stephan Mueller wrote: diff --git a/security/keys/internal.h b/security/keys/internal.h index a705a7d..7659b52 100644 --- a/security/keys/internal.h +++ b/security/keys/internal.h @@ -259,15 +259,32 @@ static inline long keyctl_get_persistent(uid_t uid, key_serial_t

Re: [PATCH v3] DH support: add KDF handling support

On Sat, 6 Aug 2016, Stephan Mueller wrote: diff --git a/man/keyctl_dh_compute.3 b/man/keyctl_dh_compute.3 index b06d39e..92d358f 100644 --- a/man/keyctl_dh_compute.3 +++ b/man/keyctl_dh_compute.3 @@ -11,6 +11,8 @@ .\"

Re: [PATCH] crypto: DRBG: do not call drbg_instantiate in healt test

Hi Stephan, Thanks. The patch that I applied have different line numbers than yours. In any case, patch worked to get rid of Œdrbg¹ related error. Now, fips mode is failing on self-test: /boot/vmlinuz-4.7.0-1.tos2_5: OK [1.296714] alg: skcipher: setkey failed on test 1 for xts(aes-asm):

Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices

On Tue, 09 Aug 2016, Jason Cooper wrote: > Perhaps a /dev/hwrng[0-9] per rng? That would lend itself nicely to a > sysfs interface for per device quality, rate, and enabled attributes. > e.g. /sys/class/hw_random/hwrng0/{device/,quality,rate,enabled} IMHO, this is mightly annoying to use from

[PATCH] crypto: DRBG: do not call drbg_instantiate in healt test

Am Dienstag, 9. August 2016, 19:52:46 CEST schrieb Stephan Mueller: Hi Tapas, I think I found the issue. Can you please test the attached patch? ---8<--- When calling the DRBG health test in FIPS mode, the Jitter RNG is not yet present in the kernel crypto API which will cause the

Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices

Jason Cooper writes: > On another thread, regarding the ath9k-rng (actually just the adc > registers), Henrique asked about per-source knobs. My suggestion > follows from that. I'd do that with the source-specific driver instead of attempting to route controls through

Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices

Hi Keith, On Tue, Aug 09, 2016 at 10:58:05AM -0700, Keith Packard wrote: > Jason Cooper writes: > > Perhaps a /dev/hwrng[0-9] per rng? That would lend itself nicely to a > > sysfs interface for per device quality, rate, and enabled attributes. > > e.g.

Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices

Jason Cooper writes: > Perhaps a /dev/hwrng[0-9] per rng? That would lend itself nicely to a > sysfs interface for per device quality, rate, and enabled attributes. > e.g. /sys/class/hw_random/hwrng0/{device/,quality,rate,enabled} I was interested in the data being

Re: [PATCH 2/2] ath9k: disable RNG by default

Hi Henrique, On Tue, Aug 09, 2016 at 07:24:58AM -0300, Henrique de Moraes Holschuh wrote: > On Tue, 09 Aug 2016, Stephan Mueller wrote: > > RHEL 7 and Fedora do not adjust it. So, shall we consider those rng-tools > > then > > broken (at least in those large distros)? > > Might I humbly

Re: FIPS mode: modprobe: ERROR: could not insert 'drbg'

Am Dienstag, 9. August 2016, 17:11:09 CEST schrieb Tapas Sarangi: Hi Tapas, Herbert, > Hi Stephan, > > Thanks. I have already tried that. ‘drbg’ module is loaded fine in a > non-fips mode. Here are output from some commands. There is something strange going on. I have to compile the DRBG

Re: [PATCH 2/2] ath9k: disable RNG by default

On Tue, Aug 09, 2016 at 03:02:27PM +0800, miaoq...@codeaurora.org wrote: > From: Miaoqing Pan > > ath9k RNG will dominates all the noise sources from the real HW > RNG, disable it by default. But we strongly recommand to enable > it if the system without HW RNG,

Re: FIPS mode: modprobe: ERROR: could not insert 'drbg'

Hi Stephan, Thanks. I have already tried that. ‘drbg’ module is loaded fine in a non-fips mode. Here are output from some commands. I see that at some point you had a patch to use CONFIG_CRYPTO_LRNG. I am not using that, could that be a problem ? -Tapas [root@localhost ~]# modprobe drbg

Re: FIPS mode: modprobe: ERROR: could not insert 'drbg'

Am Dienstag, 9. August 2016, 16:34:59 CEST schrieb Tapas Sarangi: Hi Tapas, > Hi Stephan, > > Following up from the other thread: > > While trying to boot in FIPS mode, kernel panics with the following > message. So far, I don¹t have success to get more information about which > module or

Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices

Hi Keith, Herbert, On Tue, Aug 09, 2016 at 05:50:58PM +0800, Herbert Xu wrote: > On Mon, Jul 25, 2016 at 01:07:35PM -0700, Keith Packard wrote: > > Instead of having only one hwrng feeding /dev/random at a time, maintain > > a list of devices and cycle between them when filling the entropy pool.

FIPS mode: modprobe: ERROR: could not insert 'drbg'

Hi Stephan, Following up from the other thread: While trying to boot in FIPS mode, kernel panics with the following message. So far, I don¹t have success to get more information about which module or symbol is causing this. I haven¹t found any errors or warnings in kernel compilation. It boots

Re: RSA key size not allowed in FIPS

Am Dienstag, 9. August 2016, 16:07:06 CEST schrieb Tapas Sarangi: Hi Tapas, > Hi Stephan, > > > Thanks for your responses. I am past this error now. > > I am still NOT out of trouble. Now, test integrity fails while trying to > get into FIPS mode. Here is the snippet of error messages. I

Re: RSA key size not allowed in FIPS

Hi Stephan, Thanks for your responses. I am past this error now. I am still NOT out of trouble. Now, test integrity fails while trying to get into FIPS mode. Here is the snippet of error messages. I will create a separate thread for this, /boot/vmlinuz-4.7.0-1.tos2_5: OK modprobe: ERROR:

Re: RSA key size not allowed in FIPS

Embarrassing! Yes, I just saw this while you are pressing send on that replyŠ default bits were set to 4096 in x509.genkey. :-( I am trying out with 2048 bits. I will confirm. -Tapas On 8/9/16, 9:55 AM, "Stephan Mueller" wrote: >Am Dienstag, 9. August 2016, 14:39:03 CEST

Re: RSA key size not allowed in FIPS

Am Dienstag, 9. August 2016, 14:39:03 CEST schrieb Tapas Sarangi: Hi Tapas, David, > Hi Stephan, > > If I understand this correctly, this (CONFIG_MODULE_SIG_HASH=“sha256") > tells about the key size used. > I am using “sha256”. Initially, I was using “sha512” which I thought could > be causing

Re: RSA key size not allowed in FIPS

Looking at the kernel compilation log, it seems to be generating a 4k (4096 bits) private key, although I am specifying CONFIG_MODULE_SIG_HASH=“sha256”. How can I generate RSA key that is within 2k-3k bits ? Here is a snippet from the compilation log: ### Now generating an X.509 key pair to be

Re: RSA key size not allowed in FIPS

Hi Stephan, If I understand this correctly, this (CONFIG_MODULE_SIG_HASH=“sha256") tells about the key size used. I am using “sha256”. Initially, I was using “sha512” which I thought could be causing problem, but I am getting same error when change it to “sha256”. [root@localhost ~]# grep

Re: RSA key size not allowed in FIPS

On 08/09/2016 09:10 AM, Tapas Sarangi wrote: Ps : I could not send any attachment, is it possible to send attachment to this mailing list ? Pretty sure that's frowned upon. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to

Re: RSA key size not allowed in FIPS

Am Dienstag, 9. August 2016, 14:10:33 CEST schrieb Tapas Sarangi: Hi Tapas, > Hello, > > I am using vanilla kernel-4.7 source. It crashes with the following when > booted with ³fips=1 boot=/dev/sda1² option at the kernel command line > argument. The kernel only allows 2k and 3k RSA keys in

RSA key size not allowed in FIPS

Hello, I am using vanilla kernel-4.7 source. It crashes with the following when booted with ³fips=1 boot=/dev/sda1² option at the kernel command line argument. [0.642411] RSA: key size not allowed in FIPS mode [0.643099] Problem loading in-kernel X.509 certificate (-22) [0.800524]

Re: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy

Hi Ted, On Tue, Aug 09, 2016 at 07:56:22AM -0400, Theodore Ts'o wrote: > On Tue, Aug 09, 2016 at 06:30:03AM +, Pan, Miaoqing wrote: > > Agree with Jason's point, also understand Stephan's concern. The > > date rate can be roughly estimated by 'cat /dev/random |rngtest -c > > 1000', the

Re: testmgr.h

Am Dienstag, 9. August 2016, 08:21:43 CEST schrieb Gary R Hook: Hi Gary, > Q: Is there a policy (de facto or otherwise) on adding tests to testmgr.h? > Two cases: > > 1) Tests from the NIST document(s) on various ciphers and hashes wherein > we add to an existing set of tests? For example, 3DES

testmgr.h

Q: Is there a policy (de facto or otherwise) on adding tests to testmgr.h? Two cases: 1) Tests from the NIST document(s) on various ciphers and hashes wherein we add to an existing set of tests? For example, 3DES ECB mode, or AES GCM? I suppose this question is really about, "how much is

[PATCH v5 1/4] crypto: add template handling for RNGs

This patch adds the ability to register templates for RNGs. RNGs are "meta" mechanisms using raw cipher primitives. Thus, RNGs can now be implemented as templates to allow the complete flexibility the kernel crypto API provides. Signed-off-by: Stephan Mueller ---

[PATCH v5 2/4] crypto: kdf - add known answer tests

Add known answer tests to the testmgr for the KDF (SP800-108) cipher. Signed-off-by: Stephan Mueller --- crypto/testmgr.c | 226 +++ crypto/testmgr.h | 110 +++ 2 files changed, 336 insertions(+)

[PATCH v5 3/4] crypto: kdf - SP800-108 Key Derivation Function

The SP800-108 compliant Key Derivation Function is implemented as a random number generator considering that it behaves like a deterministic RNG. All three KDF types specified in SP800-108 are implemented. The code comments provide details about how to invoke the different KDF types.

[PATCH v5 0/4] crypto: Key Derivation Function (SP800-108)

Hi, this patch set implements all three key derivation functions defined in SP800-108. The implementation is provided as a template for random number generators, since a KDF can be considered a form of deterministic RNG where the key material is used as a seed. With the KDF implemented as a

[PATCH v5 4/4] crypto: kdf - enable compilation

Include KDF into Kconfig and Makefile for compilation. Signed-off-by: Stephan Mueller --- crypto/Kconfig | 7 +++ crypto/Makefile | 1 + 2 files changed, 8 insertions(+) diff --git a/crypto/Kconfig b/crypto/Kconfig index 84d7148..16f3221 100644 --- a/crypto/Kconfig

Re: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy

On Tue, Aug 09, 2016 at 06:30:03AM +, Pan, Miaoqing wrote: > Agree with Jason's point, also understand Stephan's concern. The > date rate can be roughly estimated by 'cat /dev/random |rngtest -c > 1000', the average speed is .294Kibits/s. I will sent the patch > to disable ath9k RNG by

Re: [PATCH 0/7] Various fixes for the cesa driver

Romain Perier wrote: > This patches series contains various fixes for ahash requests, dma > operations and an important fixe in the core of the driver (cesa.c). It > also includes some code cleanups. All applied. Thanks. -- Email: Herbert Xu

Re: crypto: crc32c-vpmsum - Convert to CPU feature based module autoloading

On Thu, 2016-04-08 at 06:38:15 UTC, Anton Blanchard wrote: > From: Anton Blanchard > > This patch utilises the GENERIC_CPU_AUTOPROBE infrastructure > to automatically load the crc32c-vpmsum module if the CPU supports > it. > > Signed-off-by: Anton Blanchard

Re: [PATCH] crypto: caam - avoid kernel warnings on probe failure

On Tue, Aug 09, 2016 at 08:30:10AM +0100, Russell King wrote: > While debugging setkey issues, the following warnings were found while > trying to reinsert the caam module. Fix this by avoiding the duplicated > cleanup in the probe path after caam_remove(), which has already cleaned > up the

Re: [PATCH 00/11] Further iMX CAAM updates

On Mon, Aug 08, 2016 at 06:04:01PM +0100, Russell King - ARM Linux wrote: > This is a re-post (with hopefully bugs fixed from December's review). > Untested, because AF_ALG appears to be broken in 4.8-rc1. Maybe > someone can provide some hints how to test using tcrypt please? > > Here are

Re: [PATCH v2 0/7] crypto: img-hash - fixes and interface changes

On Fri, Aug 05, 2016 at 02:00:13PM +0100, Will Thomas wrote: > Hi Herbert, > > This patchset includes small stability fixes, power management > and import/export interface functions for the img-hash driver. > > Changes as discussed for [1/7], [2/7] and [5/7]. > > > Govindraj Raja (1): >

Re: [PATCH] crypto/testmgr.c: fix !x==y confusion

On Fri, Jul 29, 2016 at 04:32:09PM +0800, yanjiang@windriver.com wrote: > From: Yanjiang Jin > > "if (!ret == template[i].fail)" is confusing to compilers (gcc5): > > crypto/testmgr.c: In function '__test_aead': > crypto/testmgr.c:531:12: warning: logical not is

Re: [PATCH 00/10] Enablement of a v5 CCP

On Tue, Jul 26, 2016 at 07:09:11PM -0500, Gary R Hook wrote: > The following series updates the CCP driver to support > both current and new cryptographic coprocessor models. > Refactor code to further separate device-specific code > from driver logic, then add equivalent support for the > new

Re: [PATCH] crypto: ccp - Fix non-conforming comment style

On Tue, Jul 26, 2016 at 06:09:46PM -0500, Gary R Hook wrote: > Adhere to the cryptodev comment convention. > > Signed-off-by: Gary R Hook Patch applied. Thanks. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key:

Re: [PATCH 0/2] Fix a resource release omission in error handling code

On Fri, Jul 22, 2016 at 03:32:40PM +0200, Quentin Lambert wrote: > The first patch is a style fix, the second add calls to npe_release. > The reason for me thinking that they are necessary is that every other > branches > leading to an error return are calling this function. Both patches

Re: [PATCH v2] crypto: powerpc - CRYPT_CRC32C_VPMSUM should depend on ALTIVEC

On Tue, Aug 09, 2016 at 08:46:15AM +1000, Michael Ellerman wrote: > The optimised crc32c implementation depends on VMX (aka. Altivec) > instructions, so the kernel must be built with Altivec support in order > for the crc32c code to build. > > Fixes: 6dd7a82cc54e ("crypto: powerpc - Add POWER8

Re: AF_ALG broken?

On Tue, Aug 09, 2016 at 08:27:17AM +0100, Russell King - ARM Linux wrote: > > From: Russell King > Subject: [PATCH] crypto: caam - fix non-hmac hashes > > Since 6de62f15b581 ("crypto: algif_hash - Require setkey before > accept(2)"), the AF_ALG interface requires

Re: [PATCH 2/2] ath9k: disable RNG by default

On Tue, 09 Aug 2016, Stephan Mueller wrote: > RHEL 7 and Fedora do not adjust it. So, shall we consider those rng-tools > then > broken (at least in those large distros)? Might I humbly suggest that the kernel start providing some metatada about the quality of the random source that userspace

Re: [PATCHv3 03/11] crypto: omap-sham: implement context export/import APIs

On Thu, Aug 04, 2016 at 01:28:38PM +0300, Tero Kristo wrote: > Context export/import are now required for ahash algorithms due to > required support in algif_hash. Implement these for OMAP SHA driver, > saving and restoring the internal state of the driver. > > Signed-off-by: Tero Kristo

Re: [PATCH 2/2] ath9k: disable RNG by default

Am Dienstag, 9. August 2016, 17:56:57 CEST schrieb Herbert Xu: Hi Herbert, > On Tue, Aug 09, 2016 at 11:56:08AM +0200, Stephan Mueller wrote: > > Am Dienstag, 9. August 2016, 17:46:56 CEST schrieb Herbert Xu: > > > > Hi Herbert, > > > > > You're supposed to tweak the quality of the input. In

Re: [PATCH v4 1/4] crypto: add template handling for RNGs

Stephan Mueller wrote: > + > +static inline struct rng_alg *__crypto_rng_alg(struct crypto_alg *alg) > +{ > + return container_of(alg, struct rng_alg, base); > +} > + > +static inline struct rng_instance *rng_instance( > + struct crypto_instance *inst) > +{ > +

Re: [PATCH 2/2] ath9k: disable RNG by default

On Tue, Aug 09, 2016 at 11:56:08AM +0200, Stephan Mueller wrote: > Am Dienstag, 9. August 2016, 17:46:56 CEST schrieb Herbert Xu: > > Hi Herbert, > > > > You're supposed to tweak the quality of the input. In any case, > > How is that tweak supposed to happen? The rngd does not allow changing

Re: [PATCH 2/2] ath9k: disable RNG by default

Am Dienstag, 9. August 2016, 17:46:56 CEST schrieb Herbert Xu: Hi Herbert, > > You're supposed to tweak the quality of the input. In any case, How is that tweak supposed to happen? The rngd does not allow changing the amount of read data relative to the assumed entropy. > this is not

Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices

On Mon, Jul 25, 2016 at 01:07:35PM -0700, Keith Packard wrote: > Instead of having only one hwrng feeding /dev/random at a time, maintain > a list of devices and cycle between them when filling the entropy pool. > > Signed-off-by: Keith Packard So you're cycling RNGs even for

Re: [PATCH 0/7] Various fixes for the cesa driver

Hello, Is it normal that Herbert, as the crypto maintainer, is not Cc'ed on those patches? On Tue, 9 Aug 2016 11:03:13 +0200, Romain Perier wrote: > This patches series contains various fixes for ahash requests, dma > operations and an important fixe in the core of the driver (cesa.c). It >

Re: [PATCH 2/2] ath9k: disable RNG by default

On Tue, Aug 09, 2016 at 11:37:39AM +0200, Stephan Mueller wrote: > Am Dienstag, 9. August 2016, 17:17:55 CEST schrieb Herbert Xu: > > Hi Herbert, > > > On Tue, Aug 09, 2016 at 11:02:58AM +0200, Stephan Mueller wrote: > > > But shouldn't the default of the rngd then be adjusted a bit? > > > >

Re: AF_ALG zero-size hash fails

On Tue, Aug 09, 2016 at 10:18:34AM +0100, Russell King - ARM Linux wrote: > Hi, > > While testing AF_ALG with openssl af-alg-rr, I've found that: > > OPENSSL_CONF=/shared/crypto/openssl-imx.cnf openssl dgst -sha1 > fails with a zero hash result: > > socket(PF_ALG, SOCK_SEQPACKET, 0) = 3

Re: [PATCH 2/2] ath9k: disable RNG by default

Am Dienstag, 9. August 2016, 17:17:55 CEST schrieb Herbert Xu: Hi Herbert, > On Tue, Aug 09, 2016 at 11:02:58AM +0200, Stephan Mueller wrote: > > But shouldn't the default of the rngd then be adjusted a bit? > > Please elaborate. in rngd_linux.c:random_add_entropy(void *buf, size_t size):

Re: [PATCH 2/2] ath9k: disable RNG by default

On Tue, Aug 09, 2016 at 11:02:58AM +0200, Stephan Mueller wrote: > > But shouldn't the default of the rngd then be adjusted a bit? Please elaborate. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key:

AF_ALG zero-size hash fails

Hi, While testing AF_ALG with openssl af-alg-rr, I've found that: OPENSSL_CONF=/shared/crypto/openssl-imx.cnf openssl dgst -sha1 http://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net. -- To unsubscribe from

[PATCH 5/7] crypto: marvell - Update transformation context for each dequeued req

So far, sub part of mv_cesa_int was responsible of dequeuing complete requests, then call the 'cleanup' operation on these reqs and call the crypto api callback 'complete'. The problem is that the transformation context 'ctx' is retrieved only once before the while loop. Which means that the wrong

[PATCH 7/7] crypto: marvell - Don't hardcode block size in mv_cesa_ahash_cache_req

Don't use 64 'as is', as max block size in mv_cesa_ahash_cache_req. Use CESA_MAX_HASH_BLOCK_SIZE instead, this is better for readability. Signed-off-by: Romain Perier --- drivers/crypto/marvell/hash.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff

[PATCH 4/7] crypto: marvell: make mv_cesa_ahash_cache_req() return bool

From: Thomas Petazzoni The mv_cesa_ahash_cache_req() function always returns 0, which makes its return value pretty much useless. However, in addition to returning a useless value, it also returns a boolean in a variable passed by reference to indicate if the

[PATCH 6/7] crypto: marvell - Don't overwrite default creq->state during initialization

Currently, in mv_cesa_{md5,sha1,sha256}_init creq->state is initialized before the call to mv_cesa_ahash_init. This is wrong because this function fills creq with zero by using memset, so its 'state' that contains the default DIGEST is overwritten. This commit fixes the issue by initializing

[PATCH 0/7] Various fixes for the cesa driver

This patches series contains various fixes for ahash requests, dma operations and an important fixe in the core of the driver (cesa.c). It also includes some code cleanups. Romain Perier (3): crypto: marvell - Update transformation context for each dequeued req crypto: marvell - Don't

[PATCH 2/7] crypto: marvell: remove unused parameter in mv_cesa_ahash_dma_add_cache()

From: Thomas Petazzoni The dma_iter parameter of mv_cesa_ahash_dma_add_cache() is never used, so get rid of it. Signed-off-by: Thomas Petazzoni --- drivers/crypto/marvell/hash.c | 3 +-- 1 file changed, 1 insertion(+),

[PATCH 3/7] crypto: marvell: turn mv_cesa_ahash_init() into a function returning void

From: Thomas Petazzoni The mv_cesa_ahash_init() function always returns 0, and the return value is anyway never checked. Turn it into a function returning void. Signed-off-by: Thomas Petazzoni ---

[PATCH 1/7] crypto: marvell: be explicit about destination in mv_cesa_dma_add_op()

From: Thomas Petazzoni The mv_cesa_dma_add_op() function builds a mv_cesa_tdma_desc structure to copy the operation description to the SRAM, but doesn't explicitly initialize the destination of the copy. It works fine because the operatin description must be

Re: [PATCH 2/2] ath9k: disable RNG by default

Am Dienstag, 9. August 2016, 16:58:58 CEST schrieb Herbert Xu: Hi Herbert, > On Tue, Aug 09, 2016 at 10:07:29AM +0200, Stephan Mueller wrote: > > Herbert, Matt, should such noise sources be added to the HW random > > framework? The thing is that the in-kernel HW random to input_pool link > > per

Re: [PATCH 2/2] ath9k: disable RNG by default

On Tue, Aug 09, 2016 at 10:07:29AM +0200, Stephan Mueller wrote: > > Herbert, Matt, should such noise sources be added to the HW random framework? > The thing is that the in-kernel HW random to input_pool link per default uses > a more conservative entropy estimate than the user space rngd. I

Re: [PATCH 2/2] ath9k: disable RNG by default

Am Dienstag, 9. August 2016, 07:35:33 CEST schrieb Pan, Miaoqing: Hi Miaoqing, Herbert, Matt, > Hi Stephan, > > So your suggestion is to use HW Random framework ? Actually, which was > done by the commit 6301566e0b2d ("ath9k: export HW random number > generator"), but it was reverted, you can

[PATCH] crypto: caam - avoid kernel warnings on probe failure

While debugging setkey issues, the following warnings were found while trying to reinsert the caam module. Fix this by avoiding the duplicated cleanup in the probe path after caam_remove(), which has already cleaned up the resources. [ cut here ] WARNING: CPU: 0 PID: 2346

Re: AF_ALG broken?

On Tue, Aug 09, 2016 at 03:14:02PM +0800, Herbert Xu wrote: > On Tue, Aug 09, 2016 at 08:08:59AM +0100, Russell King - ARM Linux wrote: > > > > I thought I gave the commands and link to your example code. The > > openssl case is md5, though sha* also gives the same result. Your > > example code

Re: [PATCH 2/2] ath9k: disable RNG by default

Am Dienstag, 9. August 2016, 15:02:27 CEST schrieb miaoq...@codeaurora.org: Hi Miaoqing, > From: Miaoqing Pan > > ath9k RNG will dominates all the noise sources from the real HW > RNG, disable it by default. But we strongly recommand to enable > it if the system

Re: AF_ALG broken?

On Tue, Aug 09, 2016 at 08:08:59AM +0100, Russell King - ARM Linux wrote: > > I thought I gave the commands and link to your example code. The > openssl case is md5, though sha* also gives the same result. Your > example code was sha1 iirc. I guess none of these would be using > HMAC - the

[PATCH 2/2] ath9k: disable RNG by default

From: Miaoqing Pan ath9k RNG will dominates all the noise sources from the real HW RNG, disable it by default. But we strongly recommand to enable it if the system without HW RNG, especially on embedded systems. Signed-off-by: Miaoqing Pan ---

[PATCH 1/2] ath9k: change entropy formula for easier understanding

From: Miaoqing Pan The quality of ADC entropy is 10 bits of min-entropy for a 32-bit value, change '(((x) * 8 * 320) >> 10)' to '(((x) * 8 * 10) >> 5)' for easier understanding. Signed-off-by: Miaoqing Pan ---

RE: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy

Hi Jason, Stephan, Agree with Jason's point, also understand Stephan's concern. The date rate can be roughly estimated by 'cat /dev/random |rngtest -c 1000', the average speed is .294Kibits/s. I will sent the patch to disable ath9k RNG by default. Thanks, Miaoqing -Original