An inconsistent behaviour if using built-in initramfs and damaged external one

Hi,

during my experiments with initramfs I have noticed there is something that looks like a bug in the 9-year old code[1] of the clean_rootfs() function in init/initramfs.c. An inconsistent behaviour appears when I have both the built-in initramfs and the one in the external file but the latter is somehow damaged (e.g. wrong padding).

I wanted to leverage the functionality described in the ramfs documentation[2]: "It can also be used to supplement the kernel's built-in initramfs image. The files in the external archive will overwrite any conflicting files in the built-in initramfs archive."

Clearly there is an intention in the code to do cleanup and return to the built-in initramfs if the external initramfs was only partially unpacked:

#v+

    char *err = unpack_to_rootfs(__initramfs_start, __initramfs_size);
    if (err)
        panic(err);    /* Failed to decompress INTERNAL initramfs */
    if (initrd_start) {
#ifdef CONFIG_BLK_DEV_RAM
        int fd;
        printk(KERN_INFO "Trying to unpack rootfs image as initramfs...\n");
        err = unpack_to_rootfs((char *)initrd_start,
            initrd_end - initrd_start);
        if (!err) {
            free_initrd();
            goto done;
        } else {
            clean_rootfs();
            unpack_to_rootfs(__initramfs_start, __initramfs_size);
        }
        printk(KERN_INFO "rootfs image is not initramfs (%s)"
                "; looks like an initrd\n", err);

#v-

But inside the clean_rootfs() function non-empty directories are not going to be removed:
#v+

    ret = sys_newlstat(dirp->d_name, &st);
    WARN_ON_ONCE(ret);
    if (!ret) {
        if (S_ISDIR(st.st_mode))
            sys_rmdir(dirp->d_name);
        else
            sys_unlink(dirp->d_name);
    }
    num -= dirp->d_reclen;

#v-
Call to sys_rmdir() is assumed to be always successful.

I am aware that this is not a serious bug (if a bug at all) but I would like this note to last in the mailing list archive because debugging it took me some time and possibly some could stumble upon it as well.

Because I missed the "rootfs image is not initramfs […] looks like an initrd" message in the dmesg at first I thought that files are not overwritten with their external versions at all. I wondered how it was possible to have the following effects:

- if no /etc/shadow in the built-in image, /etc/shadow in the external though damaged image → password from the *external* image works,

- if /etc/shadow in the built-in image, /etc/shadow in the external though damaged image → password from the *built-in* image works,

- files in / from the external though damaged initramfs disappear, but files in /etc survive.

[1]: https://github.com/torvalds/linux/commit/df52092f3c97788592ef72501a43fb7ac6a3cfe0
[2]: https://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt

Marcin Szewczyk
http://wodny.org

...

Then, here is another very minor gotcha (or feature?) people might want to be aware of.

When using *early* initramfs images (e.g. for microcode updates), the files are searched for using the full path. You do *not* have to include the directories a, then a/b, then a/b/c in that exact order, to finally have a file a/b/c/d. It is enough to just have file a/b/c/d.

So, you can just have /kernel/x86/microcode/<processor_vendor>.bin (without leading /kernel, /kernel/x86, /kernel/x86/microcode) in an early initramfs, and it will *work* for early microcode update purposes.

However, the kernel will attempt to merge the contents of these early initramfs images into the final initramfs. For that to work, you need the leading directories (path components) to be created before their children and in the correct order, because the kernel will not supply any that are missing: instead, it will drop objects it can't create when their parent directories were not created beforehand.

So, if the early initramfs has a/, a/b, and e/f/g/h, the kernel can use a/b and e/f/g/h for early initramfs purposes (e.g. microcode updates, ACPI table overrides, etc), but only a/ and a/b are likely to be present in the final initramfs. e/f/g/h will likely be dropped, because some leading path components are missing (e/, e/f, e/f/g)... *unless* they were created by a previously-loaded initramfs segment.

I am not aware of anything that makes use of this behavior, but it is there since early initramfs images were introduced.

  Henrique Holschuh

...

I better clarify this one. I don't know of anything that makes use of this behavior *with the purpose of dropping uneeded files from the final initramfs*.

iucode_tool[1] can optionally make use of the exact early initramfs semanthics to shrink its size to the absolute minimum. That means it will use the "doesn't require leading directory entries" feature, as well as a 16-byte block size.

[1] https://gitlab.com/iucode-tool/iucode-tool/wikis/home

  Henrique Holschuh