linux-kernel - Re: [PATCH v2] initramfs: print error and shell out for unsupported content

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: <53334393.5050008@ahsoftware.de>
Date:	Wed, 26 Mar 2014 22:16:03 +0100
From:	Alexander Holler <holler@...oftware.de>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	linux-kernel@...r.kernel.org, Levente Kurusa <levex@...ux.com>
Subject: Re: [PATCH v2] initramfs: print error and shell out for unsupported
 content

Am 22.03.2014 00:07, schrieb Alexander Holler:
> Am 21.03.2014 23:55, schrieb Andrew Morton:
>> On Fri, 21 Mar 2014 23:49:57 +0100 Alexander Holler <holler@...oftware.de> wrote:
>>
>>> Am 21.03.2014 22:03, schrieb Andrew Morton:
>>>> On Thu, 20 Mar 2014 23:00:45 +0100 Alexander Holler <holler@...oftware.de> wrote:
>>>>
>>>>> The initramfs generation is broken for file and directory names which contain
>>>>> colons or spaces. Print an error and don't try to continue.
>>>
>>>> It would be better to fix the it-doesnt-work-with-all-filenames bug.
>>>> Any details on that?
>>>
>>> IMHO not worth the time. The whole process which is curently used is
>>> extremly fragile.
>>>
>>> E.g it's almost guaranteed to fail trying to include arbitrary filenames
>>> as dependencies in a Makefile. Besides the one problem I've discoverd
>>> with colons, there could be much more things happen, e.g. with filenames
>>> which do include other special Makefile characters you all would have to
>>> escape correctly.

To be a bit more verbose, (gnu)make doesn't support quoted filenames. 
That means one has to escape all kind of characters which might have a 
special meaning for make. Not really doable. Furthermore escaped 
characters are not very well supported by make and are usable only by a 
few rules.

>>> And the problem with spaces isn't as easy to fix as it first does look
>>> like. I think it might be easier to write the whole stuff new instead of
>>> trying to escape the spaces in various ways needed to end up correctly
>>> in the cpio (it first goes through shell code and is then feeded as some
>>> list to a C program).

To be a bit more verbose here, the shell script 
(scripts/gen_initramfs_list.sh) identifes filenames based on the 
position in a string which is delimited by the usual (shell) whitespace. 
E.g. $1 = filename, $2 = mode, ...
And this stuff is then feeded to usr/gen_init_cpio.c,which uses a 
similiar approach like

sscanf(line, "%" str(PATH_MAX) "s %" str(PATH_MAX) "s %o %d %d", name, 
target, ...

which obviously fails for filenames with whitspace too.

What I think might be reasonable is:

- get rid of the dependency list in form of a include into the Makefile 
and just generate the cpio-archive every time make is called. Common 
initramfs sizes are about a few megabytes and with today machines such a 
cpio-archive is build in about a second,

- get rid of gen_initramfs_list.sh and rewrite gen_init_cpio.c such that 
it reads the filenames, modes and similiar itself (e.g. by using stat(2)).


But I don't have any motivation to do so. Sorry.


Maybe Levente Kurusa is interested in doing so, he seems to have an 
interest in the topic as he was quiet fast to send an answer to my patch.


Regards,

Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/