public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: "Marko Mäkelä" <marko.makela@iki.fi>
To: Philippe Reynes <philippe.reynes@softathome.com>
Cc: jonny.green@keytechinc.com, raymondmaoca@gmail.com, u-boot@lists.denx.de
Subject: Re: [RFC PATCH 0/4] add software ecdsa support
Date: Mon, 9 Feb 2026 18:04:57 +0200	[thread overview]
Message-ID: <aYoFqWew28crCb1i@kehys.lan> (raw)
In-Reply-To: <20260202170307.217200-1-philippe.reynes@softathome.com>

Mon, Feb 02, 2026 at 06:03:03PM +0100, Philippe Reynes wrote:
>I have tested this code with sandbox, and I have
>followed those steps:
>
>0) build u-boot using sandbox_defconfig and adding those options:
>CONFIG_ECDSA_SW=y
>CONFIG_ECDSA_MBEDTLS=y
>CONFIG_ECDSA=y
>CONFIG_ECDSA_VERIFY=y

I believe that I was able to build an ECDSA signed fitImage of a Linux 
kernel. At least "dtc" shows that a signature is present, just like with 
my earlier attempt with RSA.

>1) add a signature node to an its file
>	signature-256 {
>		algo = "sha256,ecdsa256";
>		key-name-hint = "private-key-256";
>	};
>
>2) generate an ecdsa key
>openssl ecparam -name prime256v1 -genkey -noout -out private-key-256.pem
>
>3) create the itb file
>./tools/mkimage -f <file.its> -k . -K arch/sandbox/dts/test.dtb <file.itb>

Step 1) is part of <file.its>, which specifies how a signed payload, 
such as a Linux kernel, is built in <file.itb>, right?

I assume that arch/sandbox/dts/test.dts is the source code for 
arch/sandbox/dts/test.dtb. Would this file correspond to the file 
u-boot.dtb in a non-sandbox environment (in my case, based on 
rpi_4_defconfig)?

For me, mkimage version 2025.01 (as shipped in Debian Sid) would crash 
if I ask it to write the public key to u-boot.dtb using the parameter 
"-K u-boot.dtb". The following statement in do_add() would hit SIGSEGV:

         ret = fdt_setprop_string(fdt, key_node, FIT_KEY_REQUIRED,
                                  info->require_keys);

The function do_add() is invoked by ecdsa_add_verify_data(). For my 
kernel build, I did not yet try a mkimage that is built from the latest 
u-boot. Should that make a difference?

For an earlier experiment with an RSA signed fitImage, I was able to do 
the following:

make -j$(nproc) CROSS_COMPILE=aarch64-linux-gnu- all u-boot.dtb

cp u-boot.dtb u-boot-pubkey.dtb
ALGO=$(scripts/dtc/dtc -I dtb /target/fitImage |grep -A10 signature|
sed -ne "s/\s*algo = \"\(.*\)\";/\1/p")
tools/fdt_add_pubkey -a "$ALGO" -n dev -k . -r conf u-boot-pubkey.dtb
tools/fit_check_sign -f /target/fitImage -k u-boot-pubkey.dtb

make -j$(nproc) CROSS_COMPILE=aarch64-linux-gnu- \
EXT_DTB=u-boot-pubkey.dtb

cp -L u-boot.img /target/

With CONFIG_ECDSA, fdt_add_pubkey would SIGSEGV (unrelated to these 
changes) and fit_check_sign does not appear to be built.

I would appreciate some help in embedding the ECDSA public key to the 
u-boot image, so that I can test this.

Best regards,

	Marko

  parent reply	other threads:[~2026-02-09 16:05 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-02 17:03 [RFC PATCH 0/4] add software ecdsa support Philippe Reynes
2026-02-02 17:03 ` [RFC PATCH 1/4] mbedtls: enable support of ecc Philippe Reynes
2026-02-02 19:03   ` Raymond Mao
2026-02-02 17:03 ` [RFC PATCH 2/4] ecdsa: initial support of ecdsa using mbedtls Philippe Reynes
2026-02-02 17:03 ` [RFC PATCH 3/4] test: lib: sw_ecdsa: add initial test Philippe Reynes
2026-02-02 17:03 ` [RFC PATCH 4/4] drivers: crypto: add software ecdsa support Philippe Reynes
2026-02-02 19:09 ` [RFC PATCH 0/4] " Raymond Mao
2026-02-02 19:44 ` Tom Rini
2026-02-04 19:02 ` Marko Mäkelä
2026-02-04 19:28   ` Raymond Mao
2026-02-05 18:16     ` Marko Mäkelä
2026-02-05 18:47       ` Raymond Mao
2026-02-08 18:37     ` Marko Mäkelä
2026-02-09 16:04 ` Marko Mäkelä [this message]
2026-02-14 19:38   ` Marko Mäkelä
2026-02-15 18:31     ` Marko Mäkelä

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=aYoFqWew28crCb1i@kehys.lan \
    --to=marko.makela@iki.fi \
    --cc=jonny.green@keytechinc.com \
    --cc=philippe.reynes@softathome.com \
    --cc=raymondmaoca@gmail.com \
    --cc=u-boot@lists.denx.de \
    /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