The SGL is MAX_SGL_ENTS + 1 in size. The last SG entry is used for the
chaining and is properly updated with the sg_chain invocation. During
the filling-in of the initial SG entries, sg_mark_end is called for each
SG entry. This is appropriate as long as no additional SGL is chained
with the curren
Am Dienstag, 22. August 2017, 08:33:15 CEST schrieb Herbert Xu:
Hi Herbert,
> On Thu, Aug 10, 2017 at 08:06:18AM +0200, Stephan Müller wrote:
> > Hi Herbert,
> >
> > I found that issue while playing around with edge conditions in my
> > algif_akcipher implementation. This issue only manifests in
Hi Tudor,
>> you still need to get the public key out of the kernel if you want to use it
>> from user space. Or feed the remote public key if you plan to use some sort
>> of key derivation function.
>
> The crypto hardware that I'm working on, generates the private key
> internally within the
Hi, Marcel,
On 08/30/2017 10:21 AM, Marcel Holtmann wrote:
you still need to get the public key out of the kernel if you want to use it
from user space. Or feed the remote public key if you plan to use some sort of
key derivation function.
The crypto hardware that I'm working on, generates
Hi Tudor,
> akcipher can work with its own internal keys, now that we have crypto
> accelerators that can generate keys that never leave the hardware. Going
> through the kernel's key subsystem seems superfluous in this case.
>
> I also understand the need of going through the kernel's key subsys
When two adjacent TX SGL are processed and parts of both TX SGLs
are pulled into the per-request TX SGL, the wrong per-request
TX SGL entries were updated.
This fixes a NULL pointer dereference when a cipher implementation walks
the TX SGL where some of the SGL entries were NULL.
Signed-off-by: S
