* Re: [PATCH] crypto: qat - increase number of supported devices
From: Herbert Xu @ 2016-12-30 12:20 UTC (permalink / raw)
To: Giovanni Cabiddu; +Cc: linux-crypto, giovanni.cabiddu, Xin Zeng
In-Reply-To: <20161222150102.6376-1-giovanni.cabiddu@intel.com>
On Thu, Dec 22, 2016 at 03:01:02PM +0000, Giovanni Cabiddu wrote:
> From: Xin Zeng <xin.zeng@intel.com>
>
> The unsigned long type for init_status and start_status in
> service_hndl are not long enough to represent more than 64
> acceleration devices. Use an array instead.
>
> Signed-off-by: Xin Zeng <xin.zeng@intel.com>
> Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: qat - modify format of dev top level debugfs entries
From: Herbert Xu @ 2016-12-30 12:20 UTC (permalink / raw)
To: Giovanni Cabiddu; +Cc: linux-crypto, giovanni.cabiddu, Pablo Marcos Oltra
In-Reply-To: <20161222150034.6203-1-giovanni.cabiddu@intel.com>
On Thu, Dec 22, 2016 at 03:00:34PM +0000, Giovanni Cabiddu wrote:
> From: Pablo Marcos Oltra <pablo.marcos.oltra@intel.com>
>
> Remove leading zeros in pci function number to be consistent
> with output from lspci.
>
> Signed-off-by: Pablo Marcos Oltra <pablo.marcos.oltra@intel.com>
> Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: qat - zero esram only for DH85x devices
From: Herbert Xu @ 2016-12-30 12:20 UTC (permalink / raw)
To: Giovanni Cabiddu; +Cc: linux-crypto, giovanni.cabiddu
In-Reply-To: <20161222150024.6122-1-giovanni.cabiddu@intel.com>
On Thu, Dec 22, 2016 at 03:00:24PM +0000, Giovanni Cabiddu wrote:
> Zero embedded ram in DH85x devices. This is not
> needed for newer generations as it is done by HW.
>
> Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: qat - fix bar discovery for c62x
From: Herbert Xu @ 2016-12-30 12:19 UTC (permalink / raw)
To: Giovanni Cabiddu; +Cc: linux-crypto, giovanni.cabiddu
In-Reply-To: <20161222150012.6040-1-giovanni.cabiddu@intel.com>
On Thu, Dec 22, 2016 at 03:00:12PM +0000, Giovanni Cabiddu wrote:
> Some accelerators of the c62x series have only two bars.
> This patch skips BAR0 if the accelerator does not have it.
>
> Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: qat - replace hardcoded BIT(0) in vf_isr
From: Herbert Xu @ 2016-12-30 12:19 UTC (permalink / raw)
To: Giovanni Cabiddu; +Cc: linux-crypto, giovanni.cabiddu
In-Reply-To: <20161222145940.5952-1-giovanni.cabiddu@intel.com>
On Thu, Dec 22, 2016 at 02:59:40PM +0000, Giovanni Cabiddu wrote:
> Replace BIT(0) macro with proper definition in pf2vf path
>
> Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: qat - fix comments describing adf_disable_sriov()
From: Herbert Xu @ 2016-12-30 12:19 UTC (permalink / raw)
To: Giovanni Cabiddu; +Cc: linux-crypto, giovanni.cabiddu, Ahsan Atta
In-Reply-To: <20161222145924.5870-1-giovanni.cabiddu@intel.com>
On Thu, Dec 22, 2016 at 02:59:24PM +0000, Giovanni Cabiddu wrote:
> From: Ahsan Atta <ahsan.atta@intel.com>
>
> Signed-off-by: Ahsan Atta <ahsan.atta@intel.com>
> Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: qat - fix indentation
From: Herbert Xu @ 2016-12-30 12:18 UTC (permalink / raw)
To: Giovanni Cabiddu; +Cc: linux-crypto, giovanni.cabiddu, Ahsan Atta
In-Reply-To: <20161222145823.5782-1-giovanni.cabiddu@intel.com>
On Thu, Dec 22, 2016 at 02:58:23PM +0000, Giovanni Cabiddu wrote:
> From: Ahsan Atta <ahsan.atta@intel.com>
>
> Signed-off-by: Ahsan Atta <ahsan.atta@intel.com>
> Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: orinoco: Use shash instead of ahash for MIC calculations
From: Kalle Valo @ 2016-12-30 12:15 UTC (permalink / raw)
To: Andrew Lutomirski
Cc: linux-kernel, linux-usb, linux-wireless, Eric Biggers,
linux-crypto, Herbert Xu, Stephan Mueller
In-Reply-To: <87vau1k4ka.fsf@purkki.adurom.net>
Kalle Valo <kvalo@codeaurora.org> writes:
> Kalle Valo <kvalo@codeaurora.org> writes:
>
>> Andrew Lutomirski <luto@kernel.org> wrote:
>>> Eric Biggers pointed out that the orinoco driver pointed scatterlists
>>> at the stack.
>>>
>>> Fix it by switching from ahash to shash. The result should be
>>> simpler, faster, and more correct.
>>>
>>> Cc: stable@vger.kernel.org # 4.9 only
>>> Reported-by: Eric Biggers <ebiggers3@gmail.com>
>>> Signed-off-by: Andy Lutomirski <luto@kernel.org>
>>
>> 11 patches applied to wireless-drivers-next.git, thanks.
>>
>> 1fef293b8a98 orinoco: Use shash instead of ahash for MIC calculations
>> a08b98196a36 rt2800: make rx ampdu_factor depend on number of rx chains
>> e49abb19d1bf rt2800: don't set ht parameters for non-aggregated frames
>> a51b89698ccc rt2800: set minimum MPDU and PSDU lengths to sane values
>> 8f03a7c6e7f9 rt2800: set MAX_PSDU len according to remote STAs capabilities
>> 8845254112ac rt2800: rename adjust_freq_offset function
>> bc0077053948 rt2800: warn if doing VCO recalibration for unknow RF chip
>> 24d42ef3b152 rt2800: perform VCO recalibration for RF5592 chip
>> d96324703ffa rt2x00: merge agc and vco works with link tuner
>> eb79a8fe94c8 rt2800: replace mdelay by usleep on vco calibration.
>> 31369c323ba0 rt2800: replace msleep() with usleep_range() on channel switch
>
> Oh man, when I was applying rt2800 patches I did an off by one error
> with my patchwork script ('commit 2-12' vs 'commit 1-11') and
> accidentally applied this orinoco patch to wireless-drivers-next along
> with the 10 rt2800 patches above. And failed to spot that before pushing
> the tree :(
>
> As this orinoco patch is pretty important I'll cherry pick it manually
> to wireless-drivers also so that it goes to 4.10. This means that the
> patch is in both trees, but just with a different commit id.
This is the commit in wireless-drivers:
commit 570b90fa230b8021f51a67fab2245fe8df6fe37d
Author: Andrew Lutomirski <luto@kernel.org>
Date: Mon Dec 12 12:55:55 2016 -0800
orinoco: Use shash instead of ahash for MIC calculations
Eric Biggers pointed out that the orinoco driver pointed
scatterlists
at the stack.
Fix it by switching from ahash to shash. The result should be
simpler, faster, and more correct.
kvalo: cherry picked from commit
1fef293b8a9850cfa124a53c1d8878d355010403 as I
accidentally applied this patch to wireless-drivers-next when I was
supposed to
apply this wireless-drivers
Cc: stable@vger.kernel.org # 4.9 only
Reported-by: Eric Biggers <ebiggers3@gmail.com>
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
--
Kalle Valo
^ permalink raw reply
* Re: orinoco: Use shash instead of ahash for MIC calculations
From: Kalle Valo @ 2016-12-30 12:02 UTC (permalink / raw)
To: Andrew Lutomirski
Cc: linux-kernel, linux-usb, linux-wireless, Eric Biggers,
linux-crypto, Herbert Xu, Stephan Mueller
In-Reply-To: <20161230113451.C10ED614E4@smtp.codeaurora.org>
Kalle Valo <kvalo@codeaurora.org> writes:
> Andrew Lutomirski <luto@kernel.org> wrote:
>> Eric Biggers pointed out that the orinoco driver pointed scatterlists
>> at the stack.
>>
>> Fix it by switching from ahash to shash. The result should be
>> simpler, faster, and more correct.
>>
>> Cc: stable@vger.kernel.org # 4.9 only
>> Reported-by: Eric Biggers <ebiggers3@gmail.com>
>> Signed-off-by: Andy Lutomirski <luto@kernel.org>
>
> 11 patches applied to wireless-drivers-next.git, thanks.
>
> 1fef293b8a98 orinoco: Use shash instead of ahash for MIC calculations
> a08b98196a36 rt2800: make rx ampdu_factor depend on number of rx chains
> e49abb19d1bf rt2800: don't set ht parameters for non-aggregated frames
> a51b89698ccc rt2800: set minimum MPDU and PSDU lengths to sane values
> 8f03a7c6e7f9 rt2800: set MAX_PSDU len according to remote STAs capabilities
> 8845254112ac rt2800: rename adjust_freq_offset function
> bc0077053948 rt2800: warn if doing VCO recalibration for unknow RF chip
> 24d42ef3b152 rt2800: perform VCO recalibration for RF5592 chip
> d96324703ffa rt2x00: merge agc and vco works with link tuner
> eb79a8fe94c8 rt2800: replace mdelay by usleep on vco calibration.
> 31369c323ba0 rt2800: replace msleep() with usleep_range() on channel switch
Oh man, when I was applying rt2800 patches I did an off by one error
with my patchwork script ('commit 2-12' vs 'commit 1-11') and
accidentally applied this orinoco patch to wireless-drivers-next along
with the 10 rt2800 patches above. And failed to spot that before pushing
the tree :(
As this orinoco patch is pretty important I'll cherry pick it manually
to wireless-drivers also so that it goes to 4.10. This means that the
patch is in both trees, but just with a different commit id.
Sorry for the mess.
--
Kalle Valo
^ permalink raw reply
* Re: orinoco: Use shash instead of ahash for MIC calculations
From: Kalle Valo @ 2016-12-30 11:34 UTC (permalink / raw)
To: Andrew Lutomirski
Cc: linux-kernel, linux-usb, linux-wireless, Eric Biggers,
linux-crypto, Herbert Xu, Stephan Mueller, Andy Lutomirski
In-Reply-To: <8818c45b9ec6a04d85fabf9bb437cf119fd23659.1481575835.git.luto@kernel.org>
Andrew Lutomirski <luto@kernel.org> wrote:
> Eric Biggers pointed out that the orinoco driver pointed scatterlists
> at the stack.
>
> Fix it by switching from ahash to shash. The result should be
> simpler, faster, and more correct.
>
> Cc: stable@vger.kernel.org # 4.9 only
> Reported-by: Eric Biggers <ebiggers3@gmail.com>
> Signed-off-by: Andy Lutomirski <luto@kernel.org>
11 patches applied to wireless-drivers-next.git, thanks.
1fef293b8a98 orinoco: Use shash instead of ahash for MIC calculations
a08b98196a36 rt2800: make rx ampdu_factor depend on number of rx chains
e49abb19d1bf rt2800: don't set ht parameters for non-aggregated frames
a51b89698ccc rt2800: set minimum MPDU and PSDU lengths to sane values
8f03a7c6e7f9 rt2800: set MAX_PSDU len according to remote STAs capabilities
8845254112ac rt2800: rename adjust_freq_offset function
bc0077053948 rt2800: warn if doing VCO recalibration for unknow RF chip
24d42ef3b152 rt2800: perform VCO recalibration for RF5592 chip
d96324703ffa rt2x00: merge agc and vco works with link tuner
eb79a8fe94c8 rt2800: replace mdelay by usleep on vco calibration.
31369c323ba0 rt2800: replace msleep() with usleep_range() on channel switch
--
https://patchwork.kernel.org/patch/9471353/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: simd ciphers
From: Stephan Müller @ 2016-12-30 10:51 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto
In-Reply-To: <20161229094415.GA14453@gondor.apana.org.au>
Am Donnerstag, 29. Dezember 2016, 17:44:15 CET schrieb Herbert Xu:
Hi Herbert,
> On Wed, Dec 28, 2016 at 12:21:52PM +0100, Stephan Müller wrote:
> > This patch does not help. But I now found the issue: we need some Kconfig
> > wizardry to mandate pcbc to be compiled statically when AES-NI is static.
> > Currently I had pcbc always as a module even when selecting AES-NI as
> > static compilation.
>
> OK, please test this patch and see if it cures the problem with
> aesni built-in and pcbc built as a module.
This patch works -- PCBC can be compiled as a module whereas AES-NI is
compiled statically and yet AES-NI can be loaded.
Thanks.
Tested-by: Stephan Müller <smueller@chronox.de>
Ciao
Stephan
^ permalink raw reply
* Re: [RFC PATCH v2] crypto: Add IV generation algorithms
From: Herbert Xu @ 2016-12-30 10:27 UTC (permalink / raw)
To: Binoy Jayan
Cc: Milan Broz, Oded, Ofir, David S. Miller, linux-crypto, Mark Brown,
Arnd Bergmann, Linux kernel mailing list, Alasdair Kergon,
Mike Snitzer, dm-devel, Shaohua Li, linux-raid, Rajendra
In-Reply-To: <CAHv-k_9SynECq7qDbrW59=LsV_WNj+9Ffa=6tATyNKOt36he6Q@mail.gmail.com>
On Thu, Dec 29, 2016 at 02:53:25PM +0530, Binoy Jayan wrote:
>
> When we keep these in dm-crypt and if more than one key is used
> (it is actually more than one parts of the original key),
> there are more than one cipher instance created - one for each
> unique part of the key. Since the crypto requests are modelled
> to go through the template ciphers in the order:
>
> "essiv -> cbc -> aes"
>
> a particular cipher instance of the IV (essiv in this example) is
> responsible to encrypt an entire bigger block. If this bigger block
> is to be later split into 512 bytes blocks and then encrypted using
> the other cipher instance depending on the following formula:
>
> key_index = sector & (key_count - 1)
This is just a matter of structuring the key for the IV generator.
The IV generator's key in this case should be a combination of the
key to the underlying CBC plus the set of all keys for the IV
generator itself. It should then allocate the required number of
tfms as is currently done by crypt_alloc_tfms in dm-crypt.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Crypto Fixes for 4.10
From: Herbert Xu @ 2016-12-30 10:19 UTC (permalink / raw)
To: Linus Torvalds, David S. Miller, Linux Kernel Mailing List,
Linux Crypto Mailing List
In-Reply-To: <20161227094558.GA10491@gondor.apana.org.au>
Hi Linus:
This push fixes a boot failure on some platforms when crypto self
test is enabled along with the new acomp interface.
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus
Laura Abbott (1):
crypto: testmgr - Use heap buffer for acomp test input
crypto/testmgr.c | 30 ++++++++++++++++++++++++++++--
1 file changed, 28 insertions(+), 2 deletions(-)
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [RFC PATCH] crypto: skcipher - introduce walksize attribute for SIMD algos
From: Ard Biesheuvel @ 2016-12-29 14:09 UTC (permalink / raw)
To: linux-crypto; +Cc: herbert, Ard Biesheuvel
In some cases, SIMD algorithms can only perform optimally when
allowed to operate on multiple input blocks in parallel. This is
especially true for bit slicing algorithms, which typically take
the same amount of time processing a single block or 8 blocks in
parallel. However, other SIMD algorithms may benefit as well from
bigger strides.
So add a walksize attribute to the skcipher algorithm definition, and
wire it up to the skcipher walk API. To avoid confusion between the
skcipher and AEAD attributes, rename the skcipher_walk chunksize
attribute to 'stride', and set it from the walksize (in the skcipher
case) or from the chunksize (in the AEAD case).
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
crypto/skcipher.c | 20 +++++++-----
include/crypto/internal/skcipher.h | 2 +-
include/crypto/skcipher.h | 34 ++++++++++++++++++++
3 files changed, 47 insertions(+), 9 deletions(-)
diff --git a/crypto/skcipher.c b/crypto/skcipher.c
index aca07c643d41..7570d7c958e8 100644
--- a/crypto/skcipher.c
+++ b/crypto/skcipher.c
@@ -185,12 +185,12 @@ void skcipher_walk_complete(struct skcipher_walk *walk, int err)
data = p->data;
if (!data) {
data = PTR_ALIGN(&p->buffer[0], walk->alignmask + 1);
- data = skcipher_get_spot(data, walk->chunksize);
+ data = skcipher_get_spot(data, walk->stride);
}
scatterwalk_copychunks(data, &p->dst, p->len, 1);
- if (offset_in_page(p->data) + p->len + walk->chunksize >
+ if (offset_in_page(p->data) + p->len + walk->stride >
PAGE_SIZE)
free_page((unsigned long)p->data);
@@ -297,7 +297,7 @@ static int skcipher_next_copy(struct skcipher_walk *walk)
p->len = walk->nbytes;
skcipher_queue_write(walk, p);
- if (offset_in_page(walk->page) + walk->nbytes + walk->chunksize >
+ if (offset_in_page(walk->page) + walk->nbytes + walk->stride >
PAGE_SIZE)
walk->page = NULL;
else
@@ -342,7 +342,7 @@ static int skcipher_walk_next(struct skcipher_walk *walk)
SKCIPHER_WALK_DIFF);
n = walk->total;
- bsize = min(walk->chunksize, max(n, walk->blocksize));
+ bsize = min(walk->stride, max(n, walk->blocksize));
n = scatterwalk_clamp(&walk->in, n);
n = scatterwalk_clamp(&walk->out, n);
@@ -391,7 +391,7 @@ static int skcipher_copy_iv(struct skcipher_walk *walk)
unsigned a = crypto_tfm_ctx_alignment() - 1;
unsigned alignmask = walk->alignmask;
unsigned ivsize = walk->ivsize;
- unsigned bs = walk->chunksize;
+ unsigned bs = walk->stride;
unsigned aligned_bs;
unsigned size;
u8 *iv;
@@ -461,7 +461,7 @@ static int skcipher_walk_skcipher(struct skcipher_walk *walk,
SKCIPHER_WALK_SLEEP : 0;
walk->blocksize = crypto_skcipher_blocksize(tfm);
- walk->chunksize = crypto_skcipher_chunksize(tfm);
+ walk->stride = crypto_skcipher_walksize(tfm);
walk->ivsize = crypto_skcipher_ivsize(tfm);
walk->alignmask = crypto_skcipher_alignmask(tfm);
@@ -523,7 +523,7 @@ static int skcipher_walk_aead_common(struct skcipher_walk *walk,
walk->flags &= ~SKCIPHER_WALK_SLEEP;
walk->blocksize = crypto_aead_blocksize(tfm);
- walk->chunksize = crypto_aead_chunksize(tfm);
+ walk->stride = crypto_aead_chunksize(tfm);
walk->ivsize = crypto_aead_ivsize(tfm);
walk->alignmask = crypto_aead_alignmask(tfm);
@@ -819,6 +819,7 @@ static void crypto_skcipher_show(struct seq_file *m, struct crypto_alg *alg)
seq_printf(m, "max keysize : %u\n", skcipher->max_keysize);
seq_printf(m, "ivsize : %u\n", skcipher->ivsize);
seq_printf(m, "chunksize : %u\n", skcipher->chunksize);
+ seq_printf(m, "walksize : %u\n", skcipher->walksize);
}
#ifdef CONFIG_NET
@@ -891,11 +892,14 @@ static int skcipher_prepare_alg(struct skcipher_alg *alg)
{
struct crypto_alg *base = &alg->base;
- if (alg->ivsize > PAGE_SIZE / 8 || alg->chunksize > PAGE_SIZE / 8)
+ if (alg->ivsize > PAGE_SIZE / 8 || alg->chunksize > PAGE_SIZE / 8 ||
+ alg->walksize > PAGE_SIZE / 8)
return -EINVAL;
if (!alg->chunksize)
alg->chunksize = base->cra_blocksize;
+ if (!alg->walksize)
+ alg->walksize = alg->chunksize;
base->cra_type = &crypto_skcipher_type2;
base->cra_flags &= ~CRYPTO_ALG_TYPE_MASK;
diff --git a/include/crypto/internal/skcipher.h b/include/crypto/internal/skcipher.h
index 8735979ed341..e42f7063f245 100644
--- a/include/crypto/internal/skcipher.h
+++ b/include/crypto/internal/skcipher.h
@@ -66,7 +66,7 @@ struct skcipher_walk {
int flags;
unsigned int blocksize;
- unsigned int chunksize;
+ unsigned int stride;
unsigned int alignmask;
};
diff --git a/include/crypto/skcipher.h b/include/crypto/skcipher.h
index cc4d98a7892e..3c17a33255b0 100644
--- a/include/crypto/skcipher.h
+++ b/include/crypto/skcipher.h
@@ -115,6 +115,9 @@ struct crypto_skcipher {
* IV of exactly that size to perform the encrypt or decrypt operation.
* @chunksize: Equal to the block size except for stream ciphers such as
* CTR where it is set to the underlying block size.
+ * @walksize: Equal to the chunk size except in cases where the algorithm is
+ * considerably more efficient if it can operate on multiple chunks
+ * in parallel. Should be a multiple of chunksize.
* @base: Definition of a generic crypto algorithm.
*
* All fields except @ivsize are mandatory and must be filled.
@@ -131,6 +134,7 @@ struct skcipher_alg {
unsigned int max_keysize;
unsigned int ivsize;
unsigned int chunksize;
+ unsigned int walksize;
struct crypto_alg base;
};
@@ -289,6 +293,19 @@ static inline unsigned int crypto_skcipher_alg_chunksize(
return alg->chunksize;
}
+static inline unsigned int crypto_skcipher_alg_walksize(
+ struct skcipher_alg *alg)
+{
+ if ((alg->base.cra_flags & CRYPTO_ALG_TYPE_MASK) ==
+ CRYPTO_ALG_TYPE_BLKCIPHER)
+ return alg->base.cra_blocksize;
+
+ if (alg->base.cra_ablkcipher.encrypt)
+ return alg->base.cra_blocksize;
+
+ return alg->walksize;
+}
+
/**
* crypto_skcipher_chunksize() - obtain chunk size
* @tfm: cipher handle
@@ -307,6 +324,23 @@ static inline unsigned int crypto_skcipher_chunksize(
}
/**
+ * crypto_skcipher_walksize() - obtain walk size
+ * @tfm: cipher handle
+ *
+ * In some cases, algorithms can only perform optimally when operating on
+ * multiple blocks in parallel. This is reflected by the walksize, which
+ * must be a multiple of the chunksize (or equal if the concern does not
+ * apply)
+ *
+ * Return: walk size in bytes
+ */
+static inline unsigned int crypto_skcipher_walksize(
+ struct crypto_skcipher *tfm)
+{
+ return crypto_skcipher_alg_walksize(crypto_skcipher_alg(tfm));
+}
+
+/**
* crypto_skcipher_blocksize() - obtain block size of cipher
* @tfm: cipher handle
*
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] crypto: arm/aes-neonbs - process 8 blocks in parallel if we can
From: Ard Biesheuvel @ 2016-12-29 12:13 UTC (permalink / raw)
To: Herbert Xu
Cc: linux-crypto@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20161229022348.GA13402@gondor.apana.org.au>
On 29 December 2016 at 02:23, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Wed, Dec 28, 2016 at 07:50:44PM +0000, Ard Biesheuvel wrote:
>>
>> So about this chunksize, is it ever expected to assume other values
>> than 1 (for stream ciphers) or the block size (for block ciphers)?
>> Having block size, IV size *and* chunk size fields may be confusing to
>> some already, so if the purpose of chunk size can be fulfilled by a
>> single 'stream cipher' flag, perhaps we should change that first.
>
> For users (such as algif) it's much more convenient to have a size
> rather than a flag because that's what they need to determine the
> minimum size for partial updates.
>
> For implementors you don't need to specify the chunksize at all
> unless you're a stream cipher (or some other case in future where
> the minimum partial update size is not equal to your block size).
>
OK, fair enough. So I will add a field 'walksize' to the skcipher_alg
struct in my proposal. I think the walk logic itself needs to change
very little, though: we can simply set the walk's chunksize to the
skcipher's walksize if it exceeds its chunksize (and walksize %
chunksize should be 0 in any case, and walksize should default to the
chunksize if not supplied)
If this sounds reasonable to you, I will hack something up next week.
^ permalink raw reply
* Re: simd ciphers
From: Herbert Xu @ 2016-12-29 9:44 UTC (permalink / raw)
To: Stephan Müller; +Cc: linux-crypto
In-Reply-To: <2449210.sSYcIB5U3R@positron.chronox.de>
On Wed, Dec 28, 2016 at 12:21:52PM +0100, Stephan Müller wrote:
>
> This patch does not help. But I now found the issue: we need some Kconfig
> wizardry to mandate pcbc to be compiled statically when AES-NI is static.
> Currently I had pcbc always as a module even when selecting AES-NI as static
> compilation.
OK, please test this patch and see if it cures the problem with
aesni built-in and pcbc built as a module.
Thanks,
---8<---
Subject: crypto: aesni - Fix failure when built-in with modular pcbc
If aesni is built-in but pcbc is built as a module, then aesni
will fail completely because when it tries to register the pcbc
variant of aes the pcbc template is not available.
This patch fixes this by modifying the pcbc presence test so that
if aesni is built-in then pcbc must also be built-in for it to be
used by aesni.
Fixes: 85671860caac ("crypto: aesni - Convert to skcipher")
Reported-by: Stephan Müller <smueller@chronox.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/arch/x86/crypto/aesni-intel_glue.c b/arch/x86/crypto/aesni-intel_glue.c
index 36ca150..7ad0ed7 100644
--- a/arch/x86/crypto/aesni-intel_glue.c
+++ b/arch/x86/crypto/aesni-intel_glue.c
@@ -1024,7 +1024,8 @@ struct {
const char *basename;
struct simd_skcipher_alg *simd;
} aesni_simd_skciphers2[] = {
-#if IS_ENABLED(CONFIG_CRYPTO_PCBC)
+#if (defined(MODULE) && IS_ENABLED(CONFIG_CRYPTO_PCBC)) || \
+ IS_BUILTIN(CONFIG_CRYPTO_PCBC)
{
.algname = "pcbc(aes)",
.drvname = "pcbc-aes-aesni",
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* Re: [RFC PATCH v2] crypto: Add IV generation algorithms
From: Binoy Jayan @ 2016-12-29 9:23 UTC (permalink / raw)
To: Herbert Xu
Cc: Milan Broz, Oded, Ofir, David S. Miller, linux-crypto, Mark Brown,
Arnd Bergmann, Linux kernel mailing list, Alasdair Kergon,
Mike Snitzer, dm-devel, Shaohua Li, linux-raid, Rajendra
In-Reply-To: <20161223075114.GA3580@gondor.apana.org.au>
Hi Herbert,
Sorry for the delayed response, I was busy with testing dm-crypt
with bonnie++ for regressions. I tried to find some alternative
way to keep the IV algorithms' registration in the dm-crypt.
Also there were some changes done in dm-crypt keys structure too
recently.
c538f6e dm crypt: add ability to use keys from the kernel key retention service
On Thu, Dec 22, 2016 at 04:25:12PM +0530, Binoy Jayan wrote:
>
> > It doesn't have to live outside of dm-crypt. You can register
> > these IV generators from there if you really want.
>
> Sorry, but I didn't understand this part.
What I mean is that moving the IV generators into the crypto API
does not mean the dm-crypt team giving up control over them. You
could continue to keep them within the dm-crypt code base and
still register them through the normal crypto API mechanism
When we keep these in dm-crypt and if more than one key is used
(it is actually more than one parts of the original key),
there are more than one cipher instance created - one for each
unique part of the key. Since the crypto requests are modelled
to go through the template ciphers in the order:
"essiv -> cbc -> aes"
a particular cipher instance of the IV (essiv in this example) is
responsible to encrypt an entire bigger block. If this bigger block
is to be later split into 512 bytes blocks and then encrypted using
the other cipher instance depending on the following formula:
key_index = sector & (key_count - 1)
it is not possible as the cipher instances do not have access to
each other's instances. So, number of keys used is crucial while
performing encryption.
If there was only a single key, it should not have been a problem.
But if there are more than one key, then encrypting a bigger block
with a single key would cause backward incompatibility.
I was wondering if this is acceptable.
bigger block: What I mean by bigger block here is the set of 512-byte
blocks that dm-crypt can be optimized to process at once.
Thanks,
Binoy
^ permalink raw reply
* Re: [PATCH] crypto: arm/aes-neonbs - process 8 blocks in parallel if we can
From: Herbert Xu @ 2016-12-29 2:23 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: linux-crypto@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAKv+Gu__722s0JkpTzqDu7MmrzSMQ9jJQn=RYnxgSyV+P6MZRQ@mail.gmail.com>
On Wed, Dec 28, 2016 at 07:50:44PM +0000, Ard Biesheuvel wrote:
>
> So about this chunksize, is it ever expected to assume other values
> than 1 (for stream ciphers) or the block size (for block ciphers)?
> Having block size, IV size *and* chunk size fields may be confusing to
> some already, so if the purpose of chunk size can be fulfilled by a
> single 'stream cipher' flag, perhaps we should change that first.
For users (such as algif) it's much more convenient to have a size
rather than a flag because that's what they need to determine the
minimum size for partial updates.
For implementors you don't need to specify the chunksize at all
unless you're a stream cipher (or some other case in future where
the minimum partial update size is not equal to your block size).
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] crypto: arm/aes-neonbs - process 8 blocks in parallel if we can
From: Ard Biesheuvel @ 2016-12-28 19:50 UTC (permalink / raw)
To: Herbert Xu
Cc: linux-crypto@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20161228092328.GA12494@gondor.apana.org.au>
On 28 December 2016 at 09:23, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Wed, Dec 28, 2016 at 09:19:32AM +0000, Ard Biesheuvel wrote:
>>
>> Ok, so that implies a field in the skcipher algo struct then, rather than some definition internal to the driver?
>
> Oh yes it should definitely be visible to other crypto API drivers
> and algorithms. It's just that we don't want to export it outside
> of the crypto API, e.g., to IPsec or algif.
>
Understood.
So about this chunksize, is it ever expected to assume other values
than 1 (for stream ciphers) or the block size (for block ciphers)?
Having block size, IV size *and* chunk size fields may be confusing to
some already, so if the purpose of chunk size can be fulfilled by a
single 'stream cipher' flag, perhaps we should change that first.
^ permalink raw reply
* [ANNOUNCE] /dev/random - a new approach (code for 4.10-rc1)
From: Stephan Müller @ 2016-12-28 17:17 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-crypto
Hi,
The patch set that can be downloaded at [1] provides a different approach to /
dev/random which I call Linux Random Number Generator (LRNG) to collect
entropy within the Linux kernel. The main improvements compared to the legacy
/dev/random is to provide sufficient entropy during boot time as well as in
virtual environments and when using SSDs or Device Mapper targets. A secondary
design goal is to limit the impact of the entropy collection on massive
parallel systems and also allow the use accelerated cryptographic primitives.
Also, all steps of the entropic data processing are testable. Finally
performance improvements are visible at /dev/urandom and get_random_bytes.
The design and implementation is driven by a set of goals described in [2]
that the LRNG completely implements. Furthermore, [2] includes a
comparison with RNG design suggestions such as SP800-90B, SP800-90C, and
AIS20/31.
[1] http://www.chronox.de/lrng.html
[2] http://www.chronox.de/lrng/doc/lrng.pdf
Ciao
Stephan
^ permalink raw reply
* Re: simd ciphers
From: Stephan Müller @ 2016-12-28 11:21 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto
In-Reply-To: <20161228102826.GB12607@gondor.apana.org.au>
Am Mittwoch, 28. Dezember 2016, 18:28:26 CET schrieb Herbert Xu:
Hi Herbert,
> On Wed, Dec 28, 2016 at 11:00:51AM +0100, Stephan Müller wrote:
> > When I configure AES-NI as module, it works. When compiling it statically,
> > the allocation returns an -ENOENT.
> >
> > Now, when I diff both config files after a simple toggle from AES-NI=y to
> > =m I see (linux-4.10.config contains the static config, .config contains
> > the module
> > configuration):
> Thanks Stephan! Does this patch help?
This patch does not help. But I now found the issue: we need some Kconfig
wizardry to mandate pcbc to be compiled statically when AES-NI is static.
Currently I had pcbc always as a module even when selecting AES-NI as static
compilation.
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH] crypto: qat - initialize cra_flags before register into kpp
From: Herbert Xu @ 2016-12-28 10:12 UTC (permalink / raw)
To: Giovanni Cabiddu; +Cc: linux-crypto, giovanni.cabiddu, Sushil Kumar
In-Reply-To: <20161222150051.6284-1-giovanni.cabiddu@intel.com>
On Thu, Dec 22, 2016 at 03:00:51PM +0000, Giovanni Cabiddu wrote:
> Initialize dh.base.cra_flags before registering the dh algorithm.
> Without this fix, the registration of the dh algorithm might fail
> if the qat driver is restarted.
>
> Signed-off-by: Sushil Kumar <sushilx.kumar@intel.com>
> Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Please patch the crypto API instead. I think unsetting the bit
CRYPTO_ALG_DEAD at the top of crypto_register_alg should do the
trick.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: simd ciphers
From: Herbert Xu @ 2016-12-28 10:28 UTC (permalink / raw)
To: Stephan Müller; +Cc: linux-crypto
In-Reply-To: <3170771.4e7c0aHuJX@positron.chronox.de>
On Wed, Dec 28, 2016 at 11:00:51AM +0100, Stephan Müller wrote:
>
> When I configure AES-NI as module, it works. When compiling it statically, the
> allocation returns an -ENOENT.
>
> Now, when I diff both config files after a simple toggle from AES-NI=y to =m I
> see (linux-4.10.config contains the static config, .config contains the module
> configuration):
Thanks Stephan! Does this patch help?
---8<---
Subject: crypto: pcbc - Move pcbc registration up to subsys_initcall
The pcbc template is required by aesni. As aesni registers itself
at late_initcall, we have to make sure pcbc is registered before
that.
This patch moves it to subsys_initcall like cryptd.
Fixes: 85671860caac ("crypto: aesni - Convert to skcipher")
Reported-by: Stephan Müller <smueller@chronox.de>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/crypto/pcbc.c b/crypto/pcbc.c
index e4538e0..0855c61 100644
--- a/crypto/pcbc.c
+++ b/crypto/pcbc.c
@@ -307,7 +307,7 @@ static void __exit crypto_pcbc_module_exit(void)
crypto_unregister_template(&crypto_pcbc_tmpl);
}
-module_init(crypto_pcbc_module_init);
+subsys_initcall(crypto_pcbc_module_init);
module_exit(crypto_pcbc_module_exit);
MODULE_LICENSE("GPL");
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* Re: George's crazy full state idea (Re: HalfSipHash Acceptable Usage)
From: George Spelvin @ 2016-12-28 10:04 UTC (permalink / raw)
To: daniel, hannes, linux
Cc: ak, davem, David.Laight, ebiggers3, eric.dumazet, Jason,
kernel-hardening, linux-crypto, linux-kernel, luto, netdev, tom,
tytso, vegard.nossum
In-Reply-To: <1482902602.2234.1.camel@stressinduktion.org>
Hannes Frederic Sowa wrote:
> We call extract_crng when we run out of batched entropy and reseed. How
> often we call down to extract_crng depends on how much entropy we
> extracted by calls to get_random_int/long, so the number of calls into
> those functions matter.
>
> In extract_crng we have a timer which reseeds every 300s the CPRNG and
> either uses completely new entropy from the CRNG or calls down into the
> CPRNG while also doing backtracing protection (which feeds chacha's
> block size / 2 back into chacha, if I read the code correctly, thus
> 1024 bits, which should be enough).
In the current code, _extract_crng checks to see if more than 300 s
have elapsed since last time it was reseeded, and if so, reseeds with
fresh entropy.
In addition, on every read (or get_random_bytes), if the request leaves
enough ranfom bits in the last ChaCha block, it feeds back 256 bits
(the ChaCha block size is 16*32 = 512 bits) for anti-backtracking.
If the last read happened to not fit under that limit (size % 512 >
256), *and* there are no calls for RNG output for a long time, there is
no upper limit to how long the old ChaCha key can hang around.
> On Fri, 2016-12-23 at 20:17 -0500, George Spelvin wrote:
>> For example, two mix-backs of 64 bits gives you 65 bit security, not 128.
>> (Because each mixback can be guessed and verified separately.)
> Exactly, but the full reseed after running out of entropy is strong
> enough to not be defeated by your argumentation. Neither the reseed
> from the CRNG.
Yes, I was just reacting to your original statement:
>>>>> couldn't we simply use 8 bytes of the 64 byte
>>>>> return block to feed it directly back into the state chacha?
It's not the idea that's bad, just the proposed quantity.
>> If you want that, I have a pile of patches to prandom I really
>> should push upstream. Shall I refresh them and send them to you?
> I would like to have a look at them in the new year, certainly! I can
> also take care about the core prandom patches, but don't know if I have
> time to submit the others to the different subsystems.
>
> Maybe, if David would be okay with that, we can submit all patches
> through his tree, as he is also the dedicated maintainer for prandom.
Amazing, thank you very much! They're just minor cleanups, nothing
too exciting. I'll put it in the queue to make sure they're up to
date.
^ permalink raw reply
* Re: simd ciphers
From: Stephan Müller @ 2016-12-28 10:00 UTC (permalink / raw)
To: Herbert Xu; +Cc: linux-crypto
In-Reply-To: <20161228085938.GA11904@gondor.apana.org.au>
Am Mittwoch, 28. Dezember 2016, 16:59:38 CET schrieb Herbert Xu:
Hi Herbert,
> > With 4.10-rc1, I also do not get the AES-NI implementations to work. do
> > you
> > have any ideas what may be the issue?
>
> I'm having problems reproducing this. Does it work for you if you
> build them as modules?
When I configure AES-NI as module, it works. When compiling it statically, the
allocation returns an -ENOENT.
Now, when I diff both config files after a simple toggle from AES-NI=y to =m I
see (linux-4.10.config contains the static config, .config contains the module
configuration):
$ diff -urN ../linux-4.10.config .config
--- ../linux-4.10.config 2016-12-28 10:56:51.805526584 +0100
+++ .config 2016-12-28 11:00:17.959608195 +0100
@@ -4062,8 +4062,8 @@
CONFIG_CRYPTO_AUTHENC=m
CONFIG_CRYPTO_TEST=m
CONFIG_CRYPTO_ABLK_HELPER=m
-CONFIG_CRYPTO_SIMD=y
-CONFIG_CRYPTO_GLUE_HELPER_X86=y
+CONFIG_CRYPTO_SIMD=m
+CONFIG_CRYPTO_GLUE_HELPER_X86=m
#
# Authenticated Encryption with Associated Data
@@ -4132,7 +4132,7 @@
#
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_AES_X86_64=y
-CONFIG_CRYPTO_AES_NI_INTEL=y
+CONFIG_CRYPTO_AES_NI_INTEL=m
CONFIG_CRYPTO_ANUBIS=m
CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_BLOWFISH=m
Ciao
Stephan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox