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: <CAK7LNASUsZB--DWMB4hpw74OnTiz+d2jrdp+CA9L=AOdkbEmhg@mail.gmail.com>
Date:   Fri, 17 Aug 2018 17:14:26 +0900
From:   Masahiro Yamada <yamada.masahiro@...ionext.com>
To:     Andrzej Pietrasiewicz <andrzej.p@...sung.com>
Cc:     Bjørn Forsman <bjorn.forsman@...il.com>,
        LKML <linux-kernel@...r.kernel.org>, forney@...gle.com
Subject: Re: [PATCH] Revert "kbuild: create deterministic initramfs directory listings"

2018-08-17 16:47 GMT+09:00 Andrzej Pietrasiewicz <andrzej.p@...sung.com>:
> 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


I cannot add LANG=C to the high-level of the build system at least
since it would break the localization.


-- 
Best Regards
Masahiro Yamada