On Thu, 22 Jan 2009 10:32:17 +0800 Huang Ying wrote:
> Use dedicate workqueue for crypto
>
> - A dedicated workqueue named kcrypto_wq is created.
>
> - chainiv uses kcrypto_wq instead of keventd_wq.
>
> - For cryptd, struct cryptd_queue is defined to be a per-CPU queue,
> which holds one str
On 24 января 2009 01:31:50 Herbert Xu wrote:
>
> 2) The highmem primitives we use are currently softirq only. We
> could make them work for hardirq as well, but because of 1) we
> didn't.
>
Could you point to example of such primitive in code under crypto?
Thank you!
signature.asc
Description:
Andrey Borzenkov wrote:
>
> As I can understand, user context requirement is due to potential for
> setkey to sleep (although it appears, that currently the only module
> that can sleep is shash which is calling kmalloc with GFP_KERNEL). Is it
> correct?
Yep.
> But where is the difference bet
According to Documentation/crypto/api-intro.txt:
DEVELOPER NOTES
Transforms may only be allocated in user context, and cryptographic
methods may only be called from softirq and user contexts. For
transforms with a setkey method it too should only be called from
user context.
As I can understand
pseudo RNGs provide predictable outputs based on input parateters {key, V, DT},
the idea behind them is that only the user should know what the inputs are.
While its nice to have default known values for testing purposes, it seems
dangerous to allow the use of those default values without some sort
FIPS 140-2 specifies that all access to various cryptographic modules be
prevented in the event that any of the provided self tests fail on the various
implemented algorithms. The way this is currently done is by simply panicing the
box. We do this already for the various alg tests in testmgr.c,
