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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170613000622.GB25393@khazad-dum.debian.net>
Date:   Mon, 12 Jun 2017 21:06:22 -0300
From:   Henrique de Moraes Holschuh <hmh@....eng.br>
To:     Marcin Szewczyk <marcin.szewczyk@...ny.org>
Cc:     linux-kernel@...r.kernel.org
Subject: Re: An inconsistent behaviour if using built-in initramfs and
 damaged external one

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