Use the GENMASK helper instead of custom calculations to generate masks,
It also helps the readability.
Signed-off-by: Antoine Tenart
---
drivers/crypto/sunxi-ss/sun4i-ss-hash.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git
A bit is appended at the end of the input buffer for sha1. Simplify the
code assigning it.
Signed-off-by: Antoine Tenart
---
drivers/crypto/sunxi-ss/sun4i-ss-hash.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git
Add a node for the cryptographic engine that can be found on sun5i SoCs.
This cryptographic engine is compatible with the Allwinner cryptographic
accelerator driver.
Signed-off-by: Antoine Tenart
---
arch/arm/boot/dts/sun5i.dtsi | 8
1 file changed, 8
Parts of the bf buffer were dynamically set to 0. Change this to set the
whole buffer to 0 by default to avoid any mistake.
Signed-off-by: Antoine Tenart
---
drivers/crypto/sunxi-ss/sun4i-ss-hash.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff
The CRYPTO_ALG_KERN_DRIVER_ONLY flag is set for hardware accelerated
ciphers accessible through a kernel driver only. This is the case for
ciphers exposed by the sun4i-ss driver. This patch sets this flag.
Signed-off-by: Antoine Tenart
---
Hello,
This series adds the cryptographic engine support to sun5i SoCs. This is
based on top of v4.12-rc1 and was tested on a CHIP. The series begins
with fixes and improvements. The series is available at:
https://github.com/atenart/linux v4.12-rc1/sun5i-crypto
The 8 first patches are reworks
Update the sun4i-ss driver to use the skcipher API instead of the old
ablkcipher one. It's a bit more tricky than s/ablkcipher/skcipher/, but
still nothing special and the driver's logic stays the same.
Signed-off-by: Antoine Tenart
---
Do not use DMA is the request is 0 length.
Signed-off-by: Antoine Tenart
---
drivers/crypto/sunxi-ss/sun4i-ss-hash.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
The run-time self-tests fail quite early, as soon as the input block
size is larger than 64 bytes:
alg: hash: Test 4 failed for sha1-sun4i-ss
: b9 c9 1e 52 c0 26 d8 39 81 ff f2 3c 99 b1 27 b2
0010: 30 d6 c9 85
One thing to notice is the value of the last word, which is the one
Cosmetic clean up if conditional checks on 0s values.
Signed-off-by: Antoine Tenart
---
drivers/crypto/sunxi-ss/sun4i-ss-cipher.c | 28 +++---
drivers/crypto/sunxi-ss/sun4i-ss-core.c | 10
drivers/crypto/sunxi-ss/sun4i-ss-hash.c |
Cosmetic change to avoid having a full screen a variable definitions. It
also helps to see which variables share the same type.
Signed-off-by: Antoine Tenart
---
drivers/crypto/sunxi-ss/sun4i-ss-hash.c | 31 +++
1 file changed, 11
On Mon, May 29, 2017 at 8:36 PM, Joe Perches wrote:
> On Mon, 2017-05-29 at 20:11 +0300, Gilad Ben-Yossef wrote:
>> On Mon, May 29, 2017 at 7:57 PM, Joe Perches wrote:
>> > On Mon, 2017-05-29 at 16:37 +0200, Greg Kroah-Hartman wrote:
>> > > On Sun, May 28,
On Mon, 2017-05-29 at 20:11 +0300, Gilad Ben-Yossef wrote:
> On Mon, May 29, 2017 at 7:57 PM, Joe Perches wrote:
> > On Mon, 2017-05-29 at 16:37 +0200, Greg Kroah-Hartman wrote:
> > > On Sun, May 28, 2017 at 05:40:26PM +0300, Gilad Ben-Yossef wrote:
> > > > cc_crypto_ctx.h had
On Mon, May 29, 2017 at 5:41 PM, Greg Kroah-Hartman
wrote:
> On Sun, May 28, 2017 at 05:40:29PM +0300, Gilad Ben-Yossef wrote:
>> The Linked List Item descriptors were being accessed via
>> a baroque set of defines and macro. Re-factor for structs
>> and inline
On Mon, May 29, 2017 at 5:38 PM, Greg Kroah-Hartman
wrote:
> On Sun, May 28, 2017 at 05:40:27PM +0300, Gilad Ben-Yossef wrote:
>> ccree had a lot of boilerplate code for dealing with bitops
>> and bitfield register access. Move it over to the generic kernel
>>
On Mon, May 29, 2017 at 7:57 PM, Joe Perches wrote:
> On Mon, 2017-05-29 at 16:37 +0200, Greg Kroah-Hartman wrote:
>> On Sun, May 28, 2017 at 05:40:26PM +0300, Gilad Ben-Yossef wrote:
>> > cc_crypto_ctx.h had multiple coding style violations reported by
>> > checkpatch. Fix them
On Mon, 2017-05-29 at 16:37 +0200, Greg Kroah-Hartman wrote:
> On Sun, May 28, 2017 at 05:40:26PM +0300, Gilad Ben-Yossef wrote:
> > cc_crypto_ctx.h had multiple coding style violations reported by
> > checkpatch. Fix them all.
>
> Sorry, no. You need to do only one-thing-per-patch, and "fix all
On Wed, May 24, 2017 at 04:43:52PM +1200, Derek Robson wrote:
> Fixed block comment alignment, Style fix only
> Found using checkpatch
>
> Signed-off-by: Derek Robson
> ---
> drivers/staging/ccree/ssi_fips_ll.c | 21 -
> 1 file changed, 12 insertions(+),
Hi Corentin,
On Mon, May 29, 2017 at 04:47:57PM +0200, Corentin Labbe wrote:
> On Wed, May 24, 2017 at 09:06:50PM +0200, Antoine Tenart wrote:
> > + .cra_flags = CRYPTO_ALG_TYPE_SKCIPHER |
> > +CRYPTO_ALG_KERN_DRIVER_ONLY,
>
> You add
On Wed, May 24, 2017 at 09:06:50PM +0200, Antoine Tenart wrote:
> Update the sun4i-ss driver to use the skcipher API instead of the old
> ablkcipher one. It's a bit more tricky than s/ablkcipher/skcipher/, but
> still nothing special and the driver's logic stays the same.
>
> Signed-off-by:
On Sun, May 28, 2017 at 05:40:26PM +0300, Gilad Ben-Yossef wrote:
> cc_crypto_ctx.h had multiple coding style violations reported by
> checkpatch. Fix them all.
Sorry, no. You need to do only one-thing-per-patch, and "fix all coding
style issues is not "one thing". I wouldn't take this kind of
On Sun, May 28, 2017 at 05:40:29PM +0300, Gilad Ben-Yossef wrote:
> The Linked List Item descriptors were being accessed via
> a baroque set of defines and macro. Re-factor for structs
> and inline function for readability and sanity.
>
> Signed-off-by: Gilad Ben-Yossef
>
On Sun, May 28, 2017 at 05:40:27PM +0300, Gilad Ben-Yossef wrote:
> ccree had a lot of boilerplate code for dealing with bitops
> and bitfield register access. Move it over to the generic kernel
> infrastructure used for doing the same.
>
> Signed-off-by: Gilad Ben-Yossef
>
Hi, Horia,
On 28.05.2017 20:22, Horia Geantă wrote:
On 5/25/2017 10:18 AM, Tudor Ambarus wrote:
Rename ecdh_make_pub_key() to ecc_make_pub_key().
This function might as well be used by ecdsa.
Where exactly is ecdsa used in the kernel?
Hi, Stephan,
On 29.05.2017 12:56, Stephan Müller wrote:
Am Montag, 29. Mai 2017, 11:47:48 CEST schrieb Tudor Ambarus:
Hi Tudor,
Hm, there should be no blocking for the DRBG to initialize.
What happens if you compile that as a module and insmod it at runtime?
We will have a nop:
#ifdef
We forgot to set the error code on this path so it could result in
returning NULL which leads to a NULL dereference.
Fixes: db6c43bd2132 ("crypto: KEYS: convert public key and digsig asym to the
akcipher api")
Signed-off-by: Dan Carpenter
---
v2: Style change
Sorry
Am Montag, 29. Mai 2017, 11:47:48 CEST schrieb Tudor Ambarus:
Hi Tudor,
> > Hm, there should be no blocking for the DRBG to initialize.
> >
> > What happens if you compile that as a module and insmod it at runtime?
>
> We will have a nop:
>
> #ifdef CONFIG_CRYPTO_MANAGER_DISABLE_TESTS
>
> /*
Hi, Stephan,
On 29.05.2017 12:23, Stephan Müller wrote:
Am Montag, 29. Mai 2017, 11:08:38 CEST schrieb Tudor Ambarus:
Hi Tudor,
+ unsigned int nbytes = ndigits << ECC_DIGITS_TO_BYTES_SHIFT;
+
+ get_random_bytes(priv, nbytes);
Can you please use crypto_get_default_rng /
On 29 May 2017 at 14:51, Antoine Tenart
wrote:
>> As you have got help from other people for testing, wouldn't it be
>> nice to add tested-by tag?
>
> Well, they're listed as authors of the driver: not only they helped to
> test it but they developed parts of
Am Montag, 29. Mai 2017, 11:08:38 CEST schrieb Tudor Ambarus:
Hi Tudor,
>
> >> + unsigned int nbytes = ndigits << ECC_DIGITS_TO_BYTES_SHIFT;
> >> +
> >> + get_random_bytes(priv, nbytes);
> >
> > Can you please use crypto_get_default_rng / crypto_rng_get_bytes /
> > crypto_put_default_rng?
>
Hello,
On Sun, May 28, 2017 at 11:09:43AM +0530, PrasannaKumar Muralidharan wrote:
> On 24 May 2017 at 19:40, Antoine Tenart
> wrote:
> > Add support for Inside Secure SafeXcel EIP197 cryptographic engine,
> > which can be found on Marvell Armada 7k and 8k
Hi Maxime,
On Mon, May 29, 2017 at 10:29:31AM +0200, Maxime Ripard wrote:
> On Mon, May 29, 2017 at 10:09:44AM +0200, Antoine Tenart wrote:
> > > Which speed are the SS clocks ?
> >
> > The AHB SS clk is running at 300 MHz and the SS clk at 150 MHz. SS clk
> > is at the expected rate but the AHB
Hi, Stephan,
Thank you for the review. Please see inline.
On 28.05.2017 21:44, Stephan Müller wrote:
Am Mittwoch, 17. Mai 2017, 17:26:50 CEST schrieb Tudor Ambarus:
Hi Tudor,
Add support for generating ecc private keys.
Generation of ecc private keys is helpful in a user-space to kernel
On Mon, May 29, 2017 at 10:09:44AM +0200, Antoine Tenart wrote:
> > Which speed are the SS clocks ?
>
> The AHB SS clk is running at 300 MHz and the SS clk at 150 MHz. SS clk
> is at the expected rate but the AHB SS clk has a higher rate that what's
> expected.
>
> In the probing function only
gcm is starting an async. crypto op and waiting for it complete.
Move it over to generic code doing the same.
Signed-off-by: Gilad Ben-Yossef
---
crypto/gcm.c | 32 ++--
1 file changed, 6 insertions(+), 26 deletions(-)
diff --git a/crypto/gcm.c
algif starts several async crypto ops and waits for their completion.
Move it over to generic code doing the same.
Signed-off-by: Gilad Ben-Yossef
---
crypto/af_alg.c | 27 ---
crypto/algif_aead.c | 14 +++---
crypto/algif_hash.c
DRBG is starting an async. crypto op and waiting for it complete.
Move it over to generic code doing the same.
The code now also passes CRYPTO_TFM_REQ_MAY_SLEEP flag indicating
crypto request memory allocation may use GFP_KERNEL which should
be perfectly fine as the code is obviously sleeping for
Invoking a possibly async. crypto op and waiting for completion
while correctly handling backlog processing is a common task
in the crypto API implementation and outside users of it.
This patch adds a generic implementation for doing so in
preparation for using it across the board instead of hand
public_key_verify_signature() is starting an async crypto op and
waiting for it to complete. Move it over to generic code doing
the same.
Signed-off-by: Gilad Ben-Yossef
---
crypto/asymmetric_keys/public_key.c | 28
1 file changed, 4
testmgr is starting async. crypto ops and waiting for them to complete.
Move it over to generic code doing the same.
This also provides a test of the generic crypto async. wait code.
Signed-off-by: Gilad Ben-Yossef
---
crypto/testmgr.c | 184
fscrypt starts several async. crypto ops and waiting for them to
complete. Move it over to generic code doing the same.
Signed-off-by: Gilad Ben-Yossef
---
fs/crypto/crypto.c | 28
fs/crypto/fname.c | 36
dm-verity is starting async. crypto ops and waiting for them to complete.
Move it over to generic code doing the same.
This also fixes a possible data coruption bug created by the
use of wait_for_completion_interruptible() without dealing
correctly with an interrupt aborting the wait prior to the
The code sample is waiting for an async. crypto op completion.
Adapt sample to use the new generic infrastructure to do the same.
This also fixes a possible data coruption bug created by the
use of wait_for_completion_interruptible() without dealing
correctly with an interrupt aborting the wait
cifs starts an async. crypto op and waits for their completion.
Move it over to generic code doing the same.
Signed-off-by: Gilad Ben-Yossef
Acked-by: Pavel Shilovsky
---
fs/cifs/smb2ops.c | 30 --
1 file changed, 4
ima starts several async crypto ops and waits for their completions.
Move it over to generic code doing the same.
Signed-off-by: Gilad Ben-Yossef
Acked-by: Mimi Zohar
---
security/integrity/ima/ima_crypto.c | 56
Many users of kernel async. crypto services have a pattern of
starting an async. crypto op and than using a completion
to wait for it to end, resulting of the same code repeating
itself in multiple places, sometime with coding errors.
This patch aims to introduce a generic "wait for async.
crypto
Hi Corentin,
On Fri, May 26, 2017 at 04:55:01PM +0200, Corentin Labbe wrote:
> On Wed, May 24, 2017 at 09:06:51PM +0200, Antoine Tenart wrote:
> >
> > + /*
> > +* The datasheet isn't very clear about when to retrieve the digest. The
> > +* bit SS_DATA_END is cleared when the engine
Hi Cosar,
Thank you for the patch
On 22/05/17 16:34, Cosar Dindar wrote:
> This patch adds CRC (CRC32 Crypto) support for STM32F4 series.
>
> As an hardware limitation polynomial and key setting are not supported.
> They are fixed as 0x4C11DB7 (poly) and 0x (key).
> CRC32C Castagnoli
48 matches
Mail list logo