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

Petr Štetiar ynezz at true.cz
Tue May 14 08:07:36 EDT 2019


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?

> 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.

> 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).

-- ynezz

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


More information about the openwrt-devel mailing list