On Wed, 30 Aug 2006, Sven Luther wrote:
Do you really need to bring up ipw2200 so early ? It is some kind of
wireless
device, right ?
if modules are not in use the device is initialized when the kernel starts
up. this is before any userspace starts.
Well. but you could do the initialization at open time too, like the other
case that was mentioned here, no ?
no, at least not in the current kernel. as was mentioned earlier in this thread
the ipw2200 needs the firmware at initialization, but some others don't need it
until open. I don't know if it's even possible to re-write the driver to do
this.
As for initramfs, you can just cat it behind the kernel, and it should work
just fine, or at least this is how it was supposed to work.
yes, if I want to set one up.
other then this new requirement to have the ipw2200 driver as a module I
have no reason to use one. normal userspace is good enough for me.
Well, ok.
The real question seems to be if we want to keep the firmware inside the
driver or not.
If we want to remove it, then we put, not the module, but the firmware itself
with some basic userspace to load it on demand in the initramfs, and this is
reason enough to create an initramfs. The fact that the builtin device is
initialized before the initramfs is loaded seems like a bug to me, since the
idea of the initramfs (well, one of them at least), was to initialize it early
enough for this kind of things.
this isn't my understanding.
my understanding is that the kernel fully initializes all built-in drivers, then
loads userspace and starts running it.
that userspace can be on a device that it knows how to read, or it can be
userspace on initramfs so that you can load additional modules to give you
access to the hardware that you want to run on.
this is needed if your root drive is a SCSI drive and you have it's driver
compiled as a module for example.
this is needed if your root drive uses dm and you need to initialize the array
(one advantage of md, from the user standpoint, is that it doesn't require this
additional layer before use)
however this is not soon enough to supply the firmware for devices like this.
If on the other side, it is more important to not have an initramfs (because
of security issues, or bootloader constraints or what not), then sure, there
is not much choice than putting the firmware in the driver or in the kernel
directly.
But again, the initramfs is just a memory space available at the end of the
kernel, and there is no hardware-related constraint to access it which are in
any way different from having the firmware linked in together with the kernel,
so it is only a matter of organisation of code, as well as taking a decision
on the above, and to act accordyingly.
if the firmware needed for any drivers compiled in was appended to the kernel
the same way that initramfs is, without requireing the other things needed to
make initrmfs useable I think that would be reasonable (bundling them togeather
as opposed to embedding the firmware in the kernel). it may even be possible to
have the firmware as files in a initramfs that contains nothing else, and the
kernel knows how to read the data directly (without the hotplug firmware request
userspace stuff)
Does using an initramfs really have some negative side, security related ?
Would some kind of signed or encrypted initramfs be preferable there ?
adding an initramfs to a system that doesn't need it otherwise adds
complications to the configure and boot process.
requireing modules when they weren't required before adds complication, and
if/when the patch that's floating around to eliminate access to /dev/kmem is
ever accepted, there are security advantages of running a kernel that doesn't
have any support for run-time modifications (i.e. module loading).
I realize that many people want to make initramfs mandatory (with things like
partition detection moved to userspace), but unless there is a standard
initramfs that is shipped and maintained with the kernel to implement things
like this (see the klibc discussion a few weeks ago) you are adding
complications without much of a benifit to the user.
David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
