[OpenAFS] Monolithic kernel (linux > 2.6.8) without loadable modules support

Jeffrey Hutzelman jhutz@cmu.edu
Wed, 30 Mar 2005 17:19:46 -0500


On Monday, March 28, 2005 11:26:30 PM +0000 "P.L.Freemak" 
<xcondor@freemail.it> wrote:

> where I work we are evaluating a large deployment of clients and linux
> servers interconnected via openAFS. We'd like to start with a test on two
> servers replicating some folder with openAFS. My problem is that an
> enterprise wide security policy enforce me to  deploy every server
> without loadable modules support. I would like to ask if is it possible
> in some way to have a linux kernel (version > 2.6.8) compiled without
> loadable modules support fully supporting openAFS read and write. I've
> seen that the kernel built-in openAFS support is read only.

Well, for starters, it's worth noting that "OpenAFS" is the name of a 
particular piece of software, and while the "afs" in the mainstream Linux 
kernels speaks some of the same protocols, it is not OpenAFS.  In 
particular, it shares virtually no code with OpenAFS, and its integration 
model is somewhat different.

At the moment, there is no support for compiling OpenAFS into the kernel; 
it is intended to be loaded as a module.  In fact, I don't believe the 
kernel build system supports compiling in "external" modules that are 
maintained outside the kernel tree.

That said, I'm reasonable certain that, with a sufficient understanding of 
the kbuild architecture, you could hack something together that would allow 
you to compile OpenAFS into the kernel.  A good place to start would be the 
kbuild documentation in Documentation/kbuild (in the Linux kernel source). 
I would not be surprised if a patch supporting this in a clean way were 
accepted into OpenAFS.  I'm not sure exactly what "a clean way" would be, 
but I'd expect it to involve a make target that produced a file or 
directory tree to be added to the kernel source before building a kernel.


The other thing you could look into, if you have some lattitude to 
interpret your security policy, would be to investigate the signed-module 
patches.  This approach would allow you to build a kernel which loads only 
modules cryptographically signed by an authorized key.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA