Re: [PATCH v1 1/6] efi: Switch to use new generic UUID API

On 26 July 2017 at 08:52, Christoph Hellwig wrote: > On Tue, Jul 25, 2017 at 01:40:06PM +0300, Andy Shevchenko wrote: >> Christoph, can we apply this one at least to move things forward? > > Id be happy to pick this up for 4.14. Does everyone involved agree > that the uuid tree is

Re: [PATCH v1 1/6] efi: Switch to use new generic UUID API

> Cc: Matt Fleming <m...@codeblueprint.co.uk> > Cc: Ard Biesheuvel <ard.biesheu...@linaro.org> > Signed-off-by: Andy Shevchenko <andriy.shevche...@linux.intel.com> Acked-by: Ard Biesheuvel <ard.biesheu...@linaro.org> > --- > drivers/firmwa

[PATCH v2 1/2] crypto/algapi - use separate dst and src operands for __crypto_xor()

In preparation of introducing crypto_xor_cpy(), which will use separate operands for input and output, modify the __crypto_xor() implementation, which it will share with the existing crypto_xor(), which provides the actual functionality when not using the inline version. Signed-off-by: Ard

[PATCH v2 0/2] crypto/algapi - refactor crypto_xor() to avoid memcpy()s

rrences of crypto_xor() involving a memcpy() to use a new API function crypto_xor_cpy() which combines the two operations. v2: - keep existing crypto_xor() as-is, and add crypto_xor_cpy() for the cases where a redundant memcpy() can be eliminated. Ard Biesheuvel (2): crypto/algapi -

[PATCH v2 2/2] crypto/algapi - make crypto_xor() take separate dst and src arguments

called crypto_xor_cpy(), taking separate input and output arguments. This removes the need for the separate memcpy(). Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- arch/arm/crypto/aes-ce-glue.c | 4 +--- arch/arm/crypto/aes-neonbs-glue.c | 5 ++--- arch/arm64/cryp

Re: [PATCH 2/2] crypto/algapi - make crypto_xor() take separate dst and src arguments

