All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Horia Geantă" <horia.geanta@nxp.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
	"David S. Miller" <davem@davemloft.net>,
	"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>
Subject: Re: [PATCH 16/18] crypto: talitos - do hw_context DMA mapping outside the requests
Date: Tue, 20 Feb 2018 11:32:25 +0000	[thread overview]
Message-ID: <VI1PR0402MB3342B99A1BEA5622F29F79EF98CF0@VI1PR0402MB3342.eurprd04.prod.outlook.com> (raw)
In-Reply-To: 20180220103436.GA20571@gondor.apana.org.au

On 2/20/2018 12:34 PM, Herbert Xu wrote:
> On Mon, Feb 19, 2018 at 01:16:30PM +0000, Horia Geantă wrote:
>>
>>> And what about ALGIF path from user space ?
>>> What if the user never calls the last sendmsg() which will call 
>>> hash_finup() ?
>>>
>> User is expected to follow the rules of the crypto API.
>> Of course, kernel won't (or at least shouldn't) crash in case of misuse.
>> However, in these cases some resources might not be freed - it's unavoidable.
> 
> the crypto API does not require the presence of a finalisation.
> It is entirely optional.  So leaving resources pinned down until
> final/finup occurs is unacceptable, both from user-space and the
> kernel.
> 
If final/finup is optional, how is the final hash supposed to be retrieved?

According to documentation, these are the accepted flows (with the option to
export/import a partial hash b/w update and final/finup):

.init() -> .update() -> .final()
            ^    |         |
            '----'         '---> HASH

.init() -> .update() -> .finup()
            ^    |         |
            '----'         '---> HASH

           .digest()
               |
               '---------------> HASH

Note that digest() is not an issue in the case we are discussing, since resource
allocation happens only in init().

Thanks,
Horia

WARNING: multiple messages have this Message-ID (diff)
From: "Horia Geantă" <horia.geanta@nxp.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Christophe LEROY <christophe.leroy@c-s.fr>,
	"David S. Miller" <davem@davemloft.net>,
	"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH 16/18] crypto: talitos - do hw_context DMA mapping outside the requests
Date: Tue, 20 Feb 2018 11:32:25 +0000	[thread overview]
Message-ID: <VI1PR0402MB3342B99A1BEA5622F29F79EF98CF0@VI1PR0402MB3342.eurprd04.prod.outlook.com> (raw)
In-Reply-To: 20180220103436.GA20571@gondor.apana.org.au

On 2/20/2018 12:34 PM, Herbert Xu wrote:
> On Mon, Feb 19, 2018 at 01:16:30PM +0000, Horia Geantă wrote:
>>
>>> And what about ALGIF path from user space ?
>>> What if the user never calls the last sendmsg() which will call 
>>> hash_finup() ?
>>>
>> User is expected to follow the rules of the crypto API.
>> Of course, kernel won't (or at least shouldn't) crash in case of misuse.
>> However, in these cases some resources might not be freed - it's unavoidable.
> 
> the crypto API does not require the presence of a finalisation.
> It is entirely optional.  So leaving resources pinned down until
> final/finup occurs is unacceptable, both from user-space and the
> kernel.
> 
If final/finup is optional, how is the final hash supposed to be retrieved?

According to documentation, these are the accepted flows (with the option to
export/import a partial hash b/w update and final/finup):

.init() -> .update() -> .final()
            ^    |         |
            '----'         '---> HASH

.init() -> .update() -> .finup()
            ^    |         |
            '----'         '---> HASH

           .digest()
               |
               '---------------> HASH

Note that digest() is not an issue in the case we are discussing, since resource
allocation happens only in init().

Thanks,
Horia

WARNING: multiple messages have this Message-ID (diff)
From: "Horia Geantă" <horia.geanta@nxp.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Christophe LEROY <christophe.leroy@c-s.fr>,
	"David S. Miller" <davem@davemloft.net>,
	"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH 16/18] crypto: talitos - do hw_context DMA mapping outside the requests
Date: Tue, 20 Feb 2018 11:32:25 +0000	[thread overview]
Message-ID: <VI1PR0402MB3342B99A1BEA5622F29F79EF98CF0@VI1PR0402MB3342.eurprd04.prod.outlook.com> (raw)
In-Reply-To: 20180220103436.GA20571@gondor.apana.org.au

On 2/20/2018 12:34 PM, Herbert Xu wrote:=0A=
> On Mon, Feb 19, 2018 at 01:16:30PM +0000, Horia Geant=E3 wrote:=0A=
>>=0A=
>>> And what about ALGIF path from user space ?=0A=
>>> What if the user never calls the last sendmsg() which will call =0A=
>>> hash_finup() ?=0A=
>>>=0A=
>> User is expected to follow the rules of the crypto API.=0A=
>> Of course, kernel won't (or at least shouldn't) crash in case of misuse.=
=0A=
>> However, in these cases some resources might not be freed - it's unavoid=
able.=0A=
> =0A=
> the crypto API does not require the presence of a finalisation.=0A=
> It is entirely optional.  So leaving resources pinned down until=0A=
> final/finup occurs is unacceptable, both from user-space and the=0A=
> kernel.=0A=
> =0A=
If final/finup is optional, how is the final hash supposed to be retrieved?=
=0A=
=0A=
According to documentation, these are the accepted flows (with the option t=
o=0A=
export/import a partial hash b/w update and final/finup):=0A=
=0A=
.init() -> .update() -> .final()=0A=
            ^    |         |=0A=
            '----'         '---> HASH=0A=
