linux-kernel - Re: acpi dsts loading and populate

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:	Tue, 12 Feb 2008 06:37:30 +0100
From:	Christoph Hellwig <hch@....de>
To:	Eric Piel <eric.piel@...mplin-utc.net>
Cc:	Christoph Hellwig <hch@....de>, dsdt@...gusch.at,
	len.brown@...el.com, linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...l.org>, trenn@...e.de
Subject: Re: acpi dsts loading and populate_rootfs

[skipping the populate_rootfs discussion as it seems you have a better
 handle on that than me]

On Sun, Feb 10, 2008 at 12:58:09PM +0100, Eric Piel wrote:
> >And while we're at it the file reading thing in there is utter crap
> >aswell.  You really should be using the firmware loader which works
> >perfectly fine if you initramfs is set up for it.  So please folks,
> >back to the drawing board, do it properly and send it out to lkml
> >for review please.
> Christoph, if you have seen this part of the code, you have probably 
> also read the big fat warning explaining why this cannot be done by 
> firmware loader (ie: userspace cannot be run at this early time, 
> corresponding to acpi_early_init()). However, you probably know the 
> kernel ten times better than me. Could you explain what I misunderstood 
> when writing this warning, and give me some hints about how to use the 
> firmware loader in this case?

Sorry, I misparsed the comment.  I took it for the usual I'm too lazy
to put something that could load firmware into initramfs excuse.

But thinking about it is there a reason acpi initialization needs to
happen so early that we can't even have userspace in initramfs running?

But if we can't use real userspace this could should at least be written
like the pseudo-userspace in init/do_mounts*.c, using the sys_ syscall
implementations.

As an additional comment the stat + open approach is racy and not a good
idea.  Please just open the file using sys_open, it will tell you
if the file doesn't exist and then use fstat on it to find the
length.  It would also be useful if this kind of code is not hidden
inside acpi but rather done somewhere close to the early init code
because that's where people would expect this kind of nastiness._
syscall
implementations.

As an additional comment the stat + open approach is racy and not a good
idea.  Please just open the file using sys_open, it will tell you
if the file doesn't exist and then use fstat on it to find the
length.  It would also be useful if this kind of code is not hidden
inside acpi but rather done somewhere close to the early init code
because that's where people would expect this kind of nastiness.
--
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/