On 18 July 2017 at 09:39, Herbert Xu <herb...@gondor.apana.org.au> wrote: > On Mon, Jul 10, 2017 at 02:45:48PM +0100, Ard Biesheuvel wrote: >> There are quite a number of occurrences in the kernel of the pattern >> >> if (dst != src) >> memcpy(dst,

[PATCH 0/2] crypto/algapi - refactor crypto_xor() to avoid memcpy()s

ccurrences of crypto_xor() to use a separate output argument. Ard Biesheuvel (2): crypto/algapi - use separate dst and src operands for __crypto_xor() crypto/algapi - make crypto_xor() take separate dst and src arguments arch/arm/crypto/aes-ce-glue.c | 4 +--- arch/arm/crypto/aes-neonbs-

Re: [PATCH v3 1/2] mac80211: fils_aead: Use crypto api CMAC shash rather than bare cipher

On 8 February 2017 at 07:00, Johannes Berg wrote: > This looks strange to me: > >> +static int aes_s2v(struct crypto_shash *tfm, >> size_t num_elem, const u8 *addr[], size_t len[], >> u8 *v) >> { >> - u8 d[AES_BLOCK_SIZE], tmp[AES_BLOCK_SIZE]; >> +

[PATCH v3 0/2] mac80211: use crypto shash for AES cmac

- replace compound literal zero vectors with explicitly defined ones - drop a redundant memcpy() in #2 Ard Biesheuvel (2): mac80211: fils_aead: Use crypto api CMAC shash rather than bare cipher mac80211: aes-cmac: switch to shash CMAC driver net/mac80211/Kconfig | 1 + net/mac80211

[PATCH v3 1/2] mac80211: fils_aead: Use crypto api CMAC shash rather than bare cipher

usually expose the cipher API. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- net/mac80211/Kconfig | 1 + net/mac80211/aes_cmac.h | 4 -- net/mac80211/fils_aead.c | 74 +--- 3 files changed, 34 insertions(+), 45 deletions(-) diff --git a/net/mac80211/Kco

[PATCH v3 2/2] mac80211: aes-cmac: switch to shash CMAC driver

efficient and more secure implementations, especially on platforms where SIMD ciphers have a considerable setup cost. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- net/mac80211/aes_cmac.c | 126 net/mac80211/aes_cmac.h | 11 +- net/mac80211/key.h | 2

Re: [PATCH v2 0/2] mac80211: use crypto shash for AES cmac

On 6 February 2017 at 10:01, Malinen, Jouni <jo...@qca.qualcomm.com> wrote: > On Sun, Feb 05, 2017 at 03:23:26PM +0000, Ard Biesheuvel wrote: >> NOTE: Jouni has been so kind to test patch #2, and confirmed that it is >> working. >> I have not tested patch #1 myse

Re: [PATCH v2 1/2] mac80211: fils_aead: Use crypto api CMAC shash rather than bare cipher

On 6 February 2017 at 08:47, Johannes Berg wrote: > >> { >> u8 d[AES_BLOCK_SIZE], tmp[AES_BLOCK_SIZE]; >> + struct shash_desc *desc; >> + u8 buf[sizeof(*desc) + crypto_shash_descsize(tfm)] >> CRYPTO_MINALIGN_ATTR; I realised we have a more idiomatic

[PATCH v2 2/2] mac80211: aes-cmac: switch to shash CMAC driver

efficient and more secure implementations, especially on platforms where SIMD ciphers have considerable setup time. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- net/mac80211/aes_cmac.c | 130 +--- net/mac80211/aes_cmac.h | 11 +- net/mac80211/key.h | 2

[PATCH v2 0/2] mac80211: use crypto shash for AES cmac

. I have not tested patch #1 myself, mainly because the test methodology requires downloading Ubuntu installer images, and I am currently on a metered 3G connection (and will be for another couple of weeks) Ard Biesheuvel (2): mac80211: fils_aead: Use crypto api CMAC shash rather

[PATCH v2 1/2] mac80211: fils_aead: Use crypto api CMAC shash rather than bare cipher

usually expose the cipher API. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- net/mac80211/Kconfig | 1 + net/mac80211/aes_cmac.h | 4 -- net/mac80211/fils_aead.c | 74 +--- 3 files changed, 35 insertions(+), 44 deletions(-) diff --git a/net/mac80211/Kco

Re: [RFC PATCH 0/2] mac80211: use crypto shash for AES cmac

On 4 February 2017 at 14:39, Malinen, Jouni <jo...@qca.qualcomm.com> wrote: > On Sat, Feb 04, 2017 at 02:24:36PM +0000, Ard Biesheuvel wrote: >> There is another issue I spotted: the skcipher you allocate may be of >> the async variant, which may return from skcipher_encrypt()

Re: [RFC PATCH 0/2] mac80211: use crypto shash for AES cmac

On 4 February 2017 at 11:35, Malinen, Jouni <jo...@qca.qualcomm.com> wrote: > On Fri, Feb 03, 2017 at 09:55:36PM +0000, Ard Biesheuvel wrote: >> OK, that looks like something I could figure out how to use. But are >> you saying the CMAC code is never called in practice? &

Re: [RFC PATCH 0/2] mac80211: use crypto shash for AES cmac

On 3 February 2017 at 21:47, Malinen, Jouni <jo...@qca.qualcomm.com> wrote: > On Fri, Feb 03, 2017 at 07:25:53PM +0000, Ard Biesheuvel wrote: >> The mac80211 aes_cmac code reimplements the CMAC algorithm based on the >> core AES cipher, which is rather restrictive in how

[RFC PATCH 2/2] mac80211: aes-cmac: switch to shash CMAC driver

efficient and more secure implementations, especially on platforms where SIMD ciphers have considerable setup time. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- net/mac80211/Kconfig| 1 + net/mac80211/aes_cmac.c | 137 +--- net/mac80211/aes_cmac.h | 11 +

[RFC PATCH 0/2] mac80211: use crypto shash for AES cmac

no idea how I would go about testing this code, but I am on a mission to remove as many dependencies on the generic AES cipher as I can. Ard Biesheuvel (2): mac80211: fils_aead: clone shared CMAC functions into private version mac80211: aes-cmac: switch to shash CMAC driver net/mac80211/Kconfig

[RFC PATCH 1/2] mac80211: fils_aead: clone shared CMAC functions into private version

-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- net/mac80211/aes_cmac.h | 4 -- net/mac80211/fils_aead.c | 68 2 files changed, 68 insertions(+), 4 deletions(-) diff --git a/net/mac80211/aes_cmac.h b/net/mac80211/aes_cmac.h index c827e1d5de8b..3702041f44fd 100644 ---

Re: [PATCH] crypto: ccm - avoid scatterlist for MAC encryption

On 19 October 2016 at 08:43, Johannes Berg <johan...@sipsolutions.net> wrote: > On Wed, 2016-10-19 at 11:31 +0800, Herbert Xu wrote: >> On Mon, Oct 17, 2016 at 06:21:14PM +0100, Ard Biesheuvel wrote: >> > >> > >> > Annoyingly, all this complicati

Re: [RFC PATCH 2/2] mac80211: aes_ccm: cache AEAD request structures per CPU

On 18 October 2016 at 15:24, Johannes Berg <johan...@sipsolutions.net> wrote: > On Tue, 2016-10-18 at 15:18 +0100, Ard Biesheuvel wrote: >> >> > Hmm. Is it really worth having a per-CPU variable for each possible >> > key? You could have a large number of those

Re: [RFC PATCH 2/2] mac80211: aes_ccm: cache AEAD request structures per CPU

On 18 October 2016 at 15:16, Johannes Berg <johan...@sipsolutions.net> wrote: > On Tue, 2016-10-18 at 15:08 +0100, Ard Biesheuvel wrote: >> >> + aead_req = *this_cpu_ptr(ccmp->reqs); >> + if (!aead_req) { >> + aead_req = kzall

[RFC PATCH 2/2] mac80211: aes_ccm: cache AEAD request structures per CPU

, and so we can simply keep a cached aead_request structure per CPU, and deallocate all of them when deallocating the AEAD transform. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- net/mac80211/aes_ccm.c | 49 ++-- net/mac80211/key.h | 1 + 2 files chang

[RFC PATCH 0/2] mac80211: aes_ccm: cache AEAD request allocations per CPU

did not suffer from the API violation issue in the first place) Ard Biesheuvel (2): mac80211: aes_ccm: prepare key struct for storing context data mac80211: aes_ccm: cache AEAD request structures per CPU net/mac80211/aes_ccm.c | 80 +--- net/mac80211/aes_ccm.h | 16 ++-- net

[RFC PATCH 1/2] mac80211: aes_ccm: prepare key struct for storing context data

As a prepatory change to allow per CPU caching of request structures, refactor the key allocation routine so we can access per key data beyond the core AEAD transform easily. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- net/mac80211/aes_ccm.c | 35 +++

Re: [PATCH] crypto: ccm - avoid scatterlist for MAC encryption

On 17 October 2016 at 18:08, Andy Lutomirski <l...@amacapital.net> wrote: > On Mon, Oct 17, 2016 at 12:37 AM, Ard Biesheuvel > <ard.biesheu...@linaro.org> wrote: >> On 17 October 2016 at 08:28, Johannes Berg <johan...@sipsolutions.net> wrote: >>> On Sat, 20

[PATCH v4] mac80211: move struct aead_req off the stack

ed-off-by: Johannes Berg <johannes.b...@intel.com> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- net/mac80211/aes_ccm.c | 46 +--- net/mac80211/aes_ccm.h | 8 ++-- net/mac80211/aes_cmac.c | 5 +-- net/mac80211/aes_cmac.h | 2 + net/mac802

Re: [PATCH v4] mac80211: move extra crypto data off the stack

On 17 October 2016 at 14:16, Johannes Berg <johan...@sipsolutions.net> wrote: > On Mon, 2016-10-17 at 14:06 +0100, Ard Biesheuvel wrote: >> >> Actually, while I think it will be worthwhile going forward to >> implement such an 'auxiliary data' feature in a generic way,

Re: [PATCH v4] mac80211: move extra crypto data off the stack

On 17 October 2016 at 11:02, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > > >> On 17 Oct 2016, at 10:54, Johannes Berg <johan...@sipsolutions.net> wrote: >> >> >>>> Well, if your other patch to make it OK to be on-stack would be >>&g

Re: [PATCH v4] mac80211: move extra crypto data off the stack

> On 17 Oct 2016, at 10:54, Johannes Berg wrote: > > >>> Well, if your other patch to make it OK to be on-stack would be >>> applied instead, this wouldn't make much sense either :) >>> >> >> Yes but that one only fixes ccm not gcm > > Yes, but we can do the same

Re: [PATCH v4] mac80211: move extra crypto data off the stack

> On 17 Oct 2016, at 10:35, Johannes Berg <johan...@sipsolutions.net> wrote: > >> On Mon, 2016-10-17 at 10:30 +0100, Ard Biesheuvel wrote: >> >> Yes. But as I replied, setting the req size is not supported atm, >> although it is reasonable to dema

Re: [PATCH v4] mac80211: move extra crypto data off the stack

> On 17 Oct 2016, at 10:35, Johannes Berg <johan...@sipsolutions.net> wrote: > >> On Mon, 2016-10-17 at 10:30 +0100, Ard Biesheuvel wrote: >> >> Yes. But as I replied, setting the req size is not supported atm, >> although it is reasonable to dema

Re: [PATCH v4] mac80211: move extra crypto data off the stack

On 17 October 2016 at 10:23, Johannes Berg wrote: > >> Apologies for going back and forth on this, but it appears there may >> be another way to deal with this. >> >> First of all, we only need this handling for the authenticated data, > > Are you sure b_0/j_0 aren't

Re: [PATCH v4] mac80211: move extra crypto data off the stack

On 17 October 2016 at 10:14, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > On 17 October 2016 at 09:33, Johannes Berg <johan...@sipsolutions.net> wrote: >> From: Johannes Berg <johannes.b...@intel.com> >> >> As the stack can (on x86-64) now be virtua

Re: [PATCH v4] mac80211: move extra crypto data off the stack

> the SG APIs correctly by putting on-stack buffers into SG tables. > This leads to kernel crashes. > > Fix this by allocating the extra fields dynamically on the fly as > needed, using a kmem cache. > > I used per-CPU memory in a previous iteration of this patch, but > A

Re: [PATCH] crypto: ccm - avoid scatterlist for MAC encryption

On 17 October 2016 at 08:47, Johannes Berg <johan...@sipsolutions.net> wrote: > On Mon, 2016-10-17 at 08:37 +0100, Ard Biesheuvel wrote: >> >> Could we get a statement first whether it is supported to allocate >> aead_req (and other crypto req structures) on the stack?

Re: [PATCH] crypto: ccm - avoid scatterlist for MAC encryption

On 17 October 2016 at 08:28, Johannes Berg <johan...@sipsolutions.net> wrote: > On Sat, 2016-10-15 at 18:16 +0100, Ard Biesheuvel wrote: >> The CCM code goes out of its way to perform the CTR encryption of the >> MAC using the subordinate CTR driver. To this end, it tweaks th

[PATCH] crypto: ccm - avoid scatterlist for MAC encryption

, and record it in the aead_req private context so we can apply it to the MAC in cypto_ccm_auth_mac(). This greatly simplifies the scatterlist manipulation, and no longer requires scatterlists to refer to buffers that may live on the stack. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.

Re: [PATCH] mac80211: aes_ccm: move struct aead_req off the stack

> On 14 Oct 2016, at 14:46, Johannes Berg wrote: > > >> >> Is the aad[] actually reused? I would assume it only affects the mac >> on encryption, and the verification on decryption but I don't think >> we actually need it back from the crypto routines. > > I don't

Re: [PATCH] mac80211: aes_ccm: move struct aead_req off the stack

On 14 October 2016 at 14:15, Johannes Berg <johan...@sipsolutions.net> wrote: > On Fri, 2016-10-14 at 14:13 +0100, Ard Biesheuvel wrote: >> >> > But if we allocate things anyway, is it worth expending per-CPU >> > buffers on these? >> >> Ehmm, maybe n

Re: [PATCH] mac80211: aes_ccm: move struct aead_req off the stack

On 14 October 2016 at 14:10, Johannes Berg wrote: > >> So use kzalloc > > Do we really need kzalloc()? We have things on the stack right now, and > don't initialize, so surely we don't really need to zero things? > >> This only addresses one half of the problem. The

[PATCH] mac80211: aes_ccm: move struct aead_req off the stack

. This pattern already exists in the IPsec ESP driver, but in the future, we may need to improve upon this by either moving the request into the SKB, or using a slab cache to allocate/free the data structures. Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org> --- This only address

Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)

On 14 October 2016 at 11:00, Johannes Berg wrote: > >> So why is the performance hit acceptable for ESP but not for WPA? We >> could easily implement the same thing, i.e., >> kmalloc(GFP_ATOMIC)/kfree the aead_req struct rather than allocate it >> on the stack > > Yeah,

Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)

On 14 October 2016 at 09:39, Ard Biesheuvel <ard.biesheu...@linaro.org> wrote: > On 14 October 2016 at 09:28, Johannes Berg <johan...@sipsolutions.net> wrote: >> >>>1. revert that patch (doing so would need some major adjustments now, >>> since it'

Re: [mac80211] BUG_ON with current -git (4.8.0-11417-g24532f7)

On 14 October 2016 at 09:28, Johannes Berg wrote: > >>1. revert that patch (doing so would need some major adjustments now, >> since it's pretty old and a number of new things were added in the >> meantime) > > This it will have to be, I guess. > >>

Re: [patch] mac80111: aes_ccm: cleanup ieee80211_aes_key_setup_encrypt()

with branches for error handling. Signed-off-by: Dan Carpenter dan.carpen...@oracle.com Acked-by: Ard Biesheuvel ard.biesheu...@linaro.org Thanks, Ard. diff --git a/net/mac80211/aes_ccm.c b/net/mac80211/aes_ccm.c index 7869bb40..208df7c 100644 --- a/net/mac80211/aes_ccm.c +++ b/net/mac80211/aes_ccm.c

Re: [PATCH] mac80211: Fix regression that triggers a kernel BUG with CCMP

On 6 November 2014 10:55, Ronald Wahl ronald.w...@raritan.com wrote: Commit 7ec7c4a9a686c608315739ab6a2b0527a240883c (mac80211: port CCMP to cryptoapi's CCM driver) introduced a regression when decrypting empty packets (data_len == 0). This will lead to backtraces like: (scatterwalk_start)

Re: [PATCH v2] mac80211: Fix regression that triggers a kernel BUG with CCMP

generates garbage when the internal FIFO overruns. This patch adds an additional length check. Cc: sta...@vger.kernel.org Fixes: 7ec7c4a9a686 (mac80211: port CCMP to cryptoapi's CCM driver) Signed-off-by: Ronald Wahl ronald.w...@raritan.com Acked-by: Ard Biesheuvel ard.biesheu...@linaro.org

Re: [PATCH] mac80211: Fix regression that triggers a kernel BUG with CCMP

On 6 November 2014 14:50, Ronald Wahl ronald.w...@raritan.com wrote: On 06.11.2014 14:14, Johannes Berg wrote: On Thu, 2014-11-06 at 14:07 +0100, Ronald Wahl wrote: But there are LTS kernels not maintained by Greg like 3.12 and 3.16. How about these? If sending patches to stable@kernel org