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:	Fri, 21 Sep 2012 14:51:12 +0200
From:	Thomas Renninger <trenn@...e.de>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	linux-kernel@...r.kernel.org, lenb@...nel.org,
	robert.moore@...el.com, Fenghua Yu <fenghua.yu@...el.com>,
	initramfs@...r.kernel.org, bigeasy@...utronix.de, vojcek@...n.pl,
	eric.piel@...mplin-utc.net, linux-acpi@...r.kernel.org,
	yinghai@...nel.org, "H. Peter Anvin" <hpa@...ux.intel.com>
Subject: Re: [PATCH 1/2] lib: Add early cpio decoder

On Tuesday, September 04, 2012 07:00:09 PM H. Peter Anvin wrote:
> On 08/30/2012 02:29 AM, Thomas Renninger wrote:
> > From: "H. Peter Anvin" <hpa@...ux.intel.com>
> >
> > Add a simple cpio decoder without library dependencies for the purpose
> > of extracting components from the initramfs blob for early kernel
> > uses.  Intended consumers so far are microcode and ACPI override.
> >
> > Signed-off-by: H. Peter Anvin <hpa@...ux.intel.com>
> > CC: Thomas Renninger <trenn@...e.de>
> > Link: http://lkml.kernel.org/r/201203261651.29640.trenn@suse.de
> > Signed-off-by: Thomas Renninger <trenn@...e.de>
> 
> I was trying to figure out if there is a way to do what you want 
> (support for multiple files) without the problems of the callback 
> interface.  I think it is actually fairly straightforward; we need a 
> prefix iterator (so you can give it a string like "kernel/acpi/" rather 
> than a full filename) and it needs to be able to accept a "last" pointer 
> so it can resume scanning at the point it last left off.  That should be 
> a pretty trivial change.
Yep, this is a good idea.
 
> The other thing we presumably want to do -- and this is generic -- is to 
> be able to handle multiple sources for the initramfs; at the very least 
> there is built in vs provided from the boot loader.  I had originally 
> intended to just handle that by calling the earlycpio function once per 
> block, but the "last left off" bit makes that a little harder.  Need to 
> think about that a little bit.
I guess I understand the first part, not sure about the "last left off" 
bit.
"Multiple sources" means bootloader already points to multiple sources,
right?
This is somewhat out of scope as this would need both, bootloader and
kernel adjustings.
This is about "built in" which means multiple cpios concatenated together
and passed via bootloader as one "file" (initrd).
At least I understand it that way.
The only disadvantage I run into is that once the cpios are concatenated,
I couldn't figure out an easy way how to slice them into separate
cpio/zip archives again.

> I am guessing that this may not need to be something we need from the 
> very beginning, or am I wrong?

I have re-worked the patches:
  - added an offset argument to be able to iterate over files inside
    a directory as suggested
  - removed the strlen and memcmp function duplication in earlycpio.c
    This is not needed for this patchset and would be confusing.
    This can easily be added in the context of the patches which need it

I'll re-submit.

Thanks,

   Thomas
--
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