As discussed before, here is a simple patch to allow for early
initialization of security modules when compiled statically into the
kernel. The standard do_initcalls is too late for complete coverage of
all filesystems and threads for example. If this looks OK, I'd like to
push it on to Linus. Patch is against 2.5.69-bk. It is tested on i386,
and various arch maintainers are copied on relevant bits of patch.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
--- 1.30/arch/i386/vmlinux.lds.S Tue May 6 06:54:06 2003
+++ edited/arch/i386/vmlinux.lds.S Mon May 12 16:20:10 2003
@@ -81,6 +81,9 @@
__con_initcall_start = .;
.con_initcall.init : { *(.con_initcall.init) }
__con_initcall_end = .;
+ __security_initcall_start = .;
+ .security_initcall.init : { *(.security_initcall.init) }
+ __security_initcall_end = .;
. = ALIGN(4);
__alt_instructions = .;
.altinstructions : { *(.altinstructions) }
--- 1.99/init/main.c Wed May 7 21:17:55 2003
+++ edited/init/main.c Mon May 12 16:17:01 2003
@@ -435,8 +435,8 @@
pte_chain_init();
fork_init(num_physpages);
proc_caches_init();
- security_scaffolding_startup();
buffer_init();
+ security_scaffolding_startup();
vfs_caches_init(num_physpages);
radix_tree_init();
signals_init();
--- 1.25/include/linux/init.h Mon Mar 3 13:05:26 2003
+++ edited/include/linux/init.h Mon May 12 16:17:01 2003
@@ -64,6 +64,7 @@
typedef void (*exitcall_t)(void);
extern initcall_t __con_initcall_start, __con_initcall_end;
+extern initcall_t __security_initcall_start, __security_initcall_end;
#endif
#ifndef MODULE
@@ -96,6 +97,9 @@
#define console_initcall(fn) \
static initcall_t __initcall_##fn __attribute__ ((unused,__section__ (".con_initcall.init")))=fn
+#define security_initcall(fn) \
+ static initcall_t __initcall_##fn __attribute__ ((unused,__section__ (".security_initcall.init"))) = fn
+
struct obs_kernel_param {
const char *str;
int (*setup_func)(char *);
@@ -142,6 +146,8 @@
#define fs_initcall(fn) module_init(fn)
#define device_initcall(fn) module_init(fn)
#define late_initcall(fn) module_init(fn)
+
+#define security_initcall(fn) module_init(fn)
/* These macros create a dummy inline: gcc 2.9x does not count alias
as usage, hence the `unused function' warning when __init functions
--- 1.15/security/capability.c Mon Feb 17 12:08:10 2003
+++ edited/security/capability.c Mon May 12 16:14:00 2003
@@ -348,7 +348,7 @@
}
}
-module_init (capability_init);
+security_initcall (capability_init);
module_exit (capability_exit);
MODULE_DESCRIPTION("Standard Linux Capabilities Security Module");
--- 1.2/security/root_plug.c Wed Dec 18 15:09:26 2002
+++ edited/security/root_plug.c Mon May 12 16:25:10 2003
@@ -184,7 +184,7 @@
printk (KERN_INFO "Root Plug module removed\n");
}
-module_init (rootplug_init);
+security_initcall (rootplug_init);
module_exit (rootplug_exit);
MODULE_DESCRIPTION("Root Plug sample LSM module, written for Linux Journal article");
--- 1.7/security/security.c Wed Dec 18 15:10:17 2002
+++ edited/security/security.c Mon May 12 16:17:13 2003
@@ -38,12 +38,22 @@
return 0;
}
+static void __init do_security_initcalls(void)
+{
+ initcall_t *call;
+ call = &__security_initcall_start;
+ while (call < &__security_initcall_end) {
+ (*call)();
+ call++;
+ }
+}
+
/**
* security_scaffolding_startup - initialzes the security scaffolding framework
*
* This should be called early in the kernel initialization sequence.
*/
-int security_scaffolding_startup (void)
+int __init security_scaffolding_startup (void)
{
printk (KERN_INFO "Security Scaffold v" SECURITY_SCAFFOLD_VERSION
" initialized\n");
@@ -55,6 +65,7 @@
}
security_ops = &dummy_security_ops;
+ do_security_initcalls();
return 0;
}
* Chris Wright ([email protected]) wrote:
> As discussed before, here is a simple patch to allow for early
> initialization of security modules when compiled statically into the
> kernel. The standard do_initcalls is too late for complete coverage of
> all filesystems and threads for example. If this looks OK, I'd like to
> push it on to Linus. Patch is against 2.5.69-bk. It is tested on i386,
> and various arch maintainers are copied on relevant bits of patch.
This is just the arch specific linker bits for the early initialization
for security modules patch. Does this look sane for this arch?
--- 1.21/arch/alpha/vmlinux.lds.S Wed Apr 2 00:42:56 2003
+++ edited/arch/alpha/vmlinux.lds.S Mon May 12 16:16:54 2003
@@ -74,6 +74,13 @@
__con_initcall_end = .;
}
+ . = ALIGN(8);
+ .security_initcall.init : {
+ __security_initcall_start = .;
+ *(.security_initcall.init)
+ __security_initcall_end = .;
+ }
+
. = ALIGN(64);
__per_cpu_start = .;
.data.percpu : { *(.data.percpu) }
* Chris Wright ([email protected]) wrote:
> As discussed before, here is a simple patch to allow for early
> initialization of security modules when compiled statically into the
> kernel. The standard do_initcalls is too late for complete coverage of
> all filesystems and threads for example. If this looks OK, I'd like to
> push it on to Linus. Patch is against 2.5.69-bk. It is tested on i386,
> and various arch maintainers are copied on relevant bits of patch.
This is just the arch specific linker bits for the early initialization
for security modules patch. Does this look sane for this arch?
--- 1.12/arch/s390/vmlinux.lds.S Mon Apr 14 12:11:57 2003
+++ edited/arch/s390/vmlinux.lds.S Mon May 12 16:17:00 2003
@@ -94,6 +94,9 @@
__con_initcall_start = .;
.con_initcall.init : { *(.con_initcall.init) }
__con_initcall_end = .;
+ __security_initcall_start = .;
+ .security_initcall.init : { *(.security_initcall.init) }
+ __security_initcall_end = .;
. = ALIGN(256);
__initramfs_start = .;
.init.ramfs : { *(.init.initramfs) }
* Chris Wright ([email protected]) wrote:
> As discussed before, here is a simple patch to allow for early
> initialization of security modules when compiled statically into the
> kernel. The standard do_initcalls is too late for complete coverage of
> all filesystems and threads for example. If this looks OK, I'd like to
> push it on to Linus. Patch is against 2.5.69-bk. It is tested on i386,
> and various arch maintainers are copied on relevant bits of patch.
This is just the arch specific linker bits for the early initialization
for security modules patch. Does this look sane for this arch?
--- 1.14/arch/ppc64/vmlinux.lds.S Wed Apr 2 00:42:56 2003
+++ edited/arch/ppc64/vmlinux.lds.S Mon May 12 16:16:59 2003
@@ -104,6 +104,9 @@
__con_initcall_start = .;
.con_initcall.init : { *(.con_initcall.init) }
__con_initcall_end = .;
+ __security_initcall_start = .;
+ .security_initcall.init : { *(.security_initcall.init) }
+ __security_initcall_end = .;
. = ALIGN(4096);
__initramfs_start = .;
.init.ramfs : { *(.init.ramfs) }
* Chris Wright ([email protected]) wrote:
> As discussed before, here is a simple patch to allow for early
> initialization of security modules when compiled statically into the
> kernel. The standard do_initcalls is too late for complete coverage of
> all filesystems and threads for example. If this looks OK, I'd like to
> push it on to Linus. Patch is against 2.5.69-bk. It is tested on i386,
> and various arch maintainers are copied on relevant bits of patch.
This is just the arch specific linker bits for the early initialization
for security modules patch. Does this look sane for this arch?
--- 1.15/arch/arm/vmlinux-armo.lds.in Wed Apr 2 00:42:56 2003
+++ edited/arch/arm/vmlinux-armo.lds.in Mon May 12 16:16:54 2003
@@ -43,6 +43,9 @@
__con_initcall_start = .;
*(.con_initcall.init)
__con_initcall_end = .;
+ __security_initcall_start = .;
+ *(.security_initcall.init)
+ __security_initcall_end = .;
. = ALIGN(32768);
__init_end = .;
}
--- 1.24/arch/arm/vmlinux-armv.lds.in Sun Apr 27 08:35:24 2003
+++ edited/arch/arm/vmlinux-armv.lds.in Mon May 12 16:16:55 2003
@@ -53,6 +53,9 @@
__con_initcall_start = .;
*(.con_initcall.init)
__con_initcall_end = .;
+ __security_initcall_start = .;
+ *(.security_initcall.init)
+ __security_initcall_end = .;
. = ALIGN(32);
__initramfs_start = .;
usr/built-in.o(.init.ramfs)
* Chris Wright ([email protected]) wrote:
> As discussed before, here is a simple patch to allow for early
> initialization of security modules when compiled statically into the
> kernel. The standard do_initcalls is too late for complete coverage of
> all filesystems and threads for example. If this looks OK, I'd like to
> push it on to Linus. Patch is against 2.5.69-bk. It is tested on i386,
> and various arch maintainers are copied on relevant bits of patch.
This is just the arch specific linker bits for the early initialization
for security modules patch. Does this look sane for this arch?
--- 1.29/arch/ia64/vmlinux.lds.S Wed Apr 2 00:42:56 2003
+++ edited/arch/ia64/vmlinux.lds.S Mon May 12 16:16:55 2003
@@ -141,6 +141,10 @@
.con_initcall.init : AT(ADDR(.con_initcall.init) - PAGE_OFFSET)
{ *(.con_initcall.init) }
__con_initcall_end = .;
+ __security_initcall_start = .;
+ .security_initcall.init : AT(ADDR(.security_initcall.init) - PAGE_OFFSET)
+ { *(.security_initcall.init) }
+ __security_initcall_end = .;
. = ALIGN(PAGE_SIZE);
__init_end = .;
* Chris Wright ([email protected]) wrote:
> As discussed before, here is a simple patch to allow for early
> initialization of security modules when compiled statically into the
> kernel. The standard do_initcalls is too late for complete coverage of
> all filesystems and threads for example. If this looks OK, I'd like to
> push it on to Linus. Patch is against 2.5.69-bk. It is tested on i386,
> and various arch maintainers are copied on relevant bits of patch.
This is just the arch specific linker bits for the early initialization
for security modules patch. Does this look sane for this arch?
--- 1.7/arch/m68knommu/vmlinux.lds.S Wed Apr 2 00:42:56 2003
+++ edited/arch/m68knommu/vmlinux.lds.S Mon May 12 16:16:58 2003
@@ -305,6 +305,9 @@
__con_initcall_start = .;
*(.con_initcall.init)
__con_initcall_end = .;
+ __security_initcall_start = .;
+ *(.security_initcall.init)
+ __security_initcall_end = .;
. = ALIGN(4);
__initramfs_start = .;
*(.init.ramfs)
* Chris Wright ([email protected]) wrote:
> As discussed before, here is a simple patch to allow for early
> initialization of security modules when compiled statically into the
> kernel. The standard do_initcalls is too late for complete coverage of
> all filesystems and threads for example. If this looks OK, I'd like to
> push it on to Linus. Patch is against 2.5.69-bk. It is tested on i386,
> and various arch maintainers are copied on relevant bits of patch.
This is just the arch specific linker bits for the early initialization
for security modules patch. Does this look sane for this arch?
--- 1.16/arch/m68k/vmlinux-std.lds Wed Apr 2 00:42:56 2003
+++ edited/arch/m68k/vmlinux-std.lds Mon May 12 16:16:58 2003
@@ -67,6 +67,9 @@
__con_initcall_start = .;
.con_initcall.init : { *(.con_initcall.init) }
__con_initcall_end = .;
+ __security_initcall_start = .;
+ .security_initcall.init : { *(.security_initcall.init) }
+ __security_initcall_end = .;
. = ALIGN(8192);
__initramfs_start = .;
.init.ramfs : { *(.init.ramfs) }
--- 1.14/arch/m68k/vmlinux-sun3.lds Wed Apr 2 00:42:56 2003
+++ edited/arch/m68k/vmlinux-sun3.lds Mon May 12 16:16:59 2003
@@ -61,6 +61,9 @@
__con_initcall_start = .;
.con_initcall.init : { *(.con_initcall.init) }
__con_initcall_end = .;
+ __security_initcall_start = .;
+ .security_initcall.init : { *(.security_initcall.init) }
+ __security_initcall_end = .;
. = ALIGN(8192);
__initramfs_start = .;
.init.ramfs : { *(.init.ramfs) }
* Chris Wright ([email protected]) wrote:
> As discussed before, here is a simple patch to allow for early
> initialization of security modules when compiled statically into the
> kernel. The standard do_initcalls is too late for complete coverage of
> all filesystems and threads for example. If this looks OK, I'd like to
> push it on to Linus. Patch is against 2.5.69-bk. It is tested on i386,
> and various arch maintainers are copied on relevant bits of patch.
This is just the arch specific linker bits for the early initialization
for security modules patch. Does this look sane for these arches?
--- 1.7/arch/mips64/vmlinux.lds.S Fri Feb 14 15:10:00 2003
+++ edited/arch/mips64/vmlinux.lds.S Mon May 12 16:16:59 2003
@@ -53,6 +53,9 @@
__con_initcall_start = .;
.con_initcall.init : { *(.con_initcall.init) }
__con_initcall_end = .;
+ __security_initcall_start = .;
+ .security_initcall.init : { *(.security_initcall.init) }
+ __security_initcall_end = .;
. = ALIGN(4096); /* Align double page for init_task_union */
__init_end = .;
--- 1.8/arch/mips/vmlinux.lds.S Fri Feb 14 15:09:55 2003
+++ edited/arch/mips/vmlinux.lds.S Mon May 12 16:16:59 2003
@@ -54,6 +54,9 @@
__con_initcall_start = .;
.con_initcall.init : { *(.con_initcall.init) }
__con_initcall_end = .;
+ __security_initcall_start = .;
+ .security_initcall.init : { *(.security_initcall.init) }
+ __security_initcall_end = .;
. = ALIGN(4096); /* Align double page for init_task_union */
__init_end = .;
* Chris Wright ([email protected]) wrote:
> As discussed before, here is a simple patch to allow for early
> initialization of security modules when compiled statically into the
> kernel. The standard do_initcalls is too late for complete coverage of
> all filesystems and threads for example. If this looks OK, I'd like to
> push it on to Linus. Patch is against 2.5.69-bk. It is tested on i386,
> and various arch maintainers are copied on relevant bits of patch.
This is just the arch specific linker bits for the early initialization
for security modules patch. Does this look sane for this arch?
--- 1.10/arch/sh/vmlinux.lds.S Fri Feb 14 15:11:24 2003
+++ edited/arch/sh/vmlinux.lds.S Mon May 12 16:17:00 2003
@@ -71,6 +71,9 @@
__con_initcall_start = .;
.con_initcall.init : { *(.con_initcall.init) }
__con_initcall_end = .;
+ __security_initcall_start = .;
+ .security_initcall.init : { *(.security_initcall.init) }
+ __security_initcall_end = .;
__machvec_start = .;
.machvec.init : { *(.machvec.init) }
__machvec_end = .;
* Chris Wright ([email protected]) wrote:
> As discussed before, here is a simple patch to allow for early
> initialization of security modules when compiled statically into the
> kernel. The standard do_initcalls is too late for complete coverage of
> all filesystems and threads for example. If this looks OK, I'd like to
> push it on to Linus. Patch is against 2.5.69-bk. It is tested on i386,
> and various arch maintainers are copied on relevant bits of patch.
This is just the arch specific linker bits for the early initialization
for security modules patch. Does this look sane for this arch?
--- 1.1/arch/h8300/platform/h8300h/generic/rom.ld Thu Apr 17 12:30:45 2003
+++ edited/arch/h8300/platform/h8300h/generic/rom.ld Mon May 12 16:44:10 2003
@@ -83,6 +83,9 @@
___con_initcall_start = .;
*(.con_initcall.init)
___con_initcall_end = .;
+ ___security_initcall_start = .;
+ *(.security_initcall.init)
+ ___security_initcall_end = .;
. = ALIGN(4);
___initramfs_start = .;
*(.init.ramfs)
* Chris Wright ([email protected]) wrote:
> As discussed before, here is a simple patch to allow for early
> initialization of security modules when compiled statically into the
> kernel. The standard do_initcalls is too late for complete coverage of
> all filesystems and threads for example. If this looks OK, I'd like to
> push it on to Linus. Patch is against 2.5.69-bk. It is tested on i386,
> and various arch maintainers are copied on relevant bits of patch.
This is just the arch specific linker bits for the early initialization
for security modules patch. Does this look sane for these arches?
--- 1.18/arch/sparc64/vmlinux.lds.S Wed Apr 2 00:42:56 2003
+++ edited/arch/sparc64/vmlinux.lds.S Mon May 12 16:17:00 2003
@@ -68,6 +68,9 @@
__con_initcall_start = .;
.con_initcall.init : { *(.con_initcall.init) }
__con_initcall_end = .;
+ __security_initcall_start = .;
+ .security_initcall.init : { *(.security_initcall.init) }
+ __security_initcall_end = .;
. = ALIGN(8192);
__initramfs_start = .;
.init.ramfs : { *(.init.ramfs) }
--- 1.16/arch/sparc/vmlinux.lds.S Wed Apr 2 00:42:56 2003
+++ edited/arch/sparc/vmlinux.lds.S Mon May 12 16:17:00 2003
@@ -62,6 +62,9 @@
__con_initcall_start = .;
.con_initcall.init : { *(.con_initcall.init) }
__con_initcall_end = .;
+ __security_initcall_start = .;
+ .security_initcall.init : { *(.security_initcall.init) }
+ __security_initcall_end = .;
. = ALIGN(4096);
__initramfs_start = .;
.init.ramfs : { *(.init.ramfs) }
* Chris Wright ([email protected]) wrote:
> As discussed before, here is a simple patch to allow for early
> initialization of security modules when compiled statically into the
> kernel. The standard do_initcalls is too late for complete coverage of
> all filesystems and threads for example. If this looks OK, I'd like to
> push it on to Linus. Patch is against 2.5.69-bk. It is tested on i386,
> and various arch maintainers are copied on relevant bits of patch.
This is just the arch specific linker bits for the early initialization
for security modules patch. Does this look sane for this arch?
--- 1.16/arch/cris/vmlinux.lds.S Fri Feb 14 14:37:05 2003
+++ edited/arch/cris/vmlinux.lds.S Mon May 12 16:16:55 2003
@@ -74,7 +74,12 @@
__con_initcall_start = .;
*(.con_initcall.init)
__con_initcall_end = .;
-
+ }
+ .security_initcall.init : {
+ __security_initcall_start = .;
+ *(.security_initcall.init)
+ __security_initcall_end = .;
+
/* We fill to the next page, so we can discard all init
pages without needing to consider what payload might be
appended to the kernel image. */
* Chris Wright ([email protected]) wrote:
> As discussed before, here is a simple patch to allow for early
> initialization of security modules when compiled statically into the
> kernel. The standard do_initcalls is too late for complete coverage of
> all filesystems and threads for example. If this looks OK, I'd like to
> push it on to Linus. Patch is against 2.5.69-bk. It is tested on i386,
> and various arch maintainers are copied on relevant bits of patch.
This is just the arch specific linker bits for the early initialization
for security modules patch. Does this look sane for this arch?
--- 1.19/arch/ppc/vmlinux.lds.S Wed Apr 2 00:42:56 2003
+++ edited/arch/ppc/vmlinux.lds.S Mon May 12 16:17:00 2003
@@ -115,6 +115,10 @@
.con_initcall.init : { *(.con_initcall.init) }
__con_initcall_end = .;
+ __security_initcall_start = .;
+ .security_initcall.init : { *(.security_initcall.init) }
+ __security_initcall_end = .;
+
__start___ftr_fixup = .;
__ftr_fixup : { *(__ftr_fixup) }
__stop___ftr_fixup = .;
* Chris Wright ([email protected]) wrote:
> As discussed before, here is a simple patch to allow for early
> initialization of security modules when compiled statically into the
> kernel. The standard do_initcalls is too late for complete coverage of
> all filesystems and threads for example. If this looks OK, I'd like to
> push it on to Linus. Patch is against 2.5.69-bk. It is tested on i386,
> and various arch maintainers are copied on relevant bits of patch.
This is just the arch specific linker bits for the early initialization
for security modules patch. Does this look sane for this arch?
--- 1.15/arch/x86_64/vmlinux.lds.S Wed Apr 2 00:42:56 2003
+++ edited/arch/x86_64/vmlinux.lds.S Mon May 12 16:17:00 2003
@@ -105,6 +105,9 @@
__con_initcall_start = .;
.con_initcall.init : { *(.con_initcall.init) }
__con_initcall_end = .;
+ __security_initcall_start = .;
+ .security_initcall.init : { *(.security_initcall.init) }
+ __security_initcall_end = .;
. = ALIGN(4096);
__initramfs_start = .;
.init.ramfs : { *(.init.ramfs) }
* Chris Wright ([email protected]) wrote:
> As discussed before, here is a simple patch to allow for early
> initialization of security modules when compiled statically into the
> kernel. The standard do_initcalls is too late for complete coverage of
> all filesystems and threads for example. If this looks OK, I'd like to
> push it on to Linus. Patch is against 2.5.69-bk. It is tested on i386,
> and various arch maintainers are copied on relevant bits of patch.
This is just the arch specific linker bits for the early initialization
for security modules patch. Does this look sane for this arch?
--- 1.13/arch/parisc/vmlinux.lds.S Wed Apr 2 00:42:56 2003
+++ edited/arch/parisc/vmlinux.lds.S Mon May 12 16:16:59 2003
@@ -80,6 +80,9 @@
__con_initcall_start = .;
.con_initcall.init : { *(.con_initcall.init) }
__con_initcall_end = .;
+ __security_initcall_start = .;
+ .security_initcall.init : { *(.security_initcall.init) }
+ __security_initcall_end = .;
. = ALIGN(4096);
__initramfs_start = .;
.init.ramfs : { *(.init.ramfs) }
On Mon, May 12, 2003 at 08:15:18PM -0700, Chris Wright wrote:
> * Chris Wright ([email protected]) wrote:
> > As discussed before, here is a simple patch to allow for early
> > initialization of security modules when compiled statically into the
> > kernel. The standard do_initcalls is too late for complete coverage of
> > all filesystems and threads for example. If this looks OK, I'd like to
> > push it on to Linus. Patch is against 2.5.69-bk. It is tested on i386,
> > and various arch maintainers are copied on relevant bits of patch.
>
> This is just the arch specific linker bits for the early initialization
> for security modules patch. Does this look sane for this arch?
It would work for x86-64. But why can't you use core_initcall() or
postcore_initcall() ?
-Andi
On Mon, May 12, 2003 at 10:20:00PM -0700, Chris Wright wrote:
> * Andi Kleen ([email protected]) wrote:
> >
> > It would work for x86-64. But why can't you use core_initcall() or
> > postcore_initcall() ?
>
> This is too late. Those are just for order in do_initcalls() which is
> well after some kernel threads have been created and filesystems have been
> mounted, etc. This patch allows statically linked modules to catch
> the creation of such kernel objects and give them all consistent labels.
I would give them a generic name then in case someone else needs that too,
like "early_initcalls"
May be useful for some architecture initialization for example.
-Andi
* Andi Kleen ([email protected]) wrote:
>
> It would work for x86-64. But why can't you use core_initcall() or
> postcore_initcall() ?
This is too late. Those are just for order in do_initcalls() which is
well after some kernel threads have been created and filesystems have been
mounted, etc. This patch allows statically linked modules to catch
the creation of such kernel objects and give them all consistent labels.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
On Mon, May 12, 2003 at 10:20:00PM -0700, Chris Wright wrote:
> This is too late. Those are just for order in do_initcalls() which is
> well after some kernel threads have been created and filesystems have been
> mounted, etc. This patch allows statically linked modules to catch
> the creation of such kernel objects and give them all consistent labels.
Patch looks fine to me. Could you please make the initcalls mandatory for security
modules and remove the module exports for the regioster functions so peop can't
do the crappy check for each module whether it's already initialized stuff the early selinux
for LSM versions did?
Chris Wright writes:
> This is just the arch specific linker bits for the early initialization
> for security modules patch. Does this look sane for this arch?
Looks ok to me.
Paul.
>>>>> On Mon, 12 May 2003 20:09:53 -0700, Chris Wright <[email protected]> said:
Chris> This is just the arch specific linker bits for the early
Chris> initialization for security modules patch. Does this look
Chris> sane for this arch?
Looks OK to me.
--david
* Andi Kleen ([email protected]) wrote:
> On Mon, May 12, 2003 at 10:20:00PM -0700, Chris Wright wrote:
> >
> > This is too late. Those are just for order in do_initcalls() which is
> > well after some kernel threads have been created and filesystems have been
> > mounted, etc. This patch allows statically linked modules to catch
> > the creation of such kernel objects and give them all consistent labels.
>
> I would give them a generic name then in case someone else needs that too,
> like "early_initcalls"
I orginally thought it would be nice to make it generic, but it's
location is somewhat specific to the security hooks. It seems there is
easily tension between conflicting needs, should be earlier...should be
later, so I made it specific. Is there currently a need?
thanks,
chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
On Mon, May 12, 2003 at 11:16:55PM -0700, Chris Wright wrote:
> I orginally thought it would be nice to make it generic, but it's
> location is somewhat specific to the security hooks. It seems there is
> easily tension between conflicting needs, should be earlier...should be
> later, so I made it specific. Is there currently a need?
I guess for things like the i386 mtrr driver. But go ahead with the current
one if it's not obvious.
-Andi
On Mon, May 12, 2003 at 08:08:04PM -0700, Chris Wright wrote:
> This is just the arch specific linker bits for the early initialization
> for security modules patch. Does this look sane for this arch?
Looks sane.
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Mon, May 12, 2003 at 08:03:09PM -0700, Chris Wright wrote:
>
> --- 1.30/arch/i386/vmlinux.lds.S Tue May 6 06:54:06 2003
> +++ edited/arch/i386/vmlinux.lds.S Mon May 12 16:20:10 2003
> @@ -81,6 +81,9 @@
> __con_initcall_start = .;
> .con_initcall.init : { *(.con_initcall.init) }
> __con_initcall_end = .;
> + __security_initcall_start = .;
> + .security_initcall.init : { *(.security_initcall.init) }
> + __security_initcall_end = .;
I would much prefer to have only:
+ SECURITY_INIT
and moving the common stuff to include/asm-generic/vmlinux.lds.h.
Note that I moved definition of _start and _stop inside brackets.
Doing this makes sure the start address is always correct, independent
of the end address of last section.
Starting a new section will align to member with biggest alignment,
so we may see _start have a wrong value in some cases.
Using SECURITY_INIT will make changes to all architectures
even more trivial.
Sam
===== include/asm-generic/vmlinux.lds.h 1.7 vs edited =====
--- 1.7/include/asm-generic/vmlinux.lds.h Mon Feb 3 22:00:30 2003
+++ edited/include/asm-generic/vmlinux.lds.h Tue May 13 20:02:45 2003
@@ -45,3 +45,9 @@
*(__ksymtab_strings) \
}
+#define SECURITY_INIT \
+ .security_initcall.init : { \
+ __security_initcall_start = .; \
+ *(.security_initcall.init) \
+ __security_initcall_end = .; \
+ }
Hi Chris,
Chris Wright wrote:
> This is just the arch specific linker bits for the early initialization
> for security modules patch. Does this look sane for this arch?
Yep, looks good to me.
Regards
Greg
> --- 1.7/arch/m68knommu/vmlinux.lds.S Wed Apr 2 00:42:56 2003
> +++ edited/arch/m68knommu/vmlinux.lds.S Mon May 12 16:16:58 2003
> @@ -305,6 +305,9 @@
> __con_initcall_start = .;
> *(.con_initcall.init)
> __con_initcall_end = .;
> + __security_initcall_start = .;
> + *(.security_initcall.init)
> + __security_initcall_end = .;
> . = ALIGN(4);
> __initramfs_start = .;
> *(.init.ramfs)
>
--
------------------------------------------------------------------------
Greg Ungerer -- Chief Software Dude EMAIL: [email protected]
SnapGear Pty Ltd PHONE: +61 7 3435 2888
825 Stanley St, FAX: +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia WEB: http://www.SnapGear.com
* Christoph Hellwig ([email protected]) wrote:
> On Mon, May 12, 2003 at 10:20:00PM -0700, Chris Wright wrote:
> > This is too late. Those are just for order in do_initcalls() which is
> > well after some kernel threads have been created and filesystems have been
> > mounted, etc. This patch allows statically linked modules to catch
> > the creation of such kernel objects and give them all consistent labels.
>
> Patch looks fine to me. Could you please make the initcalls mandatory
> for security modules and remove the module exports for the regioster
> functions so peop can't do the crappy check for each module whether it's
> already initialized stuff the early selinux for LSM versions did?
I absolutely agree the preconditions aren't nice, but not all security modules
need them. I don't think disabling dynamic loading needs to be a
requirement for the initcall.
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net