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]

Date:   Fri, 10 Mar 2023 09:07:04 +0100
From:   Linus Walleij <linus.walleij@...aro.org>
To:     David Laight <David.Laight@...lab.com>
Cc:     Herbert Xu <herbert@...dor.apana.org.au>,
        Lionel Debieve <lionel.debieve@...s.st.com>,
        Li kunyu <kunyu@...china.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-stm32@...md-mailman.stormreply.com" 
        <linux-stm32@...md-mailman.stormreply.com>,
        "mcoquelin.stm32@...il.com" <mcoquelin.stm32@...il.com>
Subject: Re: [v5 PATCH 7/7] crypto: stm32 - Save and restore between each request

On Thu, Mar 9, 2023 at 11:19 PM David Laight <David.Laight@...lab.com> wrote:

> > But actually I think the bug will never trigger, because the datasheet
> > for the DB8500 (Ux500) says this:
> >
> > "Then the message can be sent, by writing it word per word into the
> > HASH_DIN register.
> > When a block of 512 bits, i.e. 16 words have been written, a partial
> > digest computation will
> > start upon writing the first data of the next block. The AHB bus will
> > be busy for 82 cycles for
> > SHA-1 algorithm (66 cycles for SHA-256 algorithm)."
>
> What speed clock is that?

133 MHz.

> 4 or 5 extra clocks/word may (or may not) be significant.
>
> In terms of latency it may be noise compared to some PCIe
> reads done by hardware interrupt handlers.
> Some slow PCIe targets (like the fpga one we use) pretty
> much take 1us to handle a read cycle.

So in this case it's 1/133M s = 8ns cycle time, 82 in worst case,
so 82*8 = 656 ns < 1 us.

Yours,
Linus Walleij