Le 11/04/2021 à 02:31, Haren Myneni a écrit :
Using the same /dev/crypto/nx-gzip interface for both powerNV and
pseries. So this patcb moves VAS API to powerpc platform indepedent
directory. The actual functionality is not changed in this patch.
This patch seems to do a lot more than moving
Le 11/04/2021 à 02:27, Haren Myneni a écrit :
This patch series enables VAS / NX-GZIP on powerVM which allows
the user space to do copy/paste with the same existing interface
that is available on powerNV.
Can you explain (here and in patch 1 at least) what VAS and NX means ?
Is that Vector
Le 07/04/2021 à 19:05, Sean Christopherson a écrit :
On Wed, Apr 07, 2021, Borislav Petkov wrote:
First of all, I'd strongly suggest you trim your emails when you reply -
that would be much appreciated.
On Wed, Apr 07, 2021 at 07:24:54AM +0200, Christophe Leroy wrote:
@@ -258,7 +
Le 07/04/2021 à 00:49, Sean Christopherson a écrit :
Use the local stack to "allocate" the structures used to communicate with
the PSP. The largest struct used by KVM, sev_data_launch_secret, clocks
in at 52 bytes, well within the realm of reasonable stack usage. The
smallest structs are a m
Le 07/04/2021 à 00:49, Sean Christopherson a écrit :
Drop the dedicated init_cmd_buf and instead use a local variable. Now
that the low level helper uses an internal buffer for all commands,
using the stack for the upper layers is safe even when running with
CONFIG_VMAP_STACK=y.
Signed-off-b
Le 07/04/2021 à 00:49, Sean Christopherson a écrit :
For commands with small input/output buffers, use the local stack to
"allocate" the structures used to communicate with the PSP. Now that
__sev_do_cmd_locked() gracefully handles vmalloc'd buffers, there's no
reason to avoid using the stac
Le 03/04/2021 à 01:37, Sean Christopherson a écrit :
Copy vmalloc'd data to an internal buffer instead of rejecting outright
so that callers can put SEV command buffers on the stack without running
afoul of CONFIG_VMAP_STACK=y. Currently, the largest supported command
takes a 68 byte buffer,
Le 03/04/2021 à 01:36, Sean Christopherson a écrit :
Explicitly reject vmalloc'd data as the source for SEV commands that are
sent to the PSP. The PSP works with physical addresses, and __pa() will
not return the correct address for a vmalloc'd pionter, which at best
will cause the command to
Le 03/04/2021 à 01:37, Sean Christopherson a écrit :
Copy vmalloc'd data to an internal buffer instead of rejecting outright
so that callers can put SEV command buffers on the stack without running
afoul of CONFIG_VMAP_STACK=y. Currently, the largest supported command
takes a 68 byte buffer,
Le 03/04/2021 à 01:37, Sean Christopherson a écrit :
Copy vmalloc'd data to an internal buffer instead of rejecting outright
so that callers can put SEV command buffers on the stack without running
afoul of CONFIG_VMAP_STACK=y. Currently, the largest supported command
takes a 68 byte buffer,
Le 03/04/2021 à 01:36, Sean Christopherson a écrit :
WARN on and reject SEV commands that provide a valid data pointer, but do
not have a known, non-zero length. And conversely, reject commands that
take a command buffer but none is provided.
Aside from sanity checking intput, disallowing a
Le 02/04/2021 à 11:55, Meng Yu a écrit :
This function declaration has been added in 'ecc_curve.h',
delete it in 'crypto/ecc.h'.
Fixes: 14bb76768275(crypto: ecc - expose ecc curves)
Fixes tag is wrong I think, should be 4e6602916bc6
Signed-off-by: Meng Yu
---
crypto/ecc.h | 8
Le 01/04/2021 à 14:24, Chris von Recklinghausen a écrit :
Currently, suspend on x86_64 fails when FIPS mode is enabled because it uses md5
to generate a digest of the e820 region. MD5 is not FIPS compliant so an error
is reported and the suspend fails.
MD5 is used only to create a digest to e
Le 01/03/2021 à 11:30, Yang Li a écrit :
Rename kfree() to kfree_sensitive() to make the intention of the API
more explicit.
As far as I understand, you are not renaming kfree() to kfree_sensitive().
You are making a change to use kfree_sensitive() instead of using kfree().
Christophe
Le 21/01/2021 à 11:02, Ard Biesheuvel a écrit :
On Thu, 21 Jan 2021 at 10:54, Christophe Leroy
wrote:
Le 21/01/2021 à 08:31, Ard Biesheuvel a écrit :
On Thu, 21 Jan 2021 at 06:35, Christophe Leroy
wrote:
Le 20/01/2021 à 23:23, Ard Biesheuvel a écrit :
On Wed, 20 Jan 2021 at 19:59
Le 21/01/2021 à 08:31, Ard Biesheuvel a écrit :
On Thu, 21 Jan 2021 at 06:35, Christophe Leroy
wrote:
Le 20/01/2021 à 23:23, Ard Biesheuvel a écrit :
On Wed, 20 Jan 2021 at 19:59, Christophe Leroy
wrote:
Talitos Security Engine AESU considers any input
data size that is not a
Le 20/01/2021 à 23:23, Ard Biesheuvel a écrit :
On Wed, 20 Jan 2021 at 19:59, Christophe Leroy
wrote:
Talitos Security Engine AESU considers any input
data size that is not a multiple of 16 bytes to be an error.
This is not a problem in general, except for Counter mode
that is a stream
of 499 while all previous vectors which have a 16 bytes
multiple length succeed.
As suggested by Freescale, round up the input data length to the
nearest 16 bytes.
Fixes: 5e75ae1b3cef ("crypto: talitos - add new crypto modes")
Signed-off-by: Christophe Leroy
---
drivers/crypto/tali
t;).
However, the common nonsnoop descriptor works properly on SEC1 for
ctr(aes).
Add a second template for ctr(aes) that will be registered
only on SEC1.
Fixes: 70d355ccea89 ("crypto: talitos - fix ctr-aes-talitos")
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 22 +++
Le 07/10/2020 à 08:50, Herbert Xu a écrit :
On Sat, Oct 03, 2020 at 07:15:53PM +0200, Christophe Leroy wrote:
The following changes fix the sparse warnings with less churn:
Yes that works too. Can you please submit this patch?
This fixed two independant commits from the past. I sent
current_desc_hdr() returns a u32 but in fact this is a __be32,
leading to a lot of sparse warnings.
Change the return type to __be32 and ensure it is handled as
sure by the caller.
Fixes: 3e721aeb3df3 ("crypto: talitos - handle descriptor not found in error
path")
Signed-off-by:
before comparing it
with next_desc.
This fixes a sparse warning.
Fixes: 37b5e8897eb5 ("crypto: talitos - chain in buffered data for ahash on
SEC1")
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/driv
Quoting Herbert Xu :
On Fri, Oct 02, 2020 at 10:42:23PM +1000, Herbert Xu wrote:
I don't think that's a valid optimisation unless it's backed up
with real numbers.
Also it only matters on little-endian as they're no-ops on big-endian.
If I'm right then this driver never even worked on litt
[to Kim: Are you the initial writer of this driver, or is that someone else with your name working
at NXP ? ]
Le 02/10/2020 à 13:52, Herbert Xu a écrit :
The talitos driver has a large number of sparse warnings. It appears
to have only been tested on big-endian and where cpu_to_be32 is a
no-op
litos - fix ECB algs ivsize")
Signed-off-by: Su Kang Yin
Reviewed-by: Christophe Leroy
---
Patch for 4.9 upstream.
---
drivers/crypto/talitos.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 8b383d3d21c2..059c2d4a
Le 11/06/2020 à 13:03, Greg KH a écrit :
On Thu, Jun 11, 2020 at 12:50:24PM +0200, Christophe Leroy wrote:
Hi,
Le 11/06/2020 à 12:07, Su Kang Yin a écrit :
Patch for 4.9 upstream:
commit e1de42fdfc6a ("crypto: talitos - fix ECB algs ivsize")
wrongly modified CBC algs ivsize inst
Hi,
Le 11/06/2020 à 12:07, Su Kang Yin a écrit :
Patch for 4.9 upstream:
commit e1de42fdfc6a ("crypto: talitos - fix ECB algs ivsize")
wrongly modified CBC algs ivsize instead of ECB aggs ivsize.
To make it clear and avoid this problem to happen again, please generate
your patch with option
Le 01/05/2020 à 09:13, Eric Biggers a écrit :
From: Eric Biggers
The SHA-256 / SHA-224 library functions can't fail, so remove the
useless return value.
Also long as the declarations are being changed anyway, also fix some
parameter names in the declarations to match the definitions.
Signe
test robot
Signed-off-by: Gustavo A. R. Silva
Reviewed-by: Christophe Leroy
---
drivers/crypto/talitos.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index c9d686a0e805..4818ae427098 100644
--- a/drivers/crypto/talitos.c
+++ b/driv
When VMAP_STACK is selected, stack cannot be DMA-mapped.
Therefore, the hash result has to be DMA-mapped in the request
context and copied into areq->result at completion.
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 6 +-
1 file changed, 5 insertions(+), 1 delet
Hi Eric,
Le 01/02/2019 à 08:51, Eric Biggers a écrit :
From: Eric Biggers
Convert alg_test_hash() to use the new test framework, adding a list of
testvec_configs to test by default. When the extra self-tests are
enabled, randomly generated testvec_configs are tested as well.
This improves h
Hi Mukul
Le 24/08/2019 à 18:40, Mukul Joshi a écrit :
Hi Christophe,
[...]
I am working with MPC8360E SoC and trying to setup IPSEC tunnel between
2 hosts.
I am able to setup the tunnel but I am seeing issues with packet
decryption. The sender side doesn't seem to have a problem and the
Le 05/08/2019 à 19:00, Ard Biesheuvel a écrit :
Signed-off-by: Ard Biesheuvel
Reviewed-by: Christophe Leroy
---
drivers/crypto/talitos.c | 34
1 file changed, 7 insertions(+), 27 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index
Hi Herbert,
Le 24/06/2019 à 09:21, Christophe Leroy a écrit :
This series is the last set of fixes for the Talitos driver.
Do you plan to apply this series, or are you expecting anythink from
myself ?
Thanks
Christophe
We now get a fully clean boot on both SEC1 (SEC1.2 on mpc885) and
pto: talitos - chain in buffered data for ahash on
SEC1")
Cc: sta...@vger.kernel.org
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 69
1 file changed, 41 insertions(+), 28 deletions(-)
diff --git a/drivers/crypto/
icv_ool is not used anymore, drop it.
Fixes: e345177ded17 ("crypto: talitos - fix AEAD processing.")
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 3 ---
drivers/crypto/talitos.h | 2 --
2 files changed, 5 deletions(-)
diff --git a/drivers/crypto/talitos.c b/driv
Moves struct talitos_edesc into talitos.h so that it can be used
from any place in talitos.c
It will be required for next patch ("crypto: talitos - fix hash
on SEC1")
Signed-off-by: Christophe Leroy
Cc: sta...@vger.kernel.org
---
drivers/crypto/tali
son is
that the data will be outside the kmapped area used to access that
data.
This patch fixes the issue by adjusting the mapping iterator
offset and pgoffset fields such that offset is always lower than
PAGE_SIZE.
Signed-off-by: Christophe Leroy
Fixes: 4225fc8555a9 ("lib/scatterlist: use pa
- taken the patch "crypto: talitos - eliminate unneeded 'done' functions at
build time"
out of the series because it is independent.
- added a helper to find the header field associated to a request in
flush_channe()
v5:
- Replacing the while loop by a direct shif
pto: talitos - chain in buffered data for ahash on
SEC1")
Cc: sta...@vger.kernel.org
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 69
1 file changed, 41 insertions(+), 28 deletions(-)
diff --git a/drivers/crypto/
icv_ool is not used anymore, drop it.
Fixes: e345177ded17 ("crypto: talitos - fix AEAD processing.")
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 3 ---
drivers/crypto/talitos.h | 2 --
2 files changed, 5 deletions(-)
diff --git a/drivers/crypto/talitos.c b/driv
Moves struct talitos_edesc into talitos.h so that it can be used
from any place in talitos.c
It will be required for next patch ("crypto: talitos - fix hash
on SEC1")
Signed-off-by: Christophe Leroy
Cc: sta...@vger.kernel.org
---
drivers/crypto/tali
When building for SEC1 only, talitos2_done functions are unneeded
and should go away.
For this, use has_ftr_sec1() which will always return true when only
SEC1 support is being built, allowing GCC to drop TALITOS2 functions.
Signed-off-by: Christophe Leroy
Reviewed-by: Horia Geantă
---
taken
- taken the patch "crypto: talitos - eliminate unneeded 'done' functions at
build time"
out of the series because it is independent.
- added a helper to find the header field associated to a request in
flush_channe()
Christophe Leroy (4):
lib/scatterlist: Fix mapping ite
son is
that the data will be outside the kmapped area used to access that
data.
This patch fixes the issue by adjusting the mapping iterator
offset and pgoffset fields such that offset is always lower than
PAGE_SIZE.
Signed-off-by: Christophe Leroy
Fixes: 4225fc8555a9 ("lib/scatterlist: use pa
Le 15/06/2019 à 10:18, Christophe Leroy a écrit :
@@ -2058,7 +2065,18 @@ static int ahash_process_req(struct
ahash_request *areq, unsigned int nbytes)
sg_copy_to_buffer(areq->src, nents,
ctx_buf + req_ctx->nbuf, offset);
req_ctx->nbuf
Le 14/06/2019 à 13:32, Horia Geanta a écrit :
On 6/13/2019 3:48 PM, Christophe Leroy wrote:
@@ -336,15 +336,18 @@ static void flush_channel(struct device *dev, int ch, int
error, int reset_ch)
tail = priv->chan[ch].tail;
while (priv->chan[ch].fifo[tail
Le 13/06/2019 à 21:07, Horia Geanta a écrit :
On 6/13/2019 3:48 PM, Christophe Leroy wrote:
On SEC1, hash provides wrong result when performing hashing in several
steps with input data SG list has more than one element. This was
detected with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS:
[ 44.185947
Le 12/06/2019 à 15:59, Horia Geanta a écrit :
On 6/12/2019 8:52 AM, Christophe Leroy wrote:
Le 11/06/2019 à 18:30, Horia Geanta a écrit :
On 6/11/2019 6:40 PM, Christophe Leroy wrote:
Le 11/06/2019 à 17:37, Horia Geanta a écrit :
On 6/11/2019 5:39 PM, Christophe Leroy wrote:
This
Le 13/06/2019 à 14:13, Horia Geanta a écrit :
On 6/11/2019 5:39 PM, Christophe Leroy wrote:
Next patch will require struct talitos_edesc to be defined
earlier in talitos.c
This patch moves it into talitos.h so that it can be used
from any place in talitos.c
Fixes: 37b5e8897eb5 ("c
Le 13/06/2019 à 14:24, Horia Geanta a écrit :
On 6/13/2019 3:16 PM, Christophe Leroy wrote:
Le 13/06/2019 à 14:13, Horia Geanta a écrit :
On 6/11/2019 5:39 PM, Christophe Leroy wrote:
Next patch will require struct talitos_edesc to be defined
earlier in talitos.c
This patch moves it
Le 13/06/2019 à 14:21, Horia Geanta a écrit :
On 6/11/2019 5:39 PM, Christophe Leroy wrote:
icv_ool is not used anymore, drop it.
Fixes: 9cc87bc3613b ("crypto: talitos - fix AEAD processing")
I can't find this SHA1.
Are you referring to commit e345177ded17 ("crypto
3.crypto'
v2: dropped patch 1 which was irrelevant due to a rebase weirdness. Added Cc to
stable on the 2 first patches.
v3:
- removed stable reference in patch 1
- reworded patch 1 to include name of patch 2 for the dependency.
- mentionned this dependency in patch 2 as well.
icv_ool is not used anymore, drop it.
Fixes: e345177ded17 ("crypto: talitos - fix AEAD processing.")
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 3 ---
drivers/crypto/talitos.h | 2 --
2 files changed, 5 deletions(-)
diff --git a/drivers/crypto/talitos.c b/driv
t;crypto: talitos - move struct talitos_edesc into
talitos.h") as required for this change to build properly.
Fixes: 37b5e8897eb5 ("crypto: talitos - chain in buffered data for ahash on
SEC1")
Cc: sta...@vger.kernel.org
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 63
Moves it into talitos.h so that it can be used
from any place in talitos.c
This will be required for next
patch ("crypto: talitos - fix hash on SEC1")
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 30 --
drivers/crypto/tali
When building for SEC1 only, talitos2_done functions are unneeded
and should go away.
For this, use has_ftr_sec1() which will always return true when only
SEC1 support is being built, allowing GCC to drop TALITOS2 functions.
Signed-off-by: Christophe Leroy
Reviewed-by: Horia Geantă
Le 13/06/2019 à 14:39, Horia Geanta a écrit :
On 6/13/2019 3:32 PM, Christophe Leroy wrote:
Le 13/06/2019 à 14:24, Horia Geanta a écrit :
On 6/13/2019 3:16 PM, Christophe Leroy wrote:
Le 13/06/2019 à 14:13, Horia Geanta a écrit :
On 6/11/2019 5:39 PM, Christophe Leroy wrote:
Next
Le 13/06/2019 à 14:48, Christophe Leroy a écrit :
Moves it into talitos.h so that it can be used
from any place in talitos.c
This will be required for next
patch ("crypto: talitos - fix hash on SEC1")
Signed-off-by: Christophe Leroy
Cc: sta...@vger.kernel.org
---
driv
Le 11/06/2019 à 18:30, Horia Geanta a écrit :
On 6/11/2019 6:40 PM, Christophe Leroy wrote:
Le 11/06/2019 à 17:37, Horia Geanta a écrit :
On 6/11/2019 5:39 PM, Christophe Leroy wrote:
This series is the last set of fixes for the Talitos driver.
We now get a fully clean boot on both SEC1
Below commit came with a typo in the CONFIG_ symbol, leading
to a permanently reduced max key size regarless of the driver
capabilities.
Reported-by: Horia Geantă
Fixes: b8fbdc2bc4e7 ("crypto: talitos - reduce max key size for SEC1")
Signed-off-by: Christophe Leroy
---
drivers/crypto
Le 11/06/2019 à 18:30, Horia Geanta a écrit :
On 6/11/2019 6:40 PM, Christophe Leroy wrote:
Le 11/06/2019 à 17:37, Horia Geanta a écrit :
On 6/11/2019 5:39 PM, Christophe Leroy wrote:
This series is the last set of fixes for the Talitos driver.
We now get a fully clean boot on both SEC1
Le 11/06/2019 à 17:37, Horia Geanta a écrit :
On 6/11/2019 5:39 PM, Christophe Leroy wrote:
This series is the last set of fixes for the Talitos driver.
We now get a fully clean boot on both SEC1 (SEC1.2 on mpc885) and
SEC2 (SEC2.2 on mpc8321E) with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS:
I am
8897eb5 ("crypto: talitos - chain in buffered data for ahash on
SEC1")
Cc: sta...@vger.kernel.org
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 63 ++--
1 file changed, 40 insertions(+), 23 deletions(-)
diff --git a/dr
ned-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 30 --
drivers/crypto/talitos.h | 30 ++
2 files changed, 30 insertions(+), 30 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 3b3e99f1cddb..5b401aec6
icv_ool is not used anymore, drop it.
Fixes: 9cc87bc3613b ("crypto: talitos - fix AEAD processing")
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 3 ---
drivers/crypto/talitos.h | 2 --
2 files changed, 5 deletions(-)
diff --git a/drivers/crypto/talitos.c b/driv
When building for SEC1 only, talitos2_done functions are unneeded
and should go away.
For this, use has_ftr_sec1() which will always return true when only
SEC1 support is being built, allowing GCC to drop TALITOS2 functions.
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 2
3.crypto'
v2: dropped patch 1 which was irrelevant due to a rebase weirdness. Added Cc to
stable on the 2 first patches.
Christophe Leroy (4):
crypto: talitos - move struct talitos_edesc into talitos.h
crypto: talitos - fix hash on SEC1.
crypto: talitos - eliminate unneeded &#x
Le 11/06/2019 à 13:52, Horia Geanta a écrit :
On 6/6/2019 2:31 PM, Christophe Leroy wrote:
commit d84cc9c9524e ("crypto: talitos - fix ECB algs ivsize")
wrongly modified CBC algs ivsize instead of ECB aggs ivsize.
This restore the CBC algs original ivsize of removes ECB's on
Le 11/06/2019 à 13:57, Horia Geanta a écrit :
On 6/6/2019 2:31 PM, Christophe Leroy wrote:
Next patch will require struct talitos_edesc to be defined
earlier in talitos.c
This patch moves it into talitos.h so that it can be used
from any place in talitos.c
Fixes: 37b5e8897eb5 ("c
Le 06/06/2019 à 19:28, Fabio Estevam a écrit :
Use devm_platform_ioremap_resource() to simplify the code a bit.
While at it, remove unneeded error message in case of
devm_platform_ioremap_resource() failure, as the core mm code
will take care of it.
devm_platform_ioremap_resource() doesn't
icv_ool is not used anymore, drop it.
Fixes: 9cc87bc3613b ("crypto: talitos - fix AEAD processing")
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 3 ---
drivers/crypto/talitos.h | 2 --
2 files changed, 5 deletions(-)
diff --git a/drivers/crypto/talitos.c b/driv
8897eb5 ("crypto: talitos - chain in buffered data for ahash on
SEC1")
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 63 ++--
1 file changed, 40 insertions(+), 23 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/c
Next patch will require struct talitos_edesc to be defined
earlier in talitos.c
This patch moves it into talitos.h so that it can be used
from any place in talitos.c
Fixes: 37b5e8897eb5 ("crypto: talitos - chain in buffered data for ahash on
SEC1")
Signed-off-by: Christophe Leroy
--
When building for SEC1 only, talitos2_done functions are unneeded
and should go away.
For this, use has_ftr_sec1() which will always return true when only
SEC1 support is being built, allowing GCC to drop TALITOS2 functions.
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 2
commit d84cc9c9524e ("crypto: talitos - fix ECB algs ivsize")
wrongly modified CBC algs ivsize instead of ECB aggs ivsize.
This restore the CBC algs original ivsize of removes ECB's ones.
Signed-off-by: Christophe Leroy
Fixes: d84cc9c9524e ("crypto: talitos - fix ECB algs i
] alg: No test for authenc(hmac(md5),cbc(des3_ede))
(authenc-hmac-md5-cbc-3des-talitos-hsna)
[6.631781] random: crng init done
[ 11.521795] talitos b003.crypto: fsl,sec2.2 algorithms registered in
/proc/crypto
[ 11.529803] driver: 'talitos': driver_bound: bound to device
'b0
Le 30/05/2019 à 19:50, Eric Biggers a écrit :
From: Eric Biggers
Changing ghash_mod_init() to be subsys_initcall made it start running
before the alignment fault handler has been installed on ARM. In kernel
builds where the keys in the ghash test vectors happened to be
misaligned in the ker
Le 30/05/2019 à 12:16, Pascal Van Leeuwen a écrit :
Yes. Code and data with static linkage will just be optimized away by
the compiler if the CONFIG_xx option is not enabled, so all you need
to guard are the actual statements, function calls etc.
Ok, makes sense. Then I'll just config out th
Pascal Van Leeuwen a écrit :
> Quick question regarding how to configure out code depending on a
CONFIG_xxx
> switch. As far as I understood so far, the proper way to do this is
not by
> doing an #ifdef but by using a regular if with IS_ENABLED like so:
>
> if (IS_ENABLED(CONFIG_PCI)) {
> }
>
>
Horia Geanta a écrit :
On 5/21/2019 4:34 PM, Christophe Leroy wrote:
Several test failures have popped up following recent changes to crypto
selftests.
This series fixes (most of) them.
The last three patches are trivial cleanups.
Thanks Christophe.
For the series:
Reviewed-by: Horia
Le 24/05/2019 à 12:43, Kamil Konieczny a écrit :
On 24.05.2019 12:13, Pascal Van Leeuwen wrote:
True. Those are the "other" reasons - besides acceleration - to use hardware
offload which we often use to sell our IP.
But the honest story there is that that only works out for situations
where t
Le 24/05/2019 à 10:44, Pascal Van Leeuwen a écrit :
Valid? A totally fabricated case, if you ask me. Yes, you could do that,
but is it *useful* at all? Really?
No, it's not because a file of length 0 is a file of length 0, the length
in itself is sufficient guarantee of its contents. The hash
Hi Pascal,
Le 23/05/2019 à 23:43, Pascal Van Leeuwen a écrit :
-Original Message-
From: Eric Biggers [mailto:ebigg...@kernel.org]
[...]
Note that it's not necessary that your *hardware* supports empty messages,
since you can simply do this in the driver instead:
if (req->cryp
Hi Joe & Andy
On 05/21/2019 01:34 PM, Christophe Leroy wrote:
The talitos driver has two ways to perform AEAD depending on the
HW capability. Some HW support both. It is needed to give them
different names to distingish which one it is for instance when
a test fails.
Signed-off-by: Christ
Hello,
With the new selftests I get the following failures with Talitos on SEC1
(mpc885).
I don't get those failures with Talitos on SEC2 (mpc8321E), but the
driver is slightly different for SEC1 as it doesn't support S/G operations.
How can I identify what problem to look for based on the
For decrypt, req->cryptlen includes the size of the authentication
part while all functions of the driver expect cryptlen to be
the size of the encrypted data.
As it is not expected to change req->cryptlen, this patch
implements local calculation of cryptlen.
Signed-off-by: Christophe
for SEC1.
Signed-off-by: Christophe Leroy
Fixes: 9c4a79653b35 ("crypto: talitos - Freescale integrated security engine
(SEC) driver")
---
drivers/crypto/talitos.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talit
Although the HW accepts any size and silently truncates
it to the correct length, the extra tests expects EINVAL
to be returned when the key size is not valid.
Signed-off-by: Christophe Leroy
Fixes: 4de9d0b547b9 ("crypto: talitos - Add ablkcipher algorithms")
---
drivers/crypto/tali
x27;out of line' ICV
- Never using 'out of line' ICV on encryp
- Always using 'out of line' ICV on decrypt
- Forcing the generation of a SG table on decrypt
Signed-off-by: Christophe Leroy
Fixes: aeb4c132f33d ("crypto: talitos - Convert to new AEAD in
There is no other file using talitos_submit in the kernel tree,
so it doesn't need to be exported nor made global.
This reverts commit 865d506155b117edc7e668ced373030ce7108ce9.
Signed-off-by: Christophe Leroy
Fixes: 865d506155b1 ("crypto: talitos - export the talitos_submi
In that mode, hardware ICV verification is not supported.
Signed-off-by: Christophe Leroy
Fixes: 7405c8d7ff97 ("crypto: talitos - templates for AEAD using
HMAC_SNOOP_NO_AFEU")
---
drivers/crypto/talitos.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/driv
This patch rewrites has_ftr_sec1() using IS_ENABLED()
instead of #ifdefs
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.h | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/crypto/talitos.h b/drivers/crypto/talitos.h
index 95e97951b924
CTR has a blocksize of 1.
Signed-off-by: Christophe Leroy
Fixes: 5e75ae1b3cef ("crypto: talitos - add new crypto modes")
---
drivers/crypto/talitos.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 95
The talitos driver has two ways to perform AEAD depending on the
HW capability. Some HW support both. It is needed to give them
different names to distingish which one it is for instance when
a test fails.
Signed-off-by: Christophe Leroy
Fixes: 7405c8d7ff97 ("crypto: talitos - templates for
42
This above dumps show that the actual output IV is indeed the input IV.
This is due to the IV not being copied back into the request.
This patch fixes that.
Signed-off-by: Christophe Leroy
Fixes: 4de9d0b547b9 ("crypto: talitos - Add ablkcipher algorithms")
Cc: sta...@vger.kernel.org
ngine.
Signed-off-by: Christophe Leroy
Fixes: 4de9d0b547b9 ("crypto: talitos - Add ablkcipher algorithms")
---
drivers/crypto/talitos.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index 8b9a529f1b66..1e5410f921
This patch drops the license text and replaces it
with an SPDX-License-Identifier tag.
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 15 +--
drivers/crypto/talitos.h | 25 +
2 files changed, 2 insertions(+), 38 deletions(-)
diff --git a
(SEC) driver")
Signed-off-by: Christophe Leroy
---
drivers/crypto/talitos.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
index e35581d67315..7c8a3a717b91 100644
--- a/drivers/crypto/talit
SEC1 doesn't support SHA384/512, so it doesn't require
longer keys.
This patch reduces the max key size when the driver
is built for SEC1 only.
Signed-off-by: Christophe Leroy
Fixes: 03d2c5114c95 ("crypto: talitos - Extend max key length for
SHA384/512-HMAC and AEAD")
1 - 100 of 289 matches
Mail list logo
