Hi Colin,
I've already posted a similar patch:
https://patchwork.kernel.org/patch/10482283/
--Jan
On Sat, Jun 30, 2018 at 12:30:49PM +0100, Colin King wrote:
> From: Colin Ian King
>
> The functions zip_ctx_exit, zip_compress, zip_decompress and zip_ctx_init
> are local to the source and do no
On Sun, Jul 01, 2018 at 10:04:59AM -0700, Kees Cook wrote:
> On Sat, Jun 30, 2018 at 12:03 AM, Eric Biggers wrote:
> > On Thu, Jun 28, 2018 at 05:28:43PM -0700, Kees Cook wrote:
> >> @@ -88,11 +81,13 @@ static int shash_update_unaligned(struct shash_desc
> >> *desc, const u8 *data,
> >> uns
On Sat, Jun 30, 2018 at 12:03 AM, Eric Biggers wrote:
> On Thu, Jun 28, 2018 at 05:28:43PM -0700, Kees Cook wrote:
>> @@ -88,11 +81,13 @@ static int shash_update_unaligned(struct shash_desc
>> *desc, const u8 *data,
>> unsigned long alignmask = crypto_shash_alignmask(tfm);
>> unsigned
Hi Greg,
On Sun, Jul 01, 2018 at 11:47:19AM +0200, Greg Kroah-Hartman wrote:
> On Sun, Jul 01, 2018 at 05:16:11PM +0800, Herbert Xu wrote:
> > On Thu, Jun 21, 2018 at 07:12:47AM +0900, Juan Manuel Torres Palma wrote:
> > > On Wed, Jun 20, 2018 at 11:10:51AM -0700, Eric Biggers wrote:
> > > > Also,
On Sun, Jul 01, 2018 at 05:24:39PM +0200, Ondrej Mosnáček wrote:
>
> I can see you applied this patch to your cryptodev-2.6 tree (which I
> believe is for the next release). Shouldn't this go into the
> crypto-2.6 tree so it gets into 4.18-rcX? I'm not sure, but it seems
> to me that it qualifies a
ne 1. 7. 2018 o 15:20 Herbert Xu napísal(a):
>
> On Sat, Jun 23, 2018 at 12:36:22PM +0200, Borislav Petkov wrote:
> > Lemme send a proper patch now...
> >
> > ---
> > From: Borislav Petkov
> > Date: Sun, 17 Jun 2018 13:57:42 +0200
> > Subject: [PATCH] x86/crypto: Add missing RETs
> >
> > Add expl
On Sat, Jun 23, 2018 at 12:36:22PM +0200, Borislav Petkov wrote:
> Lemme send a proper patch now...
>
> ---
> From: Borislav Petkov
> Date: Sun, 17 Jun 2018 13:57:42 +0200
> Subject: [PATCH] x86/crypto: Add missing RETs
>
> Add explicit RETs to the tail calls of AEGIS and MORUS crypto algorithms
On Tue, Jun 19, 2018 at 11:23:57PM +0300, efre...@linux.com wrote:
> The function skcipher_walk_next declared as static and marked as
> EXPORT_SYMBOL_GPL. It's a bit confusing for internal function to be
> exported. The area of visibility for such function is its .c file
> and all other modules. Ot
On Tue, Jun 19, 2018 at 11:41:32AM -0400, Farhan Ali wrote:
> Hi,
>
> Currently the Linux virtio-crypto driver registers the crypto
> algorithm without verifying if the backend actually supports the
> algorithm.
>
> This kernel patch series adds support for registering algorithm
> with Linux cryp
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 01, 2018 at 05:16:11PM +0800, Herbert Xu wrote:
> On Thu, Jun 21, 2018 at 07:12:47AM +0900, Juan Manuel Torres Palma wrote:
> > On Wed, Jun 20, 2018 at 11:10:51AM -0700, Eric Biggers wrote:
> > > Also, can you describe the users of Skein in the kernel? If there are no
> > > users,
> >
On Thu, Jun 21, 2018 at 07:12:47AM +0900, Juan Manuel Torres Palma wrote:
> On Wed, Jun 20, 2018 at 11:10:51AM -0700, Eric Biggers wrote:
> > Also, can you describe the users of Skein in the kernel? If there are no
> > users,
> > there's no need to move it out of staging, or even have it in the k
The testmgr hash tests were testing init, digest, update and final
methods but not the finup method. Add a test for this one too.
While doing this, make sure we only run the partial tests once with
the digest tests and skip them with the final and finup tests since
they are the same.
Signed-off-b
The patch set fixes ccree IV handling, finup() operation (provided
by Hadar Gat) and CTS-AES mode of operation along a code cleanup.
Since our finup() method was
The ccree driver implemented NIST 800-38A CBC-CS2 ciphertext format,
which only reverses the last two blocks if the stolen ciphertext amount
are none zero. Move it to the kernel chosen format of CBC-CS3 which swaps
the final blocks unconditionally and rename it to "cts" now that it
complies with t
From: Hadar Gat
finup() operation was incorrect, padding was missing.
Fix by setting the ccree HW to enable padding.
Signed-off-by: Hadar Gat
[ gi...@benyossef.com: refactored for better code sharing ]
Signed-off-by: Gilad Ben-Yossef
Cc: sta...@vger.kernel.org
---
drivers/crypto/ccree/cc_hash
Remove legacy code no longer used by anything.
Signed-off-by: Gilad Ben-Yossef
---
drivers/crypto/ccree/cc_cipher.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/crypto/ccree/cc_cipher.c b/drivers/crypto/ccree/cc_cipher.c
index 958ced3..5d12372 100644
--- a/drivers/crypto/ccre
We were copying our last cipher block into the request for use as IV for
all modes of operations. Fix this by discerning the behaviour based on
the mode of operation used: copy ciphertext for CBC, update counter for
CTR.
CC: sta...@vger.kernel.org
Fixes: 63ee04c8b491 ("crypto: ccree - add skcipher
A debug print about register status post interrupt can happen
quite often. Rate limit it to avoid cluttering the log.
Signed-off-by: Gilad Ben-Yossef
Reported-by: Geert Uytterhoeven
---
drivers/crypto/ccree/cc_driver.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/driv
20 matches
Mail list logo
