| Message ID | ZAVu/XHbL9IR5D3h@gondor.apana.org.au (mailing list archive) |
|---|---|
| Headers | show |
| Series | crypto: stm32 - Save and restore between each request | expand |
Hi All, Sorry for the very (very very) late response. Thanks for highlighting the issue. I'm worried about the issue seen that we've fixed at our downstream level. We (ST) are currently working on upstreaming the new peripheral update for STM32MP13 that fixed the old issue seen (such as CSR register numbers), and so on.... The issue about the context management relies on a question I've get time to ask you. There is no internal test purpose (using test manager) that really show the need of a hash update that needs to be "self-content". We've seen the issue using openssl use cases that is not using import/export. I'm wondering to understand the real need of import/export in the framework if the request must be safe itself? From hardware point of view, it is a penalty to wait for completion to save the context after each request. I understand the need of multiple hash request in // but I was wondering that it can be managed by the import/export, but it seems I was wrong. The penalty of the context saving will impact all hash requests where, in a runtime context is probably not the most important use case. I'm looking deeper to check with the DMA use case and there is some new HW restriction on the coming hash version that doesn't allow the read of CSR register at some times. BR, Lionel ST Restricted -----Original Message----- From: Herbert Xu <herbert@gondor.apana.org.au> Sent: Monday, March 6, 2023 5:42 AM To: Linus Walleij <linus.walleij@linaro.org> Cc: Lionel Debieve <lionel.debieve@foss.st.com>; Li kunyu <kunyu@nfschina.com>; davem@davemloft.net; linux-arm-kernel@lists.infradead.org; linux-crypto@vger.kernel.org; linux-kernel@vger.kernel.org; linux-stm32@st-md-mailman.stormreply.com; mcoquelin.stm32@gmail.com Subject: [v6 PATCH 0/7] crypto: stm32 - Save and restore between each request On Sat, Mar 04, 2023 at 05:34:04PM +0800, Herbert Xu wrote: > > I've split the patch up into smaller chunks for easier testing. v6 fixes a bug in the finup patch that caused the new data to be discarded instead of hashed. This patch series fixes the import/export functions in the stm32 driver. As usual, a failure in import/export indicates a general bug in the hash driver that may break as soon as two concurrent users show up and hash at the same time using any method other than digest or init+finup. Cheers, -- Email: Herbert Xu <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Tue, Mar 07, 2023 at 02:55:29PM +0100, lionel.debieve@foss.st.com wrote: > > The issue about the context management relies on a question I've get time to > ask you. There is no internal test purpose (using test manager) that really > show the need of a hash update that needs to be "self-content". We've seen Indeed this functionality is sorely missed. It shouldn't be hard to implement, because simply hashing two different requests interleaved with each other should show the problem: init(A) => update(A) => init(B) => update(B) => final(A) => final(B) > the issue using openssl use cases that is not using import/export. > I'm wondering to understand the real need of import/export in the framework > if the request must be safe itself? The hash state is normally stored in the request context. The import/export functions let you save a copy of the state for subsequent processing. The request could then be freed after the export and re-allocated prior to import, or in other contexts the request could be reused for a completely different hash in the time being (init/update/final). > >From hardware point of view, it is a penalty to wait for completion to save > the context after each request. I understand the need of multiple hash > request in // but I was wondering that it can be managed by the > import/export, but it seems I was wrong. The penalty of the context saving > will impact all hash requests where, in a runtime context is probably not > the most important use case. Oh of course we try to avoid unnecessary savings/restoring as much as we can. That's why we encourage users to use finup/digest as much as possible, in which case there may be be no need to save and restore at all. However, if the user has to do a partial update through the update function, then we have to save the state. Cheers,