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

> Indeed. And it keeps the clutter inside the aes_xxx.c files, which > could easily be updated in the future to use some auxdata feature if > it ever materializes. > > I think it would help this code, but also the ESP code you pointed > out, to have some kind of 'ordered synchronous' CRYPTO_xxx

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

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 >> think we should

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

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 > think we should address the issue at hand without too much > complication. > > If we pedal back to

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

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 :)

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

> > 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? > > In this particular patch, we could reduce the size of the struct, > >

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

> 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 >> in the

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

> 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 >> in the

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

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 > in the request specifically for this issue. So let's proceed with the > aead_request_alloc/free

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

> 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 aead_request_set_crypt(), and I wasn't sure what that really

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

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"

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

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 isn't using > the SG APIs correctly by putting