linux-kernel - Re: [v5 PATCH 7/7] crypto: stm32 - Save and restore between each request

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZAgDku9htWcetafb@gondor.apana.org.au>
Date:   Wed, 8 Mar 2023 11:40:02 +0800
From:   Herbert Xu <herbert@...dor.apana.org.au>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Lionel Debieve <lionel.debieve@...s.st.com>,
        Li kunyu <kunyu@...china.com>, davem@...emloft.net,
        linux-arm-kernel@...ts.infradead.org, linux-crypto@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        linux-stm32@...md-mailman.stormreply.com, mcoquelin.stm32@...il.com
Subject: Re: [v5 PATCH 7/7] crypto: stm32 - Save and restore between each
 request

On Wed, Mar 08, 2023 at 11:23:24AM +0800, Herbert Xu wrote:
>
> Nevermind, I know why it doesn't work.  It's specific to ux500
> where you're polling the DCAL bit.  But the DCAL bit only works
> for the final hash, it doesn't work for the intermediate state.
> 
> Let me check how the old ux500 handled this case.

Hmm, it seems to use the same bit.  I guess the meaning must be
different with ux500.

Could you check for me which wait_busy() call is actually failing?
Is it the one I added right before we save the state, or is it
something else?

If it's something perhaps we aren't restoring the state in the
right way, because the stm32 state restoring code is quite different
compared to the ux500 code.

Thanks,
-- 
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt