> 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 f
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 address the issue at hand wit
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 t
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 :)
>>>
>>> Yes but that one only fixes ccm not gcm
>>
> 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
> > 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,
> > bu
> 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 request specifically for thi
> 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 request specifically for thi
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 pat
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
> 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 di
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 isn't using
>> the SG APIs correctly by pu
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 on-stack buffers into SG tables.
> This leads to kern
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 on-stack buffers into SG tables.
This leads to kernel crashes.
Fix this by allocating the extra fields dynamical
14 matches
Mail list logo