[PATCH v3] mkimage: Default to 8-byte alignment for DTBs added via -b argument

[Tom Rini]

On Fri, Jan 23, 2026 at 11:51:59AM +0100, Marek Vasut wrote:
> On 1/23/26 11:40 AM, Anshul Dalal wrote:
> > Hi Marek,
> > 
> > On Fri Jan 23, 2026 at 3:57 PM IST, Marek Vasut wrote:
> > > On 1/23/26 4:32 AM, Beleswar Prasad Padhi wrote:
> > > > 
> > > > On 23/01/26 00:33, Marek Vasut wrote:
> > > > > On 1/22/26 6:45 PM, Tom Rini wrote:
> > > > > > On Thu, Jan 22, 2026 at 10:52:47PM +0530, Beleswar Padhi wrote:
> > > > > > 
> > > > > > > When CONFIG_SPL_MULTI_DTB_FIT is enabled, multiple device trees are
> > > > > > > packed inside the multidtb.fit FIT image. While the individual DTBs
> > > > > > > and the FIT image start address are 8-byte aligned, the DTBs embedded
> > > > > > > within the FIT image are not guaranteed to maintain 8-byte alignment.
> > > > > > > 
> > > > > > > This misalignment causes -FDT_ERR_ALIGNMENT failure in
> > > > > > > setup_multi_dtb_fit() when locating the next available DTB within the
> > > > > > > FIT blob and setting gd->fdt_blob, because of the recent libfdt
> > > > > > > hardening since commit 0535e46d55d7 ("scripts/dtc: Update to upstream
> > > > > > > version v1.7.2-35-g52f07dcca47c")
> > > > > > > 
> > > > > > > The mkimage tool already supports enforcing this alignment via the -B
> > > > > > > option, but users would have to specify it explicitly. This change
> > > > > > > makes 8-byte alignment the default when using -b.
> > > > > > > 
> > > > > > > Reported-by: Anshul Dalal <anshuld at ti.com>
> > > > > > > Closes: https://lore.kernel.org/u-boot/DFJ950O0QM0D.380U0N16ZO19E@ti.com
> > > > > > > Fixes: 0535e46d55d7 ("scripts/dtc: Update to upstream version v1.7.2-35-g52f07dcca47c")
> > > > > > > Signed-off-by: Beleswar Padhi <b-padhi at ti.com>
> > > > > > 
> > > > > > Tested-by: Tom Rini <trini at konsulko.com>
> > > > > Doesn't this enable 8-byte alignment for everything in case a DT is specified on mkimage command line ? That doesn't seem right ?
> > > > > 
> > > > > If I do mkimage -f auto -b ...dtb ... , then I only want the DTB to be 8-byte aligned, all the other blobs can be 4 byte aligned just fine .
> > > > 
> > > > 
> > > > All the mkimage flags are parsed at once and populated in the params
> > > > data structure in one shot in the code. There is no separation of code
> > > > specifically for generating a FIT for a DTB vs for anything else.
> > > 
> > > That does not seem to be true ?
> > > 
> > > $ git grep -p '\<bl_len\>' tools/
> > > tools/fit_image.c=static int fit_extract_data(struct image_tool_params
> > > *params, const char *fname)
> > > tools/fit_image.c:      align_size = params->bl_len ? params->bl_len : 4;
> > > ...
> > > 
> > > So something like that may work ?
> > > 
> > > "
> > > diff --git a/tools/fit_image.c b/tools/fit_image.c
> > > index 0306333141e..0c606ba4cc3 100644
> > > --- a/tools/fit_image.c
> > > +++ b/tools/fit_image.c
> > > @@ -642,9 +642,15 @@ static int fit_extract_data(struct
> > > image_tool_params *params, const char *fname)
> > >           for (node = fdt_first_subnode(fdt, images);
> > >                node >= 0;
> > >                node = fdt_next_subnode(fdt, node)) {
> > > -               const char *data;
> > > +               const char *data, *type;
> > >                   int len;
> > > 
> > > +               if (align_size < 8) {
> > > +                       type = fdt_getprop(fdt, node, FIT_TYPE_PROP, &len);
> > > +                       if (type && !strcmp(type, "flat_dt"))
> > > +                               align_size = 8;
> > > +               }
> > > +
> > >                   data = fdt_getprop(fdt, node, FIT_DATA_PROP, &len);
> > >                   if (!data)
> > >                           continue;
> > > "
> > > 
> > 
> > I just ran a quick test with this diff and it seems to fix the issue for
> > us. If it's okay can we take the change as is.
> I think the strcmp needs to be some strncmp and check the 'len' too.
> 
> Let's see what others think.

Probably fine to keep going as-is. If there's security challenges here
this isn't the first one I bet.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20260123/f39b99f2/attachment.sig>