From: Horia Geanta <horia.geanta@nxp.com>
To: Andrey Smirnov <andrew.smirnov@gmail.com>,
"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>
Cc: Chris Healy <cphealy@gmail.com>,
Lucas Stach <l.stach@pengutronix.de>,
Herbert Xu <herbert@gondor.apana.org.au>,
Iuliana Prodan <iuliana.prodan@nxp.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
dl-linux-imx <linux-imx@nxp.com>
Subject: Re: [PATCH v4 2/6] crypto: caam - enable prediction resistance in HRWNG
Date: Tue, 26 Nov 2019 09:13:38 +0000 [thread overview]
Message-ID: <VI1PR0402MB348521C01FBACF44C531C7CD98450@VI1PR0402MB3485.eurprd04.prod.outlook.com> (raw)
In-Reply-To: 20191121155554.1227-3-andrew.smirnov@gmail.com
On 11/21/2019 5:56 PM, Andrey Smirnov wrote:
> Instantiate CAAM RNG with prediction resistance enabled to improve its
> quality.
>
It's worth noting there are two RNG operations being changed:
-instantiation
-generation
Generation with prediction resistance (PR) is only supported on
RNG state handles instantiated with PR option.
Using PR when generating randomness effectively forces a reseed
of the DRBG / PRNG - that's how quality is improved.
> diff --git a/drivers/crypto/caam/caamrng.c b/drivers/crypto/caam/caamrng.c
> index e8baacaabe07..6dde8ae3cd9b 100644
> --- a/drivers/crypto/caam/caamrng.c
> +++ b/drivers/crypto/caam/caamrng.c
> @@ -202,7 +202,8 @@ static inline int rng_create_sh_desc(struct caam_rng_ctx *ctx)
> init_sh_desc(desc, HDR_SHARE_SERIAL);
>
> /* Generate random bytes */
> - append_operation(desc, OP_ALG_ALGSEL_RNG | OP_TYPE_CLASS1_ALG);
> + append_operation(desc, OP_ALG_ALGSEL_RNG | OP_TYPE_CLASS1_ALG |
> + OP_ALG_PR_ON);
>
> /* Store bytes */
> append_seq_fifo_store(desc, RN_BUF_SIZE, FIFOST_TYPE_RNGSTORE);
> diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
> index df4db10e9fca..a1c879820286 100644
> --- a/drivers/crypto/caam/ctrl.c
> +++ b/drivers/crypto/caam/ctrl.c
> @@ -36,7 +36,8 @@ static void build_instantiation_desc(u32 *desc, int handle, int do_sk)
> init_job_desc(desc, 0);
>
> op_flags = OP_TYPE_CLASS1_ALG | OP_ALG_ALGSEL_RNG |
> - (handle << OP_ALG_AAI_SHIFT) | OP_ALG_AS_INIT;
> + (handle << OP_ALG_AAI_SHIFT) | OP_ALG_AS_INIT |
> + OP_ALG_PR_ON;
>
> /* INIT RNG in non-test mode */
> append_operation(desc, op_flags);
> @@ -275,11 +276,12 @@ static int instantiate_rng(struct device *ctrldev, int state_handle_mask,
> return -ENOMEM;
>
> for (sh_idx = 0; sh_idx < RNG4_MAX_HANDLES; sh_idx++) {
> + const u32 rdsta_mask = (RDSTA_PR0 | RDSTA_IF0) << sh_idx;
> /*
> * If the corresponding bit is set, this state handle
> * was initialized by somebody else, so it's left alone.
> */
> - if ((1 << sh_idx) & state_handle_mask)
> + if (rdsta_mask & state_handle_mask)
> continue;
>
If a state handle was previously instantiated (e.g. by U-boot),
but without prediction resistance support, it won't be re-instantiated
("continue" / skip above).
The result is using a state handle without PR support.
Due to this, when extracting / generating randomness (in caamrng.c) with
the PR bit set, job descriptor will generate a prediction resistance error.
IMO the proper thing to do in case a state handle was instantiated
without PR support is to re-instantiate it.
There's an assumption here though: kernel handles RNG initialization only
in some cases, when it's effectively "controlling" it.
In cases when it's not, like when Management Complex (MC) f/w is present
(or OP-TEE OS, SECO etc.), kernel skips RNG init and only uses the job ring
interface for random generation.
==> MC, OP-TEE, SECO etc. have to be updated to initialize
RNG state handles with PR support
Horia
next prev parent reply other threads:[~2019-11-26 9:13 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-21 15:55 [PATCH v4 0/6] enable CAAM's HWRNG as default Andrey Smirnov
2019-11-21 15:55 ` [PATCH v4 1/6] crypto: caam - RNG4 TRNG errata Andrey Smirnov
2019-11-25 8:02 ` Horia Geanta
2019-11-25 13:21 ` Andrey Smirnov
2019-11-26 7:44 ` Horia Geanta
2019-11-21 15:55 ` [PATCH v4 2/6] crypto: caam - enable prediction resistance in HRWNG Andrey Smirnov
2019-11-26 9:13 ` Horia Geanta [this message]
2019-11-21 15:55 ` [PATCH v4 3/6] crypto: caam - allocate RNG instantiation descriptor with GFP_DMA Andrey Smirnov
2019-11-21 15:55 ` [PATCH v4 4/6] crypto: caam - move RNG presence check into a shared function Andrey Smirnov
2019-11-21 15:55 ` [PATCH v4 5/6] crypto: caam - replace DRNG with TRNG for use with hw_random Andrey Smirnov
2019-11-21 15:55 ` [PATCH v4 6/6] crypto: caam - expose SEC4 DRNG via crypto RNG API Andrey Smirnov
2019-11-23 15:29 ` [PATCH v4 0/6] enable CAAM's HWRNG as default Chris Healy
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=VI1PR0402MB348521C01FBACF44C531C7CD98450@VI1PR0402MB3485.eurprd04.prod.outlook.com \
--to=horia.geanta@nxp.com \
--cc=andrew.smirnov@gmail.com \
--cc=cphealy@gmail.com \
--cc=herbert@gondor.apana.org.au \
--cc=iuliana.prodan@nxp.com \
--cc=l.stach@pengutronix.de \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).