This patch fixes two typos related to unregistering algorithms supported by
SAHARAH 3. In sahara_register_algs the wrong algorithms are unregistered
in case of an error. In sahara_unregister_algs the wrong array is used to
determine the iteration count.
Signed-off-by: Michael Müller
---
Sorry
This patch fixes two typos related to unregistering algorithms supported by
SAHARAH 3. In sahara_register_algs the wrong algorithms are unregistered
in case of an error. In sahara_unregister_algs the wrong array is used to
determine the iteration count.
Signed-off-by: Michael Müller
---
Herbert Xu wrote:
> This was detected by the self-test thanks to Ard's chunking patch.
>
> I finally got around to testing this out on my ancient Via box. It
> turns out that the workaround got the assembly wrong and we end up
> doing count + initial cycles of the loop instead of just count.
>
On Tue, Jul 03, 2018 at 12:11:22PM -0500, Tom Lendacky wrote:
> The following patches for the PSP support within the CCP driver are
> included in this driver update series:
>
> - Fix a possible race condition when checking for command completion
> - Add a message to indicate if the PSP function
This was detected by the self-test thanks to Ard's chunking patch.
I finally got around to testing this out on my ancient Via box. It
turns out that the workaround got the assembly wrong and we end up
doing count + initial cycles of the loop instead of just count.
This obviously causes
By adding a zero byte-length for the DH parameter Q value, the public
key verification test is disabled for the given test.
Reported-by: Eric Biggers
Signed-off-by: Stephan Mueller
---
crypto/testmgr.h | 4
1 file changed, 4 insertions(+)
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
On Wed, Jul 11, 2018 at 03:26:56PM +0800, Herbert Xu wrote:
> On Tue, Jul 10, 2018 at 08:59:05PM -0700, Eric Biggers wrote:
> > From: Eric Biggers
> >
> > It was forgotten to increase DH_KPP_SECRET_MIN_SIZE to include 'q_size',
> > causing an out-of-bounds write of 4 bytes in
Am Mittwoch, 11. Juli 2018, 06:10:59 CEST schrieb Eric Biggers:
Hi Eric,
> You forgot to update the self-tests in the kernel, so they're failing now,
> as you *did* change the interface (the "key" is encoded differently now).
I was actually looking for failing self tests. But accidentally I
Am Mittwoch, 11. Juli 2018, 05:59:05 CEST schrieb Eric Biggers:
Hi Eric,
> From: Eric Biggers
>
> It was forgotten to increase DH_KPP_SECRET_MIN_SIZE to include 'q_size',
> causing an out-of-bounds write of 4 bytes in crypto_dh_encode_key(), and
> an out-of-bounds read of 4 bytes in
Hello Janakarajan Natarajan,
The patch edd303ff0e9e: "crypto: ccp - Add DOWNLOAD_FIRMWARE SEV
command" from May 25, 2018, leads to the following static checker
warning:
drivers/crypto/ccp/psp-dev.c:397 sev_get_api_version()
error: uninitialized symbol 'error'.
On Tue, Jul 10, 2018 at 08:59:05PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> It was forgotten to increase DH_KPP_SECRET_MIN_SIZE to include 'q_size',
> causing an out-of-bounds write of 4 bytes in crypto_dh_encode_key(), and
> an out-of-bounds read of 4 bytes in crypto_dh_decode_key().
Hi Stephan,
On Wed, Jun 27, 2018 at 08:15:31AM +0200, Stephan Müller wrote:
> Hi,
>
> Changes v2:
> * addition of a check that mpi_alloc succeeds.
>
> ---8<---
>
> According to SP800-56A section 5.6.2.1, the public key to be processed
> for the DH operation shall be checked for
Top of the day to you, this is in respect of a very beneficial transaction
which you would not want to let go reply for more details,
Regards,
Lee
The SGL can directly operate caller-provided memory with the exception
of stack memory. The DRBG detects whether the caller provided
non-suitable memory and uses the scratchpad only on those circumstances.
This patch increases the speed of the CTR DRBG by 1 to 3 percent
depending on the buffer
Hi Herbert,
Please find CTR DRBG performance improvements with the patches attached.
In the following, there is an example log taken with my LRNG implementation
using the getrandom(2) system call demonstrating the difference.
Without the patch set:
16 bytes| 12.267661 MB/s|
The CTR DRBG requires two SGLs pointing to input/output buffers for the
CTR AES operation. The used SGLs always have only one entry. Thus, the
SGL can be initialized during allocation time, preventing a
re-initialization of the SGLs during each call.
The performance is increased by about 1 to 3
From: Luo Xinqiang
In function scatterwalk_pagedone(), a kernel panic of invalid
page will occur if walk->offset equals 0. This patch fixes the
problem by setting the page addresswith sg_page(walk->sg)
directly if walk->offset equals 0.
Panic call stack:
[] blkcipher_walk_done+0x430/0x8dc
[]
Kedves Kedvezményezettem,
Biztos vagyok benne, hogy ez a levél meglepetésként fog megjelenni, mivel még
soha nem találkoztunk, és akkor is megkérdeznéd, hogy miért döntöttem úgy, hogy
választottam Önt a világ számos internethasználója között. Pontosan, nem tudom
megmondani, hogy miért
tree:
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
head: 5c324a2ffa06f8b6fda59a77c6807acb9f45cfee
commit: 9744fec95f0674fbf67b12c42c3784dc299dc904 [45/63] crypto: inside-secure
- remove request list to improve performance
config: powerpc-allmodconfig
On Sun, Jul 01, 2018 at 08:02:33AM +0100, Gilad Ben-Yossef wrote:
> The patch set fixes ccree IV handling, finup() operation (provided
> by Hadar Gat) and CTS-AES mode of operation along a code cleanup.
>
>
On Sat, Jun 30, 2018 at 03:16:10PM -0700, Eric Biggers wrote:
> Originally, algorithms had to declare their type in .cra_flags as a
> CRYPTO_ALG_TYPE_* value. Some types of algorithms such as "cipher"
> still have to do this. But now most algorithm types use different
> top-level C data
On Fri, Jun 29, 2018 at 02:14:35PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> There is a copy-paste error where sha256_mb_mgr_get_comp_job_avx2()
> copies the SHA-256 digest state from sha256_mb_mgr::args::digest to
> job_sha256::result_digest. Consequently, the sha256_mb algorithm
>
On Fri, Jun 29, 2018 at 02:21:11PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> "arch/x86/crypto/sha*-mb" needs a trailing slash, since it refers to
> directories. Otherwise get_maintainer.pl doesn't find the entry.
>
> Signed-off-by: Eric Biggers
Patch applied. Thanks.
--
Email:
On Fri, Jun 29, 2018 at 05:01:40PM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> I found that not only was sha256_mb sometimes computing the wrong digest
> (fixed by a separately sent patch), but under normal workloads it's
> hundreds of times slower than sha256-avx2, due to the flush
On Thu, Jun 28, 2018 at 05:21:52PM +0200, Antoine Tenart wrote:
> Hi all,
>
> This series adds support for more algorithms in the Inside Secure
> SafeXcel cryptographic engine driver. Those new algorithms are:
> - MD5 (and its hmac).
> - DES (ECB and CBC).
> - 3DES (ECB and CBC).
>
> The last
On Mon, Jun 25, 2018 at 12:00:18PM +0200, Stephan Müller wrote:
> According to SP800-56A section 5.6.2.1, the public key to be processed
> for the ECDH operation shall be checked for appropriateness. When the
> public key is considered to be an ephemeral key, the partial validation
> test as
On 07/03/2018 12:12 PM, Tom Lendacky wrote:
In preparation for adding a new PSP device ID that uses different register
offsets, add support to the PSP version data for register offset values.
And then update the code to use these new register offset values.
Signed-off-by: Tom Lendacky
---
On 07/03/2018 12:11 PM, Tom Lendacky wrote:
Remove some unused #defines for register offsets that are not used. This
will lessen the changes required when register offsets change between
versions of the device.
Signed-off-by: Tom Lendacky
---
drivers/crypto/ccp/psp-dev.c |2 +-
On 07/03/2018 12:12 PM, Tom Lendacky wrote:
Add a new CCP/PSP PCI device ID and new PSP register offsets.
Signed-off-by: Tom Lendacky
Acked-by: Gary R Hook
---
drivers/crypto/ccp/sp-pci.c | 29 -
1 file changed, 24 insertions(+), 5 deletions(-)
diff --git
On 07/05/2018 10:43 AM, Brijesh Singh wrote:
On 07/03/2018 12:11 PM, Tom Lendacky wrote:
The wait_event() function is used to detect command completion. The
interrupt handler will set the wait condition variable when the interrupt
is triggered. However, the variable used for wait_event() is
On 07/03/2018 12:12 PM, Tom Lendacky wrote:
In preparation for adding a new PSP device ID that uses different register
offsets, add support to the PSP version data for register offset values.
And then update the code to use these new register offset values.
Signed-off-by: Tom Lendacky
On 07/03/2018 12:11 PM, Tom Lendacky wrote:
Remove some unused #defines for register offsets that are not used. This
will lessen the changes required when register offsets change between
versions of the device.
Signed-off-by: Tom Lendacky
Acked-by: Gary R Hook
---
On 07/03/2018 12:11 PM, Tom Lendacky wrote:
Add a dev_notice() message to the PSP initialization to report when the
PSP initialization has succeeded and the PSP is enabled.
Signed-off-by: Tom Lendacky
Acked-by: Gary R Hook
---
drivers/crypto/ccp/psp-dev.c |2 ++
1 file changed, 2
On 07/03/2018 12:11 PM, Tom Lendacky wrote:
The wait_event() function is used to detect command completion. The
interrupt handler will set the wait condition variable when the interrupt
is triggered. However, the variable used for wait_event() is initialized
after the command has been
On 07/03/2018 12:11 PM, Tom Lendacky wrote:
The wait_event() function is used to detect command completion. The
interrupt handler will set the wait condition variable when the interrupt
is triggered. However, the variable used for wait_event() is initialized
after the command has been
On Wed, Jul 4, 2018 at 8:32 PM, Stephen Rothwell wrote:
> I have just removed that commit from the linux-next copy of mmotm (it
> was actually commit 026f20c65973 since Andrew did another release
> yesterday).
Thanks, Stephen!
Hi all,
On Wed, 4 Jul 2018 10:41:17 -0600 Logan Gunthorpe wrote:
>
> On 7/4/2018 10:23 AM, Fabio Estevam wrote:
> > From: Fabio Estevam
> >
> > This reverts commit 46e4bf08f6388ba748597275012d715d5e1861e6.
> >
> > Commit 46e4bf08f6388 ("crypto: caam: cleanup CONFIG_64BIT ifdefs
> > when using
On 7/4/2018 10:23 AM, Fabio Estevam wrote:
> From: Fabio Estevam
>
> This reverts commit 46e4bf08f6388ba748597275012d715d5e1861e6.
>
> Commit 46e4bf08f6388 ("crypto: caam: cleanup CONFIG_64BIT ifdefs
> when using io{read|write}64") causes kernel crash on imx6 systems:
>
> [2.041187]
From: Fabio Estevam
This reverts commit 46e4bf08f6388ba748597275012d715d5e1861e6.
Commit 46e4bf08f6388 ("crypto: caam: cleanup CONFIG_64BIT ifdefs
when using io{read|write}64") causes kernel crash on imx6 systems:
[2.041187] caam_jr 2101000.jr0: job ring error: irqstate: 0103
[
Add a new CCP/PSP PCI device ID and new PSP register offsets.
Signed-off-by: Tom Lendacky
---
drivers/crypto/ccp/sp-pci.c | 29 -
1 file changed, 24 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/ccp/sp-pci.c b/drivers/crypto/ccp/sp-pci.c
index
In preparation for adding a new PSP device ID that uses different register
offsets, add support to the PSP version data for register offset values.
And then update the code to use these new register offset values.
Signed-off-by: Tom Lendacky
---
drivers/crypto/ccp/psp-dev.c | 24
Remove some unused #defines for register offsets that are not used. This
will lessen the changes required when register offsets change between
versions of the device.
Signed-off-by: Tom Lendacky
---
drivers/crypto/ccp/psp-dev.c |2 +-
drivers/crypto/ccp/psp-dev.h | 10 +-
2 files
The wait_event() function is used to detect command completion. The
interrupt handler will set the wait condition variable when the interrupt
is triggered. However, the variable used for wait_event() is initialized
after the command has been submitted, which can create a race condition
with the
Add a dev_notice() message to the PSP initialization to report when the
PSP initialization has succeeded and the PSP is enabled.
Signed-off-by: Tom Lendacky
---
drivers/crypto/ccp/psp-dev.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/crypto/ccp/psp-dev.c
The following patches for the PSP support within the CCP driver are
included in this driver update series:
- Fix a possible race condition when checking for command completion
- Add a message to indicate if the PSP function has been enabled
- In preparation for moving register offsets into the
On Tue, Jul 3, 2018 at 11:18 AM, Fabio Estevam wrote:
> Hi Horia,
>
> I am not able to boot linux-next 20180703 on imx6 due to a problem
> with the CAAM driver.
which is caused by the following commit:
commit 46e4bf08f6388ba748597275012d715d5e1861e6
Author: Logan Gunthorpe
Date: Thu Jun 28
Hi Horia,
I am not able to boot linux-next 20180703 on imx6 due to a problem
with the CAAM driver.
Any ideas?
[1.872473] caam 210.caam: Entropy delay = 3200
[1.938223] caam 210.caam: Instantiated RNG4 SH0
[1.998983] caam 210.caam: Instantiated RNG4 SH1
[2.004019]
On 06/28/2018 04:07 PM, Linus Walleij wrote:
> This breaks out a lock status checker to be used with further
> refactorings.
>
> Signed-off-by: Linus Walleij
> ---
> ChangeLog v1->v2:
> - Rebased
> ---
> drivers/crypto/atmel-ecc.c | 38 ++
> 1 file
Hi, Linus,
On 06/28/2018 04:07 PM, Linus Walleij wrote:
> This reads out the serial number of the crypto chip and prints it,
> also toss this into the entropy pool as it is device-unique data.
>
> Signed-off-by: Linus Walleij
> ---
> ChangeLog v1->v2:
> - kfree(cmd) was missed. Fix it with a
Hi, Linus,
On 06/28/2018 04:07 PM, Linus Walleij wrote:
> Instead of casting the struct for the command into (u8 *)
> which is problematic in many ways, and instead of
> calculating the CRC sum in a separate function, marshal,
> checksum and send the command in one single function.
>
> Instead
Hi, Linus,
On 06/28/2018 04:07 PM, Linus Walleij wrote:
> Report errors once when they happen on the I2C bus so we
> get good information in cases such as when the wrong I2C
> address is used.
>
> Signed-off-by: Linus Walleij
> ---
> ChangeLog v1->v2:
> - Strip some comments that are now
Hi, Linus,
On 06/28/2018 04:07 PM, Linus Walleij wrote:
> The Atmel ECC driver contains a check for the I2C bus clock
> frequency, so as to check that the I2C adapter in use
> satisfies the device specs.
>
> If the device is connected to a device tree node that does not
> contain a clock
On Mon, Jun 18, 2018 at 03:33:23PM -0700, Eric Biggers wrote:
> Building the kernel with CONFIG_THUMB2_KERNEL=y and
> CONFIG_CRYPTO_SPECK_NEON set fails with the following errors:
>
> arch/arm/crypto/speck-neon-core.S: Assembler messages:
>
> arch/arm/crypto/speck-neon-core.S:419: Error:
On Mon, Jun 18, 2018 at 10:22:36AM -0700, Eric Biggers wrote:
> From: Eric Biggers
>
> Hi, this series fixes various bugs in the VMAC template (crypto/vmac.c).
> First, the per-request context was being stored in the transform
> context, which made VMAC not thread-safe, and the kernel could be
>
On Sun, Jul 1, 2018 at 1:16 AM, Eric Biggers wrote:
> From: Eric Biggers
>
> Some skcipher algorithms set .cra_flags = CRYPTO_ALG_TYPE_SKCIPHER. But
> this is redundant with the C structure type ('struct skcipher_alg'), and
> crypto_register_skcipher() already sets the type flag automatically,
On Sun, Jul 1, 2018 at 1:16 AM, Eric Biggers wrote:
> From: Eric Biggers
>
> Some ahash algorithms set .cra_type = _ahash_type. But this is
> redundant with the C structure type ('struct ahash_alg'), and
> crypto_register_ahash() already sets the .cra_type automatically.
> Apparently the
On Sun, Jul 1, 2018 at 1:16 AM, Eric Biggers wrote:
> From: Eric Biggers
>
> Many ahash algorithms set .cra_flags = CRYPTO_ALG_TYPE_AHASH. But this
> is redundant with the C structure type ('struct ahash_alg'), and
> crypto_register_ahash() already sets the type flag automatically,
> clearing
From: Eric Biggers
Some crypto API users allocating a tfm with crypto_alloc_$FOO() are also
specifying the type flags for $FOO, e.g. crypto_alloc_shash() with
CRYPTO_ALG_TYPE_SHASH. But, that's redundant since the crypto API will
override any specified type flag/mask with the correct ones.
So,
From: Eric Biggers
Many shash algorithms set .cra_flags = CRYPTO_ALG_TYPE_SHASH. But this
is redundant with the C structure type ('struct shash_alg'), and
crypto_register_shash() already sets the type flag automatically,
clearing any type flag that was already there. Apparently the useless
From: Eric Biggers
Many ahash algorithms set .cra_flags = CRYPTO_ALG_TYPE_AHASH. But this
is redundant with the C structure type ('struct ahash_alg'), and
crypto_register_ahash() already sets the type flag automatically,
clearing any type flag that was already there. Apparently the useless
From: Eric Biggers
Some ahash algorithms set .cra_type = _ahash_type. But this is
redundant with the C structure type ('struct ahash_alg'), and
crypto_register_ahash() already sets the .cra_type automatically.
Apparently the useless assignment has just been copy+pasted around.
So, remove the
Originally, algorithms had to declare their type in .cra_flags as a
CRYPTO_ALG_TYPE_* value. Some types of algorithms such as "cipher"
still have to do this. But now most algorithm types use different
top-level C data structures, and different registration and allocation
functions. And for
From: Eric Biggers
Some skcipher algorithms set .cra_flags = CRYPTO_ALG_TYPE_SKCIPHER. But
this is redundant with the C structure type ('struct skcipher_alg'), and
crypto_register_skcipher() already sets the type flag automatically,
clearing any type flag that was already there. Apparently the
From: Eric Biggers
Some aead algorithms set .cra_flags = CRYPTO_ALG_TYPE_AEAD. But this is
redundant with the C structure type ('struct aead_alg'), and
crypto_register_aead() already sets the type flag automatically,
clearing any type flag that was already there. Apparently the useless
From: Eric Biggers
sha1-generic had a cra_priority of 0, so it wasn't possible to have a
lower priority SHA-1 implementation, as is desired for sha1_mb which is
only useful under certain workloads and is otherwise extremely slow.
Change it to priority 100, which is the priority used for many of
From: Eric Biggers
sha256-generic and sha224-generic had a cra_priority of 0, so it wasn't
possible to have a lower priority SHA-256 or SHA-224 implementation, as
is desired for sha256_mb which is only useful under certain workloads
and is otherwise extremely slow. Change them to priority 100,
From: Eric Biggers
sha512-generic and sha384-generic had a cra_priority of 0, so it wasn't
possible to have a lower priority SHA-512 or SHA-384 implementation, as
is desired for sha512_mb which is only useful under certain workloads
and is otherwise extremely slow. Change them to priority 100,
From: Eric Biggers
With all the crypto modules enabled on x86, and with a CPU that supports
AVX-2 but not SHA-NI instructions (e.g. Haswell, Broadwell, Skylake),
the "multibuffer" implementations of SHA-1, SHA-256, and SHA-512 are the
highest priority. However, these implementations only
From: Eric Biggers
I found that not only was sha256_mb sometimes computing the wrong digest
(fixed by a separately sent patch), but under normal workloads it's
hundreds of times slower than sha256-avx2, due to the flush delay. The
same applies to sha1_mb and sha512_mb. Yet, currently these can
From: Eric Biggers
"arch/x86/crypto/sha*-mb" needs a trailing slash, since it refers to
directories. Otherwise get_maintainer.pl doesn't find the entry.
Signed-off-by: Eric Biggers
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
From: Eric Biggers
There is a copy-paste error where sha256_mb_mgr_get_comp_job_avx2()
copies the SHA-256 digest state from sha256_mb_mgr::args::digest to
job_sha256::result_digest. Consequently, the sha256_mb algorithm
sometimes calculates the wrong digest. Fix it.
Reproducer using AF_ALG:
Hi Eric,
sorry for my late response.
On Fri, Jun 22, 2018 at 08:12:26PM -0700, Eric Biggers wrote:
> Hi Jan,
>
> On Fri, Jun 22, 2018 at 04:37:20PM +0200, Jan Glauber wrote:
> > While commit 336073840a87 ("crypto: testmgr - Allow different compression
> > results")
> > allowed to test
Rewrite the function atmel_ecc_init_read_cmd() into a more
general atmel_ecc_init_read_config_word() function to read
any word from the configuration zone, and use this
parameterized with what we want to read out.
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Rebased
---
This breaks out a lock status checker to be used with further
refactorings.
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Rebased
---
drivers/crypto/atmel-ecc.c | 38 ++
1 file changed, 34 insertions(+), 4 deletions(-)
diff --git
This is a pure I2C driver, and this device appears on the
96boards Secure96 mezzanine card, so we want to enable the
driver on other devices. Cut the Kconfig limitations to
Atmel SoC only.
Reviewed-by: Tudor Ambarus
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Collect Tudor's review
The config zone has 0x16 words of 4 bytes each, so provide
some basic defines so that we can address these individually.
Rename the last word to "footer", this is where we currently
look to see if the configuration is locked.
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Diet the defines
The Atmel ECC driver contains a check for the I2C bus clock
frequency, so as to check that the I2C adapter in use
satisfies the device specs.
If the device is connected to a device tree node that does not
contain a clock frequency setting, such as an I2C mux or gate,
this blocks the probe. Make
Instead of just providing a broad error message about the
chip being unlocked provide details on what is unlocked,
one line per thing that can be locked: data and OTP and
configuration are locked independently. Loose the
overzealous defines.
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
-
Instead of casting the struct for the command into (u8 *)
which is problematic in many ways, and instead of
calculating the CRC sum in a separate function, marshal,
checksum and send the command in one single function.
Instead of providing the length of the whole command
in defines, it makes more
This reads out the serial number of the crypto chip and prints it,
also toss this into the entropy pool as it is device-unique data.
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- kfree(cmd) was missed. Fix it with a goto construction.
- Coding style fixes.
---
drivers/crypto/atmel-ecc.c
Report errors once when they happen on the I2C bus so we
get good information in cases such as when the wrong I2C
address is used.
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Strip some comments that are now obvious from the context
with the error messages.
- Do not print the excess
On Tue, Jun 12, 2018 at 2:59 PM Tudor Ambarus
wrote:
> On 06/05/2018 04:49 PM, Linus Walleij wrote:
> > The config zone has 0x16 words of 4 bytes each, so provide
> > some basic defines so that we can address these individually.
>
> Are you going to use all these defines? I would add just the
On Tue, Jun 12, 2018 at 3:25 PM Tudor Ambarus
wrote:
> On 06/05/2018 04:49 PM, Linus Walleij wrote:
> > Instead of just providing a broad error message about the
> > chip being unlocked provide details on what is unlocked,
> > one line per thing that can be locked: data and OTP and
> >
On Tue, Jun 12, 2018 at 3:13 PM Tudor Ambarus
wrote:
> > +#include
>
> includes should be ordered alphabetically.
OK fixed.
> > +static int atmel_ecc_get_serial(struct i2c_client *client)
> > +{
> > + struct atmel_ecc_cmd *cmd;
> > + u8 serial[9];
>
> int i, ret; before serial to
On Tue, Jun 12, 2018 at 12:19 PM Tudor Ambarus
wrote:
> The struct atmel_ecc_cmd (__packed) is composed of u8 members with only
> 2 exceptions, u16 param2 and u16 crc that were written in little endian,
> as the device expects. The (u8 *) cast will point to the first member,
> which is u8 as
On Tue, Jun 12, 2018 at 2:36 PM Tudor Ambarus
wrote:
> On 06/05/2018 04:49 PM, Linus Walleij wrote:
> > /* send the command */
>
> I guess that this comment will become superfluous if you're going to add
> an error message.
OK stripped obvious comments.
> > - return
On Mon, Jun 11, 2018 at 11:46 AM Tudor Ambarus
wrote:
> On 06/05/2018 04:49 PM, Linus Walleij wrote:
> > The Atmel ECC driver contains a check for the I2C bus clock
> > frequency, so as to check that the I2C adapter in use
> > satisfies the device specs.
> >
> > If the device is connected to a
Hi,
Changes v2:
* addition of a check that mpi_alloc succeeds.
---8<---
According to SP800-56A section 5.6.2.1, the public key to be processed
for the DH operation shall be checked for appropriateness. The check
shall covers the full verification test in case the domain parameter Q
is provided
Hi Rob,
On Tue, Jun 26, 2018 at 11:24 AM, Rob Herring wrote:
>> Would it be OK to use: compatible = "fsl,imx51-sahara", "fsl,imx53-sahara"; ?
>
> Yes, but the order should be reversed as it should be most specific
> and newest first.
Thanks for the feedback. Just sent a dts patch as you
Am Dienstag, 26. Juni 2018, 12:17:42 CEST schrieb Stephan Müller:
Hi,
> + MPI val = mpi_alloc(0);
I just saw that I did not check for val after allocation. That will be fixed
in another installment of the patch.
Ciao
Stephan
On Mon, Jun 25, 2018 at 2:27 PM Fabio Estevam wrote:
>
> Hi Rob,
>
> On Mon, Jun 25, 2018 at 5:21 PM, Rob Herring wrote:
>
> > Looks like imx51 should be a fallback and you can drop the driver
> > change.
>
> I thought about that too.
>
> If I do like this in imx51.dtsi:
>
> compatible =
Hi,
This patch is an RFC to discuss the following: step 1 in
dh_is_pubkey_valid requires the public key to be in the range of
1 < y < p - 1. The currently implemented check is 1 < y < p since the
calculation of p - 1 requires the presence of mpi_sub or mpi_sub_ui.
Both functions are currently not
Hi Rob,
On Mon, Jun 25, 2018 at 5:21 PM, Rob Herring wrote:
> Looks like imx51 should be a fallback and you can drop the driver
> change.
I thought about that too.
If I do like this in imx51.dtsi:
compatible = "fsl,imx51-sahara", "fsl,imx53-sahara";
Then the driver works just fine.
I was
On Fri, Jun 22, 2018 at 03:45:28PM -0300, Fabio Estevam wrote:
> From: Fabio Estevam
>
> i.MX51 and i.MX53 share the same sahara IP block version, so add
> i.MX51 in the list of supported SoCs.
>
> Signed-off-by: Fabio Estevam
> ---
> Changes since v1:
> - Fix typo in commit log "i.MX51 and
According to SP800-56A section 5.6.2.1, the public key to be processed
for the ECDH operation shall be checked for appropriateness. When the
public key is considered to be an ephemeral key, the partial validation
test as defined in SP800-56A section 5.6.2.3.4 can be applied.
The partial
On Fri, Jun 22, 2018 at 07:50:02PM -0700, Eric Biggers wrote:
> Hi Jan,
>
> On Fri, Jun 22, 2018 at 04:37:21PM +0200, Jan Glauber wrote:
> > The test vectors were generated using the ThunderX ZIP coprocessor.
> >
> > Signed-off-by: Jan Glauber
> > ---
> > crypto/testmgr.c | 9 ++
> >
Hi Jan,
On Fri, Jun 22, 2018 at 04:37:20PM +0200, Jan Glauber wrote:
> While commit 336073840a87 ("crypto: testmgr - Allow different compression
> results")
> allowed to test non-generic compression algorithms there are some corner
> cases that would not be detected in test_comp().
>
> For
Hi Jan,
On Fri, Jun 22, 2018 at 04:37:21PM +0200, Jan Glauber wrote:
> The test vectors were generated using the ThunderX ZIP coprocessor.
>
> Signed-off-by: Jan Glauber
> ---
> crypto/testmgr.c | 9 ++
> crypto/testmgr.h | 77
> 2 files
tree:
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
head: 38641b83ebc54635151810eeef00b61da3097952
commit: 9e46eafdf82a67dd069eef27c48898b79379c9f2 [9/15] crypto: inside-secure -
sha384 support
reproduce:
# apt-get install sparse
git
On 06/22/2018 01:03 PM, Timur Tabi wrote:
Perhaps it's because you implemented the 'wait' functionality in this
driver? Before the patch there wasn't any sort of wait check so we would
bail out if there wasn't any data even if the caller requested that we
wait for randomness to be available.
501 - 600 of 29368 matches
Mail list logo
