From mboxrd@z Thu Jan  1 00:00:00 1970
From: Richard Weinberger <richard@nod.at>
Date: Fri, 13 Jul 2018 10:08:19 +0200
Subject: [U-Boot] [Bug & Question] ubifs does not understand ".." in
	file path ?
In-Reply-To: <2945f4a3-44aa-f13d-ba0f-a4d13e898bce@denx.de>
References: <CAK7LNAS=WqYLnaZrQBx-YffsV1CDWJCoVP067npGKHG_wHQM5Q@mail.gmail.com>
 <59fb6084-72bd-2d79-cc4d-ab05b06fe317@denx.de>
 <2945f4a3-44aa-f13d-ba0f-a4d13e898bce@denx.de>
Message-ID: <5460944.FaGYc3FPU0@blindfold>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

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