On 07/03/14 01:06, Sandy Harris wrote:
> On Tue, Jul 1, 2014 at 7:14 AM, Corentin LABBE
> wrote:
>
>> I am writing the PRNG driver for the Allwinner Security System SoC A20.
>
> The datasheet my search turned up (v1, Feb. 2013) just says: "160-bit
> hardware PRNG with 192-bit seed" and gives no
On Tue, Jul 1, 2014 at 7:14 AM, Corentin LABBE
wrote:
> I am writing the PRNG driver for the Allwinner Security System SoC A20.
The datasheet my search turned up (v1, Feb. 2013) just says: "160-bit
hardware PRNG with 192-bit seed" and gives no other details. Do you
have more info, perhaps from
On 2 July 2014 23:21, Mimi Zohar wrote:
> On Tue, 2014-07-01 at 23:12 +0300, Dmitry Kasatkin wrote:
>> Use of multiple-page collect buffers reduces:
>> 1) the number of block IO requests
>> 2) the number of asynchronous hash update requests
>>
>> Second is important for HW accelerated hashing, bec
On Tue, 2014-07-01 at 23:12 +0300, Dmitry Kasatkin wrote:
> Use of multiple-page collect buffers reduces:
> 1) the number of block IO requests
> 2) the number of asynchronous hash update requests
>
> Second is important for HW accelerated hashing, because significant
> amount of time is spent for
Per further discussion with NIST, the requirements for FIPS state that
we only need to panic the system on failed kernel module signature checks
for crypto subsystem modules. This moves the fips-mode-only module
signature check out of the generic module loading code, into the crypto
subsystem, at p
On Wed, 2014-07-02 at 21:21 +0300, Dmitry Kasatkin wrote:
> On 2 July 2014 20:44, Mimi Zohar wrote:
> > On Tue, 2014-07-01 at 23:12 +0300, Dmitry Kasatkin wrote:
> >
> >> -/*
> >> - * Calculate the MD5/SHA1 file digest
> >> - */
> >> +static struct crypto_ahash *ima_alloc_atfm(enum hash_algo algo
On Wed, 2014-07-02 at 21:20 +0300, Dmitry Kasatkin wrote:
> On 2 July 2014 19:40, Mimi Zohar wrote:
> > On Tue, 2014-07-01 at 23:12 +0300, Dmitry Kasatkin wrote:
> >> Async hash API allows to use HW acceleration for hash calculation.
> >> It may give significant performance gain or/and reduce pow
On 07/02/2014 11:40 AM, Dmitry Kasatkin wrote:
>> > We should reserve command-line parameters for things that really need
>> > tweaking in early boot or are _needed_ to boot.
...
> Is module param good enough or it should be sysctl?
Doesn't matter to me much. sysctls seem to be the easiest things
On 2 July 2014 21:33, Dave Hansen wrote:
> On 07/01/2014 01:12 PM, Dmitry Kasatkin wrote:
>> + ima_ahash= [IMA] Asynchronous hash usage parameters
>> + Format:
>> + Set the minimal file size when use asynchronous hash.
>> + If i
On 07/01/2014 01:12 PM, Dmitry Kasatkin wrote:
> + ima_ahash= [IMA] Asynchronous hash usage parameters
> + Format:
> + Set the minimal file size when use asynchronous hash.
> + If ima_ahash is not provided, ahash usage is disable
On 2 July 2014 20:44, Mimi Zohar wrote:
> On Tue, 2014-07-01 at 23:12 +0300, Dmitry Kasatkin wrote:
>
>> -/*
>> - * Calculate the MD5/SHA1 file digest
>> - */
>> +static struct crypto_ahash *ima_alloc_atfm(enum hash_algo algo)
>> +{
>> + struct crypto_ahash *tfm = ima_ahash_tfm;
>> + int r
On 2 July 2014 19:40, Mimi Zohar wrote:
> On Tue, 2014-07-01 at 23:12 +0300, Dmitry Kasatkin wrote:
>> Async hash API allows to use HW acceleration for hash calculation.
>> It may give significant performance gain or/and reduce power consumption,
>> which might be very beneficial for battery power
On Tue, 2014-07-01 at 23:12 +0300, Dmitry Kasatkin wrote:
> -/*
> - * Calculate the MD5/SHA1 file digest
> - */
> +static struct crypto_ahash *ima_alloc_atfm(enum hash_algo algo)
> +{
> + struct crypto_ahash *tfm = ima_ahash_tfm;
> + int rc;
> +
> + if ((algo != ima_hash_algo && algo <
On Tue, 2014-07-01 at 23:12 +0300, Dmitry Kasatkin wrote:
> Async hash API allows to use HW acceleration for hash calculation.
> It may give significant performance gain or/and reduce power consumption,
> which might be very beneficial for battery powered devices.
>
> This patch introduces hash c
On Wed, Jul 02, 2014 at 08:38:50PM +0800, Herbert Xu wrote:
> On Fri, Jun 27, 2014 at 03:12:54PM -0400, Jarod Wilson wrote:
> > Per further discussion with NIST, the requirements for FIPS state that
> > we only need to panic the system on failed kernel module signature checks
> > for crypto subsyst
On Fri, Jun 27, 2014 at 03:12:54PM -0400, Jarod Wilson wrote:
> Per further discussion with NIST, the requirements for FIPS state that
> we only need to panic the system on failed kernel module signature checks
> for crypto subsystem modules. This moves the fips-mode-only module
> signature check o
This patch fixes a memory leak that appears when caam_jr module is unloaded.
Cc: # 3.13+
Signed-off-by: Cristian Stoica
---
drivers/crypto/caam/jr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/caam/jr.c b/drivers/crypto/caam/jr.c
index 1d80bd3..f127f86 100644
--- a/driver
17 matches
Mail list logo
