linux-kernel - Re: [PATCH] INITRAMFS: Add option to preserve mtime from INITRAMFS cpio images

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]

Date:	Thu, 4 Sep 2008 09:11:42 +0200
From:	"Frans Meulenbroeks" <fransmeulenbroeks@...il.com>
To:	"Nye Liu" <nyet@....com>
Cc:	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Nye Liu" <nyet@...t.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] INITRAMFS: Add option to preserve mtime from INITRAMFS cpio images

2008/9/4 Nye Liu <nyet@....com>:
> On Wed, Sep 03, 2008 at 03:22:31PM -0700, Andrew Morton wrote:
>> > From: Nye Liu <nyet@...t.org>
>> >
>> > When unpacking the cpio into the initramfs, mtimes are not preserved by
>> > default. This patch adds an INITRAMFS_PRESERVE_MTIME option that allows mtimes
>> > stored in the cpio image to be used when constructing the initramfs. For
>> > embedded applications that run exclusively out of the initramfs, this is
>> > invaluable.
>>
>> Why is it "invlauable".  Please explain this value in full detail -
>> it's the whole reason for merging the patch!
>
> When building embedded application initramfs images, its nice to know
> when the files were actually created during the build process - that
> makes it easier to see what files were modified when so we can compare
> the files that are being used on the image with the files used during
> the build process. This might help (for example) to determine if the
> target system has all the updated files you expect to see w/o having to
> check MD5s etc.

Hm.

"Invaluable" != "nice to know".

What worries me is that this code is executed at boot time (when
populating the ramfs).
For embedded systems a fast boot time is often important.
I admit that the net effect of this on boot time is marginal (but some
might consider having mtime a marginal benefit), and 100 cents also
make a dollar, so my suggestion would be to either reject this patch
or make it optional (e.g. depending on some debug config flag).

Best regards, Frans.
--
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/