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
* Reiner Sailer ([email protected]) 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
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.
Chris Wright <[email protected]> wrote on 05/16/2005 04:03:17 PM:
> * Reiner Sailer ([email protected]) 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
* Reiner Sailer ([email protected]) wrote:
> Chris Wright <[email protected]> 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