All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@konsulko.com>
To: Simon Glass <sjg@chromium.org>
Cc: Daniel Golle <daniel@makrotopia.org>,
	Ludwig Nussel <ludwig.nussel@siemens.com>,
	Anton Ivanov <anton@binarly.io>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	Marek Vasut <marek.vasut@mailbox.org>,
	Quentin Schulz <quentin.schulz@cherry.de>,
	Wolfgang Wallner <wolfgang.wallner@at.abb.com>,
	Randolph Sapp <rs@ti.com>, Francois Berder <fberder@outlook.fr>,
	u-boot@lists.denx.de
Subject: Re: [PATCH 3/3] test: fit: verify dm-verity roothash is covered by the config signature
Date: Tue, 14 Jul 2026 10:46:47 -0600	[thread overview]
Message-ID: <20260714164647.GA749385@bill-the-cat> (raw)
In-Reply-To: <CAFLszTjfcmPuUnmVg60pVzsnzSm0kPn3zLL7GMkCTpUyHCQUZw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2554 bytes --]

On Tue, Jul 14, 2026 at 06:17:11AM -0600, Simon Glass wrote:
> Hi Daniel,
> 
> On 2026-07-12T00:33:05, Daniel Golle <daniel@makrotopia.org> wrote:
> > test: fit: verify dm-verity roothash is covered by the config signature
> >
> > A dm-verity protected filesystem image is not hashed by U-Boot; its
> > integrity is delegated to the kernel, which trusts the roothash taken
> > from the FIT dm-verity subnode. For that chain of trust to hold, the
> > roothash (and salt) must be part of the region covered by the
> > configuration signature, otherwise an attacker can replace both the
> > filesystem and the roothash while keeping the signature valid.
> >
> > Add two independent checks of this property:
> >
> >  - test/py/tests/test_fit_verity_sign.py signs a configuration that
> >    references a filesystem image carrying a dm-verity subnode, then
> >    confirms that tampering the roothash or the salt is rejected by
> >    fit_check_sign. A control that tampers a byte known to be signed
> >    proves the check can fail.
> >
> >  - test/boot/fit_verity.c gains a runtime unit test that builds the
> >    exact node list the configuration signature is computed over,
> >    turns it into hashed regions and checks both that the roothash
> > [...]
> >
> > boot/image-fit-sig.c                  |  25 +++--
> >  include/image.h                       |  25 +++++
> >  test/boot/fit_verity.c                | 194 ++++++++++++++++++++++++++++++++++
> >  test/py/tests/test_fit_verity_sign.py | 162 ++++++++++++++++++++++++++++
> >  4 files changed, 399 insertions(+), 7 deletions(-)
> 
> Somehow I didn't get this email, but I'll try to reply here.
> 
> > diff --git a/boot/image-fit-sig.c b/boot/image-fit-sig.c
> > @@ -340,8 +340,19 @@ static int fit_config_add_hash(const void *fit, int image_noffset,
> > +#if CONFIG_IS_ENABLED(UNIT_TEST)
> > +#define VISIBLE_IF_UT
> > +#else
> > +#define VISIBLE_IF_UT static
> > +#endif
> 
> Tom commented on this, but I'll just add this. Linux has
> VISIBLE_IF_KUNIT but in U-Boot so far we just stop the static when the
> function is needed elsewhere. LTO can be used to avoid the code-size
> increase, for platforms that want it.

As part of why this should be its own discussion, a quick look at
VISIBLE_IF_KUNIT in the kernel leads me to think it's not quite the same
set of needs, or if so there's a lot more architectural enforcement
around what is/isn't exposed just for testing, which we lack today.
Talking about LTO isn't relevant here.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

      reply	other threads:[~2026-07-14 16:46 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-12  0:33 [PATCH 0/3] boot: fit: authenticate the dm-verity roothash Daniel Golle
2026-07-12  0:33 ` [PATCH 1/3] boot: fit: factor out node-path collection in fit_config_add_hash() Daniel Golle
2026-07-13 22:08   ` Tom Rini
2026-07-14 12:17   ` Simon Glass
2026-07-12  0:33 ` [PATCH 2/3] boot: fit: cover the dm-verity roothash with the config signature Daniel Golle
2026-07-13 22:08   ` Tom Rini
2026-07-14 12:17   ` Simon Glass
2026-07-12  0:33 ` [PATCH 3/3] test: fit: verify dm-verity roothash is covered by " Daniel Golle
2026-07-13 22:08   ` Tom Rini
2026-07-14 12:17     ` Simon Glass
2026-07-14 16:46       ` Tom Rini [this message]

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=20260714164647.GA749385@bill-the-cat \
    --to=trini@konsulko.com \
    --cc=anton@binarly.io \
    --cc=daniel@makrotopia.org \
    --cc=fberder@outlook.fr \
    --cc=ludwig.nussel@siemens.com \
    --cc=marek.vasut@mailbox.org \
    --cc=neil.armstrong@linaro.org \
    --cc=quentin.schulz@cherry.de \
    --cc=rs@ti.com \
    --cc=sjg@chromium.org \
    --cc=u-boot@lists.denx.de \
    --cc=wolfgang.wallner@at.abb.com \
    /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.