Re: Identifying UBI volume instance / storing UBI volume metadata

[valentio@free.fr]

Hello Rafał,

How about storing the squashfs into the rootfs ubi volume (as a bare file), start with an initramfs appended to the kernel and mount the root file with loopback block dev. The RW overlay part would be stored directly in the ubifs. (All modifications to the root image file would go in the overlay, so impossible to break the image)

This way, when you flash a new firmware, everything gets wiped, and you can factory reset by rm the RW directory.

It diverges quite a bit from OpenWRT usual way though.

Regards,

--
Olivier

----- Mail original -----
> De: "Rafał Miłecki" <zajec5@gmail.com>
> À: "MTD Maling List" <linux-mtd@lists.infradead.org>
> Cc: "OpenWrt Development List" <openwrt-devel@lists.openwrt.org>
> Envoyé: Jeudi 9 Décembre 2021 14:22:30
> Objet: Identifying UBI volume instance / storing UBI volume metadata
> 
> Hi,
> 
> I'm Linux developer involved in OpenWrt & buildroot projects. I work
> on building firmware images for home routers but I need to work with
> existing designs. I don't work for Broadcom (or any other
> manufacturer) and so I can't change how firmware images are handled
> by
> original software.
> 
> I'm dealing right now with BCM4908 platform that uses UBI and I need
> some help.
> 
> By Broadcom's design BCM4908 uses two relevant UBI volumes:
> 1. bootfs
> 2. rootfs
> 
> Every firmware file (accepted by bootloader & original firmware UI)
> contains two images: bootfs (with kernel & DTBs) and rootfs. Flashing
> firmware (through bootloader of original UI) is a process of simply
> writing firmware-contained "bootfs" and "rootfs" images to
> corresponding UBI volumes.
> 
> 
> My problem is making OpenWrt's design fit that BCM4908 case. OpenWrt
> uses two *rootfs* volumes:
> 1. rootfs: squashfs RO
> 2. overlay: ubifs overlay
> 
> As you can see "overlay" needs to be created by OpenWrt's user space.
> It can't be part of flashed firmware file.
> 
> My problem is /linking/ "overlay" with currently running firmware.
> Let
> m explain:
> Whenever a new flashing happens the OLD "overlay" needs to be
> recognized and wiped.
> It's required to make sure newly flashed firmware doesn't use non-own
> data.
> 
> 
> My ideas I have for solving that:
> 
> 1. Getting "bootfs" / "rootfs" volume per-flashing unique number and
> writing it in "overlay" ubifs. Then wipe "overlay" on mismatch.
> Unfortunately I can't see anything flashing-specific number in UBI
> volume header.
> Image sequence does never change in my case as UBI doesn't get
> reformatted.
> I'm not sure if sqnum is unique but it seems it can change anyway
> when
> UBI needs to handle with flash wearing.
> 
> 2. Generating random number and writing it in some metadata of RO
> "bootfs" or "rootfs" AND in "overlay" ubifs. Then wipe "overlay" on
> mismatch.
> That I think would require adding a custom field in the
> "ubi_vtbl_record" struct. I'm not sure if upstream UBI can be
> extended
> like that and I don't want such heavy downstream (OpenWrt) hacks.
> 
> 
> Any adivces, please?
> 
> --
> Rafał
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/