From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9B55EC433EF for ; Fri, 11 Feb 2022 14:03:00 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 5A02683A79; Fri, 11 Feb 2022 15:02:58 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=reject dis=none) header.from=dh-electronics.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=dh-electronics.com header.i=@dh-electronics.com header.b="t0Q83FW4"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 30CB183A8D; Fri, 11 Feb 2022 15:02:57 +0100 (CET) Received: from mx3.securetransport.de (mx3.securetransport.de [116.203.31.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 3BF9483A2B for ; Fri, 11 Feb 2022 15:02:54 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=reject dis=none) header.from=dh-electronics.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=jneuhauser@dh-electronics.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dh-electronics.com; s=dhelectronicscom; t=1644588157; bh=folowldnSoS4QZcQ+pRnf1aiP+QEolwCi7FNsTMYN0g=; h=From:To:CC:Subject:Date:From; b=t0Q83FW4Ib+/08anWcLtX6VmkGYusAqYZcnU/7qV2zcJ21UvtTtgkhK+yNSwTi+/z ds2mfApgD7idHnfeRnFA7ggfp87JEwnbPREh8txhrFYmmsW2+h463HPmqtKoc1GTo2 Ckbgqcq/yteaP/OmNtgKLI80KtFSFzhnvcA3IpWTix5NFeEQ3i3ZqKBJXBI+L1Qiuz Ex8Cz7di8vmlnbqOBZ+MlcMzamFpY2NSOnjAqfGOey7e/CaADAFzESnveLFG0gjJkl bO7jD9DuXh9CT5WDnJhDHtiPvSf7etkLHR4An+Z1g4VdMRaAQN5fOBi0ivnS10RJoH AmlG1z9rcUdGw== X-secureTransport-forwarded: yes From: Johann Neuhauser Complaints-To: abuse@cubewerk.de To: "patrick.delaunay@foss.st.com" , "Patrice Chotard" CC: "u-boot@lists.denx.de" Subject: STM32MP: Can't lock PHK fuses through U-Boot cmd's "stm32key" or "fuse" Thread-Topic: STM32MP: Can't lock PHK fuses through U-Boot cmd's "stm32key" or "fuse" Thread-Index: AdgfTipwApmH7kw/SI+0KqKvDXjCtA== Date: Fri, 11 Feb 2022 14:02:22 +0000 Message-ID: <1133c192473b46f1998fb3415bf7dbf2@dh-electronics.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.5 at phobos.denx.de X-Virus-Status: Clean Hello Patrick, Patrice and other devs, I'm trying to roll out secure boot with U-Boot v2022.01 only. The boot flow should be like: BootROM -(signed STM32 image)-> U-Boot SPL -(signed fit)-> U-Boot -(signed = fit)-> Linux Everything except the first part in the chain is working as expected. I've used the U-Boot cmd "stm32key" to programm the file "publicKeyhash.bin= ", but the command failed with: "Lock OTP 24 failed". Here are the excact commands with output (hash values are replaced by xxxxx= xxx): STM32MP> load mmc 0:4 ${loadaddr} publicKeyhash.bin STM32MP> stm32key read ${loadaddr} Read KEY at 0xc2000000 OTP value 24: xxxxxxxx OTP value 25: xxxxxxxx OTP value 26: xxxxxxxx OTP value 27: xxxxxxxx OTP value 28: xxxxxxxx OTP value 29: xxxxxxxx OTP value 30: xxxxxxxx OTP value 31: xxxxxxxx STM32MP> stm32key fuse -y ${loadaddr} Lock OTP 24 failed A second call failed because the word 24 is already fused and not locked! STM32MP> stm32key fuse ${loadaddr} OTP HASH 24: xxxxxxxx lock : 0 OTP HASH 25: 0 lock : 0 OTP HASH 26: 0 lock : 0 OTP HASH 27: 0 lock : 0 OTP HASH 28: 0 lock : 0 OTP HASH 29: 0 lock : 0 OTP HASH 30: 0 lock : 0 OTP HASH 31: 0 lock : 0 OTP 0: closed status: 0 lock : 0 Hash of key is not locked! Error: can't fuse again the OTP After this failed attempt, I tried to fuse the hash with the command "fuse"= , like: STM32MP> fuse prog -y 0 0x18 0x4e31bbcd STM32MP> fuse prog -y 0 0x19 0x51e827dd STM32MP> fuse prog -y 0 0x1a 0x3511f521 STM32MP> fuse prog -y 0 0x1b 0xfd9c11a2 STM32MP> fuse prog -y 0 0x1c 0x5b997b82 STM32MP> fuse prog -y 0 0x1d 0x8150adc5 STM32MP> fuse prog -y 0 0x1e 0xa9c68fa9 STM32MP> fuse prog -y 0 0x1f 0x72a3ba74 Which gives me a matching "stm32key read" =3D=3D "stm32key read ${loadaddr}= ", except that the fuses aren't locked. If I wanna lock the fuses with, it always fails with "ERROR": STM32MP> fuse prog -y 0 0x10000018 1 1 1 1 1 1 1 1 Programming bank 0 word 0x10000018 to 0x00000001... ERROR According to the reference manual, chapter 4, only writes to the shadow reg= isters aren't allowed! Do you have any clue why locking the fuses isn't possilbe either with "stm3= 2key" or with "fuse"? The next thing is, that I can't authenticate any signed STM32 images with t= he non locked PHK fuses. And no, I haven't closed the device already nor have I locked/fused any oth= er fuses. I've implemented a authentication status output inside "arch/arm/mach-stm32= mp/spl.c" like in TF-A "plat/st/stm32mp1/bl2_plat_setup.c", which I'll probably mainl= ine into U-Boot. I'm using a STM32MP157C on a DHCOM with PDK2 from DH electronics GmbH. Best regards and a nice weekend, Johann Neuhauser DH electronics GmbH | Am Anger 8 | 83346 Bergen | Germany | Fon: +49 8662 4= 882 0 Board of Management: Stefan Daxenberger, Helmut Henschke | HRB Traunstein 9= 602