linux-kernel - Re: [PATCH 1/2] init: Introduce early initrd files through uncompressed cpio passing

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] [day] [month] [year] [list]

Message-Id: <201207241116.02354.trenn@suse.de>
Date:	Tue, 24 Jul 2012 11:16:01 +0200
From:	Thomas Renninger <trenn@...e.de>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	linux-kernel@...r.kernel.org, lenb@...nel.org,
	linux-acpi@...r.kernel.org, initramfs@...r.kernel.org,
	bigeasy@...utronix.de, Fenghua Yu <fenghua.yu@...el.com>
Subject: Re: [PATCH 1/2] init: Introduce early initrd files through uncompressed cpio passing

On Monday, July 23, 2012 05:09:16 PM H. Peter Anvin wrote:
> On 07/23/2012 07:40 AM, Thomas Renninger wrote:
> > This is another problem and I expect I call:
> > early_initrd_find_cpio_data()
> > early enough for Fenghua's needs.
> > If not, how early exactly is this needed?
> 
> We're calling that from arch-specific code before even turning paging 
> on.
Why?
If you would shed more light into what you (or Fenghua)
try to achieve that would help.
What kind of platform/CPU is this?
What happens if firmware is not provided (that early,..)?

...

> Now, you definitely do have a valid point about being able to iterate 
> over multiple files with a common prefix.  We could do that with either 
> a callback (where the callback is passed in as an argument), but I think 
> it might be nicer to do that as an iterator interface... let me ketch on 
> this.
Please do.

I finally would like to have the ACPI table via initird overriding.
ACPICA people added the physical table override stuff only for this.
With the cpio encapsulation (using initrd_start) this is a nice,
arch independent approach.
I can imagine the one or other arch picks this up. One example
could be flattened device tree passing via intird for ARM.

Maybe it could be kept arch independent with a "weird archs need things
even earlier" specific interface/hook if really needed.
Then others could pass initrd_start as now done, but X86 or
specific archs do some nasty HW specific stuff.

...

Hm, I could imagine this early fiddling will take some time.
If the cpio encapsulation as shown is acceptable, these patches
could get pushed already and the "very very early" additions can
be pushed on top in one of the next kernel rounds.

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/