From: Herbert Xu
Date: Sat, 18 Apr 2015 09:33:17 +0800
> On Fri, Apr 17, 2015 at 03:19:53PM -0400, David Miller wrote:
>>
>> The kiocb argument is no longer present.
>>
>> Signed-off-by: David S. Miller
>
> I think Linus has already fixed this with
>
> commit eccd02f32a2c25139da2d5e72ebab1fe
On Sat, Apr 18, 2015 at 04:04:14AM +0200, Stephan Mueller wrote:
>
> However, the only serious solution I can offer to not block is to use my
> Jitter RNG which delivers entropy in (almost all) use cases. See [1]. The
> code
> is relatively small and does not have any dependencies. In this case
Am Samstag, 18. April 2015, 09:36:18 schrieb Herbert Xu:
Hi Herbert,
> On Sat, Apr 18, 2015 at 03:32:03AM +0200, Stephan Mueller wrote:
> > In any case, I am almost ready with the patch for an async seeding.
> > Though, I want to give it a thorough testing.
>
> I don't see the point of async see
On Sat, Apr 18, 2015 at 03:32:03AM +0200, Stephan Mueller wrote:
>
> In any case, I am almost ready with the patch for an async seeding. Though, I
> want to give it a thorough testing.
I don't see the point of async seeding, unless you're also making
all generate calls block until the seeding is
On Fri, Apr 17, 2015 at 03:19:53PM -0400, David Miller wrote:
>
> The kiocb argument is no longer present.
>
> Signed-off-by: David S. Miller
I think Linus has already fixed this with
commit eccd02f32a2c25139da2d5e72ebab1fee7b5baab
Author: Linus Torvalds
Date: Wed Apr 15 14:09:46 2015 -0700
Am Samstag, 18. April 2015, 09:27:44 schrieb Herbert Xu:
Hi Herbert,
> On Fri, Apr 17, 2015 at 03:22:56PM +0200, Stephan Mueller wrote:
> > > The only reason someone would use this is to comply with the
> > > standard and this is what the standard requires so I don't see
> > > how we can do anyth
On Fri, Apr 17, 2015 at 03:22:56PM +0200, Stephan Mueller wrote:
>
> > The only reason someone would use this is to comply with the
> > standard and this is what the standard requires so I don't see
> > how we can do anything else.
>
> I do not see a definite quality requirement of the seed source
The kiocb argument is no longer present.
Signed-off-by: David S. Miller
diff --git a/crypto/algif_aead.c b/crypto/algif_aead.c
index 527d27b..95ad689 100644
--- a/crypto/algif_aead.c
+++ b/crypto/algif_aead.c
@@ -163,8 +163,7 @@ static void aead_data_wakeup(struct sock *sk)
rcu_read_unl
From: Christophe Leroy
> Linux CodyingStyle recommends to use short variables for local
> variables. ptr is just good enough for those 3 lines functions.
> It helps keep single lines shorter than 80 characters.
...
> -static void to_talitos_ptr(struct talitos_ptr *talitos_ptr, dma_addr_t
> dma_add
Le 17/04/2015 17:14, David Laight a écrit :
From: Christophe Leroy
Linux CodyingStyle recommends to use short variables for local
variables. ptr is just good enough for those 3 lines functions.
It helps keep single lines shorter than 80 characters.
...
-static void to_talitos_ptr(struct talito
On 17/04/2015 17:49, Maxime Ripard wrote:
> On Fri, Apr 17, 2015 at 05:01:55PM +0200, Gregory CLEMENT wrote:
>> On 17/04/2015 16:50, Maxime Ripard wrote:
>>> On Fri, Apr 17, 2015 at 04:40:43PM +0200, Gregory CLEMENT wrote:
Hi Maxime,
On 17/04/2015 16:32, Maxime Ripard wrote:
> On
On Fri, Apr 17, 2015 at 05:01:55PM +0200, Gregory CLEMENT wrote:
> On 17/04/2015 16:50, Maxime Ripard wrote:
> > On Fri, Apr 17, 2015 at 04:40:43PM +0200, Gregory CLEMENT wrote:
> >> Hi Maxime,
> >>
> >> On 17/04/2015 16:32, Maxime Ripard wrote:
> >>> On Fri, Apr 17, 2015 at 04:19:22PM +0200, Boris
On Fri, Apr 17, Christophe Leroy wrote:
> v3 is a complete rework of the patchset. Since a kernel can be built
> with support for both MPC82xx and MPC83xx at the same time, talitos
> driver shall support both SEC1 and SEC2+ at the same time.
The used git send-email command lacked the --thread opt
On 17/04/2015 16:50, Maxime Ripard wrote:
> On Fri, Apr 17, 2015 at 04:40:43PM +0200, Gregory CLEMENT wrote:
>> Hi Maxime,
>>
>> On 17/04/2015 16:32, Maxime Ripard wrote:
>>> On Fri, Apr 17, 2015 at 04:19:22PM +0200, Boris Brezillon wrote:
Hi Gregory,
On Fri, 17 Apr 2015 15:01:01 +02
On Fri, Apr 17, 2015 at 04:40:43PM +0200, Gregory CLEMENT wrote:
> Hi Maxime,
>
> On 17/04/2015 16:32, Maxime Ripard wrote:
> > On Fri, Apr 17, 2015 at 04:19:22PM +0200, Boris Brezillon wrote:
> >> Hi Gregory,
> >>
> >> On Fri, 17 Apr 2015 15:01:01 +0200
> >> Gregory CLEMENT wrote:
> >>
> >>> Hi
This patch refactors the handling of the input and output data that is quite
similar in several functions
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 159 ---
1 file changed, 81 insertions(+), 78 deletions(-)
diff --git a/drivers/cr
This patch enhances the talitos_desc struct with fields for SEC1.
SEC1 has only one header field, and has a 'next_desc' field in
addition.
This mixed descriptor will continue to fit SEC2, and for SEC1
we will recopy hdr value into hdr1 value in talitos_submit()
Signed-off-by: Christophe Leroy
---
SEC 1.0, 1.2 and 2.x+ have different EU base addresses, so we need to
define pointers for each EU in the driver private data structure.
The proper address is set by the probe function depending on the
SEC type, in order to provide access to the proper address.
Signed-off-by: Christophe Leroy
---
j_extent field is specific to SEC2 so we add a helper function to clear it
so that SEC1 can redefine that function as nop
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/talitos.c b/driver
Do use zero_entry value to init the descriptors ptrs to zero instead of
writing 0 in each field
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 85741
j_extent field is specific to SEC2 so we add a helper function to clear it
so that SEC1 can redefine that function as nop
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/talitos.c b/driver
Linux CodyingStyle recommends to use short variables for local
variables. ptr is just good enough for those 3 lines functions.
It helps keep single lines shorter than 80 characters.
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 20 ++--
1 file changed, 10 inserti
Linux CodyingStyle recommends to use short variables for local
variables. ptr is just good enough for those 3 lines functions.
It helps keep single lines shorter than 80 characters.
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 20 ++--
1 file changed, 10 inserti
map_single_talitos_ptr() is always called with extent == 0, so lets remove this
unused parameter
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/tal
This patch adds a helper function for reads and writes of the len
param of the talitos descriptor. This will help implement
SEC1 later.
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 24 +---
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/drive
This patch enhances the talitos_desc struct with fields for SEC1.
SEC1 has only one header field, and has a 'next_desc' field in
addition.
This mixed descriptor will continue to fit SEC2, and for SEC1
we will recopy hdr value into hdr1 value in talitos_submit()
Signed-off-by: Christophe Leroy
---
This patch refactors the handling of the input and output data that is quite
similar in several functions
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 159 ---
1 file changed, 81 insertions(+), 78 deletions(-)
diff --git a/drivers/cr
Do use zero_entry value to init the descriptors ptrs to zero instead of
writing 0 in each field
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 85741
map_single_talitos_ptr() is always called with extent == 0, so lets remove this
unused parameter
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/tal
Hi Maxime,
On 17/04/2015 16:32, Maxime Ripard wrote:
> On Fri, Apr 17, 2015 at 04:19:22PM +0200, Boris Brezillon wrote:
>> Hi Gregory,
>>
>> On Fri, 17 Apr 2015 15:01:01 +0200
>> Gregory CLEMENT wrote:
>>
>>> Hi Boris,
>>>
>>> On 17/04/2015 10:39, Boris Brezillon wrote:
On Fri, 17 Apr 2015 1
This patch adds a helper function for reads and writes of the len
param of the talitos descriptor. This will help implement
SEC1 later.
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 24 +---
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/drive
On Fri, Apr 17, 2015 at 04:19:22PM +0200, Boris Brezillon wrote:
> Hi Gregory,
>
> On Fri, 17 Apr 2015 15:01:01 +0200
> Gregory CLEMENT wrote:
>
> > Hi Boris,
> >
> > On 17/04/2015 10:39, Boris Brezillon wrote:
> > > On Fri, 17 Apr 2015 10:33:56 +0200
> > > Boris Brezillon wrote:
> > >
> > >>
talitos descriptor is slightly different for SEC1 and SEC2+, so
lets the helper function that fills the descriptor take into account
the type of SEC.
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 105 ++-
1 file changed, 67 insertions(
The purpose of this set of patchs is to add to talitos crypto driver
the support for the SEC1 version of the security engine, which is
found in mpc885 and mpc8272 processors.
v3 is a complete rework of the patchset. Since a kernel can be built
with support for both MPC82xx and MPC83xx at the same
This patch adapts the interrupts handling and reset function for
SEC1. On SEC1, registers are almost similar to SEC2+, but bits
are sometimes located at different places. So we need to define
TALITOS1 and TALITOS2 versions of some fields, and manage according
to whether it is SEC1 or SEC2.
On SEC1
SEC1 descriptor is a bit different to SEC2+ descriptor.
talitos_submit() will have to copy hdr field into hdr1 field and
send the descriptor starting at hdr1 up to next_desc.
For SEC2, it remains unchanged and next_desc is just ignored.
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.
SEC1 bugs on 0 data hash, so we submit an already padded block representing 0
data
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index dddf4b3..f1406d
SEC1 bugs on 0 data hash, so we submit an already padded block representing 0
data
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index dddf4b3..f1406d
Oops, this is the first time I use directly the output of git
format-patch into sendmail, and
it looks like the mails are dated with the commit date, not today's date.
I will resend now with today's date. Sorry for the noise.
Christophe
Le 17/04/2015 15:47, Christophe Leroy a écrit :
The purp
We add a new feature in the features field, to mark compatible
"fsl,sec1.0"
We also define a helper function called has_ftr_sec1() to help
functions quickly determine if they are running on SEC1 or SEC2+.
When only SEC1 or SEC2 is compiled in, has_ftr_sec1() return
trivial corresponding value. If b
This patch adapts the interrupts handling and reset function for
SEC1. On SEC1, registers are almost similar to SEC2+, but bits
are sometimes located at different places. So we need to define
TALITOS1 and TALITOS2 versions of some fields, and manage according
to whether it is SEC1 or SEC2.
On SEC1
This patch adds a CONFIG option to select SEC1, SEC2+ or both.
Signed-off-by: Christophe Leroy
---
drivers/crypto/Kconfig | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 800bf41..8a76a01 100644
--- a/drivers/crypto/Kco
SEC1 doesn't support scatter/gather, SEC1 doesn't handle link tables.
Therefore, for SEC1 we have to do it by SW. For that, we reserve
space at the end of the extended descriptor, in lieu of the space
reserved for the link tables on SEC2, and we perform sg_copy() when
preparing the descriptors
We
talitos descriptor is slightly different for SEC1 and SEC2+, so
lets the helper function that fills the descriptor take into account
the type of SEC.
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 105 ++-
1 file changed, 67 insertions(
We add a specific compatible for SEC1, to handle the differences
between SEC1 and SEC2+
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index f1406d7b..c04074d 100644
--- a
SEC1 descriptor is a bit different to SEC2+ descriptor.
talitos_submit() will have to copy hdr field into hdr1 field and
send the descriptor starting at hdr1 up to next_desc.
For SEC2, it remains unchanged and next_desc is just ignored.
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.
This patch updates the documentation by including SEC1 into SEC2/3 doc
Signed-off-by: Christophe Leroy
---
Documentation/devicetree/bindings/crypto/fsl-sec2.txt | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec2.txt
b/Docu
This patch updates the documentation by including SEC1 into SEC2/3 doc
Signed-off-by: Christophe Leroy
---
Documentation/devicetree/bindings/crypto/fsl-sec2.txt | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec2.txt
b/Docu
We add a specific compatible for SEC1, to handle the differences
between SEC1 and SEC2+
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index f1406d7b..c04074d 100644
--- a
The purpose of this set of patchs is to add to talitos crypto driver
the support for the SEC1 version of the security engine, which is
found in mpc885 and mpc8272 processors.
v3 is a complete rework of the patchset. Since a kernel can be built
with support for both MPC82xx and MPC83xx at the same
SEC 1.0, 1.2 and 2.x+ have different EU base addresses, so we need to
define pointers for each EU in the driver private data structure.
The proper address is set by the probe function depending on the
SEC type, in order to provide access to the proper address.
Signed-off-by: Christophe Leroy
---
SEC1 doesn't support scatter/gather, SEC1 doesn't handle link tables.
Therefore, for SEC1 we have to do it by SW. For that, we reserve
space at the end of the extended descriptor, in lieu of the space
reserved for the link tables on SEC2, and we perform sg_copy() when
preparing the descriptors
We
This patch adds a CONFIG option to select SEC1, SEC2+ or both.
Signed-off-by: Christophe Leroy
---
drivers/crypto/Kconfig | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 800bf41..8a76a01 100644
--- a/drivers/crypto/Kco
We add a new feature in the features field, to mark compatible
"fsl,sec1.0"
We also define a helper function called has_ftr_sec1() to help
functions quickly determine if they are running on SEC1 or SEC2+.
When only SEC1 or SEC2 is compiled in, has_ftr_sec1() return
trivial corresponding value. If b
Hi Gregory,
On Fri, 17 Apr 2015 15:01:01 +0200
Gregory CLEMENT wrote:
> Hi Boris,
>
> On 17/04/2015 10:39, Boris Brezillon wrote:
> > On Fri, 17 Apr 2015 10:33:56 +0200
> > Boris Brezillon wrote:
> >
> >> Hi Jason,
> >>
> >> On Mon, 13 Apr 2015 20:11:46 +
> >> Jason Cooper wrote:
> >>
>
Am Freitag, 17. April 2015, 21:11:37 schrieb Herbert Xu:
Hi Herbert,
> On Fri, Apr 17, 2015 at 02:48:51PM +0200, Stephan Mueller wrote:
> > Do you really think that this is possible? If the DRBG becomes the stdrng,
> > you would imply that those callers (e.g. IPSEC) may suffer from a long
> > blo
On Fri, Apr 17, 2015 at 02:48:51PM +0200, Stephan Mueller wrote:
>
> Do you really think that this is possible? If the DRBG becomes the stdrng,
> you
> would imply that those callers (e.g. IPSEC) may suffer from a long block (and
> with long I mean not just seconds, but minutes).
It's only 49 b
Hi Boris,
On 17/04/2015 10:39, Boris Brezillon wrote:
> On Fri, 17 Apr 2015 10:33:56 +0200
> Boris Brezillon wrote:
>
>> Hi Jason,
>>
>> On Mon, 13 Apr 2015 20:11:46 +
>> Jason Cooper wrote:
>>
> I'd appreciate if we'd look into it. I understand from on-list and
> off-list dis
Hi,
the current implementation of the DRBG generates a shadow copy of its
DRBG state for each incoming request. The idea is that only a short
term lock is needed to spawn the shadow copy. The drawback is that
if multiple parallel requests come in, the generated DRBG shadow
states only differ by a
The creation of a shadow copy is intended to only hold a short term
lock. But the drawback is that parallel users have a very similar DRBG
state which only differs by a high-resolution time stamp.
As the locking is changed to use a long-term lock to avoid such similar
DRBG states, the entire creat
The buffer uses for temporary data must be cleared entirely. In AES192
the used buffer is drbg_statelen(drbg) + drbg_blocklen(drbg) as
documented in the comment above drbg_ctr_df.
This patch ensures that the temp buffer is completely wiped.
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 2 +
As the DRBG does not operate on shadow copies of the DRBG instance
any more, the cipher handles only need to be allocated once during
initalization time and deallocated during uninstantiate time.
Signed-off-by: Stephan Mueller
---
crypto/drbg.c | 12
1 file changed, 4 insertions(+),
The DRBG shall hold a long term lock. Therefore, the lock is changed to
a mutex which implies that the DRBG can only be used in process context.
The lock now guards the instantiation as well as the entire DRBG
generation operation. Therefore, multiple callers are fully serialized
when generating a
Am Freitag, 17. April 2015, 10:14:30 schrieb Herbert Xu:
Hi Herbert,
> On Fri, Apr 17, 2015 at 03:19:17AM +0200, Stephan Mueller wrote:
> > 1. during initialization of a DRBG instance, seed from get_random_bytes to
> > have a DRBG state that is seeded and usable.
>
> I think we either need to us
Hey Boris,
On Fri, Apr 17, 2015 at 10:39:46AM +0200, Boris Brezillon wrote:
> On Fri, 17 Apr 2015 10:33:56 +0200 Boris Brezillon
> wrote:
> > On Mon, 13 Apr 2015 20:11:46 + Jason Cooper
> > wrote:
> > > >
> > > > > I'd appreciate if we'd look into it. I understand from on-list and
> > >
On Fri, 17 Apr 2015 10:33:56 +0200
Boris Brezillon wrote:
> Hi Jason,
>
> On Mon, 13 Apr 2015 20:11:46 +
> Jason Cooper wrote:
>
> > >
> > > > I'd appreciate if we'd look into it. I understand from on-list and
> > > > off-list discussion that the rewrite was unavoidable. So I'm willing
Hi Jason,
On Mon, 13 Apr 2015 20:11:46 +
Jason Cooper wrote:
> >
> > > I'd appreciate if we'd look into it. I understand from on-list and
> > > off-list discussion that the rewrite was unavoidable. So I'm willing to
> > > concede that. Giving people time to migrate from old to new while
67 matches
Mail list logo
