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: <532CC215.1000107@ahsoftware.de>
Date:	Fri, 21 Mar 2014 23:49:57 +0100
From:	Alexander Holler <holler@...oftware.de>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] initramfs: print error and shell out for unsupported
 content

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.

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).

And I think that just isn't worth the time. Using find | cpio works just
fine to generate a cpio archive and usually an initramfs just contains
some megabytes. So it isn't a problem at all to rebuild the complete
cpio archive with every call of make, it doesn't need much more than
about a second or similiar on almost any machine.

And for the records, I indeed had a deeper look, trying to fix it. But,
as said, quickly realized that it will need too much effort and doesn't
make sense, if it will be doable correctly at all.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