Mailinglist Archive: opensuse-security (757 mails)

< Previous Next >
Re: [suse-security] Re: [SLE] Kernel RPMs in the ftp sites.
On Wednesday 23 January 2002 17:05, Peter Nixon wrote:
> On Mon, 21 Jan 2002 10:35:12 -0500
>
> Nadeem Hasan <nhasan@xxxxxxxxx> wrote:
> > Anders Johansson wrote:
> > > On Saturday 19 January 2002 18.19, Nadeem Hasan wrote:
>
> If you keep up with the Linux Kernel Mailinglist, you will notice that the
> plan is to make initrd mandatory in 2.5x >

Err, that's only partially true, from the discussions I've seen. Work
planned and started in 2.5, then all kernel inititial root filesystems will
be loaded by a hidden compressed 'initial ram disk', which will be loaded
along with the kernel, as it'll be tacked to the end of it. Alan Cox
actually wrote he'd like _all_ drivers being modules only and not even be
compilable in, the kernel build code would have to decide what's necessary in
the hidden initrd. See recent lwn.net kernel list report if you're
interested in the details.

Linus objected strongly, last summer to making the current initrd framework
compulsory on ease of use grounds, when the idea of _always_ using the boot
loader for initial root was discussed to avoid special case '/' code. Hence
the paper, on a new format (based on a cpio.gz archive) which recently
received publicity. It is to be tacked onto end of the kernel, by the kbuild
system (L. decreed a simple cat initial-root-file >> bzImage should be
possible), and should _not_ require a seperate 'distro' command to create it.

The point is that modules and initrd's ought to become easier, and things are
moving to more dynamic distro style kernels, rather than custom compiles, for
maintenance reasons. Those objections on security grounds that modules are
less secure, are weakened, as there's code around to patch monolithic kernels
with analagous to adding or altering kernel modules. I also suspect that
once the new initial root filesystem code is in the kernel, someone will be
able to optomise the memory layout of those modules by having them next to
the kernel, and avoid the current TLB overhead, which is the basis for some
objections to using modules. Could lead to some interesting space/efficiency
tradeoffs on kernel sizes.

It'll be interesting to see how it works out in practice once they come to
trying deploying it for real.

Rob

< Previous Next >