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

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

[Marcin Szewczyk]

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

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

[Henrique de Moraes Holschuh]

On Mon, 12 Jun 2017, Marcin Szewczyk wrote:
> 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 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.

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

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

[Henrique de Moraes Holschuh]

On Mon, 12 Jun 2017, Henrique de Moraes Holschuh wrote:
> 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.

...

> 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.

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