[U-Boot] [Bug & Question] ubifs does not understand ".." in file path ?
Hi.
I was playing around with the ditro-boot on NAND + UBI.
I was hit by a problem when loading files from ubifs.
My 'extlinux.conf' script looks like this:
--------------------------------- menu title UniPhier Boot Options.
timeout 5
default UniPhier
label UniPhier kernel ../Image initrd ../rootfs.cpio.gz fdtdir .. ----------------------------------
As doc/README.distro says, 'extlinux.conf' is generally located in 'extlinux' subdirectory.
So, the paths to kernel, initrd, fdt usually contain '..'
This totally works fine when loading files from a FAT-formated MMC device.
'run bootcmd_mmc0' successfully boots Linus in the disto-boot manner.
However, 'run bootcmd_ubifs0' fails to boot.
=> run bootcmd_ubifs0 ubi0: attaching mtd1 ubi0: scanning is finished ubi0: attached mtd1 (name "mtd=1", size 1023 MiB) ubi0: PEB size: 262144 bytes (256 KiB), LEB size: 253952 bytes ubi0: min./max. I/O unit sizes: 4096/4096, sub-page size 4096 ubi0: VID header offset: 4096 (aligned 4096), data offset: 8192 ubi0: good PEBs: 4088, bad PEBs: 4, corrupted PEBs: 0 ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128 ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image sequence number: 1407739552 ubi0: available PEBs: 0, total reserved PEBs: 4088, PEBs reserved for bad PEB handling: 76 UBIFS (ubi0:0): UBIFS: mounted UBI device 0, volume 0, name "boot", R/O mode UBIFS (ubi0:0): LEB size: 253952 bytes (248 KiB), min./max. I/O unit sizes: 4096 bytes/4096 bytes UBIFS (ubi0:0): FS size: 1014284288 bytes (967 MiB, 3994 LEBs), journal size 33521664 bytes (31 MiB, 132 LEBs) UBIFS (ubi0:0): reserved for root: 4952683 bytes (4836 KiB) UBIFS (ubi0:0): media format: w5/r0 (latest is w4/r0), UUID cc8f68da-030d-408c-a91f-f8cc195a2946, small LPT model Scanning ubi 0:... Found /boot/extlinux/extlinux.conf Retrieving file: /boot/extlinux/extlinux.conf 148 bytes read in 1 ms (144.5 KiB/s) UniPhier Boot Options. 1: UniPhier Enter choice: 1: UniPhier Retrieving file: /boot/extlinux/../rootfs.cpio.gz Skipping UniPhier for failure retrieving initrd SCRIPT FAILED: continuing...
The boot log says it succeeded in loading '/boot/extlinux/extlinux.conf' but failed in loading '/boot/extlinux/../rootfs.cpio.gz'
In my quick experiments,
load '/boot/extlinux/extlinux.conf' -> SUCCESS load '/boot/extlinux/../rootfs.cpio.gz' -> FAILURE load '/boot/rootfs.cpio.gz' -> SUCCESS load '/boot/extlinux/../Image' -> FAILURE load '/boot/Image' -> SUCCESS load '/boot/extlinux/../uniphier-ld20-ref.dtb' -> FAILURE load '/boot/uniphier-ld20-ref.dtb' -> SUCCESS
From the test results above,
my conclusion is loading a file path that contains '..' is not working.
Not sure where the root cause is. Anybody who has insight about this?
Hello Masahiro,
Am 13.07.2018 um 06:44 schrieb Masahiro Yamada:
Hi.
I was playing around with the ditro-boot on NAND + UBI.
I was hit by a problem when loading files from ubifs.
My 'extlinux.conf' script looks like this:
menu title UniPhier Boot Options.
timeout 5
default UniPhier
label UniPhier kernel ../Image initrd ../rootfs.cpio.gz fdtdir ..
As doc/README.distro says, 'extlinux.conf' is generally located in 'extlinux' subdirectory.
So, the paths to kernel, initrd, fdt usually contain '..'
This totally works fine when loading files from a FAT-formated MMC device.
'run bootcmd_mmc0' successfully boots Linus in the disto-boot manner.
However, 'run bootcmd_ubifs0' fails to boot.
=> run bootcmd_ubifs0 ubi0: attaching mtd1 ubi0: scanning is finished ubi0: attached mtd1 (name "mtd=1", size 1023 MiB) ubi0: PEB size: 262144 bytes (256 KiB), LEB size: 253952 bytes ubi0: min./max. I/O unit sizes: 4096/4096, sub-page size 4096 ubi0: VID header offset: 4096 (aligned 4096), data offset: 8192 ubi0: good PEBs: 4088, bad PEBs: 4, corrupted PEBs: 0 ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128 ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image sequence number: 1407739552 ubi0: available PEBs: 0, total reserved PEBs: 4088, PEBs reserved for bad PEB handling: 76 UBIFS (ubi0:0): UBIFS: mounted UBI device 0, volume 0, name "boot", R/O mode UBIFS (ubi0:0): LEB size: 253952 bytes (248 KiB), min./max. I/O unit sizes: 4096 bytes/4096 bytes UBIFS (ubi0:0): FS size: 1014284288 bytes (967 MiB, 3994 LEBs), journal size 33521664 bytes (31 MiB, 132 LEBs) UBIFS (ubi0:0): reserved for root: 4952683 bytes (4836 KiB) UBIFS (ubi0:0): media format: w5/r0 (latest is w4/r0), UUID cc8f68da-030d-408c-a91f-f8cc195a2946, small LPT model Scanning ubi 0:... Found /boot/extlinux/extlinux.conf Retrieving file: /boot/extlinux/extlinux.conf 148 bytes read in 1 ms (144.5 KiB/s) UniPhier Boot Options. 1: UniPhier Enter choice: 1: UniPhier Retrieving file: /boot/extlinux/../rootfs.cpio.gz Skipping UniPhier for failure retrieving initrd SCRIPT FAILED: continuing...
The boot log says it succeeded in loading '/boot/extlinux/extlinux.conf' but failed in loading '/boot/extlinux/../rootfs.cpio.gz'
In my quick experiments,
load '/boot/extlinux/extlinux.conf' -> SUCCESS load '/boot/extlinux/../rootfs.cpio.gz' -> FAILURE load '/boot/rootfs.cpio.gz' -> SUCCESS load '/boot/extlinux/../Image' -> FAILURE load '/boot/Image' -> SUCCESS load '/boot/extlinux/../uniphier-ld20-ref.dtb' -> FAILURE load '/boot/uniphier-ld20-ref.dtb' -> SUCCESS
From the test results above, my conclusion is loading a file path that contains '..' is not working.
Not sure where the root cause is. Anybody who has insight about this?
No idea, need to try it, but may
fs/ubifs/ubifs.c ubifs_findfile() has a problem with ".." ?
bye, Heiko
On 07/13/2018 09:44 AM, Heiko Schocher wrote:
Hello Masahiro,
Am 13.07.2018 um 06:44 schrieb Masahiro Yamada:
Hi.
I was playing around with the ditro-boot on NAND + UBI.
I was hit by a problem when loading files from ubifs.
My 'extlinux.conf' script looks like this:
menu title UniPhier Boot Options.
timeout 5
default UniPhier
label UniPhier kernel ../Image initrd ../rootfs.cpio.gz fdtdir ..
As doc/README.distro says, 'extlinux.conf' is generally located in 'extlinux' subdirectory.
So, the paths to kernel, initrd, fdt usually contain '..'
This totally works fine when loading files from a FAT-formated MMC device.
'run bootcmd_mmc0' successfully boots Linus in the disto-boot manner.
However, 'run bootcmd_ubifs0' fails to boot.
=> run bootcmd_ubifs0 ubi0: attaching mtd1 ubi0: scanning is finished ubi0: attached mtd1 (name "mtd=1", size 1023 MiB) ubi0: PEB size: 262144 bytes (256 KiB), LEB size: 253952 bytes ubi0: min./max. I/O unit sizes: 4096/4096, sub-page size 4096 ubi0: VID header offset: 4096 (aligned 4096), data offset: 8192 ubi0: good PEBs: 4088, bad PEBs: 4, corrupted PEBs: 0 ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128 ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image sequence number: 1407739552 ubi0: available PEBs: 0, total reserved PEBs: 4088, PEBs reserved for bad PEB handling: 76 UBIFS (ubi0:0): UBIFS: mounted UBI device 0, volume 0, name "boot", R/O mode UBIFS (ubi0:0): LEB size: 253952 bytes (248 KiB), min./max. I/O unit sizes: 4096 bytes/4096 bytes UBIFS (ubi0:0): FS size: 1014284288 bytes (967 MiB, 3994 LEBs), journal size 33521664 bytes (31 MiB, 132 LEBs) UBIFS (ubi0:0): reserved for root: 4952683 bytes (4836 KiB) UBIFS (ubi0:0): media format: w5/r0 (latest is w4/r0), UUID cc8f68da-030d-408c-a91f-f8cc195a2946, small LPT model Scanning ubi 0:... Found /boot/extlinux/extlinux.conf Retrieving file: /boot/extlinux/extlinux.conf 148 bytes read in 1 ms (144.5 KiB/s) UniPhier Boot Options. 1: UniPhier Enter choice: 1: UniPhier Retrieving file: /boot/extlinux/../rootfs.cpio.gz Skipping UniPhier for failure retrieving initrd SCRIPT FAILED: continuing...
The boot log says it succeeded in loading '/boot/extlinux/extlinux.conf' but failed in loading '/boot/extlinux/../rootfs.cpio.gz'
In my quick experiments,
load '/boot/extlinux/extlinux.conf' -> SUCCESS load '/boot/extlinux/../rootfs.cpio.gz' -> FAILURE load '/boot/rootfs.cpio.gz' -> SUCCESS load '/boot/extlinux/../Image' -> FAILURE load '/boot/Image' -> SUCCESS load '/boot/extlinux/../uniphier-ld20-ref.dtb' -> FAILURE load '/boot/uniphier-ld20-ref.dtb' -> SUCCESS
From the test results above, my conclusion is loading a file path that contains '..' is not working.
Not sure where the root cause is. Anybody who has insight about this?
No idea, need to try it, but may
fs/ubifs/ubifs.c ubifs_findfile() has a problem with ".." ?
CCing Richard, btw ubifs in U-Boot is completely broken.
Am Freitag, 13. Juli 2018, 10:00:23 CEST schrieb Marek Vasut:
On 07/13/2018 09:44 AM, Heiko Schocher wrote:
Hello Masahiro,
Am 13.07.2018 um 06:44 schrieb Masahiro Yamada:
Hi.
I was playing around with the ditro-boot on NAND + UBI.
I was hit by a problem when loading files from ubifs.
My 'extlinux.conf' script looks like this:
menu title UniPhier Boot Options.
timeout 5
default UniPhier
label UniPhier kernel ../Image initrd ../rootfs.cpio.gz fdtdir ..
As doc/README.distro says, 'extlinux.conf' is generally located in 'extlinux' subdirectory.
So, the paths to kernel, initrd, fdt usually contain '..'
This totally works fine when loading files from a FAT-formated MMC device.
'run bootcmd_mmc0' successfully boots Linus in the disto-boot manner.
However, 'run bootcmd_ubifs0' fails to boot.
=> run bootcmd_ubifs0 ubi0: attaching mtd1 ubi0: scanning is finished ubi0: attached mtd1 (name "mtd=1", size 1023 MiB) ubi0: PEB size: 262144 bytes (256 KiB), LEB size: 253952 bytes ubi0: min./max. I/O unit sizes: 4096/4096, sub-page size 4096 ubi0: VID header offset: 4096 (aligned 4096), data offset: 8192 ubi0: good PEBs: 4088, bad PEBs: 4, corrupted PEBs: 0 ubi0: user volume: 1, internal volumes: 1, max. volumes count: 128 ubi0: max/mean erase counter: 1/0, WL threshold: 4096, image sequence number: 1407739552 ubi0: available PEBs: 0, total reserved PEBs: 4088, PEBs reserved for bad PEB handling: 76 UBIFS (ubi0:0): UBIFS: mounted UBI device 0, volume 0, name "boot", R/O mode UBIFS (ubi0:0): LEB size: 253952 bytes (248 KiB), min./max. I/O unit sizes: 4096 bytes/4096 bytes UBIFS (ubi0:0): FS size: 1014284288 bytes (967 MiB, 3994 LEBs), journal size 33521664 bytes (31 MiB, 132 LEBs) UBIFS (ubi0:0): reserved for root: 4952683 bytes (4836 KiB) UBIFS (ubi0:0): media format: w5/r0 (latest is w4/r0), UUID cc8f68da-030d-408c-a91f-f8cc195a2946, small LPT model Scanning ubi 0:... Found /boot/extlinux/extlinux.conf Retrieving file: /boot/extlinux/extlinux.conf 148 bytes read in 1 ms (144.5 KiB/s) UniPhier Boot Options. 1: UniPhier Enter choice: 1: UniPhier Retrieving file: /boot/extlinux/../rootfs.cpio.gz Skipping UniPhier for failure retrieving initrd SCRIPT FAILED: continuing...
The boot log says it succeeded in loading '/boot/extlinux/extlinux.conf' but failed in loading '/boot/extlinux/../rootfs.cpio.gz'
In my quick experiments,
load '/boot/extlinux/extlinux.conf' -> SUCCESS load '/boot/extlinux/../rootfs.cpio.gz' -> FAILURE load '/boot/rootfs.cpio.gz' -> SUCCESS load '/boot/extlinux/../Image' -> FAILURE load '/boot/Image' -> SUCCESS load '/boot/extlinux/../uniphier-ld20-ref.dtb' -> FAILURE load '/boot/uniphier-ld20-ref.dtb' -> SUCCESS
From the test results above, my conclusion is loading a file path that contains '..' is not working.
Not sure where the root cause is. Anybody who has insight about this?
No idea, need to try it, but may
fs/ubifs/ubifs.c ubifs_findfile() has a problem with ".." ?
CCing Richard, btw ubifs in U-Boot is completely broken.
Erm, ".." handling is not the business of a filesystem. VFS does that.
Thanks, //richard
Am Freitag, 13. Juli 2018, 10:00:23 CEST schrieb Marek Vasut:
CCing Richard, btw ubifs in U-Boot is completely broken.
BTW: Can you please define "completely broken"?
Last week it used to work here. ;)
Thanks, //richard
On 07/13/2018 10:15 AM, Richard Weinberger wrote:
Am Freitag, 13. Juli 2018, 10:00:23 CEST schrieb Marek Vasut:
CCing Richard, btw ubifs in U-Boot is completely broken.
BTW: Can you please define "completely broken"?
Last week it used to work here. ;)
Did you fix it ? Last time we discussed this, about a month ago, you mentioned the ubifs code is completely broken and I had massive problems with it myself.
Marek,
Am Freitag, 13. Juli 2018, 10:53:48 CEST schrieb Marek Vasut:
On 07/13/2018 10:15 AM, Richard Weinberger wrote:
Am Freitag, 13. Juli 2018, 10:00:23 CEST schrieb Marek Vasut:
CCing Richard, btw ubifs in U-Boot is completely broken.
BTW: Can you please define "completely broken"?
Last week it used to work here. ;)
Did you fix it ? Last time we discussed this, about a month ago, you mentioned the ubifs code is completely broken and I had massive problems with it myself.
Well, this is not what I said on IRC. The u-boot "bindings" are not nice but functional. We saw over the last time a few ubifs_assert() triggering, these triggered since ever but nobody noticed. The loglevel rework just exposed them.
So yes, there are things that need improving but calling the whole thing as broken is false. For the ".." issue, here someone has to sit down and either make sure that all filesystems in u-boot get this handled in a generic way or hack it directly into the ubifs code. I prefer the former...
Thanks, //richard
participants (4)
-
Heiko Schocher -
Marek Vasut -
Masahiro Yamada -
Richard Weinberger