Identifying UBI volume instance / storing UBI volume metadata

Identifying UBI volume instance / storing UBI volume metadata

[Rafał Miłecki]

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ł

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

Re: Identifying UBI volume instance / storing UBI volume metadata

[valentio]

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/

Re: Identifying UBI volume instance / storing UBI volume metadata

[Rafał Miłecki]

On 9.12.2021 21:11, Olivier Valentin wrote:
> 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.

Thanks for your reply. It doesn't fit OpenWrt's current design well but
I think it's probably time to rework OpenWrt's init if needed.

Just to make sure I understood your correctly:

Do you suggest "rootfs" UBI volume using ubifs with something like:
/root.squashfs
/overlay/

(and then initramfs as you described)?

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