linux-kernel - Re: [PATCH v3 1/2] init/initramfs.c: do unpacking asynchronously

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: <5ae69ecb-7f1a-c10b-5f5f-db3ee47dc059@rasmusvillemoes.dk>
Date:   Mon, 15 Mar 2021 22:59:52 +0100
From:   Rasmus Villemoes <linux@...musvillemoes.dk>
To:     Andrew Morton <akpm@...ux-foundation.org>,
        Rasmus Villemoes <linux@...musvillemoes.dk>
Cc:     Luis Chamberlain <mcgrof@...nel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Jessica Yu <jeyu@...nel.org>, Borislav Petkov <bp@...en8.de>,
        Jonathan Corbet <corbet@....net>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org,
        Nick Desaulniers <ndesaulniers@...gle.com>
Subject: Re: [PATCH v3 1/2] init/initramfs.c: do unpacking asynchronously

On 15/03/2021 22.33, Andrew Morton wrote:
> On Sat, 13 Mar 2021 22:25:27 +0100 Rasmus Villemoes <linux@...musvillemoes.dk> wrote:
> 
>> Most of the boot process doesn't actually need anything from the
>> initramfs, until of course PID1 is to be executed. So instead of doing
>> the decompressing and populating of the initramfs synchronously in
>> populate_rootfs() itself, push that off to a worker thread.
[...]
> 
> This seems sensible.  And nice.

Thanks.

> Are you sure that you've found all the code paths that require that
> initramfs be ready?  You have one in init/main, one in the bowels of
> the firmware loader and one in UML.  How do we know that there are no
> other such places?

No, I don't _know_ that I've found all such places, but nobody, Linus
included, have been able to come up with any that I've missed. At this
point, the only way to figure it out is to get the code into linux-next
(and the more time it gets before the merge window, the better). Since
it's default-on, it should get quite a bit of testing that way.

> Also, all this doesn't buy anything for uniprocessor machines.  Is
> there a simple way of making it all go away if !CONFIG_SMP?

It absolutely does buy something for UP, at least for some special case:
The ppc machine I'm talking about is UP, and without getting the
initramfs unpacking pushed to the background, the machine doesn't get to
pet the external hardware watchdog soon enough. So this is really the
difference between booting successfully or being a power-consuming paper
weight. Also, lots of device initialization actually makes the CPU
twiddle its thumbs now and then, so having something other than the idle
thread to schedule makes better use of the single CPU.

Rasmus