linux-kernel - [RESEND PATCH 6/6] crypto: caam: detect RNG init when TrustZone is active

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:   Wed, 24 Jan 2018 14:50:35 +0000
From:   Bryan O'Donoghue <pure.logic@...us-software.ie>
To:     horia.geanta@....com, aymen.sghaier@....com,
        linux-crypto@...r.kernel.org, linux-kernel@...r.kernel.org
Cc:     fabio.estevam@....com, peng.fan@....com,
        herbert@...dor.apana.org.au, davem@...emloft.net,
        lukas.auer@...ec.fraunhofer.de, rui.silva@...aro.org,
        ryan.harkin@...aro.org,
        Bryan O'Donoghue <pure.logic@...us-software.ie>
Subject: [RESEND PATCH 6/6] crypto: caam: detect RNG init when TrustZone is active

When TrustZone is enabled on sec4 compatible silicon the first page of the
CAAM is reserved for TrustZone only, this means that access to the deco
registers is restricted and will return zero when read.

The solution to this problem is to initialize the RNG prior to TrustZone
being enabled or to initialize the RNG from a TrustZone context and
simultaneously to ensure that the job-ring registers have been assigned to
the correct non-TrustZone context.

Assigning of the job-ring registers is a task for u-boot or OPTEE/TrustZone
as is the initialization of the RNG. This patch adds logic to detect RNG
initialization if and only if TrustZone has been detected as active on the
CAAM block.

If TrustZone is initialized and the RNG looks to be setup - we mark the RNG
as good to go and continue to load, else we mark the RNG as bad and bail
out.

More detail on the original problem and the split fix between u-boot and
Linux is available in these two threads

Link: https://github.com/OP-TEE/optee_os/issues/1408
Link: https://tinyurl.com/yam5gv9a
Link: https://patchwork.ozlabs.org/cover/865042

Signed-off-by: Bryan O'Donoghue <pure.logic@...us-software.ie>
Cc: "Horia Geantă" <horia.geanta@....com>
Cc: Aymen Sghaier <aymen.sghaier@....com>
Cc: Fabio Estevam <fabio.estevam@....com>
Cc: Peng Fan <peng.fan@....com>
Cc: Herbert Xu <herbert@...dor.apana.org.au>
Cc: "David S. Miller" <davem@...emloft.net>
Cc: Lukas Auer <lukas.auer@...ec.fraunhofer.de>
---
 drivers/crypto/caam/ctrl.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/drivers/crypto/caam/ctrl.c b/drivers/crypto/caam/ctrl.c
index 7fd3bfc..66a7c7e 100644
--- a/drivers/crypto/caam/ctrl.c
+++ b/drivers/crypto/caam/ctrl.c
@@ -711,6 +711,24 @@ static int caam_probe(struct platform_device *pdev)
 			int inst_handles =
 				rd_reg32(&ctrl->r4tst[0].rdsta) &
 								RDSTA_IFMASK;
+
+			/*
+			 * If TrustZone is active then u-boot or the TrustZone
+			 * firmware must have initialized the RNG for us else we
+			 * cannot do so from Linux.
+			 *
+			 * We've previously detected TrustZone so now let's
+			 * detect if the RNG has been initialized.
+			 */
+			if (ctrlpriv->trust_zone) {
+				ret = -ENODEV;
+				if (ctrlpriv->rng4_sh_init || inst_handles)
+					ret = 0;
+				dev_info(dev, "TrustZone active RNG looks %s\n",
+					 ret ? "uninitialized" : "initialized");
+				break;
+			}
+
 			/*
 			 * If either SH were instantiated by somebody else
 			 * (e.g. u-boot) then it is assumed that the entropy
-- 
2.7.4