mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Marco Felsch <m.felsch@pengutronix.de>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Ahmad Fatoum <a.fatoum@pengutronix.de>,
	Barebox List <barebox@lists.infradead.org>
Subject: Re: [PATCH 0/6] implement i.MX93 AHAB secure boot
Date: Thu, 15 Feb 2024 11:12:52 +0100	[thread overview]
Message-ID: <20240215101252.nefqtngf5vxm2a5f@pengutronix.de> (raw)
In-Reply-To: <Zc3ItV4Ak4NDdWPs@pengutronix.de>

On 24-02-15, Sascha Hauer wrote:
> On Wed, Feb 14, 2024 at 07:09:16PM +0100, Ahmad Fatoum wrote:
> > Hello Sascha,
> > 
> > On 13.02.24 16:17, Sascha Hauer wrote:
> > > This adds support for AHAB based secure boot on i.MX93. The user
> > > interface is integrated into the existing hab command used for ealier
> > > i.MX variants. On i.MX93 the hab command can:
> > > 
> > > - read/write the SRK hash
> > > - lock the device
> > > - show lock status of the device
> > > 
> > > Like done with HAB the AHAB events will be shown during boot so that
> > > possible failure events are seen should there be any issues like no
> > > or wrong SRK hash fused or an unsigned image is attempted to be started.
> > > 
> > > Unlike with HAB it is currently not possible to sign the barebox images
> > > directly within the barebox build system. Instead, the images need to be
> > > signed afterwards with the NXP CST tool. I am currently unsure if it's
> > > worth the hassle, as it turned out to be quite straight forward to
> > > integrate the signing process into YOCTO (likely also ptxdist, but I
> > > haven't tried yet). In the end it might be easier than adding another
> > > indirection with tunneling the necessary keys through the barebox build
> > > process. I might be convinced otherwise though.
> > 
> > Could you make the signing inside the barebox build system optional
> > for HAB? Then we could have a prompt symbol that depends on HABv4, e.g.
> > CONFIG_HAB_SIGN_IMAGES or something and disabling that would require
> > external signing like for AHAB. I think this would improve user experience
> > a fair bit, because HAB and AHAB could be handled the same build-system
> > side and it would be easily discoverable in Kconfig that one supports
> > sigining internally and the other doesn't.
> 
> Originally it was a design decision to integrate the signing into
> barebox. I wanted to make barebox self contained and not depend on
> external tools to generate images.
> I am not sure though if anyone really builds signed images without
> the help of a build system. So I had the same thought as well if we
> could let the build system do the signing also for HAB. I haven't looked
> into it what it takes to implement that. One point where it gets
> difficult is our special trick to create signed USB images. We handle
> the DCD table in imx-usb-loader to setup DDR and disable DCD in the
> image. To make that work with signed images we sign an image which
> has the DCD table disabled.

Additional the i.MX8M signing is quite different compared to the i.MX5/6
sigining since only the pbl part is signed and we use symbols to get the
size of the pbl. I'm not saying that it's impossible but we would need
to expose information to the build system.

Regards,
  Marco

> 
> Sascha
> 
> -- 
> Pengutronix e.K.                           |                             |
> Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
> 
> 



  parent reply	other threads:[~2024-02-15 10:14 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-13 15:17 Sascha Hauer
2024-02-13 15:17 ` [PATCH 1/6] hab: drop incomplete i.MX28 support Sascha Hauer
2024-02-13 15:17 ` [PATCH 2/6] hab: drop i.MX35 Sascha Hauer
2024-02-13 15:17 ` [PATCH 3/6] hab: cleanup hab status printing during boot Sascha Hauer
2024-02-13 15:17 ` [PATCH 4/6] hab: pass flags to lockdown_device() Sascha Hauer
2024-02-13 15:17 ` [PATCH 5/6] ARM: i.MX: ele: implement more ELE operations Sascha Hauer
2024-02-13 15:17 ` [PATCH 6/6] hab: implement i.MX9 support Sascha Hauer
2024-02-14 18:09 ` [PATCH 0/6] implement i.MX93 AHAB secure boot Ahmad Fatoum
2024-02-15  8:17   ` Sascha Hauer
2024-02-15  8:29     ` Ahmad Fatoum
2024-02-15  8:36       ` Sascha Hauer
2024-02-15 10:12     ` Marco Felsch [this message]
2024-02-16 11:58 ` Sascha Hauer

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=20240215101252.nefqtngf5vxm2a5f@pengutronix.de \
    --to=m.felsch@pengutronix.de \
    --cc=a.fatoum@pengutronix.de \
    --cc=barebox@lists.infradead.org \
    --cc=s.hauer@pengutronix.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