Commit Graph

14 Commits

Author SHA1 Message Date
David Bauer
34437af888 base-files: allow ignoring minor compat-version check
Downstream projects might re-generate device-specific configuration
based on OpenWrt's defaults on each upgrade, thus being unaffected by
forward- as well as backwards-breaking configuration.

Add a new sysupgrade parameter, which allows sysupgrades between minor
compat-versions. Upgrades will still fail upon mismatching major compat
versions.

Signed-off-by: David Bauer <mail@david-bauer.net>
2022-06-18 22:11:04 +02:00
Florian Eckert
e0c6506158 base-files: change logging for upgrade on fwtool
Remove vn call in favour of v call. This commit serves as preparation
for removing the v function call.

Signed-off-by: Florian Eckert <fe@dev.tdt.de>
[alter slightly to prevent double space after colon]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
2021-05-17 01:00:14 +02:00
Yousong Zhou
128bb4e8d3 base-files: upgrade: fwtool.sh: rewording logs
The intent is to make it sound more like info level message, not some
error like "404 not found".  x86 target at the moment makes image with
only signature but no metadata (ref commit f8141216 "x86: append
metadata to combined images").

Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com>
Reviewed-By: Philip Prindeville <philipp@redfish-solutions.com>
2020-11-11 21:29:55 +08:00
Yousong Zhou
856b288d27 base-files: upgrade: fwtool.sh: use v for log lines
This will have at least the following effects

 - Log lines will have common prefix
 - They will be output to stderr instead of stdout

Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com>
2020-11-11 21:29:55 +08:00
Adrian Schmutzler
02d6ac1060 base-files: fwtool: make compat_version backward compatible
So far, the compatibility mechanism only works if both device and
image are already updated to the new routines. This patch extends
the sysupgrade metadata and fwtool_check_image() to account for
"older" images as well:

The basic mechanism for older devices to check for image compatibility
is the supported_devices entry. This can be exploited by putting
a custom message into this variable of the metadata, so older FW
will produce a mismatch and print the message as it thinks it's the
list of supported devices. So, we have two cases:

device 1.0, image 1.0:
  The metadata will just contain supported_devices as before.

device 1.0, image 1.1:
  The metadata will contain:

  "new_supported_devices":["device_string1", "device_string2", ...],
  "supported_devices":["Image version 1.1 incompatible to device: ..."]

  If the device is "legacy", i.e. does not have the updated fwtool.sh,
  it will just fail with image check and print the content of
  supported_devices. If DEVICE_COMPAT_MESSAGE is set, this will be
  printed on old devices as well through the same mechanism. Otherwise
  a generic "Please check documentation ..." is appended.

  Upgrade can still be performed with -F like when
  SUPPORTED_DEVICES has been removed to prevent bricking.

  If the device has updated fwtool.sh (but is 1.0), it will just use
  the new_supported_devices instead, and work as intended (flashing
  with -n will work, flashing without will print the appropriate
  warning).

This mechanism should provide a fair tradeoff between simplicity
and functionality.

Since we touched a lot of fields in metadata, this also bumps
metadata_version to 1.1.

Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
2020-07-31 11:40:15 +02:00
Adrian Schmutzler
ad3e1f9db4 base-files: fwtool: implement compatibility check for images
We regularly encounter the situation that devices are subject to
changes that will make them incompatible to previous versions.
Removing SUPPORTED_DEVICES will not really be helpful in most of these
cases, as this only helps after a rename.

To solve this situation, this patchset introduces a compatibility
version for devices. In this patch, the actual checks are implemented
into fwtool_check_image():

If an incompatible change is introduced, one can increase either
the minor version (1.0->1.1) or the major version (1.0->2.0).

Minor version increment:
This will still allow sysupgrade, but require to reset config
(-n or SAVE_CONFIG=0). If sysupgrade is called without -n, a
corresponding message will be printed. If sysupgrade is called
with -n, it will just pass, with supported devices being checked
as usual. (Which will allow us to add back SUPPORTED_DEVICES for
many cases.)

Major version increment:
This is meant for potential (rare) cases where sysupgrade is
not possible at all, because it would break the device.
In this case, a warning will be printed, and -n won't help.

If image check fails because of one of the versions parts not
matching, the content of DEVICE_COMPAT_MESSAGE is printed in
addition to the generic message (if set).

For both cases, upgrade can still be forced with -F as usual.

Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
2020-07-31 11:40:15 +02:00
Felix Fietkau
b044b52ab9 base-files: fix ucert verification
ucert needs to check the firmware part with metadata, but without the signature.
Use the new fwtool mode to extract that without altering the firmware image inside
the check

Signed-off-by: Felix Fietkau <nbd@nbd.name>
2019-02-12 16:42:03 +01:00
Felix Fietkau
61e01f248e base-files: do not strip fwtool signature data during check
Same reason as in commit 9808bd2799 -
sysupgrade --test must not alter the image in any way

Signed-off-by: Felix Fietkau <nbd@nbd.name>
2019-02-09 14:34:24 +01:00
Jo-Philipp Wich
9808bd2799 Revert "base-files: fwtool: Fix wrong checksum on combined-image with metadata"
This reverts commit 41770add03.

The fwtool_check_image() procedure is used by `sysupgrade --test` which must
not alter the image under test in any way.

Currently, when the LuCI ui or any other sysupgrade wrapper first invokes
sysupgrade --test to verify the compatibility of the image and then calculates
the sha256sum over it, the resulting checksum will differ from the original
image since the test invocation will implicitely strip the metadata trailer.

To properly fix the underlying issue, the combined image checksumming code
must be modified to skip the metadata trailer.

Signed-off-by: Jo-Philipp Wich <jo@mein.io>
2018-12-02 16:05:44 +01:00
Petr Štetiar
41770add03 base-files: fwtool: Fix wrong checksum on combined-image with metadata
If I create following image:

define Device/engenius-m36
  IMAGE/sysupgrade.bin := combined-image | append-metadata
endef

Sysupgrade then errors out:

  Invalid image. Contents do not match checksum (image:cd285595eaf297370404ae0e2815ec1a calculated:2cf9a2286fb6b01af3ea189128017d44)
  Image check 'platform_check_image' failed.

By removing the metadata from the image I get combined-image checksum
working again and sysupgrade works.

Signed-off-by: Petr Štetiar <ynezz@true.cz>
2018-11-26 12:05:45 +01:00
Daniel Golle
8174853c78 base-files: introduce sysupgrade signature chain verification
Verify ucert signature chains in sysupgrade images in case ucert is
installed and $CHECK_IMAGE_SIGNARURE = 1.
Also make sure ucert host binary is present and generate a self-signed
ucert in case $TOPDIR/key-build.ucert is missing.

Signed-off-by: Daniel Golle <daniel@makrotopia.org>
2018-08-08 02:22:54 +02:00
John Crispin
5e1b4c57de base-files: drop fwtool_pre_upgrade
this feature has never worked, the fw image name was not passed and the -t
parameter was missing in the tool invocation. drop the feature.

Signed-off-by: John Crispin <john@phrozen.org>
2018-07-30 17:42:39 +02:00
Felix Fietkau
81b5e8e5d2 base-files: add a hint in sysupgrade that shows what to do when the image metadata check fails
Signed-off-by: Felix Fietkau <nbd@nbd.name>
2016-12-04 11:41:49 +01:00
Felix Fietkau
cc853810a4 base-files: validate metadata of sysupgrade images
Use fwtool to extract it, only require metadata to be present if the
platform sysupgrade script sets REQUIRE_IMAGE_METADATA=1

Image metadata is in JSON format and contains a list of supported
devices, along with version information that could be displayed by a UI
later before the actual upgrade happens.

Signed-off-by: Felix Fietkau <nbd@nbd.name>
2016-11-19 11:24:09 +01:00