No one seems to have responded to this, and I'd like to start working on it next week. If developers could think about this and comment, it would be appreciated.
On Fri, 12 Jun 2009 18:37:42 -0400 "Daniel Dickinson <crazycsh...@gmail.com> (by way of Daniel Dickinson" <crazycsh...@gmail.com> wrote: > I would like to suggest an improvement I would implement for the LuCI > firmware update. > > Current the LuCI update is pretty basic; it calculates the md5sum of > the image and if you want to make sure it transferred correclty you > have to find the md5sums file and manual verify the sum. > > This is awkward and not very effective, and it also misses the class > of error in which the image is corrupt on the host machine. > > I would therefore like to propose that all targets implement the > creation of an additional firmware image that is targeted at upgrades > of OpenWRT from OpenWRT (using LuCI). > > Currently the firmware images are all designed to be flashed using > vendor methods, and upgrading from within OpenWRT is a poor cousin. > > I think we need a firmware image that can be used to verify the > validity of the image before flashing it, that is unified for all > routers supported by OpenWRT. > > We need: > > * An MD5SUM or SHA1SUM of the image (that is, the portion that will be > writen to the flash or other target device), so that the validity of > the image can be verified. > * An MD5SUM or SHA1SUM of the header (to ensure none of the header > information has been corrupted, since it will determine how we flash > the device) > * An indicator the the method and/or parameters needed to flash the > image (since different routers probably have different requirements); > for example 'mtd linux' > * For boards that need it; the starting offset of the kernel, the > length of the kernel, the starting offset of the rootfs, and the > length of the rootfs > * Immediately before the start of the rootfs (in the padding between > kernel and rootfs) (i.e. at the tail end of the kernel mtd partition > for flash devices), there should be a space for vendors to place data, > that, if non-null, must match what is already on the router. This > allows a vendor who is a service provider to create firmware images > for specific clients, and to ensure they can't accidentally flash the > wrong router with the wrong image. > * In the same location should probably also be an indication of which > router this is, so that flashing the wrong router can be prevented. > * Some vendors may want a signed header (with a public/private key) so > that web interface flashing can only be done with approved images > (serial console/tftp flashing is of course still open for anything, > but in the service provider scenario the case would never be opened so > serial console flashing is not an issue). > > This header would not be present on the router after flashing (but the > flash safety features between kernel and rootfs would), it is only to > ensure that the image flashed is not corrupt and is valid for this > router. > > Ideally the between kernel+rootfs portion of the image would also be > generated for the vendor flash methods (e.g. CFE, TFTP, Vendor web > interface) so that upgrades via LuCI have the safety features > available before the first upgrade (i.e. once OpenWRT is on the > router). > > I'd like to implement this for brcm63xx soon, so any comments would be > appreciated. > > Thank you, > > Daniel > -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org The C Shore (Daniel Dickinson's Website) http://www.bmts.com/~cshore
signature.asc
Description: PGP signature
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
