[OpenWrt-Devel] Squashfs breakage lottery with UBI WAS: [PATCH RFC 2/2] amp821xx: use newly added pad-squashfs for Meraki MR24

[Russell Senior]

>>>>> "Christian" == Christian Lamparter <chunkeey at gmail.com> writes:

> I've posted a similar message to the bugreport:
> <https://bugs.openwrt.org/index.php?do=details&task_id=2460>

I should have filed the bug first and linked it in my patch.

> What's happening here is that mksquashfs4 is being told
> through the "-nopad" option to "do not pad filesystem to a
> multiple of 4K" [0].

> |define Image/mkfs/squashfs |
> $(STAGING_DIR_HOST)/bin/mksquashfs4 $(call
> mkfs_target_dir,$(1)) $@ \ | -nopad -noappend -root-owned \ |
> -comp $(SQUASHFSCOMP) $(SQUASHFSOPT) \ | -processors 1 |endef

> My guess is that this affects more than just the MR24 (I'm
> looking at you too: pad2jffs and various pad-to $value)
> . I've tried tracking down the change that added the "-nopad"
> and found it in a commit from 2005 titled: "add some changes
> from whiterussian to head" [1] [2]:

I agree that other devices where rootfs is squashfs and lives on a ubi
volume are probaby also vulnerable to this problem. Regrettably, I haven't
thought of any other of those devices that I have on hand to test. 

> | $(KDIR)/root.squashfs: | @mkdir -p $(KDIR)/root/jffs |-
> $(STAGING_DIR)/bin/mksquashfs-lzma $(KDIR)/root $@ -noappend
> -root-owned -le |+ $(STAGING_DIR)/bin/mksquashfs-lzma
> $(KDIR)/root $@ -nopad -noappend -root-owned -le


> So, this is really old...

> Question is, should we just drop the -nopad? Since as you
> established, in the described corner-case (see above)
> squashfs needs this 4k padding and the generated squashfs
> could be considered broken otherwise?

I'm under the impression that the -nopad makes sense for NOR flash where
the kernel and rootfs are glued together, padding the isolated rootfs
would cause alignment problems or wasted space in the combined blobs.

> (Judging from your
> message, you went through the kernel code. Can you please
> share the place where the lack of the padding is breaking the
> fs?)

It's mostly inferred from the fact that I saw the error and kernel
panic, and glancing at the kernel squashfs code. I am not pretending to
understand completely how the squashfs kernel code works, but the
position of the error relative to the size of the rootfs in my panic
case strongly suggests it was trying to read past the end of the ubi
volume.

The error comes in the kernel's fs/squashfs/block.c in the
squashfs_read_data() function. There are a bunch of conditions (at least
5) within the function (see "goto read_failure;") that will lead to that
message being printed.


-- 
Russell Senior, President
russell at personaltelco.net

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