[OpenWrt-Devel] [PATCH v2] gemini: Support sysupgrade on DIR-685

[Linus Walleij]

[Adding Stijn Tintel as DAP-2695 A1 maintainer, I think he want to
know how we solve this.]

On Tue, May 14, 2019 at 2:07 PM Petr Štetiar <ynezz at true.cz> wrote:

> Linus Walleij <linus.walleij at linaro.org> [2019-05-14 13:16:50]:
> > On Tue, May 14, 2019 at 10:30 AM Petr Štetiar <ynezz at true.cz> wrote:
> >
> > > Linus Walleij <linus.walleij at linaro.org> [2019-05-12 21:13:17]:
> >
> > > > +REQUIRE_IMAGE_METADATA=1
> > >
> > > once you set this, you don't need to check for the image magic, do you? If so,
> > > please provide the reason for that.
> >
> > The image magic is necessary for the boot loader to recognize
> > and boot the image. Since flashing an image without this magic
> > will brick the device,
>
> bricking the device is a strong wording, as brick means, that you can't use
> any recovery method and you probably need soldering iron at least. It seems to
> me, that you can just render the device unbootable, right?

Yeah, you need a soldering iron if it goes that far. A proper UART
gives a console that can recover the machine.

> > I feel it should be check as a "better safe than sorry" measure, so we
> > cannot under any circumstances flash something that the router cannot boot.
>
> I think, that metadata and JSON parsing is tad more complex and thus more
> advanced validity checking then your proposed first 4-byte header check.
> Really, how could you be sure, that any of the following bytes past this
> header are valid, thus still won't render flashed device unbootable.

Yeah the 4 bytes are just an indication that the header is
intact and we're not flashing rubbish.

There is some additional checksums etc in the header as well,
see below.

> > Do you want me to add this to the commit message?
>
> I see no point, really.
>
> > In theory yes but in so many practical situations I have muttered the words
> > "that should not happen" and that is why I feel it is better to have double
> > safety checks.
>
> It makes no sense to pretend any safety here, both solutions (4-byte header
> check, unsigned metadata) are just poor man's workarounds. Should you need any
> safety, then enforce only signed images (or add some functionality to metadata
> handling which could check hash of complete image, not just 4-byte header).

Actually there is some safety since the DIR-685 has all that. Just checking
the 4 bytes in the header is a quick sanity check. The check comes from
target/linux/ar71xx/base-files/lib/upgrade/platform.sh
by the way, as the same is used in  D-Link DAP-2695 A1.

The full header format can be seen in tools/firmware-utils/src/mkwrggimg.c
and includes a MD5 digest. This MD5 digest is checked by the ROM
of the machine every time it boots.

So what happens in this case is that when we add another checksum
around this checksummed image.

I guess I could insist on writing a utility in C to check that custom
MD5 sum before we flash, it has a nice "being close to what the target
wants" feeling about it.

But on the other hand it could be nice that it is done
according to the OpenWrt standard, and what really matters is that
some checksum is checked, so I guess I will go with your suggestion
unless the DAP-2695 A1 people have some other opinion?

Yours,
Linus Walleij

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel