sbabic/libubootenv

Generic library and tools to access and modify U-Boot environment from User Space

libubootenv's Issues

"Replacement old tools" is untrue for `fw_setenv`

The script format supported by this new implementation of fw_setenv is not compatible with the one of the original implementation.

From the original fw_setenv help message (eg. version 2019.01):

Script Syntax:
  key [space] value
  lines starting with '#' are treated as comment

  A variable without value will be deleted. Any number of spaces are
  allowed between key and value. Space inside of the value is treated
  as part of the value itself.

The new (undocumented) implementation instead requires the following format:

name=value

Blindly switching to the new fw_setenv tool in an otherwise working setup leads to unpleasant surprises. Been there, found this.

fw_printenv does not work with `/dev/disk/by-path/platform-11270000.ufshci-scsi-0:0:0:1`

Hi,

I have /dev/disk/by-path/platform-11270000.ufshci-scsi-0:0:0:1 on my device and I found that fw_printenv will separate the path by checking : then only check if /dev/disk/by-path/platform-11270000.ufshci-scsi-0 exists.

so I am wondering if it makes sense to check the original path first, if it does not exitst, then fallback to the original mechanism that check the splitted path?

I have draft a diff and it works fine on my device

diff --git a/src/uboot_env.c b/src/uboot_env.c
index b924c49..a5dc598 100644
--- a/src/uboot_env.c
+++ b/src/uboot_env.c
@@ -342,21 +342,26 @@ static int normalize_device_path(char *path, struct uboot_flash_env *dev)
        char *sep = NULL, *normalized = NULL;
        size_t normalized_len = 0, volume_len = 0, output_len = 0;
 
-       /*
-        * if volume name is present, split into device path and volume
-        * since only the device path needs normalized
-        */
-       sep = strchr(path, DEVNAME_SEPARATOR);
-       if (sep)
-       {
-               volume_len = strlen(sep);
-               *sep = '\0';
-       }
 
+       /* Check the original path first, then fallback to splitted path */
        if ((normalized = realpath(path, NULL)) == NULL)
        {
-               /* device file didn't exist */
-               return -EINVAL;
+               /*
+                * if volume name is present, split into device path and volume
+                * since only the device path needs normalized
+                */
+               sep = strchr(path, DEVNAME_SEPARATOR);
+               if (sep)
+               {
+                       volume_len = strlen(sep);
+                       *sep = '\0';
+               }
+
+               if ((normalized = realpath(path, NULL)) == NULL)
+               {
+                       /* device file didn't exist */
+                       return -EINVAL;
+               }
        }
 
        normalized_len = strlen(normalized);

Default environment

Dear

For industrial embedded systems it is preferred to have a system which recovers when the environment gets corrupt. In current implementation, the fw_printenv and fw_setenv tool just fail when the environment is corrupt.

A default environment is supported by the tool but not used by default. The configuration file /etc/fw_env.config however is loaded as fallback and another file can be specified with argument -c. Isn't it better to also provide a default path for the default environment?

What's the reason to implement it this way?

Kind regards
Pieter Cardoen

issue with LINE_LENGTH in libuboot_load_file()

Hi,
In uboot_env.c the libuboot_load_file() function is used to load and parse the default environment file passed with -f option. The issue I encountered, is that this function will read the file line by line in chunks of max LINE_LENGTH characters (to extract the environment variables from it), and if a line in the provided file exceeds this limit, the environment will be corrupted !!!

Two problems with this: firstly there is no warning that is printed. Normally the function should detect this and return error when encountered, to avoid corrupted environment. (I'll be happy to submit a patch for this)

Secondly, the value of LINE_LENGTH is set at compile time, and cannot be modified later. Maybe it could be interesting to have an additional option that goes with the -f option to specify the max line length.

If this is viewed as not a bug by the maintainer, I would suggest at least to add a warning about this limitation in the README or the usage of the cmd.

The default value for LINE_LENGTH is 1024 bytes, which is defined as a macro. 1024B can be easily exceeded in some cases when defining scripts e.g. Recovery/Prod scripts.

Kind regards
Abder

CRC32 error

We are working on imx8 bsp by nxp ( Yocto Kirkstone). libubootenv recipe version 0.3.2
I have cloned meta-swupdate and did modifiacations to adapt it to IMX.(see below defconfig modifications)
When running fw_printenv, fw_setenv for the first time it print "Cannot read environment, using default" (libuboot_open returns -61 nodata)
in next runs fw_printenv, fw_setenv are loading the config and the env file correctly
when I run setenv the value is changed as expected in the "current" env and the CRC is calculated and stored.
when uboot loads in the next power cycle it complains about bad CRC and loads default evniorment instead.

I suspect there is somekind of missalignment between the CRC calculation of u-boot and the CRC calculation done in libubootenv uboot_env.c.

are you farmiliar with such a problem ?

CONFIG_BOOTCOUNT_LIMIT=y
CONFIG_BOOTCOUNT_ENV=y
CONFIG_SYS_REDUNDAND_ENVIRONMENT=y
CONFIG_ENV_OFFSET_REDUND=0x402000
CONFIG_BOOTCOUNT_BOOTLIMIT=3

fw_printenv 'undefined symbol: crc32'

Hello,
Attempting to use fw_printenv on raspberry pi cm3. However, this always comes back with the error:
fw_printenv: symbol lookup error: /usr/lib/libubootenv.so.0.1: undefined symbol: crc32

Attempted to link with zlib but still no luck. Any thoughts?

Thank you for your time.

Please make YAML a build option

YAML pulls in new libs which takes space and existing project has no use for YAML

New release?

How about a 0.3 release? Especially the pkgconfig support would be nice to have in a release.

Error "Cannot read environment, using default" - after upgrade from Yocto gatesgarth to langdale - 0.3.2 and 0.3.3

I originally posted this as a comment to issue #20, however it's probably easier to manage if I move it into a new issue here.

I have a similar issue to #20 after updating from gatesgarth to langdale - with both libubootenv 0.3.2 and 0.3.3.

Note: this was working for 0.3.2 in gatesgarth but has broken for me in langdale with both 0.3.2 and 0.3.3.

The U-Boot config is stored in SPI Flash, and U-Boot reports this when booting:

Loading Environment from SPIFlash... SF: Detected mt25qu02g with page size 512 Bytes, erase size 128 KiB, total 512 MiB

fw_printenv and fw_setenv were working in gatesgarth with the config:

/dev/mtd0		0x2e00000	0x40000     0x40000       0       1

U-Boot config:

CONFIG_ENV_OFFSET=0x2E00000
CONFIG_ENV_OFFSET_REDUND=0x1E80000
CONFIG_ENV_IS_IN_SPI_FLASH=y
CONFIG_ENV_SIZE=0x40000
CONFIG_ENV_SECT_SIZE=0x40000

But with langdale, and no changes to U-Boot's config, I now see:

# fw_printenv -c fw_env.config bootcmd
Cannot read environment, using default
Cannot read default environment from file

I understand that the second line is due to a missing u-boot-initial-env file. It's the first line I'm concerned about.

Also, with strace, I can see that the environment is actually read from the Flash (I have a variable 'altbootcmd', which appears below), but it is then discarded for some reason and the error emitted instead:

# strace fw_printenv -c fw_env.config bootcmd
...
openat(AT_FDCWD, "/dev/mtd0", O_RDONLY) = 4
lseek(4, 48234496, SEEK_SET)            = 48234496
read(4, "\245a\30\0\0altbootcmd=run sqc_boot_alt"..., 262144) = 262144
close(4)                                = 0
munmap(0xffffba48f000, 266240)          = 0
write(2, "Cannot read environment, using d"..., 39Cannot read environment, using default
) = 39
...

The first bytes of the relevant section of Flash look like this:

# hexdump -C -s 0x2E00000 -n 64 /dev/mtd0
02e00000  a5 61 18 00 00 61 6c 74  62 6f 6f 74 63 6d 64 3d  |.a...altbootcmd=|
02e00010  72 75 6e 20 73 71 63 5f  62 6f 6f 74 5f 61 6c 74  |run sqc_boot_alt|
02e00020  00 61 72 63 68 3d 61 72  6d 00 62 61 75 64 72 61  |.arch=arm.baudra|
02e00030  74 65 3d 31 31 35 32 30  30 00 62 6f 61 72 64 3d  |te=115200.board=|

U-Boot does not report a corrupted environment, and in the course of this testing I have done env default -f -a ; saveenv several times to make sure it is valid.

I'll dig into the source code next, and try to figure out why the 262144 (0x40000) bytes are not processed as a valid environment.

fw_printenv Configuration file wrong or corrupted

I am running into the following issue that I am struggling to get to the bottom of:

root@orange-pi-zero:~# fw_printenv
Configuration file wrong or corrupted

I am running v0.3.1 on a yocto build (hardknott) for the orange pi zero. This is a relatively bare-bones implementation so far, but the following, potentially relevant parameters, are set in my local.conf.

WKS_FILE = "sunxi-sdcard-image.wks.in"
PREFERRED_PROVIDER_u-boot="u-boot"
PREFERRED_PROVIDER_virtual/bootloader="u-boot"
PREFERRED_PROVIDER_virtual/kernel="linux-mainline"
KERNEL_DEVICETREE = ""

What is odd to me about this is when I stop the u-boot process and run printenv, it shows exactly what I'd expect to be coming from fw_printenv. Makes me think the issue is further downstream.

This issue is coming about because I am attempting to utilize rauc for OTA updates. Rauc uses fw_printenv for one of its processes.

Any help would be much appreciated. Please let me know if there is any additional information that would help us figure this out.

Please add tag

Hi,

It has been released version 0.1, but it seems that git tags are not set.
Could you add it?

Buffer overflows in libuboot_env_store

It looks like there are a few buffer overflows possible in libuboot_env_store.

Some effort has been made to avoid this. For example, while appending variables into the buffer, it checks if there there is enough space left in the buffer for the variable name, the variable value, and two more bytes (the equal and the null terminator for this variable), if there is not enough space, it returns -ENOMEM. So far so good.

Unfortunately, that is not the only place where data gets appended to the buffer. There are two more areas where that happens, and both look problematic to me.

For the first, let us assume that saveflags remains zero. In that scenario, right after writing out the variables into the buffer, the code will execute *buf++ = '\0';. It is not clear to me that is safe. I'm pretty sure that the variable populating logic would allow the null byte for the final variable to land in the very last byte of the buffer. Then the *buf++ = '\0'; line for terminating the list would be writing one past the end of the buffer.

Even worse is if execution enters into the saveflags branch. That branch does not check before writing with snprintf. For the very first such write, snprintf will (by design) ensure the buffer cannot overflow. However, snprintf will in such a scenario return a value larger than size, which will increment the buffer pointer past the end of the buffer. Then the next size calculation will underflow and wrap around (because size_t is unsigned). Because of that wrap-around the next snprintf would think there is tons of space left and could write outside the bounds of the buffer.

Calculating the sizes in that branch seems more finicky to do up front. An alternative could be to store the return value of each snprintf call into ret, and then check for truncation which is defined as a return value greater than or equal to the size parameter. If truncation occurred, return -ENOMEM. Otherwise we could proceed with buf += ret.

Lastly since we are already discussing security adjacent considerations, the use of malloc instead of calloc for this buffer (which gets written in full to disk, but is not always fully initialized by the function) is a potential information leakage channel. While hopefully swupdate is not just freeing memory that contains sensitive stuff, it is plausible that some other applications that use this as a library might.

Hope this helps.

libubootenv v0.3.2 cannot read env

Hi, I'm having strange issue on cm4. I'm using v0.3.2 and print env ends with:

fw_printenv 
Cannot read environment, using default
Cannot read default environment from file

I checked config file and it's present with content:

cat /etc/fw_env.config
/dev/mmcblk0 0x800000 0x2000
/dev/mmcblk0 0x1000000 0x2000

I checked with dd and hexdump if env is present at offset and it is:

dd if=/dev/mmcblk0 of=env.bin bs=1024 skip=8192 count=1 | hexdump -C env.bin

print me :

00000000  ce a7 f3 12 04 61 3d 31  00 61 6c 74 62 6f 6f 74  |.....a=1.altboot|
00000010  63 6d 64 3d 72 75 6e 20  6d 65 6e 64 65 72 5f 61  |cmd=run mender_a|
00000020  6c 74 62 6f 6f 74 63 6d  64 3b 20 72 75 6e 20 62  |ltbootcmd; run b|
00000030  6f 6f 74 63 6d 64 00 61  72 63 68 3d 61 72 6d 00  |ootcmd.arch=arm.|
00000040  62 61 75 64 72 61 74 65  3d 31 31 35 32 30 30 00  |baudrate=115200.|
00000050  62 6f 61 72 64 3d 72 70  69 00 62 6f 61 72 64 5f  |board=rpi.board_|
00000060  6e 61 6d 65 3d 43 6f 6d  70 75 74 65 20 4d 6f 64  |name=Compute Mod|
00000070  75 6c 65 20 34 00 62 6f  61 72 64 5f 72 65 76 3d  |ule 4.board_rev=|
00000080  30 78 31 34 00 62 6f 61  72 64 5f 72 65 76 5f 73  |0x14.board_rev_s|
00000090  63 68 65 6d 65 3d 31 00  62 6f 61 72 64 5f 72 65  |cheme=1.board_re|
000000a0  76 69 73 69 6f 6e 3d 30  78 41 30 33 31 34 30 00  |vision=0xA03140.|
000000b0  62 6f 6f 74 5f 61 5f 73  63 72 69 70 74 3d 6c 6f  |boot_a_script=lo|
000000c0  61 64 20 24 7b 64 65 76  74 79 70 65 7d 20 24 7b  |ad ${devtype} ${|
000000d0  64 65 76 6e 75 6d 7d 3a  24 7b 64 69 73 74 72 6f  |devnum}:${distro|
000000e0  5f 62 6f 6f 74 70 61 72  74 7d 20 24 7b 73 63 72  |_bootpart} ${scr|
000000f0  69 70 74 61 64 64 72 7d  20 24 7b 70 72 65 66 69  |iptaddr} ${prefi|
00000100  78 7d 24 7b 73 63 72 69  70 74 7d 3b 20 73 6f 75  |x}${script}; sou|
00000110  72 63 65 20 24 7b 73 63  72 69 70 74 61 64 64 72  |rce ${scriptaddr|
00000120  7d 00 62 6f 6f 74 5f 65  66 69 5f 62 69 6e 61 72  |}.boot_efi_binar|
00000130  79 3d 6c 6f 61 64 20 24  7b 64 65 76 74 79 70 65  |y=load ${devtype|
00000140  7d 20 24 7b 64 65 76 6e  75 6d 7d 3a 24 7b 64 69  |} ${devnum}:${di|
00000150  73 74 72 6f 5f 62 6f 6f  74 70 61 72 74 7d 20 24  |stro_bootpart} $|
00000160  7b 6b 65 72 6e 65 6c 5f  61 64 64 72 5f 72 7d 20  |{kernel_addr_r} |
00000170  65 66 69 2f 62 6f 6f 74  2f 62 6f 6f 74 61 61 36  |efi/boot/bootaa6|
00000180  34 2e 65 66 69 3b 20 69  66 20 66 64 74 20 61 64  |4.efi; if fdt ad|
00000190  64 72 20 24 7b 66 64 74  5f 61 64 64 72 5f 72 7d  |dr ${fdt_addr_r}|
000001a0  3b 20 74 68 65 6e 20 62  6f 6f 74 65 66 69 20 24  |; then bootefi $|
000001b0  7b 6b 65 72 6e 65 6c 5f  61 64 64 72 5f 72 7d 20  |{kernel_addr_r} |
000001c0  24 7b 66 64 74 5f 61 64  64 72 5f 72 7d 3b 65 6c  |${fdt_addr_r};el|
000001d0  73 65 20 62 6f 6f 74 65  66 69 20 24 7b 6b 65 72  |se bootefi ${ker|
000001e0  6e 65 6c 5f 61 64 64 72  5f 72 7d 20 24 7b 66 64  |nel_addr_r} ${fd|
000001f0  74 63 6f 6e 74 72 6f 6c  61 64 64 72 7d 3b 66 69  |tcontroladdr};fi|
00000200  00 62 6f 6f 74 5f 65 66  69 5f 62 6f 6f 74 6d 67  |.boot_efi_bootmg|
00000210  72 3d 69 66 20 66 64 74  20 61 64 64 72 20 24 7b  |r=if fdt addr ${|
00000220  66 64 74 5f 61 64 64 72  5f 72 7d 3b 20 74 68 65  |fdt_addr_r}; the|
00000230  6e 20 62 6f 6f 74 65 66  69 20 62 6f 6f 74 6d 67  |n bootefi bootmg|
00000240  72 20 24 7b 66 64 74 5f  61 64 64 72 5f 72 7d 3b  |r ${fdt_addr_r};|
00000250  65 6c 73 65 20 62 6f 6f  74 65 66 69 20 62 6f 6f  |else bootefi boo|
00000260  74 6d 67 72 3b 66 69 00  62 6f 6f 74 5f 65 78 74  |tmgr;fi.boot_ext|
00000270  6c 69 6e 75 78 3d 73 79  73 62 6f 6f 74 20 24 7b  |linux=sysboot ${|
00000280  64 65 76 74 79 70 65 7d  20 24 7b 64 65 76 6e 75  |devtype} ${devnu|
00000290  6d 7d 3a 24 7b 64 69 73  74 72 6f 5f 62 6f 6f 74  |m}:${distro_boot|
000002a0  70 61 72 74 7d 20 61 6e  79 20 24 7b 73 63 72 69  |part} any ${scri|
000002b0  70 74 61 64 64 72 7d 20  24 7b 70 72 65 66 69 78  |ptaddr} ${prefix|
000002c0  7d 24 7b 62 6f 6f 74 5f  73 79 73 6c 69 6e 75 78  |}${boot_syslinux|
000002d0  5f 63 6f 6e 66 7d 00 62  6f 6f 74 5f 6e 65 74 5f  |_conf}.boot_net_|
000002e0  75 73 62 5f 73 74 61 72  74 3d 75 73 62 20 73 74  |usb_start=usb st|
000002f0  61 72 74 00 62 6f 6f 74  5f 70 63 69 5f 65 6e 75  |art.boot_pci_enu|
00000300  6d 3d 70 63 69 20 65 6e  75 6d 00 62 6f 6f 74 5f  |m=pci enum.boot_|
00000310  70 72 65 66 69 78 65 73  3d 2f 20 2f 62 6f 6f 74  |prefixes=/ /boot|
00000320  2f 00 62 6f 6f 74 5f 73  63 72 69 70 74 5f 64 68  |/.boot_script_dh|
00000330  63 70 3d 62 6f 6f 74 2e  73 63 72 2e 75 69 6d 67  |cp=boot.scr.uimg|
00000340  00 62 6f 6f 74 5f 73 63  72 69 70 74 73 3d 62 6f  |.boot_scripts=bo|
00000350  6f 74 2e 73 63 72 2e 75  69 6d 67 20 62 6f 6f 74  |ot.scr.uimg boot|
00000360  2e 73 63 72 00 62 6f 6f  74 5f 73 79 73 6c 69 6e  |.scr.boot_syslin|
00000370  75 78 5f 63 6f 6e 66 3d  65 78 74 6c 69 6e 75 78  |ux_conf=extlinux|
00000380  2f 65 78 74 6c 69 6e 75  78 2e 63 6f 6e 66 00 62  |/extlinux.conf.b|
00000390  6f 6f 74 5f 74 61 72 67  65 74 73 3d 6d 6d 63 30  |oot_targets=mmc0|
000003a0  20 6d 6d 63 31 20 75 73  62 30 20 70 78 65 20 64  | mmc1 usb0 pxe d|
000003b0  68 63 70 20 00 62 6f 6f  74 61 72 67 73 3d 63 6f  |hcp .bootargs=co|
000003c0  68 65 72 65 6e 74 5f 70  6f 6f 6c 3d 31 4d 20 38  |herent_pool=1M 8|
000003d0  32 35 30 2e 6e 72 5f 75  61 72 74 73 3d 31 20 73  |250.nr_uarts=1 s|
000003e0  6e 64 5f 62 63 6d 32 38  33 35 2e 65 6e 61 62 6c  |nd_bcm2835.enabl|
000003f0  65 5f 63 6f 6d 70 61 74  5f 61 6c 73 61 3d 30 20  |e_compat_alsa=0 |

Am i missing something? Thanks.

Block device incorrectly detected as mtd device

On my device, I have been using the block device /dev/mtdblock4 to access the environment. With the old U-Boot fw_setenv this worked fine, but libubootenv incorrectly detects this as an MTD device, causing writes to fail.

lock option missing from cmdline api

At various points during boot, /var/lock is not always available/mounted yet so its important to be able to specify an alternative for the lockfile.

Currently its hard-coded into the code, however in u-boot-fw-utils is was a configurable option.

We are currently in process of replacing u-boot-fw-utils with libubootenv and as we are using the lock option its breaking our scripts.

https://developer.toradex.com/knowledge-base/u-boot-fw-utils

-l, --lock lock node, default:/var/lock

https://github.com/sbabic/libubootenv/blob/master/src/uboot_env.c#L58