On Fri, Jan 20, 2017 at 06:07:04PM +0100, Cyrille Pitchen wrote:
> Hi all,
>
> Le 13/01/2017 à 12:39, Herbert Xu a écrit :
> > On Fri, Jan 13, 2017 at 12:36:56PM +0100, Stephan Müller wrote:
> >>
> >> I thought I understood that you would not want to see it in any
> >> implementation. But, ok,
Am Freitag, 20. Januar 2017, 18:07:04 CET schrieb Cyrille Pitchen:
Hi Cyrille,
>
> I've taken Stephan's other comments into account from his review of the
> atmel-authenc driver so I'm preparing a new series but I don't know what to
> do for the associated data copy.
>
> Please let me know
Hi all,
Le 13/01/2017 à 12:39, Herbert Xu a écrit :
> On Fri, Jan 13, 2017 at 12:36:56PM +0100, Stephan Müller wrote:
>>
>> I thought I understood that you would not want to see it in any
>> implementation. But, ok, if you want to leave it.
>
> If you remove it from authenc then authenc will be
Hi Stephan,
this series of patches sounds like a good idea. I haven't tested it with
the Atmel AES hardware yet but I have many dummy questions:
Looking at some driver patches in the series, it seems you only add a call
to crypto_aead_copy_ad() but I don't see any removal of the previous driver
Am Freitag, 13. Januar 2017, 19:33:24 CET schrieb Herbert Xu:
Hi Herbert,
> On Fri, Jan 13, 2017 at 12:30:15PM +0100, Stephan Müller wrote:
> > So, the patch set you want to see is:
> >
> > - remove the AAD copy operation from authenc and not add it to any AEAD
> > implementations
>
> Why
On Fri, Jan 13, 2017 at 12:36:56PM +0100, Stephan Müller wrote:
>
> I thought I understood that you would not want to see it in any
> implementation. But, ok, if you want to leave it.
If you remove it from authenc then authenc will be broken.
--
Email: Herbert Xu
On Fri, Jan 13, 2017 at 12:30:15PM +0100, Stephan Müller wrote:
>
> So, the patch set you want to see is:
>
> - remove the AAD copy operation from authenc and not add it to any AEAD
> implementations
Why would you remove it from authenc?
> - add the AAD copy operation to algif_aead
No just
Am Freitag, 13. Januar 2017, 19:26:23 CET schrieb Herbert Xu:
Hi Herbert,
> On Fri, Jan 13, 2017 at 12:19:48PM +0100, Stephan Müller wrote:
> > That is correct, but I thought that playing with pointers is always faster
> > than doing memcpy. Are you saying that this assumption is not true when
On Fri, Jan 13, 2017 at 11:58:24AM +0100, Stephan Müller wrote:
>
> May I ask how the in-place code path can be invoked by algif_aead or
> algif_skcipher? As far as I understand, this code path is only invoked when
> the cipher implementation sees that the src and dst SGLs are identical.
It's
On Fri, Jan 13, 2017 at 12:19:48PM +0100, Stephan Müller wrote:
>
> That is correct, but I thought that playing with pointers is always faster
> than doing memcpy. Are you saying that this assumption is not true when we
> somehow have the code to try to perform an in-place operation?
If you're
Am Freitag, 13. Januar 2017, 19:14:06 CET schrieb Herbert Xu:
Hi Herbert,
> On Fri, Jan 13, 2017 at 12:12:39PM +0100, Stephan Müller wrote:
> > Adding such code should IMHO not be impaired by pointing to the AAD held
> > in
> > the src SGL by the dst SGL as offered with the older patch mentioned
On Fri, Jan 13, 2017 at 12:12:39PM +0100, Stephan Müller wrote:
>
> Adding such code should IMHO not be impaired by pointing to the AAD held in
> the src SGL by the dst SGL as offered with the older patch mentioned before.
The point is you're turning what could otherwise be a linear SGL
into a
Am Freitag, 13. Januar 2017, 19:04:17 CET schrieb Herbert Xu:
Hi Herbert,
> On Fri, Jan 13, 2017 at 11:58:24AM +0100, Stephan Müller wrote:
> > May I ask how the in-place code path can be invoked by algif_aead or
> > algif_skcipher? As far as I understand, this code path is only invoked
> > when
Am Freitag, 13. Januar 2017, 18:23:39 CET schrieb Herbert Xu:
Hi Herbert,
> On Thu, Jan 12, 2017 at 05:37:33PM +0100, Stephan Müller wrote:
> > I would not understand that statement.
> >
> > With the patch mentioned above that I provided some weeks ago, we have the
> > following scenario for an
On Thu, Jan 12, 2017 at 05:37:33PM +0100, Stephan Müller wrote:
>
> I would not understand that statement.
>
> With the patch mentioned above that I provided some weeks ago, we have the
> following scenario for an encryption (in case of decryption, it is almost
> identical, just the tag
Am Freitag, 13. Januar 2017, 00:06:29 CET schrieb Herbert Xu:
Hi Herbert,
> On Thu, Jan 12, 2017 at 05:01:13PM +0100, Stephan Müller wrote:
> > I fully agree. Therefore, I was under the impression that disregarding the
> > AAD in recvmsg entirely would be most appropriate as offered with the
> >
On Thu, Jan 12, 2017 at 04:50:46PM +0100, Stephan Müller wrote:
>
> So you say that we could remove it from authenc() entirely (this is currently
> the only location where such copy operation is found for the encryption
> direction)?
>
> I would concur that the kernel does not need that.
On Thu, Jan 12, 2017 at 05:01:13PM +0100, Stephan Müller wrote:
>
> I fully agree. Therefore, I was under the impression that disregarding the
> AAD
> in recvmsg entirely would be most appropriate as offered with the patch
> "crypto: AF_ALG - disregard AAD buffer space for output". In this case
Am Donnerstag, 12. Januar 2017, 23:53:44 CET schrieb Herbert Xu:
Hi Herbert,
>
> > If we only want to solve that for algif_aead, wouldn't it make more sense
> > if the user space caller takes care of that (such as libkcapi)? By
> > tinkering with the SGLs and copying the data to the dst buffer
Am Donnerstag, 12. Januar 2017, 23:39:24 CET schrieb Herbert Xu:
Hi Herbert,
> On Thu, Jan 12, 2017 at 04:34:39PM +0100, Stephan Müller wrote:
> > We would only be able to remove it if all AEAD implementations are
> > converted. But for the conversion time, we do face that issue.
>
> It doesn't
Am Donnerstag, 12. Januar 2017, 23:27:10 CET schrieb Herbert Xu:
Hi Herbert,
> On Thu, Jan 12, 2017 at 04:23:50PM +0100, Stephan Müller wrote:
> > As far as I understand, we have the following AAD copy operations that we
> > discuss:
> >
> > - algif_aead: you suggested to add the AAD copy
On Thu, Jan 12, 2017 at 04:23:50PM +0100, Stephan Müller wrote:
>
> As far as I understand, we have the following AAD copy operations that we
> discuss:
>
> - algif_aead: you suggested to add the AAD copy operation here
>
> - AEAD implementations: over time, the AEAD implementations shall
Am Donnerstag, 12. Januar 2017, 22:57:28 CET schrieb Herbert Xu:
Hi Herbert,
> On Thu, Jan 12, 2017 at 12:22:09PM +0100, Stephan Müller wrote:
> > When addressing the issue in the algif_aead code, and expect that over
> > time
> > the AEAD implementations will gain the copy operation, eventually
On Thu, Jan 12, 2017 at 12:22:09PM +0100, Stephan Müller wrote:
>
> When addressing the issue in the algif_aead code, and expect that over time
> the AEAD implementations will gain the copy operation, eventually we will
> copy
> the AAD twice. Of course, this could be prevented, if the
Am Donnerstag, 12. Januar 2017, 14:19:36 CET schrieb Herbert Xu:
Hi Herbert,
>
> I think it's too much churn. Let's get the algif_aead code fixed
> up first, and then pursue this later.
To eliminate the extra churn of having all AEAD implementations changed to
invoke copy operation, what
Am Donnerstag, 12. Januar 2017, 14:19:36 CET schrieb Herbert Xu:
Hi Herbert,
> On Tue, Jan 10, 2017 at 02:36:21AM +0100, Stephan Müller wrote:
> > to all driver maintainers: the patches I added are compile tested, but
> > I do not have the hardware to verify the code. May I ask the respective
>
On Tue, Jan 10, 2017 at 02:36:21AM +0100, Stephan Müller wrote:
>
> to all driver maintainers: the patches I added are compile tested, but
> I do not have the hardware to verify the code. May I ask the respective
> hardware maintainers to verify that the code is appropriate and works
> as
27 matches
Mail list logo