On Thu, Jun 06, 2019 at 08:36:52AM +, Horia Geanta wrote:
>
> Yes, an internally kmalloc-ed buffer is used for storing the IV (both input
> and
> output IV).
> Once HW finishes the job, area is DMA unmapped and then output IV is copied
> into
> req->iv.
That sounds good to me. Thanks!
--
E
On 6/6/2019 10:16 AM, Herbert Xu wrote:
> On Thu, Jun 06, 2019 at 07:10:06AM +, Horia Geanta wrote:
>>
>> Not really.
>> I am in favor of using the HW to update the IV, which would work for all
>> skcipher algorithms.
>> I have the fix ready, will send it in a couple of days.
>
> OK that would
On Thu, Jun 06, 2019 at 07:10:06AM +, Horia Geanta wrote:
>
> Not really.
> I am in favor of using the HW to update the IV, which would work for all
> skcipher algorithms.
> I have the fix ready, will send it in a couple of days.
OK that would be interesting to see. But I presume you are stil
On 6/6/2019 9:58 AM, Herbert Xu wrote:
> On Thu, Jun 06, 2019 at 08:53:10AM +0200, Ard Biesheuvel wrote:
>>
>> That same patch 'fixes' CBC, since CBC was never broken to begin with.
>> The CTS driver does not have something like the auth_tag sharing the
>> same cacheline with the IV, so CBC has alw
On Thu, Jun 06, 2019 at 08:53:10AM +0200, Ard Biesheuvel wrote:
>
> That same patch 'fixes' CBC, since CBC was never broken to begin with.
> The CTS driver does not have something like the auth_tag sharing the
> same cacheline with the IV, so CBC has always worked fine.
CBC is broken. Any crypto
On Thu, 6 Jun 2019 at 08:46, Herbert Xu wrote:
>
> On Thu, Jun 06, 2019 at 08:42:46AM +0200, Ard Biesheuvel wrote:
> > On Thu, 6 Jun 2019 at 08:37, Herbert Xu wrote:
> > >
> > > On Thu, May 30, 2019 at 04:31:09PM +0200, Ard Biesheuvel wrote:
> > > >
> > > > This might work:
> > > >
> > > > diff -
On Thu, Jun 06, 2019 at 08:42:46AM +0200, Ard Biesheuvel wrote:
> On Thu, 6 Jun 2019 at 08:37, Herbert Xu wrote:
> >
> > On Thu, May 30, 2019 at 04:31:09PM +0200, Ard Biesheuvel wrote:
> > >
> > > This might work:
> > >
> > > diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg
On Thu, 6 Jun 2019 at 08:37, Herbert Xu wrote:
>
> On Thu, May 30, 2019 at 04:31:09PM +0200, Ard Biesheuvel wrote:
> >
> > This might work:
> >
> > diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
> > index c0ece44f303b..3d313d2a279a 100644
> > --- a/drivers/crypto/caam/c
On Thu, May 30, 2019 at 04:31:09PM +0200, Ard Biesheuvel wrote:
>
> This might work:
>
> diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
> index c0ece44f303b..3d313d2a279a 100644
> --- a/drivers/crypto/caam/caamalg.c
> +++ b/drivers/crypto/caam/caamalg.c
> @@ -1661,7 +166
On Fri, May 31, 2019 at 06:10:51AM +, Horia Geanta wrote:
>
> Driver is not touching the DMA mapped areas, the DMA API conventions are
> carefully followed.
> It's touching a virtual pointer that is not DMA mapped, that just happens to
> be
> on the same cache line with a DMA mapped buffer.
W
On 5/31/2019 8:43 AM, Herbert Xu wrote:
> On Fri, May 31, 2019 at 05:22:50AM +, Horia Geanta wrote:
>>
>> Unless it's clearly defined *which* virtual addresses mustn't be accessed,
>> things won't work properly.
>> In theory, any two objects could share a cache line. We can't just stop all
>> m
On 5/30/2019 4:26 PM, Ard Biesheuvel wrote:
> On Thu, 30 May 2019 at 15:18, Horia Geanta wrote:
>>
>> On 5/30/2019 11:08 AM, Ard Biesheuvel wrote:
>>> On Thu, 30 May 2019 at 09:46, Horia Geanta wrote:
On 5/30/2019 8:34 AM, Herbert Xu wrote:
> It would appear that Ard's latest sugges
On 5/31/2019 1:00 AM, Iuliana Prodan wrote:
> On 5/30/2019 6:05 PM, Ard Biesheuvel wrote:
>> On Thu, 30 May 2019 at 16:34, Herbert Xu wrote:
>>>
>>> On Thu, May 30, 2019 at 04:31:09PM +0200, Ard Biesheuvel wrote:
This might work:
>>>
>>> Looks good to me.
>>>
>>
>> Thanks Herbert,
>>
>>
On Fri, May 31, 2019 at 05:22:50AM +, Horia Geanta wrote:
>
> Unless it's clearly defined *which* virtual addresses mustn't be accessed,
> things won't work properly.
> In theory, any two objects could share a cache line. We can't just stop all
> memory accesses from CPU while a peripheral is b
On 5/30/2019 4:26 PM, Herbert Xu wrote:
> On Thu, May 30, 2019 at 01:18:34PM +, Horia Geanta wrote:
>>
>> I guess there are only two options:
>> -either cache line sharing is avoided OR
>> -users need to be *aware* they are sharing the cache line and some rules /
>> assumptions are in place on
On 5/30/2019 6:05 PM, Ard Biesheuvel wrote:
> On Thu, 30 May 2019 at 16:34, Herbert Xu wrote:
>>
>> On Thu, May 30, 2019 at 04:31:09PM +0200, Ard Biesheuvel wrote:
>>>
>>> This might work:
>>
>> Looks good to me.
>>
>
> Thanks Herbert,
>
> But given your remark regarding CBC being the only algo
On Thu, 30 May 2019 at 17:13, Herbert Xu wrote:
>
> On Thu, May 30, 2019 at 05:10:06PM +0200, Ard Biesheuvel wrote:
> >
> > Are there any generic templates relying on this for other algos than CBC?
>
> algif_skcipher relies on this.
>
I see.
In any case, that one line patch would still make thin
On Thu, May 30, 2019 at 05:10:06PM +0200, Ard Biesheuvel wrote:
>
> Are there any generic templates relying on this for other algos than CBC?
algif_skcipher relies on this.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/
On Thu, 30 May 2019 at 16:53, Pascal Van Leeuwen
wrote:
>
> >
> > This might work:
> >
> > diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
> > index c0ece44f303b..3d313d2a279a 100644
> > --- a/drivers/crypto/caam/caamalg.c
> > +++ b/drivers/crypto/caam/caamalg.c
> > @@ -
On Thu, 30 May 2019 at 17:06, Herbert Xu wrote:
>
> On Thu, May 30, 2019 at 05:04:51PM +0200, Ard Biesheuvel wrote:
> >
> > But given your remark regarding CBC being the only algo that has this
> > requirement, I wonder if this might be sufficient as well.
>
> It's not that CBC is the only one wit
On Thu, May 30, 2019 at 05:04:51PM +0200, Ard Biesheuvel wrote:
>
> But given your remark regarding CBC being the only algo that has this
> requirement, I wonder if this might be sufficient as well.
It's not that CBC is the only one with the requirement. It's just
that this is the wrong output IV
On Thu, 30 May 2019 at 16:34, Herbert Xu wrote:
>
> On Thu, May 30, 2019 at 04:31:09PM +0200, Ard Biesheuvel wrote:
> >
> > This might work:
>
> Looks good to me.
>
Thanks Herbert,
But given your remark regarding CBC being the only algo that has this
requirement, I wonder if this might be suffic
>
> This might work:
>
> diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
> index c0ece44f303b..3d313d2a279a 100644
> --- a/drivers/crypto/caam/caamalg.c
> +++ b/drivers/crypto/caam/caamalg.c
> @@ -1661,7 +1661,8 @@ static int aead_decrypt(struct aead_request *req)
> *
On Thu, May 30, 2019 at 04:31:09PM +0200, Ard Biesheuvel wrote:
>
> This might work:
Looks good to me.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Thu, 30 May 2019 at 16:28, Ard Biesheuvel wrote:
>
> On Thu, 30 May 2019 at 16:27, Herbert Xu wrote:
> >
> > On Thu, May 30, 2019 at 03:55:07PM +0200, Ard Biesheuvel wrote:
> > >
> > > > Would this work?
> >
> > I see. You need to preserve the original IV.
> >
> > > > diff --git a/drivers/cry
> On Thu, 30 May 2019 at 15:58, Herbert Xu
> wrote:
> >
> > On Thu, May 30, 2019 at 01:45:47PM +, Iuliana Prodan wrote:
> > >
> > > On the current structure of caamalg, to work, iv needs to be copied
> > > before memcpy(iv, req->iv, ivsize), from skcipher_edesc_alloc
> function.
> > > For this
On Thu, 30 May 2019 at 16:27, Herbert Xu wrote:
>
> On Thu, May 30, 2019 at 03:55:07PM +0200, Ard Biesheuvel wrote:
> >
> > > Would this work?
>
> I see. You need to preserve the original IV.
>
> > > diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
> > > index c0ece44f30
On Thu, May 30, 2019 at 03:55:07PM +0200, Ard Biesheuvel wrote:
>
> > Would this work?
I see. You need to preserve the original IV.
> > diff --git a/drivers/crypto/caam/caamalg.c b/drivers/crypto/caam/caamalg.c
> > index c0ece44f303b..2ef2f76a3cb8 100644
> > --- a/drivers/crypto/caam/caamalg.c
>
On Thu, 30 May 2019 at 15:58, Herbert Xu wrote:
>
> On Thu, May 30, 2019 at 01:45:47PM +, Iuliana Prodan wrote:
> >
> > On the current structure of caamalg, to work, iv needs to be copied
> > before memcpy(iv, req->iv, ivsize), from skcipher_edesc_alloc function.
> > For this we need edesc, bu
On Thu, May 30, 2019 at 01:45:47PM +, Iuliana Prodan wrote:
>
> On the current structure of caamalg, to work, iv needs to be copied
> before memcpy(iv, req->iv, ivsize), from skcipher_edesc_alloc function.
> For this we need edesc, but this cannot be allocated before knowing how
> much memor
On Thu, 30 May 2019 at 15:53, Ard Biesheuvel wrote:
>
> On Thu, 30 May 2019 at 15:45, Iuliana Prodan wrote:
> >
> > On 5/30/2019 4:34 PM, Herbert Xu wrote:
> > > On Thu, May 30, 2019 at 01:29:41PM +, Iuliana Prodan wrote:
> > >>
> > >> I've tried coping the IV before the extended descriptor a
On Thu, 30 May 2019 at 15:45, Iuliana Prodan wrote:
>
> On 5/30/2019 4:34 PM, Herbert Xu wrote:
> > On Thu, May 30, 2019 at 01:29:41PM +, Iuliana Prodan wrote:
> >>
> >> I've tried coping the IV before the extended descriptor allocation, but
> >> is not working and to make it work will need to
On 5/30/2019 4:34 PM, Herbert Xu wrote:
> On Thu, May 30, 2019 at 01:29:41PM +, Iuliana Prodan wrote:
>>
>> I've tried coping the IV before the extended descriptor allocation, but
>> is not working and to make it work will need to make more changes in
>> CAAM. We need the original iv, and if we
On Thu, May 30, 2019 at 01:29:41PM +, Iuliana Prodan wrote:
>
> I've tried coping the IV before the extended descriptor allocation, but
> is not working and to make it work will need to make more changes in
> CAAM. We need the original iv, and if we move it before
> skcipher_edesc_alloc we l
On 5/30/2019 1:16 AM, Ard Biesheuvel wrote:
> On Wed, 29 May 2019 at 22:27, Eric Biggers wrote:
>>
>> On Wed, May 29, 2019 at 08:10:56PM +0300, Iuliana Prodan wrote:
>>> The generic GCM driver should ensure that whatever it passes into
>>> scatterlists is safe for non-cache coherent DMA.
>>> The i
On Thu, May 30, 2019 at 01:18:34PM +, Horia Geanta wrote:
>
> I guess there are only two options:
> -either cache line sharing is avoided OR
> -users need to be *aware* they are sharing the cache line and some rules /
> assumptions are in place on how to safely work on the data
No there is a t
On Thu, 30 May 2019 at 15:18, Horia Geanta wrote:
>
> On 5/30/2019 11:08 AM, Ard Biesheuvel wrote:
> > On Thu, 30 May 2019 at 09:46, Horia Geanta wrote:
> >>
> >> On 5/30/2019 8:34 AM, Herbert Xu wrote:
> >>> On Wed, May 29, 2019 at 01:27:28PM -0700, Eric Biggers wrote:
>
> So what abou
On 5/30/2019 11:08 AM, Ard Biesheuvel wrote:
> On Thu, 30 May 2019 at 09:46, Horia Geanta wrote:
>>
>> On 5/30/2019 8:34 AM, Herbert Xu wrote:
>>> On Wed, May 29, 2019 at 01:27:28PM -0700, Eric Biggers wrote:
So what about the other places that also pass an IV located next to the
d
On Thu, 30 May 2019 at 09:46, Horia Geanta wrote:
>
> On 5/30/2019 8:34 AM, Herbert Xu wrote:
> > On Wed, May 29, 2019 at 01:27:28PM -0700, Eric Biggers wrote:
> >>
> >> So what about the other places that also pass an IV located next to the
> >> data,
> >> like crypto/ccm.c and crypto/adiantum.c
On 5/30/2019 8:34 AM, Herbert Xu wrote:
> On Wed, May 29, 2019 at 01:27:28PM -0700, Eric Biggers wrote:
>>
>> So what about the other places that also pass an IV located next to the data,
>> like crypto/ccm.c and crypto/adiantum.c? If we're actually going to make
>> this a
Fix for ccm is WIP.
We
On Wed, May 29, 2019 at 01:27:28PM -0700, Eric Biggers wrote:
>
> So what about the other places that also pass an IV located next to the data,
> like crypto/ccm.c and crypto/adiantum.c? If we're actually going to make
> this a
> new API requirement, then we need to add a debugging option that ma
On Wed, 29 May 2019 at 22:27, Eric Biggers wrote:
>
> On Wed, May 29, 2019 at 08:10:56PM +0300, Iuliana Prodan wrote:
> > The generic GCM driver should ensure that whatever it passes into
> > scatterlists is safe for non-cache coherent DMA.
> > The issue was seen while running GCM on CAAM driver.
On Wed, May 29, 2019 at 08:10:56PM +0300, Iuliana Prodan wrote:
> The generic GCM driver should ensure that whatever it passes into
> scatterlists is safe for non-cache coherent DMA.
> The issue was seen while running GCM on CAAM driver. But, since CAAM
> does not support GHASH on i.MX6, only CTR s
43 matches
Mail list logo
