crypto api initialized late

crypto api initialized late

[Reiner Sailer]

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/

  vmlinux-dirs	:= $(patsubst %/,%,$(filter %/, $(init-y) $(init-m) \
  		     $(core-y) $(core-m) $(drivers-y) $(drivers-m) \


Generally, I can think of the following solutions:
a) initialize crypto api in a initblock earlier than __initcall
b) make crypto functions global in the kernel and make crypto-api
    usage optional (goes against the idea of the api)
c) re-implement SHA1 for my LSM (won't be accepted)
d) the above patch (acceptable?)

Is there a preferred/accepted way to handle this startup-sequence problem?

Reiner

Re: crypto api initialized late

[Chris Wright]

* 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

Re: crypto api initialized late

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1009 bytes --]

On Mon, 16 May 2005 15:15:22 EDT, Reiner Sailer said:
> 
> 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:

I hit the same problem trying to add sysctl's from inside the LSM.  What I
ended up doing was letting the security_initcall() set up the *other* stuff I
needed, and then had a regular initcall() that ended up called after sysctl was
initialized, but before we went to userspace.  I'm pretty sure that all the
initcall chails get run before we mount the initrd and all that.


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: crypto api initialized late

[Reiner Sailer]

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

Re: crypto api initialized late

[Chris Wright]

* Reiner Sailer (sailer@us.ibm.com) wrote:
> Chris Wright <chrisw@osdl.org> wrote on 05/16/2005 04:03:17 PM:
> > I'm surprised this helps at all.  Does this mean you are not using
> > security_initcall() in your module?
> 
> 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.

If you are compiling as a module (assuming that's not the case here),
then it's a normal module_init.  Otherwise it's put in it's own text
segment, and called during security_init(),  which is earlier than
do_inticalls() to ensure all objects get labeled.

> 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.

Yes, it does.

thanks,
-chris