On Wed, 27 Feb 2019 at 11:02, Marc Zyngier wrote:
>
> + Lorenzo
>
> Hi Brian,
>
> On 26/02/2019 23:28, Brian Norris wrote:
> > + others
> >
> > Hi Marc,
> >
> > Thanks for the series. I have a few bits of history to add to this, and
> > some comments.
> >
> > On Sun, Feb 24, 2019 at 02:04:22PM +00
On Mon, 25 Feb 2019 at 15:53, Marc Zyngier wrote:
>
> Hi Ard,
>
> On 25/02/2019 12:45, Ard Biesheuvel wrote:
> > On Sun, 24 Feb 2019 at 15:08, Marc Zyngier wrote:
> >>
> >> For quite some time, I wondered why the PCI mwifiex device built in my
> >&
On Sun, 24 Feb 2019 at 15:08, Marc Zyngier wrote:
>
> For quite some time, I wondered why the PCI mwifiex device built in my
> Chromebook was unable to use the good old legacy interrupts. But as MSIs
> were working fine, I never really bothered investigating. I finally had a
> look, and the result
On Tue, 13 Nov 2018 at 15:04, Arend van Spriel
wrote:
>
> On 11/13/2018 11:50 PM, Ard Biesheuvel wrote:
> > Hi Arend,
> >
> > On Tue, 13 Nov 2018 at 12:51, Arend van Spriel
> > wrote:
> >>
> >> Since commit ce2e6db554fa ("brcmfmac: Add suppo
Hi Arend,
On Tue, 13 Nov 2018 at 12:51, Arend van Spriel
wrote:
>
> Since commit ce2e6db554fa ("brcmfmac: Add support for getting nvram
> contents from EFI variables") we have a device driver accessing the
> efivars api (since next-20181107). Several functions in efivars api
> assume __efivars is
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 the right one?
On 19 July 2017 at 19:28, Andy Shevchenko
wrote:
> There are new types and helpers that are supposed to be used in new code.
>
> As a preparation to get rid of legacy types and API functions do
> the conversion here.
>
> Cc: Matt Fleming
> Cc: Ard Biesheuvel
> Signed
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
ences 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 - use
called crypto_xor_cpy(),
taking separate input and output arguments. This removes the need for
the separate memcpy().
Signed-off-by: Ard Biesheuvel
---
arch/arm/crypto/aes-ce-glue.c | 4 +---
arch/arm/crypto/aes-neonbs-glue.c | 5 ++---
arch/arm64/crypto/aes-glue.c| 4 +---
arch
On 18 July 2017 at 09:39, Herbert Xu 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, src, walk.total % AES_BLOCK_S
first input operands in crypto_xor().
While we're at it, fold in the memcpy()s that can now be made redundant.
Signed-off-by: Ard Biesheuvel
---
arch/arm/crypto/aes-ce-glue.c | 4 +---
arch/arm/crypto/aes-neonbs-glue.c | 9 +++--
arch/arm64/crypto/aes-glue.c| 8
In preparation of updating crypto_xor() [which is what the crypto API
exposes to other subsystems] to use separate operands for input and
output, first modify the __crypto_xor() implementation that provides
the actual functionality when not using the inline version.
Signed-off-by: Ard Biesheuvel
urrences 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-
On 27 February 2017 at 15:06, Johannes Berg wrote:
> Hi Ard,
>
> Apologies for the non-follow-up - couldn't find the original patch.
>
> Your patch "crypto: ccm - switch to separate cbcmac driver" causes a
> BUG_ON when virtual stacks are used, in crypto_ccm_auth() is called,
> because you put oda
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];
>> + u8 d[AES_BLOCK_SIZE], t
- 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
efficient and more secure implementations, especially on
platforms where SIMD ciphers have a considerable setup cost.
Signed-off-by: Ard Biesheuvel
---
net/mac80211/aes_cmac.c | 126
net/mac80211/aes_cmac.h | 11 +-
net/mac80211/key.h | 2 +-
3 files changed, 32 insertions
x27;t usually
expose the cipher API.
Signed-off-by: Ard Biesheuvel
---
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/Kconfig b/net/mac80211/Kconfig
On 6 February 2017 at 10:01, Malinen, Jouni 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 myself, mainly because
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 SHASH_DESC_ON_STACK for this.
>
efficient and more secure implementations, especially on
platforms where SIMD ciphers have considerable setup time.
Signed-off-by: Ard Biesheuvel
---
net/mac80211/aes_cmac.c | 130 +---
net/mac80211/aes_cmac.h | 11 +-
net/mac80211/key.h | 2 +-
3 files changed, 35 insertions
.
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
x27;t usually
expose the cipher API.
Signed-off-by: Ard Biesheuvel
---
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/Kconfig b/net/mac80211/Kconfig
On 4 February 2017 at 14:39, Malinen, Jouni 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() with
>> -EINPROGR
On 4 February 2017 at 11:35, Malinen, Jouni 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?
>
> It will get called if
On 3 February 2017 at 21:47, Malinen, Jouni 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 platforms can satisfy
>> t
efficient and more secure implementations, especially on
platforms where SIMD ciphers have considerable setup time.
Signed-off-by: Ard Biesheuvel
---
net/mac80211/Kconfig| 1 +
net/mac80211/aes_cmac.c | 137 +---
net/mac80211/aes_cmac.h | 11 +-
net/mac80211/key.h | 2
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
-by: Ard Biesheuvel
---
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
--- a/net/mac80211/aes_cmac.h
+++ b
On 19 October 2016 at 08:43, Johannes Berg 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 complication with scatterlists etc is for
>>
On 18 October 2016 at 15:24, Johannes Berg 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 (typically three when
>> >
On 18 October 2016 at 15:16, Johannes Berg 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 = kzalloc(reqsize + CCM_AAD_LEN, GFP_ATOMIC);
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
---
net/mac80211/aes_ccm.c | 49 ++--
net/mac80211/key.h | 1 +
2 files changed, 36 insertions(+), 14 deletions
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
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
---
net/mac80211/aes_ccm.c | 35 +++-
net/mac80211/aes_ccm.h | 16
On 17 October 2016 at 18:08, Andy Lutomirski wrote:
> On Mon, Oct 17, 2016 at 12:37 AM, Ard Biesheuvel
> wrote:
>> On 17 October 2016 at 08:28, Johannes Berg wrote:
>>> On Sat, 2016-10-15 at 18:16 +0100, Ard Biesheuvel wrote:
>>>> The CCM code goes out of its
Signed-off-by: Ard Biesheuvel
---
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/mac80211/aes_gcm.c | 43 +++---
net/mac80211/aes_gcm.h | 6 ++-
net/mac80211/aes_gmac.c | 26
On 17 October 2016 at 14:16, Johannes Berg 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, I still
>> thin
On 17 October 2016 at 11:02, Ard Biesheuvel wrote:
>
>
>> 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 :)
> 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 for GCM, no?
>
No, not re
> On 17 Oct 2016, at 10:35, Johannes Berg 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 demand a way to allocate additional data
>
> On 17 Oct 2016, at 10:35, Johannes Berg 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 demand a way to allocate additional data
>
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 needed? We pass those
> to aea
On 17 October 2016 at 10:14, Ard Biesheuvel wrote:
> On 17 October 2016 at 09:33, Johannes Berg wrote:
>> From: Johannes Berg
>>
>> As the stack can (on x86-64) now be virtually mapped rather than
>> using "normal" kernel memory, Sergey noticed mac80211 is
nto 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
> Ard Biesheuvel pointed out that was also vmalloc'ed on s
allocating every time we need
> to use them.
>
> This pattern already exists in the IPsec ESP driver, but in the future,
> we may want/need to improve upon this, e.g. by using a slab cache.
>
> (Based on Ard's patch, but that was missing error handling and GCM/GMAC)
>
> Si
On 17 October 2016 at 08:47, Johannes Berg 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?
>
> Well, we haven't h
On 17 October 2016 at 08:28, Johannes Berg 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 the
>> input and outpu
stream directly,
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
---
This is an
> 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 think it's reused.
>
>> Exa
On 14 October 2016 at 14:15, Johannes Berg 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 not. I could spin a v2 that alloc
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 other problem, i.e.,
>> the fac
. 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
---
This only addresses one half of the problem. The other
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, maybe we should. It's likel
On 14 October 2016 at 10:25, Johannes Berg wrote:
> On Fri, 2016-10-14 at 10:21 +0100, Ard Biesheuvel wrote:
>
>> It is annotated with a TODO, though :-)
>>
>> 38320c70d282b (Herbert Xu 2008-01-28 19:35:05
>> -0800 41)
>> * TODO: Use spare
On 14 October 2016 at 10:10, Johannes Berg wrote:
> On Fri, 2016-10-14 at 10:05 +0100, Ard Biesheuvel wrote:
>>
>> Indeed. And the decrypt path does the same for auth_tag[].
>
> Hadn't gotten that far, due to the BUG_ON() in CONFIG_DEBUG_SG in the
> encrypt path :)
&g
On 14 October 2016 at 09:55, Johannes Berg wrote:
> On Fri, 2016-10-14 at 09:47 +0100, Ard Biesheuvel wrote:
>>
>> Do you have a reference for the sg_set_buf() call on odata?
>> crypto/ccm.c does not seem to have it (afaict),
>
> It's indirect - crypto_ccm_encry
On 14 October 2016 at 09:42, Johannes Berg wrote:
> On Fri, 2016-10-14 at 09:41 +0100, Ard Biesheuvel wrote:
>
>> > I assume the stack buffer itself is not the problem here, but aad,
>> > which is allocated on the stack one frame up.
>> > Do we really need to r
On 14 October 2016 at 09:39, Ard Biesheuvel wrote:
> 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
&
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.
>
>>2. allocate a per-CPU buffer
ith branches for error handling.
>
> Signed-off-by: Dan Carpenter
Acked-by: Ard Biesheuvel
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
On 6 November 2014 14:50, Ronald Wahl 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 is optional
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
Acked-by: Ard Biesheuvel
> ---
> v1 -> v2:
> - return negat
On 6 November 2014 10:55, Ronald Wahl 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) from [] (scatterwalk_
65 matches
Mail list logo
