Original ubifs code was designed that after ubifs_umount() call it is
required to also call ubi_close_volume() which closes underlying UBI
volume. But U-Boot ubifs modification have not implemented it properly
which caused that ubifsumount command contains resource leak. It can be
observed by calling simple sequence of commands:
=> ubi part mtd2
ubi0: attaching mtd2
...
=> ubifsmount ubi0
=> ubifsumount
Unmounting UBIFS volume rootfs!
=> ubi detach
ubi0 error: ubi_detach_mtd_dev: ubi0 reference count 1, destroy anyway
ubi0: detaching mtd2
ubi0: mtd2 is detached
Fix this issue by calling ubi_close_volume() and mutex_unlock() in
directly in ubifs_umount() function before freeing U-Boot's global
ubifs_sb. And remove duplicate calls of these two functions in remaining
places. Note that when ubifs_umount() is not called then during error
handling is still needed to call ubi_close_volume() and mutex_unlock.
With this change ubifsumount command does not throw that error anymore:
=> ubi part rootfs
ubi0: attaching mtd2
...
=> ubifsmount ubi0
=> ubifsumount
Unmounting UBIFS volume rootfs!
=> ubi detach
ubi0: detaching mtd2
ubi0: mtd2 is detached
Signed-off-by: Pali Rohár <pali@kernel.org>
Tighten up symbol dependencies in a number of places. Ensure that a SPL
specific option has at least a direct dependency on SPL. In places
where it's clear that we depend on something more specific, use that
dependency instead. This means in a very small number of places we can
drop redundant dependencies.
Reported-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
A crafted squashfs image could embed a huge number of empty metadata
blocks in order to make the amount of malloc()'d memory overflow and be
much smaller than expected. Because of this flaw, any random code
positioned at the right location in the squashfs image could be memcpy'd
from the squashfs structures into U-Boot code location while trying to
access the rearmost blocks, before being executed.
In order to prevent this vulnerability from being exploited in eg. a
secure boot environment, let's add a check over the amount of data
that is going to be allocated. Such a check could look like:
if (!elem_size || n > SIZE_MAX / elem_size)
return NULL;
The right way to do it would be to enhance the calloc() implementation
but this is quite an impacting change for such a small fix. Another
solution would be to add the check before the malloc call in the
squashfs implementation, but this does not look right. So for now, let's
use the kcalloc() compatibility function from Linux, which has this
check.
Fixes: c510061303 ("fs/squashfs: new filesystem")
Reported-by: Tatsuhiko Yasumatsu <Tatsuhiko.Yasumatsu@sony.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Tatsuhiko Yasumatsu <Tatsuhiko.Yasumatsu@sony.com>
Following Jincheng's report, an out-of-band write leading to arbitrary
code execution is possible because on one side the squashfs logic
accepts directory names up to 65535 bytes (u16), while U-Boot fs logic
accepts directory names up to 255 bytes long.
Prevent such an exploit from happening by capping directory name sizes
to 255. Use a define for this purpose so that developers can link the
limitation to its source and eventually kill it some day by dynamically
allocating this array (if ever desired).
Link: https://lore.kernel.org/all/CALO=DHFB+yBoXxVr5KcsK0iFdg+e7ywko4-e+72kjbcS8JBfPw@mail.gmail.com
Reported-by: Jincheng Wang <jc.w4ng@gmail.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Tested-by: Jincheng Wang <jc.w4ng@gmail.com>
Setting sblk = NULL has no effect on the caller.
We want to set *sblk = NULL if an error occurrs to avoid usage after free.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
After returning if ret <= 0 we know that ret > 0. No need to check it.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Anand Jain <anand.jain>
Commit b1a14f8a1c ("UBIFS: Change ubifsload to not read beyond the
requested size") added optimization to do not read more bytes than it is
really needed. But this commit introduced incorrect handling of the hole at
the end of file. This logic cause U-Boot to crash or lockup when trying to
read from the ubifs filesystem.
When read_block() call returns -ENOENT error (not an error, but the hole)
then dn-> structure is not filled and contain garbage. So using of dn->size
for memcpy() argument cause that U-Boot tries to copy unspecified amount of
bytes from possible unmapped memory. Which randomly cause lockup of P2020
CPU.
Fix this issue by copying UBIFS_BLOCK_SIZE bytes from read buffer when
dn->size is not available. UBIFS_BLOCK_SIZE is the size of the buffer
itself and read_block() fills buffer by zeros when it returns -ENOENT.
This patch fixes ubifsload on P2020.
Fixes: b1a14f8a1c ("UBIFS: Change ubifsload to not read beyond the requested size")
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
When compling for x86:
ld.bfd: fs/squashfs/sqfs.o: in function `sqfs_read':
u-boot/fs/squashfs/sqfs.c:1443: undefined reference to `__udivmoddi4'
ld.bfd: u-boot/fs/squashfs/sqfs.c:1521: undefined reference to `__udivmoddi4'
Signed-off-by: Sean Nyekjaer <sean.nyekjaer.ext@siemensgamesa.com>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Pali Rohár <pali@kernel.org>
It is helpful to be able to try out bootstd on sandbox, using host files.
This is easier than using a block device, which must have a filesystem,
partition table, etc.
Add a new driver which provides this feature. For now it is not used in
tests, but it is likely to be useful.
Add notes in the devicetree also, but don't disturb the tests.
Signed-off-by: Simon Glass <sjg@chromium.org>
When sandbox is used with hostfs we won't have a block device, but still
must set up the filesystem type before any filesystem operation, such as
loading a file. Add a function to handle this.
Signed-off-by: Simon Glass <sjg@chromium.org>
Implementation in linux/crc16.h provides standard CRC-16 algorithm with
polynomial x^16 + x^15 + x^2 + 1. Use it and remove duplicate ext4 CRC-16
specific code.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
File fs/ubifs/crc16.h is standard linux's crc16.h include file. So move it
from fs/ubifs to include/linux where are also other linux include files.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Stefan Roese <sr@denx.de>
Currently there is no btrfs support in SPL. But macro CONFIG_FS_BTRFS is
defined also when building SPL. When both FS_BTRFS and SPL are enabled
then build process throw compile error.
Fix check for btrfs code in fstypes[] to allow compiling FS_BTRFS only in
proper U-Boot.
Signed-off-by: Pali Rohár <pali@kernel.org>
Fix following two compile errors on big endian systems:
CC fs/btrfs/btrfs.o
In file included from include/linux/byteorder/big_endian.h:107,
from ./arch/powerpc/include/asm/byteorder.h:82,
from ./arch/powerpc/include/asm/bitops.h:8,
from include/linux/bitops.h:152,
from include/uuid.h:9,
from fs/btrfs/btrfs.c:10:
fs/btrfs/conv-funcs.h: In function ‘btrfs_key_to_disk’:
include/linux/byteorder/generic.h:90:21: error: ‘__cpu_to_le16’ undeclared (first use in this function); did you mean ‘__cpu_to_le16p’?
#define cpu_to_le16 __cpu_to_le16
^~~~~~~~~~~~~
fs/btrfs/conv-funcs.h:79:10: note: in expansion of macro ‘cpu_to_le16’
__u16: cpu_to_le16, \
^~~~~~~~~~~
CC fs/btrfs/compression.o
In file included from ./arch/powerpc/include/asm/unaligned.h:9,
from fs/btrfs/compression.c:16:
include/linux/unaligned/access_ok.h:6:19: error: redefinition of ‘get_unaligned_le16’
static inline u16 get_unaligned_le16(const void *p)
^~~~~~~~~~~~~~~~~~
In file included from fs/btrfs/ctree.h:16,
from fs/btrfs/btrfs.h:12,
from fs/btrfs/compression.c:8:
include/linux/unaligned/le_byteshift.h:40:19: note: previous definition of ‘get_unaligned_le16’ was here
static inline u16 get_unaligned_le16(const void *p)
^~~~~~~~~~~~~~~~~~
Include file asm/unaligned.h contains arch specific macros and functions
for unaligned access as opposite to linux/unaligned le_byteshift.h which
contains macros and functions specific to little endian systems only.
Signed-off-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Currently there is no UBIFS support in SPL. But macro CONFIG_CMD_UBIFS is
defined also when building SPL. when both CMD_UBIFS and SPL are enabled
then build process throw compile error.
Fix check for ubifs code in fstypes[] to allow compiling CMD_UBIFS only in
proper U-Boot.
Signed-off-by: Pali Rohár <pali@kernel.org>
Backport commit 1cb51a15b576 ("ubifs: Fix journal replay wrt. xattr
nodes") from the Linux Kernel, which has the following Signed-off-by
line:
Signed-off-by: Richard Weinberger <richard@nod.at>
For U-Boot, after comapring with the upstream commit:
Signed-off-by: Tom Rini <trini@konsulko.com>
This adds a filesystem which is backed by the host's filesystem. It is
modeled off of sandboxfs, which has very similar aims. Semihosting
doesn't support listing directories (except with SYS_SYSTEM), so neither
do we. it's possible to optimize a bit for the common case of reading a
whole file by omitting a call to smh_seek, but this is left as a future
optimization.
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
[BUG]
When passing a btrfs with NO_HOLE feature to U-boot, and if one file
contains holes, then the hash of the file is not correct in U-boot:
# mkfs.btrfs -f test.img # Since v5.15, mkfs defaults to NO_HOLES
# mount test.img /mnt/btrfs
# xfs_io -f -c "pwrite 0 4k" -c "pwrite 8k 4k" /mnt/btrfs/file
# md5sum /mnt/btrfs/file
277f3840b275c74d01e979ea9d75ac19 /mnt/btrfs/file
# umount /mnt/btrfs
# ./u-boot
=> host bind 0 /home/adam/test.img
=> ls host 0
< > 12288 Mon Dec 27 05:35:23 2021 file
=> load host 0 0x1000000 file
12288 bytes read in 0 ms
=> md5sum 0x1000000 0x3000
md5 for 01000000 ... 01002fff ==> 855ffdbe4d0ccc5acab92e1b5330e4c1
The md5sum doesn't match at all.
[CAUSE]
In U-boot btrfs implementation, the function btrfs_read_file() has the
following iteration for file extent iteration:
/* Read the aligned part */
while (cur < aligned_end) {
ret = lookup_data_extent(root, &path, ino, cur, &next_offset);
if (ret < 0)
goto out;
if (ret > 0) {
/* No next, direct exit */
if (!next_offset) {
ret = 0;
goto out;
}
}
/* Read file extent */
But for NO_HOLES features, hole extents will not have any extent item
for it.
Thus if @cur is at a hole, lookup_data_extent() will just return >0, and
update @next_offset.
But we still believe there is some data to read for @cur for ret > 0
case, causing we read extent data from the next file extent.
This means, what we do for above NO_HOLES btrfs is:
- Read 4K data from disk to file offset [0, 4K)
So far the data is still correct
- Read 4K data from disk to file offset [4K, 8K)
We didn't skip the 4K hole, but read the data at file offset [8K, 12K)
into file offset [4K, 8K).
This causes the checksum mismatch.
[FIX]
Add extra check to skip to the next non-hole range after
lookup_data_extent().
Signed-off-by: Qu Wenruo <wqu@suse.com>
This converts the following to Kconfig:
CONFIG_JFFS2_DEV
CONFIG_JFFS2_LZO
CONFIG_JFFS2_NAND
CONFIG_JFFS2_PART_OFFSET
CONFIG_JFFS2_PART_SIZE
Signed-off-by: Tom Rini <trini@konsulko.com>
For the symbols which are both hard-coded as enabled and used, move to
Kconfig. The rest of the CONFIG_YAFFS namespace is unselected anywhere,
so we leave it as is.
Signed-off-by: Tom Rini <trini@konsulko.com>
The original purpose of mtd_erase_callback() in Linux at the time it was
imported to U-Boot, was to inform the caller that erasing is done (since
it was an asynchronous operation).
All supplied callback methods in U-Boot do nothing, but the
mtd_erase_callback() function was (until previous patch) grossly abused
in U-Boot's mtdpart implementation for completely different purpose.
Since we got rid of the abusement, remove the mtd_erase_callback()
function and the .callback member from struct erase_info entirely, in
order to avoid such problems in the future.
Signed-off-by: Marek Behún <marek.behun@nic.cz>
This patch optimizes the commit mentioned below by avoiding running
a set of commands which are useless in the case when
size < mydata->sect_size and sect_count would be 0.
Fixes: 5b3ddb17ba ("fs/fat/fat.c: Do not perform zero block reads if there are no blocks left")
Signed-off-by: Ricardo Salveti <ricardo@foundries.io>
Co-developed-by: Oleksandr Suvorov <oleksandr.suvorov@foundries.io>
Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@foundries.io>
We only include <linux/mtd/rawnand.h> in <nand.h> for the forward
declaration of struct nand_chip, so do that directly. Then, include
<linux/mtd/rawnand.h> where required directly.
Signed-off-by: Tom Rini <trini@konsulko.com>
Output like the following is quite irritating:
=> bootefi hello
Scanning disk mmc2.blk...
No valid Btrfs found
Bad magic number for SquashFS image.
** Unrecognized filesystem type **
Scanning disk mmc1.blk...
No valid Btrfs found
Bad magic number for SquashFS image.
** Unrecognized filesystem type **
Scanning disk mmc0.blk...
No valid Btrfs found
Bad magic number for SquashFS image.
** Unrecognized filesystem type **
Albeit a whole disk may be formatted with a filesystem in most cases
a partition table is used and the whole disk (partition number 0) doesn't
contain a filesytem. Some partitions may only contain a blob. Not seeing a
filesytem on the whole disk or on any partition is only worth a debug
message.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
This message comes up a lot when scanning filesystems. It suggests to the
user that there is some sort of error, but in fact there is no reason to
expect that a particular partition has a sqfs filesystem. Other
filesystems don't print this error.
Turn it into a debug message.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
This message comes up a lot when scanning filesystems. It suggests to the
user that there is some sort of error, but in fact there is no reason to
expect that a particular partition has a btrfs filesystem. Other
filesystems don't print this error.
Turn it into a debug message.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Marek Behún <marek.behun@nic.cz>
Reviewed-by: Qu Wenruo <wqu@suse.com>
BTRFS volume consists of a number of subvolumes which can be mounted separately
from each other. The top-level subvolume always exists even if no subvolumes
were created manually. A subvolume can be denoted as the default subvolume i.e.
the subvolume which is mounted by default.
The default "default subvolume" is the top-level one, but this is far from the
common practices used in the wild. For instance, openSUSE provides an OS
snapshot/rollback feature based on BTRFS. To achieve this, the actual OS root
filesystem is located into a separate subvolume which is "default" but not
"top-level". That means that the /boot/dtb/ directory is also located inside
this default subvolume instead of top-level one.
However, the existing btrfs u-boot driver always uses the top-level subvolume
as the filesystem root. This behaviour 1) is inconsistent with
mount /dev/sda1 /target
command, which mount the default subvolume 2) leads to the issues when
/boot/dtb cannot be found properly (see the reference).
This patch uses the default subvolume as the filesystem root to overcome
mentioned issues.
Reference: https://bugzilla.suse.com/show_bug.cgi?id=1185656
Signed-off-by: Matwey V. Kornilov <matwey.kornilov@gmail.com>
Fixes: f06bfcf54d ("fs: btrfs: Crossport open_ctree_fs_info() from btrfs-progs")
Reviewed-by: Qu Wenruo <wqu@suse.com>
In SquashFS, the contents of a directory is stored by
squashfs_directory_entry structures which contain the file's name, inode
and position within the filesystem.
The inode number is not stored directly; instead each directory has one
or more headers which set a base inode number, and files store the
offset from that to the file's inode number.
In mksquashfs, each inode is allocated a number in the same order as
they are written to the directory table; thus the offset from the
header's base inode number to the file's inode number is usually
positive.
Hardlinks are simply stored with two directory entries referencing the
same file. This means the second entry will thus have an inode number
much lower than the surrounding files. Since the header's base inode
number comes from the first entry that uses the header, this delta will
usually be negative.
Previously, U-Boot's squashfs_directory_entry.inode_offset field was
declared as an unsigned value. Thus when a negative value was found, it
would either resolve to an invalid inode number or to that of an
unrelated file.
A squashfs image to test this can be created like so:
echo hi > sqfs_test_files/001-root-file
mkdir sqfs_test_files/002-subdir
touch sqfs_test_files/002-subdir/003-file
ln sqfs_test_files/{001-root-file,002-subdir/004-link}
mksquashfs sqfs_test_files/ test.sqfs -noappend
Note that squashfs sorts the files ASCIIbetacally, so we can use the
names to control the order they appear in. The ordering is important -
the first reference to the file must have a lower inode number than the
directory in which the second reference resides, and the second
reference cannot be the first file in the directory.
Listing this sample image in U-Boot results in:
=> sqfsls virtio 2 002-subdir
0 003-file
Inode not found.
0 004-link
Signed-off-by: Campbell Suter <campbell@snapit.group>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
It is a pain to have to specify the value 16 in each call. Add a new
hextoul() function and update the code to use it.
Add a proper comment to simple_strtoul() while we are here.
Signed-off-by: Simon Glass <sjg@chromium.org>
Since the ACPI-generation code makes use of UUIDs we typically need to
enabled UUID support for it to build. Add a new Kconfig condition.
Use it for BTRFS also.
Signed-off-by: Simon Glass <sjg@chromium.org>
When reading a directory in the UEFI file system we have to return file
attributes and timestamps. Copy this data to the directory entry structure.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
The fragmented files were not correctly read because of two issues:
- The squashfs_file_info struct has a field named 'comp', which tells if
the file's fragment is compressed or not. This field was always set to
'true' in sqfs_get_regfile_info and sqfs_get_lregfile_info. It should
actually take sqfs_frag_lookup's return value. This patch addresses
these two assignments.
- In sqfs_read, the fragments (compressed or not) were copied to the
output buffer through a for loop which was reading data at the wrong
offset. Replace these loops by equivalent calls to memcpy, with the
right parameters.
I tested this patch by comparing the MD5 checksum of a few fragmented
files with the respective md5sum output in sandbox, considering both
compressed and uncompressed fragments.
Signed-off-by: Joao Marcos Costa <jmcosta944@gmail.com>
Tested-by: Richard Genoud <richard.genoud@posteo.net>
Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>
