Re: [PATCH] crypto: testmgr - mark ctr(des3_ede) as fips_allowed

[Stephan Müller]

Am Montag, 20. März 2017, 21:28:05 CET schrieb Marcelo Henrique Cerri:

Hi Marcelo,

> 3DES is missing the fips_allowed flag for CTR mode.
> 
> Signed-off-by: Marcelo Henrique Cerri 

Acked-by: Stephan Mueller 

Ciao
Stephan

[PATCH] crypto: testmgr - mark ctr(des3_ede) as fips_allowed

[Marcelo Henrique Cerri]

3DES is missing the fips_allowed flag for CTR mode.

Signed-off-by: Marcelo Henrique Cerri 
---
 crypto/testmgr.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 89f1dd1f4b13..cd075c7d8ee1 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -2645,6 +2645,7 @@ static const struct alg_test_desc alg_test_descs[] = {
}, {
.alg = "ctr(des3_ede)",
.test = alg_test_skcipher,
+   .fips_allowed = 1,
.suite = {
.cipher = {
.enc = __VECS(des3_ede_ctr_enc_tv_template),
-- 
2.7.4

Re: Question - seeding the hw pseudo random number generator

[Krzysztof Kozlowski]

On Mon, Mar 20, 2017 at 09:28:58PM +0800, Herbert Xu wrote:
> On Mon, Mar 20, 2017 at 12:19:32PM +0530, PrasannaKumar Muralidharan wrote:
> >
> > AF_ALG interface for rng does have seeding support. I think hw_random
> > does not provide seeding support intentionally as I understand that
> > True RNG need not require seeding (please correct me if I am wrong).
> 
> Yes.  We should be converting PRNGs in hwrng over to algif_rng.

The actual hardware block can be seeded from true RNG (taking data
from thermal noise) so the solutions (if I understand correctly) for
exynos-rng might be:
1. Seed from internal TRNG making it a proper hwrandom device,
2. Convert to AF_ALG and seed with data from user-space through that
   interface.

Thanks for explanation, I'll queue it to my tasks list.

Best regards,
Krzysztof

Re: [RFC PATCH v4] IV Generation algorithms for dm-crypt

[Binoy Jayan]

On 6 March 2017 at 20:08, Gilad Ben-Yossef  wrote:
>
> I gave it a spin on a x86_64 with 8 CPUs with AES-NI using cryptd and
> on Arm  using CryptoCell hardware accelerator.
>
> There was no difference in performance between 512 and 4096 bytes
> cluster size on the x86_64 (800 MB loop file system)
>
> There was an improvement in latency of 3.2% between 512 and 4096 bytes
> cluster size on the Arm. I expect the performance benefits for this
> test for Binoy's patch to be the same.
>
> In both cases the very naive test was a simple dd with block size of
> 4096 bytes or the raw block device.
>
> I do not know what effect having a bigger cluster size would have on
> have on other more complex file system operations.
> Is there any specific benchmark worth testing with?


The multiple instances issue in /proc/crypto is fixed. It was because of
the IV code itself modifying the algorithm name inadvertently in the
global crypto algorithm lookup table when it was splitting up
"plain(cbc(aes))" into "plain" and "cbc(aes)" so as to invoke the child
algorithm.

I ran a few tests with dd, bonnie and FIO under Qemu - x86 using the
automated script [1] that I wrote to make the testing easy.
The tests were done on software implementations of the algorithms
as the real hardware was not available with me. According to the test,
I found that the sequential reads and writes have a good improvement
(5.7 %) in the data rate with the proposed solution while the random
reads shows a very little improvement. When tested with FIO, the
random writes also shows a small improvement (2.2%) but the random
reads show a little deterioration in performance (4 %).

When tested in arm hardware, only the sequential writes with bonnie
shows improvement (5.6%). All other tests shows degraded performance
in the absence of crypto hardware.

[1] https://github.com/binoyjayan/utilities/blob/master/utils/dmtest
Dependencies: dd [Full version], bonnie, fio

Thanks,
Binoy

Re: [PATCH] crypto: zip - Memory corruption in zip_clear_stats()

[Mahipal Reddy]

On Sat, Mar 18, 2017 at 4:29 PM, Dan Carpenter  wrote:
> On Sat, Mar 18, 2017 at 11:24:34AM +0100, walter harms wrote:
>>
>>
>> Am 17.03.2017 21:46, schrieb Dan Carpenter:
>> > There is a typo here.  It should be "stats" instead of "state".  The
>> > impact is that we clear 224 bytes instead of 80 and we zero out memory
>> > that we shouldn't.

Thank you Dan for identifying the issue. Yes there is a typo and it needs a fix.


>> > Fixes: 09ae5d37e093 ("crypto: zip - Add Compression/Decompression 
>> > statistics")
>> > Signed-off-by: Dan Carpenter 
>> >
>> > diff --git a/drivers/crypto/cavium/zip/zip_main.c 
>> > b/drivers/crypto/cavium/zip/zip_main.c
>> > index 0951e20b395b..6ff13d80d82e 100644
>> > --- a/drivers/crypto/cavium/zip/zip_main.c
>> > +++ b/drivers/crypto/cavium/zip/zip_main.c
>> > @@ -530,7 +530,7 @@ static int zip_clear_stats(struct seq_file *s, void 
>> > *unused)
>> > for (index = 0; index < MAX_ZIP_DEVICES; index++) {
>> > if (zip_dev[index]) {
>> > memset(_dev[index]->stats, 0,
>> > -  sizeof(struct zip_state));
>> > +  sizeof(struct zip_stats));

Yes this resolves the issue.
Thanks for this fix.
Mahipal

>>
>> as future FIXME some show find a name that differ in more than just the last 
>> char.
>> NTL maybe
>>  sizeof(zip_dev[index]->stats)
>> can be used here ?
>
> That's sort of unweildy.  I don't fear that change because I'm confident
> I would catch it with static analysis.
>
> regards,
> dan carpenter
>

Re: Question - seeding the hw pseudo random number generator

[Stephan Müller]

Am Montag, 20. März 2017, 14:28:58 CET schrieb Herbert Xu:

Hi Herbert,

> On Mon, Mar 20, 2017 at 12:19:32PM +0530, PrasannaKumar Muralidharan wrote:
> > AF_ALG interface for rng does have seeding support. I think hw_random
> > does not provide seeding support intentionally as I understand that
> > True RNG need not require seeding (please correct me if I am wrong).
> 
> Yes.  We should be converting PRNGs in hwrng over to algif_rng.

IMHO this not only applies to the PRNGs in drivers/crypto (which should simply 
register with crypto_register_rngs) but also to ~/hacking/sources/linux/arch/
s390/crypto/prng.c which exports a /dev/prandom file.

For the seeding, it may make sense to follow the example given with crypto/
drbg.c using the add_random_ready_callback function.

Ciao
Stephan

Re: Question - seeding the hw pseudo random number generator

[Herbert Xu]

On Mon, Mar 20, 2017 at 12:19:32PM +0530, PrasannaKumar Muralidharan wrote:
>
> AF_ALG interface for rng does have seeding support. I think hw_random
> does not provide seeding support intentionally as I understand that
> True RNG need not require seeding (please correct me if I am wrong).

Yes.  We should be converting PRNGs in hwrng over to algif_rng.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

[PATCH] crypto: zip - add a cast for printing atomic64_t values

[Arnd Bergmann]

kernelci.org reports a build-time regression on linux-next, with a harmless
warning in x86 allmodconfig:

drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects 
argument of type 'long int', but argument 7 has type 'long long int' [-Wformat=]
drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects 
argument of type 'long int', but argument 6 has type 'long long int' [-Wformat=]
drivers/crypto/cavium/zip/zip_main.c:489:18: warning: format '%ld' expects 
argument of type 'long int', but argument 5 has type 'long long int' [-Wformat=]

The return type for atomic64_read() unfortunately differs between
architectures, with some defining it as atomic_long_read() and others
returning a 64-bit type explicitly. Fixing this in general would be nice,
but also require changing other users of these functions, so the simpler
workaround is to add a cast here that avoids the warnings on the default
build.

Fixes: 09ae5d37e093 ("crypto: zip - Add Compression/Decompression statistics")
Signed-off-by: Arnd Bergmann 
---
 drivers/crypto/cavium/zip/zip_main.c | 40 ++--
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/drivers/crypto/cavium/zip/zip_main.c 
b/drivers/crypto/cavium/zip/zip_main.c
index 0951e20b395b..49f50c0e0308 100644
--- a/drivers/crypto/cavium/zip/zip_main.c
+++ b/drivers/crypto/cavium/zip/zip_main.c
@@ -488,32 +488,32 @@ static int zip_show_stats(struct seq_file *s, void 
*unused)
  atomic64_read(>comp_out_bytes));
seq_printf(s, "ZIP Device %d Stats\n"
  "---\n"
- "Comp Req Submitted: \t%ld\n"
- "Comp Req Completed: \t%ld\n"
- "Compress In Bytes : \t%ld\n"
- "Compressed Out Bytes  : \t%ld\n"
+ "Comp Req Submitted: \t%lld\n"
+ "Comp Req Completed: \t%lld\n"
+ "Compress In Bytes : \t%lld\n"
+ "Compressed Out Bytes  : \t%lld\n"
  "Average Chunk size: \t%llu\n"
  "Average Compression ratio : \t%llu\n"
- "Decomp Req Submitted  : \t%ld\n"
- "Decomp Req Completed  : \t%ld\n"
- "Decompress In Bytes   : \t%ld\n"
- "Decompressed Out Bytes: \t%ld\n"
- "Decompress Bad requests   : \t%ld\n"
- "Pending Req   : \t%ld\n"
+ "Decomp Req Submitted  : \t%lld\n"
+ "Decomp Req Completed  : \t%lld\n"
+ "Decompress In Bytes   : \t%lld\n"
+ "Decompressed Out Bytes: \t%lld\n"
+ "Decompress Bad requests   : \t%lld\n"
+ "Pending Req   : \t%lld\n"
"-\n",
   index,
-  atomic64_read(>comp_req_submit),
-  atomic64_read(>comp_req_complete),
-  atomic64_read(>comp_in_bytes),
-  atomic64_read(>comp_out_bytes),
+  (u64)atomic64_read(>comp_req_submit),
+  
(u64)atomic64_read(>comp_req_complete),
+  (u64)atomic64_read(>comp_in_bytes),
+  (u64)atomic64_read(>comp_out_bytes),
   avg_chunk,
   avg_cr,
-  atomic64_read(>decomp_req_submit),
-  atomic64_read(>decomp_req_complete),
-  atomic64_read(>decomp_in_bytes),
-  atomic64_read(>decomp_out_bytes),
-  atomic64_read(>decomp_bad_reqs),
-  atomic64_read(>pending_req));
+  
(u64)atomic64_read(>decomp_req_submit),
+  
(u64)atomic64_read(>decomp_req_complete),
+  (u64)atomic64_read(>decomp_in_bytes),
+  
(u64)atomic64_read(>decomp_out_bytes),
+   

[PATCH v2 06/10] x86: crypto, annotate local functions

[Jiri Slaby]

Use the newly added SYM_FUNC_START_LOCAL to annotate starts of all
functions which do not have ".globl" annotation, but their ends are
annotated by ENDPROC. This is needed to balance ENDPROC for tools that
are about to generate debuginfo.

Signed-off-by: Jiri Slaby 
Cc: Herbert Xu 
Cc: "David S. Miller" 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: 
Cc: 
---
 arch/x86/crypto/aesni-intel_asm.S| 29 ++--
 arch/x86/crypto/camellia-aesni-avx-asm_64.S  | 10 +-
 arch/x86/crypto/camellia-aesni-avx2-asm_64.S | 10 +-
 arch/x86/crypto/cast5-avx-x86_64-asm_64.S|  4 ++--
 arch/x86/crypto/cast6-avx-x86_64-asm_64.S|  4 ++--
 arch/x86/crypto/ghash-clmulni-intel_asm.S|  2 +-
 arch/x86/crypto/serpent-avx-x86_64-asm_64.S  |  4 ++--
 arch/x86/crypto/serpent-avx2-asm_64.S|  4 ++--
 arch/x86/crypto/twofish-avx-x86_64-asm_64.S  |  4 ++--
 9 files changed, 31 insertions(+), 40 deletions(-)

diff --git a/arch/x86/crypto/aesni-intel_asm.S 
b/arch/x86/crypto/aesni-intel_asm.S
index 3c465184ff8a..8913ea70323c 100644
--- a/arch/x86/crypto/aesni-intel_asm.S
+++ b/arch/x86/crypto/aesni-intel_asm.S
@@ -1746,7 +1746,7 @@ ENDPROC(aesni_gcm_enc)
 
 .align 4
 _key_expansion_128:
-_key_expansion_256a:
+SYM_FUNC_START_LOCAL(_key_expansion_256a)
pshufd $0b, %xmm1, %xmm1
shufps $0b0001, %xmm0, %xmm4
pxor %xmm4, %xmm0
@@ -1759,8 +1759,7 @@ _key_expansion_256a:
 ENDPROC(_key_expansion_128)
 ENDPROC(_key_expansion_256a)
 
-.align 4
-_key_expansion_192a:
+SYM_FUNC_START_LOCAL(_key_expansion_192a)
pshufd $0b01010101, %xmm1, %xmm1
shufps $0b0001, %xmm0, %xmm4
pxor %xmm4, %xmm0
@@ -1784,8 +1783,7 @@ _key_expansion_192a:
ret
 ENDPROC(_key_expansion_192a)
 
-.align 4
-_key_expansion_192b:
+SYM_FUNC_START_LOCAL(_key_expansion_192b)
pshufd $0b01010101, %xmm1, %xmm1
shufps $0b0001, %xmm0, %xmm4
pxor %xmm4, %xmm0
@@ -1804,8 +1802,7 @@ _key_expansion_192b:
ret
 ENDPROC(_key_expansion_192b)
 
-.align 4
-_key_expansion_256b:
+SYM_FUNC_START_LOCAL(_key_expansion_256b)
pshufd $0b10101010, %xmm1, %xmm1
shufps $0b0001, %xmm2, %xmm4
pxor %xmm4, %xmm2
@@ -1968,8 +1965,7 @@ ENDPROC(aesni_enc)
  * KEY
  * TKEYP (T1)
  */
-.align 4
-_aesni_enc1:
+SYM_FUNC_START_LOCAL(_aesni_enc1)
movaps (KEYP), KEY  # key
mov KEYP, TKEYP
pxor KEY, STATE # round 0
@@ -2032,8 +2028,7 @@ ENDPROC(_aesni_enc1)
  * KEY
  * TKEYP (T1)
  */
-.align 4
-_aesni_enc4:
+SYM_FUNC_START_LOCAL(_aesni_enc4)
movaps (KEYP), KEY  # key
mov KEYP, TKEYP
pxor KEY, STATE1# round 0
@@ -2160,8 +2155,7 @@ ENDPROC(aesni_dec)
  * KEY
  * TKEYP (T1)
  */
-.align 4
-_aesni_dec1:
+SYM_FUNC_START_LOCAL(_aesni_dec1)
movaps (KEYP), KEY  # key
mov KEYP, TKEYP
pxor KEY, STATE # round 0
@@ -2224,8 +2218,7 @@ ENDPROC(_aesni_dec1)
  * KEY
  * TKEYP (T1)
  */
-.align 4
-_aesni_dec4:
+SYM_FUNC_START_LOCAL(_aesni_dec4)
movaps (KEYP), KEY  # key
mov KEYP, TKEYP
pxor KEY, STATE1# round 0
@@ -2591,8 +2584,7 @@ ENDPROC(aesni_cbc_dec)
  * INC:== 1, in little endian
  * BSWAP_MASK == endian swapping mask
  */
-.align 4
-_aesni_inc_init:
+SYM_FUNC_START_LOCAL(_aesni_inc_init)
movaps .Lbswap_mask, BSWAP_MASK
movaps IV, CTR
PSHUFB_XMM BSWAP_MASK CTR
@@ -2617,8 +2609,7 @@ ENDPROC(_aesni_inc_init)
  * CTR:== output IV, in little endian
  * TCTR_LOW: == lower qword of CTR
  */
-.align 4
-_aesni_inc:
+SYM_FUNC_START_LOCAL(_aesni_inc)
paddq INC, CTR
add $1, TCTR_LOW
jnc .Linc_low
diff --git a/arch/x86/crypto/camellia-aesni-avx-asm_64.S 
b/arch/x86/crypto/camellia-aesni-avx-asm_64.S
index f7c495e2863c..5964d98c4448 100644
--- a/arch/x86/crypto/camellia-aesni-avx-asm_64.S
+++ b/arch/x86/crypto/camellia-aesni-avx-asm_64.S
@@ -188,7 +188,7 @@
  * larger and would only be 0.5% faster (on sandy-bridge).
  */
 .align 8
-roundsm16_x0_x1_x2_x3_x4_x5_x6_x7_y0_y1_y2_y3_y4_y5_y6_y7_cd:
+SYM_FUNC_START_LOCAL(roundsm16_x0_x1_x2_x3_x4_x5_x6_x7_y0_y1_y2_y3_y4_y5_y6_y7_cd)
roundsm16(%xmm0, %xmm1, %xmm2, %xmm3, %xmm4, %xmm5, %xmm6, %xmm7,
  %xmm8, %xmm9, %xmm10, %xmm11, %xmm12, %xmm13, %xmm14, %xmm15,
  %rcx, (%r9));
@@ -196,7 +196,7 @@ 
roundsm16_x0_x1_x2_x3_x4_x5_x6_x7_y0_y1_y2_y3_y4_y5_y6_y7_cd:
 ENDPROC(roundsm16_x0_x1_x2_x3_x4_x5_x6_x7_y0_y1_y2_y3_y4_y5_y6_y7_cd)
 
 .align 8
-roundsm16_x4_x5_x6_x7_x0_x1_x2_x3_y4_y5_y6_y7_y0_y1_y2_y3_ab:
+SYM_FUNC_START_LOCAL(roundsm16_x4_x5_x6_x7_x0_x1_x2_x3_y4_y5_y6_y7_y0_y1_y2_y3_ab)

[PATCH v2 07/10] x86: assembly, annotate aliases

[Jiri Slaby]

_key_expansion_128 is an alias to _key_expansion_256a, __memcpy to
memcpy, xen_syscall32_target to xen_sysenter_target, and so on. Annotate
them all using the new SYM_FUNC_START_ALIAS, SYM_FUNC_START_LOCAL_ALIAS,
and SYM_FUNC_END_ALIAS. This will make the tools generating the
debuginfo happy.

Signed-off-by: Jiri Slaby 
Cc: Herbert Xu 
Cc: "David S. Miller" 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: 
Cc: Boris Ostrovsky 
Cc: Juergen Gross 
Reviewed-by: Juergen Gross  [xen parts]
Cc: 
Cc: 
---
 arch/x86/crypto/aesni-intel_asm.S | 5 ++---
 arch/x86/lib/memcpy_64.S  | 4 ++--
 arch/x86/lib/memmove_64.S | 4 ++--
 arch/x86/lib/memset_64.S  | 4 ++--
 arch/x86/xen/xen-asm_64.S | 4 ++--
 5 files changed, 10 insertions(+), 11 deletions(-)

diff --git a/arch/x86/crypto/aesni-intel_asm.S 
b/arch/x86/crypto/aesni-intel_asm.S
index 8913ea70323c..ea247bfed89d 100644
--- a/arch/x86/crypto/aesni-intel_asm.S
+++ b/arch/x86/crypto/aesni-intel_asm.S
@@ -1744,8 +1744,7 @@ ENDPROC(aesni_gcm_enc)
 #endif
 
 
-.align 4
-_key_expansion_128:
+SYM_FUNC_START_LOCAL_ALIAS(_key_expansion_128)
 SYM_FUNC_START_LOCAL(_key_expansion_256a)
pshufd $0b, %xmm1, %xmm1
shufps $0b0001, %xmm0, %xmm4
@@ -1756,8 +1755,8 @@ SYM_FUNC_START_LOCAL(_key_expansion_256a)
movaps %xmm0, (TKEYP)
add $0x10, TKEYP
ret
-ENDPROC(_key_expansion_128)
 ENDPROC(_key_expansion_256a)
+SYM_FUNC_END_ALIAS(_key_expansion_128)
 
 SYM_FUNC_START_LOCAL(_key_expansion_192a)
pshufd $0b01010101, %xmm1, %xmm1
diff --git a/arch/x86/lib/memcpy_64.S b/arch/x86/lib/memcpy_64.S
index 779782f58324..2d6518b4dbd6 100644
--- a/arch/x86/lib/memcpy_64.S
+++ b/arch/x86/lib/memcpy_64.S
@@ -26,7 +26,7 @@
  * Output:
  * rax original destination
  */
-ENTRY(__memcpy)
+SYM_FUNC_START_ALIAS(__memcpy)
 ENTRY(memcpy)
ALTERNATIVE_2 "jmp memcpy_orig", "", X86_FEATURE_REP_GOOD, \
  "jmp memcpy_erms", X86_FEATURE_ERMS
@@ -40,7 +40,7 @@ ENTRY(memcpy)
rep movsb
ret
 ENDPROC(memcpy)
-ENDPROC(__memcpy)
+SYM_FUNC_END_ALIAS(__memcpy)
 EXPORT_SYMBOL(memcpy)
 EXPORT_SYMBOL(__memcpy)
 
diff --git a/arch/x86/lib/memmove_64.S b/arch/x86/lib/memmove_64.S
index 15de86cd15b0..d22af97e5b27 100644
--- a/arch/x86/lib/memmove_64.S
+++ b/arch/x86/lib/memmove_64.S
@@ -25,7 +25,7 @@
  */
 .weak memmove
 
-ENTRY(memmove)
+SYM_FUNC_START_ALIAS(memmove)
 ENTRY(__memmove)
 
/* Handle more 32 bytes in loop */
@@ -207,6 +207,6 @@ ENTRY(__memmove)
 13:
retq
 ENDPROC(__memmove)
-ENDPROC(memmove)
+SYM_FUNC_END_ALIAS(memmove)
 EXPORT_SYMBOL(__memmove)
 EXPORT_SYMBOL(memmove)
diff --git a/arch/x86/lib/memset_64.S b/arch/x86/lib/memset_64.S
index 55b95db30a61..0d3a1d341e60 100644
--- a/arch/x86/lib/memset_64.S
+++ b/arch/x86/lib/memset_64.S
@@ -18,7 +18,7 @@
  *
  * rax   original destination
  */
-ENTRY(memset)
+SYM_FUNC_START_ALIAS(memset)
 ENTRY(__memset)
/*
 * Some CPUs support enhanced REP MOVSB/STOSB feature. It is recommended
@@ -42,8 +42,8 @@ ENTRY(__memset)
rep stosb
movq %r9,%rax
ret
-ENDPROC(memset)
 ENDPROC(__memset)
+SYM_FUNC_END_ALIAS(memset)
 EXPORT_SYMBOL(memset)
 EXPORT_SYMBOL(__memset)
 
diff --git a/arch/x86/xen/xen-asm_64.S b/arch/x86/xen/xen-asm_64.S
index 2a968c087269..b3bf662a4f6a 100644
--- a/arch/x86/xen/xen-asm_64.S
+++ b/arch/x86/xen/xen-asm_64.S
@@ -117,13 +117,13 @@ ENDPROC(xen_sysenter_target)
 
 #else /* !CONFIG_IA32_EMULATION */
 
-ENTRY(xen_syscall32_target)
+SYM_FUNC_START_ALIAS(xen_syscall32_target)
 ENTRY(xen_sysenter_target)
lea 16(%rsp), %rsp  /* strip %rcx, %r11 */
mov $-ENOSYS, %rax
pushq $0
jmp hypercall_iret
-ENDPROC(xen_syscall32_target)
 ENDPROC(xen_sysenter_target)
+SYM_FUNC_END_ALIAS(xen_syscall32_target)
 
 #endif /* CONFIG_IA32_EMULATION */
-- 
2.12.0

Re: Question - seeding the hw pseudo random number generator

[PrasannaKumar Muralidharan]

> I looked at Exynos Pseudo Random Nubmer Generator driver
> (drivers/char/hw_random/exynos-rng.c) and noticed that it always seeds
> the device with jiffies.  Then I looked at few other drivers and found
> that they do not seed themself (or at least I couldn't find this).

HW random interface is meant for true RNG, not pseudo RNG. Actually
PRNGs should use AF_ALG interface. I think exynos-rng.c should follow
the same.

> I think the hw_random API does not provide generic infrastructure for
> seeding.
>
> What is the preferred approach for seeding a PRNG device? Use jiffies or
> a fixed value?
>
> Or maybe the interface should be abandoned in favor of crypto API?

AF_ALG interface for rng does have seeding support. I think hw_random
does not provide seeding support intentionally as I understand that
True RNG need not require seeding (please correct me if I am wrong).

Regards,
PrasannaKumar