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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]