linux-kernel - Re: gen_initramfs_list.sh escaping problem or stale dependency file?

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: <ef840fed-065a-7b03-580e-66add0d89f59@suse.com>
Date:   Fri, 23 Sep 2016 09:05:17 +0200
From:   Michal Marek <mmarek@...e.com>
To:     Florian Fainelli <f.fainelli@...il.com>
Cc:     linux-kernel@...r.kernel.org, sam@...nborg.org, mmarek@...e.cz,
        joe@...ches.com, lede-dev@...ts.infradead.org,
        openwrt-devel@...ts.openwrt.org
Subject: Re: gen_initramfs_list.sh escaping problem or stale dependency file?

On 2016-09-19 22:00, Florian Fainelli wrote:
> On 09/13/2016 12:24 AM, Michal Marek wrote:
>> On Mon, Sep 12, 2016 at 05:12:15PM -0700, Florian Fainelli wrote:
>>> Hi,
>>>
>>> I have a root filesystem embedding filenames that look like these:
>>>
>>> /lib/data/<vid>:<pid>
>>>
>>> these are essentially files that can be matched against an USB
>>> vendor/product id in an easy way.
>>>
>>> Now, the fun part is that this is only a problem when doing the
>>> following (using OpenWrt/LEDE as a build system):
>>>
>>> 1:
>>> - set CONFIG_INITRAMFS_SOURCE=""
>>> - build kernel modules
>>> - build my user-space tools
>>> - build the kernel image
>>> - reconfigure the kernel to now use an initramfs
>>> - build the kernel w/ initramfs
>>>
>>> and then back to step 1 with the kernel build, would I hit this error:
>>>
>>> usr/Makefile:64: *** multiple target patterns.  Stop.
>> [...]
>>> Which sorts of make sense here because the file name contains a ":"
>>> which is not escaped, so GNU Make tries to interpret it.
>>>
>>> Now the part that does not quite make sense to me is why this file is
>>> even relevant here considering that the first thing we do is set
>>> CONFIG_INITRAMFS_SOURCE="" to disable the initramfs basically.
>>
>> It is possible that we read usr/Makefile twice for some reason. But the
>> real problem is the lack of escaping. Can you try the following
>> (untested) patch?
> 
> Can you submit an official patch for this? Thanks a lot!

The % escape is wrong. I'm trying to fix it or drop this escape.

Michal