All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.