[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why *are* the kernels monolithic?

> Lesse, box with 16MB of RAM and an 8MB Flash it's booting from.
> I figure I just saved 25% of my flash and ~15% of my RAM.  Untrivial.
> Esp without swap.
> But I ask a philosophy question, unless everyones got the blow torches
> warmed up and have moved from just propane to adding O2.
> The OS is capable of loadable kernel modules.   And yet, I'd be
> pressed to name any.
> While I understand that many of the substructure devices would
> want to be in the kernel (mii, etc).  But *do* we need live drivers
> for 15+ scsi controllers in RAM?
> While it's almost moot on a box with 4 or 8GB of RAM, BSD finds itself
> often called on in the embedded market.  Fitting a computer into small
> spaces for low cost (where a second 4MB of RAM *is* a signif cost) is
> a great place for BSD.  Now these folks aren't using GENERIC anyway,
> but not having to work for it is a plus.
> Now FreeBSD modularizes EVERY driver and it's a black art to get the
> kernel with the right modules ONLY and insane to skip building them
> in any fashion.
> Is there a place in between?

Well according to the Bible (Design and Implementation of 4.4 BSD) the
main reason for not doing it is security, which is an argument that
should have some fans in this mailing list.

Page 502:

"...allowing code to be loaded dynamically into the kernel raises many
security problems. Code running outside the kernel is limited in the
damage that it can do because it does not run in privileged mode, so
cannot directly access the hardware. The kernel runs with full
privilege and access to the hardware. Thus, if it loads a module that
contains a virus, it can inflict wide-ranging damage within the system.
Kernels can be loaded across the network from a central server; if the
kernel allowed dynamic loading of modules, they too could come across
the network, so there are numerous added points for malfeasance. An
important goal of adding dynamic-loading functionality to 4.4BSD is to
develop a scheme to verify the source of and lack of corruption in any
code before that code is permitted to be loaded and used."

I'm not a big fan of LKMs on FreeBSD, and on Linux their main purpose in
life seems to be to allow vendors to supply binary-only modules.

It would be pretty easy (I would think) to have a kernel build process
sign all its modules and compile the key into the kernel, so it would be
able to verify that any module that is to be loaded is genuine. However,
that wouldn't let you load modules that are built after the fact or that
come from third party sources (unless maybe they are present at
compile-time). As far as I know no project has addressed the security
issues addressed in the 4.4 book.