=0A=
.init() -> .update() -> .finup()=0A=
            ^    |         |=0A=
            '----'         '---> HASH=0A=
=0A=
           .digest()=0A=
               |=0A=
               '---------------> HASH=0A=
=0A=
Note that digest() is not an issue in the case we are discussing, since res=
ource=0A=
allocation happens only in init().=0A=
=0A=
Thanks,=0A=
Horia=0A=

  reply	other threads:[~2018-02-20 11:32 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-06 13:04 [PATCH 00/18] crypto: talitos - fixes and performance improvement Christophe Leroy
2017-10-06 13:04 ` [PATCH 01/18] crypto: talitos - fix AEAD test failures Christophe Leroy
2017-10-06 13:04 ` [PATCH 02/18] crypto: talitos - fix memory corruption on SEC2 Christophe Leroy
2017-10-06 13:04 ` [PATCH 03/18] crypto: talitos - fix setkey to check key weakness Christophe Leroy
2017-10-06 13:04 ` [PATCH 04/18] crypto: talitos - fix AEAD for sha224 on non sha224 capable chips Christophe Leroy
2017-10-06 13:04 ` [PATCH 05/18] crypto: talitos - fix use of sg_link_tbl_len Christophe Leroy
2017-10-06 13:04 ` [PATCH 06/18] crypto: talitos - fix ctr-aes-talitos Christophe Leroy
2017-10-06 13:04 ` [PATCH 07/18] crypto: talitos - zeroize the descriptor with memset() Christophe Leroy
2017-10-06 13:04 ` [PATCH 08/18] crypto: talitos - declare local functions static Christophe Leroy
2017-10-06 13:04 ` [PATCH 09/18] crypto: talitos - use devm_kmalloc() Christophe Leroy
2017-10-06 13:04 ` [PATCH 10/18] crypto: talitos - use of_property_read_u32() Christophe Leroy
2017-10-06 13:04 ` [PATCH 11/18] crypto: talitos - use devm_ioremap() Christophe Leroy
2017-10-06 13:04 ` [PATCH 12/18] crypto: talitos - don't check the number of channels at each interrupt Christophe Leroy
2017-10-06 13:04 ` [PATCH 13/18] crypto: talitos - remove to_talitos_ptr_len() Christophe Leroy
2017-10-06 13:04 ` [PATCH 14/18] crypto: talitos - simplify tests in ipsec_esp() Christophe Leroy
2017-10-06 13:05 ` [PATCH 15/18] crypto: talitos - DMA map key in setkey() Christophe Leroy
2017-10-06 13:05 ` [PATCH 16/18] crypto: talitos - do hw_context DMA mapping outside the requests Christophe Leroy
2018-02-07 14:39   ` Horia Geantă
2018-02-07 14:39     ` Horia Geantă
2018-02-17 16:32     ` Christophe LEROY
2018-02-18 17:14       ` Horia Geantă
2018-02-18 17:14         ` Horia Geantă
2018-02-19  7:58         ` Christophe LEROY
2018-02-19  7:58           ` Christophe LEROY
2018-02-19  8:30           ` Horia Geantă
2018-02-19  8:30             ` Horia Geantă
2018-02-19  8:30             ` Horia Geantă
2018-02-19  9:14             ` Christophe LEROY
2018-02-19  9:14               ` Christophe LEROY
2018-02-19 13:16               ` Horia Geantă
2018-02-19 13:16                 ` Horia Geantă
2018-02-19 13:16                 ` Horia Geantă
2018-02-20 10:34                 ` Herbert Xu
2018-02-20 10:34                   ` Herbert Xu
2018-02-20 11:32                   ` Horia Geantă [this message]
2018-02-20 11:32                     ` Horia Geantă
2018-02-20 11:32                     ` Horia Geantă
2018-02-22 11:47                     ` Herbert Xu
2018-02-22 11:47                       ` Herbert Xu
2018-02-22 12:29                       ` Horia Geantă
2018-02-22 12:29                         ` Horia Geantă
2018-02-22 12:29                         ` Horia Geantă
2018-02-22 13:46                         ` Herbert Xu
2018-02-22 13:46                           ` Herbert Xu
2017-10-06 13:05 ` [PATCH 17/18] crypto: talitos - chain in buffered data for ahash on SEC1 Christophe Leroy
2018-03-02 17:27   ` Horia Geantă
2018-03-02 17:27     ` Horia Geantă
2018-03-02 17:42     ` Christophe LEROY
2017-10-06 13:05 ` [PATCH 18/18] crypto: talitos - avoid useless copy Christophe Leroy
2017-10-12 15:19 ` [PATCH 00/18] crypto: talitos - fixes and performance improvement Herbert Xu
2017-12-08 15:20   ` Horia Geantă
2017-12-08 15:20     ` Horia Geantă
2017-12-11 11:07     ` Herbert Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=VI1PR0402MB3342B99A1BEA5622F29F79EF98CF0@VI1PR0402MB3342.eurprd04.prod.outlook.com \
    --to=horia.geanta@nxp.com \
    --cc=davem@davemloft.net \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.