linux-kernel - Re: [PATCH] Revert "kbuild: create deterministic initramfs directory listings"

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: <20180817074747eucas1p1a70969aac4238b0c8db0d8e59f4af078~LnGev9y9l2871228712eucas1p1X@eucas1p1.samsung.com>
Date:   Fri, 17 Aug 2018 09:47:45 +0200
From:   Andrzej Pietrasiewicz <andrzej.p@...sung.com>
To:     Bjørn Forsman <bjorn.forsman@...il.com>
Cc:     LKML <linux-kernel@...r.kernel.org>, forney@...gle.com,
        Masahiro Yamada <yamada.masahiro@...ionext.com>
Subject: Re: [PATCH] Revert
 "kbuild: create deterministic initramfs directory listings"

Hi Bjørn,

W dniu 17.08.2018 o 01:34, Bjørn Forsman pisze:
> On Thu, 16 Aug 2018 at 18:18, Andrzej Pietrasiewicz
> <andrzej.p@...sung.com> wrote:
>>
>> This reverts commit 9e6e0d5f2a2713402cf9dce69b9f9b516e4185d2.
>>
>> The reverted commit introduces broken builds. Even though the cpio archive
>> does contain all the specified files, it seems that the kernel, while
>> populating rootfs, scans the cpio buffer linearly and fails to create
>> files whose parent directories are nonexistent at the moment of this failed
>> creation. As a result, such files are not accessible when kernel boots into
>> initramfs.
>>

<snip>

> 
> I'm unable to reproduce it. On my system the listing is sorted so that
> it works (parent directories appear before files). I tried to run with
> LANG=C and it also sorts correctly. What is your LANG=? I think we
> better add a LANG=C somewhere in the kernel build system, because I
> think you have a LANG= that makes it sort differently. A quick fix
> would of course be to insert it right next to sort, but there may be
> other places that may break due to LANG= settings.
> 

Thanks for the tip. My LANG is pl_PL.UTF-8. Indeed, prefixing the "sort"
invocation in question with LANG=C does solve the problem. I don't feel
competent enough to say whether this is the correct place for the fix,
or if the fix should be made elsewhere. Another option is that it is the
"sort" itself that should be fixed (or the locale, or both).

Would you be able (as the author of the patch in question) to check if
there are other locales which cause the problem?

Thanks,

Andrzej