linux-kernel - Re: [PATCH v8 4/8] crypto: caam

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: <a662c74d-96d9-dd76-2a5c-627973898a89@nxp.com>
Date:   Tue, 17 Mar 2020 23:37:32 +0200
From:   Horia Geantă <horia.geanta@....com>
To:     Andrey Smirnov <andrew.smirnov@...il.com>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>
Cc:     Chris Healy <cphealy@...il.com>,
        Lucas Stach <l.stach@...gutronix.de>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        Iuliana Prodan <iuliana.prodan@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        dl-linux-imx <linux-imx@....com>
Subject: Re: [PATCH v8 4/8] crypto: caam - simplify RNG implementation

On 3/16/2020 5:01 PM, Andrey Smirnov wrote:
> Rework CAAM RNG implementation as follows:
> 
> - Make use of the fact that HWRNG supports partial reads and will
> handle such cases gracefully by removing recursion in caam_read()
> 
> - Convert blocking caam_read() codepath to do a single blocking job
> read directly into requested buffer, bypassing any intermediary
> buffers
> 
> - Convert async caam_read() codepath into a simple single
> reader/single writer FIFO use-case, thus simplifying concurrency
> handling and delegating buffer read/write position management to KFIFO
> subsystem.
> 
> - Leverage the same low level RNG data extraction code for both async
> and blocking caam_read() scenarios, get rid of the shared job
> descriptor and make non-shared one as a simple as possible (just
> HEADER + ALGORITHM OPERATION + FIFO STORE)
> 
> - Split private context from DMA related memory, so that the former
> could be allocated without GFP_DMA.
> 
> NOTE: On its face value this commit decreased throughput numbers
> reported by
> 
>   dd if=/dev/hwrng of=/dev/null bs=1 count=100K [iflag=nonblock]
> 
> by about 15%, however commits that enable prediction resistance and
> limit JR total size impact the performance so much and move the
> bottleneck such as to make this regression irrelevant.
> 
> NOTE: On the bright side, this commit reduces RNG in kernel DMA buffer
> memory usage from 2 x RN_BUF_SIZE (~256K) to 32K.
> 
> Signed-off-by: Andrey Smirnov <andrew.smirnov@...il.com>
> Cc: Chris Healy <cphealy@...il.com>
> Cc: Lucas Stach <l.stach@...gutronix.de>
> Cc: Horia Geantă <horia.geanta@....com>
> Cc: Herbert Xu <herbert@...dor.apana.org.au>
> Cc: Iuliana Prodan <iuliana.prodan@....com>
> Cc: linux-crypto@...r.kernel.org
> Cc: linux-kernel@...r.kernel.org
> Cc: linux-imx@....com
Reviewed-by: Horia Geantă <horia.geanta@....com>

Thanks,
Horia