Re: crypto api initialized late

[Reiner Sailer <sailer@us.ibm.com>]

Chris Wright <chrisw@osdl.org> wrote on 05/16/2005 04:03:17 PM:

> * Reiner Sailer (sailer@us.ibm.com) wrote:
> >
> > I am writing a Linux Security Module that needs SHA1 support very  early in
> > the kernel startup (before any fs are mounted,modules are loaded,  or
> > files are mapped; including initrd). Therefore, I use the __initcall
> > to initialize the security module. SHA1 can currently be used only
> > through the crypto-api (static definitions and hidden context structure).
> >
> > This crypto-API, however, initializes AFTER the security module
> > code in the __initicall block. Currently, I use the following patch into
> > the main Linux Makefile to start up the crypto-API earlier:
> >
> > diff -uprN linux-2.6.12-rc3_orig/Makefile
> > linux-2.6.12-rc3-ima-newpatch/Makefile
> > --- linux-2.6.12-rc3_orig/Makefile   2005-04-20 20:03:12.000000000 -0400
> > +++ linux-2.6.12-rc3-ima-newpatch/Makefile   2005-05-11
> > 15:18:32.000000000 -0400
> > @@ -560,7 +560,7 @@ export MODLIB
> >
> >
> >  ifeq ($(KBUILD_EXTMOD),)
> > -core-y      += kernel/ mm/ fs/ ipc/ security/ crypto/
> > +core-y      += kernel/ mm/ fs/ ipc/ crypto/ security/
>
> I'm surprised this helps at all.  Does this mean you are not using
> security_initcall() in your module?
>
> thanks,
> -chris

I use simply __initcall, which is the same level as the
module_initcall used in the crypto functions (sha1.c). Looking into
init.h, security_initcall should resolve to __initcall as well.

Changing the compile sequence orders, the crypto init and sha1
registration happens just ahead of my security module because
(so I assume) the order of the compilation determines the order
of the init calls inside the same initcall block.

Going later and using late_initcall, I seemed to sometimes loose
the mapping of the "nash" executed from the initrd.

Reiner