linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] Early init for security modules
@ 2003-05-13  3:03 Chris Wright
  2003-05-13  3:07 ` Chris Wright
                   ` (15 more replies)
  0 siblings, 16 replies; 32+ messages in thread
From: Chris Wright @ 2003-05-13  3:03 UTC (permalink / raw)
  To: linux-kernel; +Cc: hch, gregkh, linux-security-module

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;
 }

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH] Early init for security modules
  2003-05-13  3:03 [PATCH] Early init for security modules Chris Wright
@ 2003-05-13  3:07 ` Chris Wright
  2003-05-13  3:08 ` Chris Wright
                   ` (14 subsequent siblings)
  15 siblings, 0 replies; 32+ messages in thread
From: Chris Wright @ 2003-05-13  3:07 UTC (permalink / raw)
  To: linux-kernel, hch, gregkh, linux-security-module; +Cc: rth

* Chris Wright (chris@wirex.com) 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) }

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH] Early init for security modules
  2003-05-13  3:03 [PATCH] Early init for security modules Chris Wright
  2003-05-13  3:07 ` Chris Wright
@ 2003-05-13  3:08 ` Chris Wright
  2003-05-13  9:03   ` Russell King
  2003-05-13  3:08 ` [PATCH] Early init for security modules Chris Wright
                   ` (13 subsequent siblings)
  15 siblings, 1 reply; 32+ messages in thread
From: Chris Wright @ 2003-05-13  3:08 UTC (permalink / raw)
  To: linux-kernel, hch, gregkh, linux-security-module; +Cc: rmk

* Chris Wright (chris@wirex.com) 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)

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH] Early init for security modules
  2003-05-13  3:03 [PATCH] Early init for security modules Chris Wright
  2003-05-13  3:07 ` Chris Wright
  2003-05-13  3:08 ` Chris Wright
@ 2003-05-13  3:08 ` Chris Wright
  2003-05-13  3:09 ` Chris Wright
                   ` (12 subsequent siblings)
  15 siblings, 0 replies; 32+ messages in thread
From: Chris Wright @ 2003-05-13  3:08 UTC (permalink / raw)
  To: linux-kernel, hch, gregkh, linux-security-module; +Cc: bjornw

* Chris Wright (chris@wirex.com) 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.  */

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH] Early init for security modules
  2003-05-13  3:03 [PATCH] Early init for security modules Chris Wright
                   ` (2 preceding siblings ...)
  2003-05-13  3:08 ` [PATCH] Early init for security modules Chris Wright
@ 2003-05-13  3:09 ` Chris Wright
  2003-05-13  3:09 ` Chris Wright
                   ` (11 subsequent siblings)
  15 siblings, 0 replies; 32+ messages in thread
From: Chris Wright @ 2003-05-13  3:09 UTC (permalink / raw)
  To: linux-kernel, hch, gregkh, linux-security-module; +Cc: alan

* Chris Wright (chris@wirex.com) 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)

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH] Early init for security modules
  2003-05-13  3:03 [PATCH] Early init for security modules Chris Wright
                   ` (3 preceding siblings ...)
  2003-05-13  3:09 ` Chris Wright
@ 2003-05-13  3:09 ` Chris Wright
  2003-05-13  5:56   ` David Mosberger
  2003-05-13  3:10 ` Chris Wright
                   ` (10 subsequent siblings)
  15 siblings, 1 reply; 32+ messages in thread
From: Chris Wright @ 2003-05-13  3:09 UTC (permalink / raw)
  To: linux-kernel, hch, gregkh, linux-security-module; +Cc: davidm

* Chris Wright (chris@wirex.com) 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 = .;
 

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH] Early init for security modules
  2003-05-13  3:03 [PATCH] Early init for security modules Chris Wright
                   ` (4 preceding siblings ...)
  2003-05-13  3:09 ` Chris Wright
@ 2003-05-13  3:10 ` Chris Wright
  2003-05-13  3:10 ` Chris Wright
                   ` (9 subsequent siblings)
  15 siblings, 0 replies; 32+ messages in thread
From: Chris Wright @ 2003-05-13  3:10 UTC (permalink / raw)
  To: linux-kernel, hch, gregkh, linux-security-module; +Cc: geert

* Chris Wright (chris@wirex.com) 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) }

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH] Early init for security modules
  2003-05-13  3:03 [PATCH] Early init for security modules Chris Wright
                   ` (5 preceding siblings ...)
  2003-05-13  3:10 ` Chris Wright
@ 2003-05-13  3:10 ` Chris Wright
  2003-05-14  0:10   ` Greg Ungerer
  2003-05-13  3:11 ` Chris Wright
                   ` (8 subsequent siblings)
  15 siblings, 1 reply; 32+ messages in thread
From: Chris Wright @ 2003-05-13  3:10 UTC (permalink / raw)
  To: linux-kernel, hch, gregkh, linux-security-module; +Cc: gerg

* Chris Wright (chris@wirex.com) 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)

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH] Early init for security modules
  2003-05-13  3:03 [PATCH] Early init for security modules Chris Wright
                   ` (6 preceding siblings ...)
  2003-05-13  3:10 ` Chris Wright
@ 2003-05-13  3:11 ` Chris Wright
  2003-05-13  3:12 ` Chris Wright
                   ` (7 subsequent siblings)
  15 siblings, 0 replies; 32+ messages in thread
From: Chris Wright @ 2003-05-13  3:11 UTC (permalink / raw)
  To: linux-kernel, hch, gregkh, linux-security-module; +Cc: ralf

* Chris Wright (chris@wirex.com) 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 = .;
 

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH] Early init for security modules
  2003-05-13  3:03 [PATCH] Early init for security modules Chris Wright
                   ` (7 preceding siblings ...)
  2003-05-13  3:11 ` Chris Wright
@ 2003-05-13  3:12 ` Chris Wright
  2003-05-13  3:13 ` Chris Wright
                   ` (6 subsequent siblings)
  15 siblings, 0 replies; 32+ messages in thread
From: Chris Wright @ 2003-05-13  3:12 UTC (permalink / raw)
  To: linux-kernel, hch, gregkh, linux-security-module; +Cc: matthew

* Chris Wright (chris@wirex.com) 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) }

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH] Early init for security modules
  2003-05-13  3:03 [PATCH] Early init for security modules Chris Wright
                   ` (8 preceding siblings ...)
  2003-05-13  3:12 ` Chris Wright
@ 2003-05-13  3:13 ` Chris Wright
  2003-05-13  3:13 ` Chris Wright
                   ` (5 subsequent siblings)
  15 siblings, 0 replies; 32+ messages in thread
From: Chris Wright @ 2003-05-13  3:13 UTC (permalink / raw)
  To: linux-kernel, hch, gregkh, linux-security-module; +Cc: anton

* Chris Wright (chris@wirex.com) 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) }

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH] Early init for security modules
  2003-05-13  3:03 [PATCH] Early init for security modules Chris Wright
                   ` (9 preceding siblings ...)
  2003-05-13  3:13 ` Chris Wright
@ 2003-05-13  3:13 ` Chris Wright
  2003-05-13  4:45   ` Paul Mackerras
  2003-05-13  3:13 ` Chris Wright
                   ` (4 subsequent siblings)
  15 siblings, 1 reply; 32+ messages in thread
From: Chris Wright @ 2003-05-13  3:13 UTC (permalink / raw)
  To: linux-kernel, hch, gregkh, linux-security-module; +Cc: paulus

* Chris Wright (chris@wirex.com) 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 = .;

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH] Early init for security modules
  2003-05-13  3:03 [PATCH] Early init for security modules Chris Wright
                   ` (10 preceding siblings ...)
  2003-05-13  3:13 ` Chris Wright
@ 2003-05-13  3:13 ` Chris Wright
  2003-05-13  3:14 ` Chris Wright
                   ` (3 subsequent siblings)
  15 siblings, 0 replies; 32+ messages in thread
From: Chris Wright @ 2003-05-13  3:13 UTC (permalink / raw)
  To: linux-kernel, hch, gregkh, linux-security-module; +Cc: schwidefsky

* Chris Wright (chris@wirex.com) 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) }

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH] Early init for security modules
  2003-05-13  3:03 [PATCH] Early init for security modules Chris Wright
                   ` (11 preceding siblings ...)
  2003-05-13  3:13 ` Chris Wright
@ 2003-05-13  3:14 ` Chris Wright
  2003-05-13  3:14 ` Chris Wright
                   ` (2 subsequent siblings)
  15 siblings, 0 replies; 32+ messages in thread
From: Chris Wright @ 2003-05-13  3:14 UTC (permalink / raw)
  To: linux-kernel, hch, gregkh, linux-security-module; +Cc: gniibe, kkojima

* Chris Wright (chris@wirex.com) 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 = .;

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH] Early init for security modules
  2003-05-13  3:03 [PATCH] Early init for security modules Chris Wright
                   ` (12 preceding siblings ...)
  2003-05-13  3:14 ` Chris Wright
@ 2003-05-13  3:14 ` Chris Wright
  2003-05-13  3:15 ` Chris Wright
  2003-05-13 18:07 ` Sam Ravnborg
  15 siblings, 0 replies; 32+ messages in thread
From: Chris Wright @ 2003-05-13  3:14 UTC (permalink / raw)
  To: linux-kernel, hch, gregkh, linux-security-module; +Cc: davem

* Chris Wright (chris@wirex.com) 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) }

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH] Early init for security modules
  2003-05-13  3:03 [PATCH] Early init for security modules Chris Wright
                   ` (13 preceding siblings ...)
  2003-05-13  3:14 ` Chris Wright
@ 2003-05-13  3:15 ` Chris Wright
  2003-05-13  5:03   ` Andi Kleen
  2003-05-13 18:07 ` Sam Ravnborg
  15 siblings, 1 reply; 32+ messages in thread
From: Chris Wright @ 2003-05-13  3:15 UTC (permalink / raw)
  To: linux-kernel, hch, gregkh, linux-security-module; +Cc: ak

* Chris Wright (chris@wirex.com) 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) }

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH] Early init for security modules
  2003-05-13  3:13 ` Chris Wright
@ 2003-05-13  4:45   ` Paul Mackerras
  0 siblings, 0 replies; 32+ messages in thread
From: Paul Mackerras @ 2003-05-13  4:45 UTC (permalink / raw)
  To: Chris Wright; +Cc: linux-kernel, hch, gregkh, linux-security-module

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.

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH] Early init for security modules
  2003-05-13  3:15 ` Chris Wright
@ 2003-05-13  5:03   ` Andi Kleen
  2003-05-13  5:20     ` Chris Wright
  0 siblings, 1 reply; 32+ messages in thread
From: Andi Kleen @ 2003-05-13  5:03 UTC (permalink / raw)
  To: linux-kernel, hch, gregkh, linux-security-module, ak

On Mon, May 12, 2003 at 08:15:18PM -0700, Chris Wright wrote:
> * Chris Wright (chris@wirex.com) 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

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH] Early init for security modules
  2003-05-13  5:03   ` Andi Kleen
@ 2003-05-13  5:20     ` Chris Wright
  2003-05-13  5:27       ` Christoph Hellwig
  2003-05-13  5:28       ` Andi Kleen
  0 siblings, 2 replies; 32+ messages in thread
From: Chris Wright @ 2003-05-13  5:20 UTC (permalink / raw)
  To: Andi Kleen; +Cc: linux-kernel, hch, greg, linux-security-module

* Andi Kleen (ak@suse.de) 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

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH] Early init for security modules
  2003-05-13  5:20     ` Chris Wright
@ 2003-05-13  5:27       ` Christoph Hellwig
  2003-05-20  0:57         ` Chris Wright
  2003-05-13  5:28       ` Andi Kleen
  1 sibling, 1 reply; 32+ messages in thread
From: Christoph Hellwig @ 2003-05-13  5:27 UTC (permalink / raw)
  To: Andi Kleen, linux-kernel, hch, greg, linux-security-module

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?

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH] Early init for security modules
  2003-05-13  5:20     ` Chris Wright
  2003-05-13  5:27       ` Christoph Hellwig
@ 2003-05-13  5:28       ` Andi Kleen
  2003-05-13  6:16         ` Chris Wright
  1 sibling, 1 reply; 32+ messages in thread
From: Andi Kleen @ 2003-05-13  5:28 UTC (permalink / raw)
  To: Andi Kleen, linux-kernel, hch, greg, linux-security-module

On Mon, May 12, 2003 at 10:20:00PM -0700, Chris Wright wrote:
> * Andi Kleen (ak@suse.de) 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

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH] Early init for security modules
  2003-05-13  3:09 ` Chris Wright
@ 2003-05-13  5:56   ` David Mosberger
  0 siblings, 0 replies; 32+ messages in thread
From: David Mosberger @ 2003-05-13  5:56 UTC (permalink / raw)
  To: Chris Wright; +Cc: linux-kernel, hch, gregkh, linux-security-module, davidm

>>>>> On Mon, 12 May 2003 20:09:53 -0700, Chris Wright <chris@wirex.com> 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

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH] Early init for security modules
  2003-05-13  5:28       ` Andi Kleen
@ 2003-05-13  6:16         ` Chris Wright
  2003-05-13  6:29           ` Andi Kleen
  0 siblings, 1 reply; 32+ messages in thread
From: Chris Wright @ 2003-05-13  6:16 UTC (permalink / raw)
  To: Andi Kleen; +Cc: linux-kernel, hch, greg, linux-security-module

* Andi Kleen (ak@suse.de) 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

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH] Early init for security modules
  2003-05-13  6:16         ` Chris Wright
@ 2003-05-13  6:29           ` Andi Kleen
  0 siblings, 0 replies; 32+ messages in thread
From: Andi Kleen @ 2003-05-13  6:29 UTC (permalink / raw)
  To: Andi Kleen, linux-kernel, hch, greg, linux-security-module

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

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH] Early init for security modules
  2003-05-13  3:08 ` Chris Wright
@ 2003-05-13  9:03   ` Russell King
  2003-05-13  9:20     ` Documentation/linu-logo-HOWTO.txt cosmos
  0 siblings, 1 reply; 32+ messages in thread
From: Russell King @ 2003-05-13  9:03 UTC (permalink / raw)
  To: linux-kernel, hch, gregkh, linux-security-module

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 (rmk@arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html


^ permalink raw reply	[flat|nested] 32+ messages in thread

* Documentation/linu-logo-HOWTO.txt
  2003-05-13  9:03   ` Russell King
@ 2003-05-13  9:20     ` cosmos
  2003-05-13  9:57       ` Documentation/linu-logo-HOWTO.txt Geert Uytterhoeven
  2003-05-13 13:16       ` Documentation/linu-logo-HOWTO.txt Alan Cox
  0 siblings, 2 replies; 32+ messages in thread
From: cosmos @ 2003-05-13  9:20 UTC (permalink / raw)
  To: linux-kernel

Hi,
i have written a doc for the hack of the bootup linux logo.The document
contains the main program that produces the linux-logo.h header file and the
aquired measurements for the WIDTH & HEIGHT for the fbcon.c file.
Can this doc be included in the Documentation of the kernel.

Best regards,
Chris.


^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: Documentation/linu-logo-HOWTO.txt
  2003-05-13  9:20     ` Documentation/linu-logo-HOWTO.txt cosmos
@ 2003-05-13  9:57       ` Geert Uytterhoeven
  2003-05-13 11:25         ` Documentation/linux-logo-HOWTO.txt cosmos
  2003-05-13 13:16       ` Documentation/linu-logo-HOWTO.txt Alan Cox
  1 sibling, 1 reply; 32+ messages in thread
From: Geert Uytterhoeven @ 2003-05-13  9:57 UTC (permalink / raw)
  To: cosmos; +Cc: Linux Kernel Development

On Tue, 13 May 2003, cosmos wrote:
> i have written a doc for the hack of the bootup linux logo.The document
> contains the main program that produces the linux-logo.h header file and the
> aquired measurements for the WIDTH & HEIGHT for the fbcon.c file.
> Can this doc be included in the Documentation of the kernel.

I guess this is for 2.4.x?

Where are the patches?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: Documentation/linux-logo-HOWTO.txt
  2003-05-13  9:57       ` Documentation/linu-logo-HOWTO.txt Geert Uytterhoeven
@ 2003-05-13 11:25         ` cosmos
  0 siblings, 0 replies; 32+ messages in thread
From: cosmos @ 2003-05-13 11:25 UTC (permalink / raw)
  To: Linux Kernel Development

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

> On Tue, 13 May 2003, cosmos wrote:
> > i have written a doc for the hack of the bootup linux logo.The document
> > contains the main program that produces the linux-logo.h header file and
the
> > aquired measurements for the WIDTH & HEIGHT for the fbcon.c file.
> > Can this doc be included in the Documentation of the kernel.
>
> I guess this is for 2.4.x?
>
> Where are the patches?
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker.
But
> when I'm talking to journalists I just say "programmer" or something like
that.
>     -- Linus Torvalds

I have included the doc in txt format as should be included in the
kernel.Yes the patch is for the 2.4.x kernel series. The C program supports
only PCX files but easily can adopt other formats.The patch can be included
also in the Kernel Hacking Section,in CONFIG_LINUX_LOGO_HACK,or sth like
that and retrieve the PCX information from the same directory which the
patch is included.
If the doc is going to be included in the kernel doc in any way please let
me know.
Thanks.

Best regards,
Chris.


[-- Attachment #2: linux-logo-HOWTO.txt --]
[-- Type: text/plain, Size: 32995 bytes --]

Linux-logo hack-HOWTO
======================
Nanakos Chrysostomos <cosmos@wired-net.gr>

This HOW-TO is written for those that want to hack the linux bootup logo.
The main files in the kernel for the vesa frame buffer bootup logo are:
[Kernel_TopDir]/drivers/video/fbcon.c & [Kernel_TopDir]/include/linux/linux_logo.h
Those two files are responsible for the bootup logo when the kernel starts in debug or quiet mode.
If we want to change this logo we have to modify the files,by using the program that is appended at the end
of this text.The image file that we have to use is a PCX image file with no more than 256 colors and not bigger
than 786432 pixels(1024x768).

For more information you can also read the [Kernel_TopDir]/Documentation/fb/vesafb.txt

--------logo.c-------------------------
/*Written by Kevin R. Sandy
* Changes to image manipulation by Nanakos Chrysostomos*/

#include <stdio.h>
#include <stdlib.h>
#include "fbcon.h"

#define COLORS	256
#define IMAGE_SIZE	786432   /*"1024x768"*/

typedef struct struct_palette
{
	unsigned char red[256];
	unsigned char green[256];
	unsigned char blue[256];
} struct_palette;

typedef struct struct_picture
{
	struct_palette palette;
	unsigned int height;
	unsigned int width;
	unsigned long int bytes_in_image;
	unsigned long int pixels_in_image;
	unsigned char image_data[IMAGE_SIZE];
} struct_logo;

struct_logo logo;

void print_usage(FILE *stream,int exit_code);
int load_image_file(const char *);
int write_logo_header(const char *);
int write_image_data(FILE *, unsigned char *);
int write_palette_info(FILE *, char *, unsigned char *);
int read_pcx_file(FILE *);

const char* program_name;
int errno;


int main(int argc,char **argv)
{
	char *image_file_name;
	char *header_file_name;
	program_name=argv[0];
	
	if( argc !=3 )
	{
		print_usage(stdout,0);
	}
	image_file_name=argv[1];
	header_file_name=argv[2];

	if ( !(load_image_file(image_file_name)) )
	{
		fprintf(stderr, "Exiting due to errors.\n\n");

		return 1;
	}
	else if ( !(write_logo_header(header_file_name)) )
	{
		fprintf(stderr, "Exiting due to errors.\n\n");

		return 1;
	}
	else
	{
		fprintf(stdout, "\n");
		fprintf(stdout, "#define LOGO_H %u\n", logo.height);
		fprintf(stdout, "#define LOGO_W %u\n", logo.width);
		fprintf(stdout, "\n");
		fprintf(stdout, "\n");

		return 0;
	}
}
void print_usage(FILE *stream,int exit_code)
{

	fprintf(stream, "Usage: %s <image>.pcx <linux-logo.h>\n",program_name);
	fprintf(stream,
	                "\n"
			"The image file should be in PCX format.     \n"
	                "It should use only 256 colors.               \n"
	                "\n");

	exit(exit_code);
}

int load_image_file(const char *image_file_name)
{
	FILE *image_file;

	image_file = fopen(image_file_name, "rb");

	if ( !image_file )
	{
		fprintf(stderr, "\n");
		fprintf(stderr, "Cannot open %s for reading:\n", image_file_name);
		fprintf(stderr, "\t%s\n", strerror(errno));
		fprintf(stderr, "\n");
		return 0;
	}

	read_pcx_file(image_file);

	fclose(image_file);				

	return 1;
}

int write_logo_header(const char *header_file_name)
{
	FILE *header_file;

	header_file = fopen(header_file_name, "wb");

	if ( !header_file )
	{
		fprintf(stderr, "\n");
		fprintf(stderr, "Cannot open %s for writing:\n", header_file_name);
		fprintf(stderr, "\t%s\n", strerror(errno));
		fprintf(stderr, "\n");
		return 0;
	}

	fprintf(header_file, "#ifndef __HAVE_ARCH_LINUX_LOGO\n");
	fprintf(header_file, "#define LINUX_LOGO_COLORS 214\n");
	fprintf(header_file, "#endif\n\n");
	fprintf(header_file, "#ifdef INCLUDE_LINUX_LOGO_DATA\n\n");
	fprintf(header_file, "#ifndef __HAVE_ARCH_LINUX_LOGO\n\n");

	write_palette_info(header_file, "red", (char *)logo.palette.red);
	write_palette_info(header_file, "green", (char *)logo.palette.green);
	write_palette_info(header_file, "blue", (char *)logo.palette.blue);
	write_image_data(header_file, (char *)logo.image_data);

	fprintf(header_file, "#endif\n\n");
	fprintf(header_file, "%s",color_logo);

	fclose(header_file);

	return 1;
}

int write_image_data(FILE *header_file, unsigned char *image_data)
{
	unsigned int ctr = 0;

	fprintf(header_file, "unsigned char linux_logo[] __initdata = {\n");

	while ( ctr < logo.pixels_in_image )
	{
		fprintf(header_file, "0x%2.2hx", image_data[ctr++] + 0x20);
		if ( ctr == logo.pixels_in_image )
		{
			fprintf(header_file, "\n};\n\n");
		}
		else if ( ctr % 8 == 0 )
		{
			fprintf(header_file, ",\n");
		}
		else
		{
			fprintf(header_file, ", ");
		}
	}

	return 1;
}

int write_palette_info(FILE *header_file, char *color, unsigned char *palette)
{
	unsigned int ctr;

	fprintf(header_file, "unsigned char linux_logo_%s[] __initdata = {\n", color);
	ctr = 0;
	while ( ctr < 256 )
	{
		fprintf(header_file, "0x%2.2hx", palette[ctr++]);
		if ( ctr == 256 )
		{
			fprintf(header_file, "\n};\n\n");
		}
		else if ( ctr % 8 == 0 )
		{
			fprintf(header_file, ",\n");
		}
		else
		{
			fprintf(header_file, ", ");
		}
	}

	return 1;
}

int read_pcx_file(FILE *pcx_file)
{
	unsigned char temp_buffer;
	unsigned int ctr, image_ctr;
	unsigned int rle_run_length;

	fseek(pcx_file, -768L, SEEK_END);			
	logo.bytes_in_image = ftell(pcx_file) - 128;		

	fseek(pcx_file, 8L, SEEK_SET);
	fscanf(pcx_file, "%2c", &logo.width);
	logo.width++;
	fscanf(pcx_file, "%2c", &logo.height);
	logo.height++;

	fseek(pcx_file, 128L, SEEK_SET);			

	for ( ctr = 0, image_ctr = 0; ctr < logo.bytes_in_image; ctr++)
	{
		temp_buffer = fgetc(pcx_file);

		if ( temp_buffer >= 192 )			
		{					
			rle_run_length = temp_buffer - 192;	
			temp_buffer = fgetc(pcx_file);
			ctr++;					
								
			while ( rle_run_length-- > 0 )
			{
				logo.image_data[image_ctr++] = temp_buffer;
			}
		}
		else						
		{
			logo.image_data[image_ctr++] = temp_buffer;
		}
	}

	logo.pixels_in_image = --image_ctr;

	for ( ctr = 0; ctr < 256; ctr++)			
	{
		logo.palette.red[ctr] = fgetc(pcx_file);
		logo.palette.green[ctr] = fgetc(pcx_file);
		logo.palette.blue[ctr] = fgetc(pcx_file);
	}

	return 1;
}

-------fbcon.h----------------------------------------
char* color_logo = "#ifndef __HAVE_ARCH_LINUX_LOGOBW

unsigned char linux_logo_bw[] __initdata = {
	0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
	0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x80, 0x00, 0x3F,
	0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x1F,
	0xFE, 0x1F, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
	0xFE, 0x3F, 0xFF, 0x0F, 0xFF, 0xFF, 0xFF, 0xFF,
	0xFF, 0xFF, 0xFE, 0x7F, 0xFF, 0xC7, 0xFF, 0xFF,
	0xFF, 0xFF, 0xFF, 0xFF, 0xFC, 0xFF, 0xFF, 0xC3,
	0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFC, 0xFF,
	0xFB, 0xE3, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
	0xFD, 0xFF, 0xFF, 0xE1, 0xFF, 0xFF, 0xFF, 0xFF,
	0xFF, 0xFF, 0xF9, 0xFF, 0xFF, 0xF1, 0xFF, 0xFF,
	0xFF, 0xFF, 0xFF, 0xFF, 0xF9, 0xFF, 0xFF, 0xF1,
	0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xF9, 0xFF,
	0xFF, 0xF8, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
	0xF9, 0xFF, 0xFF, 0xF8, 0xFF, 0xFF, 0xFF, 0xFF,
	0xFF, 0xFF, 0xF9, 0xCF, 0xC3, 0xF8, 0xFF, 0xFF,
	0xFF, 0xFF, 0xFF, 0xFF, 0xF9, 0x87, 0x81, 0xF9,
	0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xF9, 0xA7,
	0x99, 0xF9, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
	0xF9, 0xF3, 0xBC, 0xF9, 0xFF, 0xFF, 0xFF, 0xFF,
	0xFF, 0xFF, 0xF9, 0xE3, 0xBC, 0xF9, 0xFF, 0xFF,
	0xFF, 0xFF, 0xFF, 0xFF, 0xF9, 0xB0, 0x3C, 0xF9,
	0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xF9, 0xB0,
	0x19, 0xF0, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
	0xF9, 0xC0, 0x03, 0xF0, 0xFF, 0xFF, 0xFF, 0xFF,
	0xFF, 0xFF, 0xF9, 0x80, 0x01, 0xF8, 0xFF, 0xFF,
	0xFF, 0xFF, 0xFF, 0xFF, 0xF9, 0x80, 0x01, 0xF8,
	0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xF9, 0x80,
	0x01, 0xF8, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
	0xF9, 0xC0, 0x21, 0xD8, 0xFF, 0xFF, 0xFF, 0xFF,
	0xFF, 0xFF, 0xF9, 0xB1, 0x80, 0xEC, 0xC0, 0x1F,
	0xFF, 0xFF, 0xFF, 0xFF, 0xF1, 0x90, 0x00, 0xE4,
	0x00, 0x01, 0xFF, 0xFF, 0xFF, 0xFF, 0xF1, 0x8C,
	0xC0, 0x7C, 0x04, 0x81, 0xFF, 0xFF, 0xFF, 0xFF,
	0xE3, 0x80, 0x00, 0x7C, 0x40, 0x11, 0xFF, 0xFF,
	0xFF, 0xFF, 0xE3, 0x80, 0x00, 0x7F, 0xD2, 0x29,
	0xFF, 0xFF, 0xFF, 0xFF, 0x87, 0x00, 0x00, 0x3F,
	0x80, 0x19, 0xFF, 0xFF, 0xFF, 0xFF, 0x0E, 0x00,
	0x00, 0x3F, 0x80, 0x19, 0xFF, 0xFF, 0xFF, 0xFF,
	0x1E, 0x00, 0x00, 0x1F, 0x80, 0x19, 0xFF, 0xFF,
	0xFF, 0xFE, 0x1C, 0x00, 0x00, 0x1E, 0x80, 0x19,
	0xFF, 0xFF, 0xFF, 0xFE, 0x3C, 0x00, 0x00, 0x1E,
	0x80, 0x11, 0xFF, 0xFF, 0xFF, 0xFC, 0x7C, 0x00,
	0x00, 0x0F, 0x80, 0x11, 0xFF, 0xFF, 0xFF, 0xFC,
	0xF8, 0x00, 0x00, 0x0E, 0x80, 0x11, 0xFF, 0xFF,
	0xFF, 0xFC, 0xF8, 0x00, 0x00, 0x06, 0x00, 0x11,
	0xFF, 0xFF, 0xFF, 0xF8, 0xF8, 0x00, 0x00, 0x06,
	0x00, 0x01, 0xFF, 0xFF, 0xFF, 0xF9, 0xF0, 0x00,
	0x00, 0x02, 0x00, 0x09, 0xFF, 0xFF, 0xFF, 0xF1,
	0xF0, 0x00, 0x00, 0x02, 0x80, 0x10, 0xFF, 0xFF,
	0xFF, 0xF1, 0xE0, 0x00, 0x00, 0x00, 0x97, 0x10,
	0xFF, 0xFF, 0xFF, 0xE3, 0xE0, 0x00, 0x00, 0x00,
	0xDF, 0xF0, 0xFF, 0xFF, 0xFF, 0xE3, 0xC0, 0x00,
	0x00, 0x00, 0xFF, 0xF8, 0xFF, 0xFF, 0xFF, 0xC7,
	0xC0, 0x00, 0x00, 0x01, 0xFF, 0xF8, 0xFF, 0xFF,
	0xFF, 0xC7, 0x80, 0x00, 0x00, 0x01, 0xFF, 0xF8,
	0xFF, 0xFF, 0xFF, 0x8F, 0x80, 0x00, 0x00, 0x01,
	0xFF, 0xF8, 0xFF, 0xFF, 0xFF, 0x8F, 0x80, 0x00,
	0x00, 0x01, 0xFF, 0xF8, 0xFF, 0xFF, 0xFF, 0x9F,
	0x80, 0x00, 0x00, 0x01, 0xFF, 0xF8, 0xFF, 0xFF,
	0xFF, 0x9F, 0x80, 0x00, 0x00, 0x01, 0x80, 0x18,
	0xFF, 0xFF, 0xFF, 0x9E, 0x80, 0x00, 0x00, 0x03,
	0xA8, 0x11, 0xFF, 0xFF, 0xFF, 0x9F, 0x80, 0x00,
	0x00, 0x02, 0x00, 0x01, 0xFF, 0xFF, 0xFF, 0x99,
	0x80, 0x00, 0x00, 0x00, 0x00, 0x09, 0xFF, 0xFF,
	0xFF, 0x00, 0x80, 0x00, 0x00, 0x01, 0xC0, 0x01,
	0xFF, 0xFF, 0xFE, 0x20, 0x60, 0x00, 0x00, 0x00,
	0xFF, 0xC3, 0xFF, 0xFF, 0xF8, 0x00, 0x30, 0x00,
	0x00, 0x00, 0xFF, 0x0F, 0xFF, 0xFF, 0xC0, 0x40,
	0x38, 0x00, 0x00, 0x00, 0xFE, 0x47, 0xFF, 0xFF,
	0x81, 0x00, 0x1C, 0x00, 0x00, 0x00, 0xFC, 0x23,
	0xFF, 0xFF, 0x90, 0x00, 0x1E, 0x00, 0x00, 0x00,
	0x78, 0x11, 0xFF, 0xFF, 0x80, 0x00, 0x0F, 0x80,
	0x00, 0x00, 0x00, 0x01, 0xFF, 0xFF, 0x80, 0x00,
	0x07, 0xC0, 0x00, 0x00, 0x00, 0x08, 0xFF, 0xFF,
	0xC0, 0x00, 0x07, 0xC0, 0x00, 0x00, 0x00, 0x04,
	0x7F, 0xFF, 0x80, 0x00, 0x03, 0xC0, 0x00, 0x10,
	0x00, 0x00, 0x1F, 0xFF, 0x80, 0x00, 0x01, 0x80,
	0x00, 0x30, 0x00, 0x00, 0x0F, 0xFF, 0x80, 0x00,
	0x00, 0x00, 0x00, 0x70, 0x00, 0x01, 0x4F, 0xFF,
	0x80, 0x00, 0x00, 0x00, 0x00, 0xF0, 0x00, 0x00,
	0x0F, 0xFF, 0xC0, 0x00, 0x00, 0x80, 0x03, 0xF0,
	0x00, 0x00, 0x8F, 0xFF, 0x80, 0x00, 0x00, 0x40,
	0x0F, 0xF0, 0x00, 0x04, 0x1F, 0xFF, 0x80, 0x00,
	0x00, 0x7F, 0xFF, 0xF0, 0x00, 0x10, 0x1F, 0xFF,
	0xC0, 0x00, 0x00, 0x7F, 0xFF, 0xF0, 0x00, 0x40,
	0xFF, 0xFF, 0x98, 0x00, 0x00, 0xFF, 0xFF, 0xF0,
	0x00, 0x83, 0xFF, 0xFF, 0x81, 0xE0, 0x01, 0xFF,
	0xFF, 0xF8, 0x02, 0x07, 0xFF, 0xFF, 0x80, 0x3F,
	0x07, 0xE0, 0x00, 0x1C, 0x0C, 0x1F, 0xFF, 0xFF,
	0xF8, 0x03, 0xFF, 0x80, 0x00, 0x1F, 0x78, 0x1F,
	0xFF, 0xFF, 0xFF, 0x80, 0x7F, 0x00, 0x07, 0x0F,
	0xF0, 0x7F, 0xFF, 0xFF, 0xFF, 0xFE, 0x0C, 0x07,
	0xFF, 0x83, 0xC0, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
	0x00, 0x1F, 0xFF, 0xC0, 0x03, 0xFF, 0xFF, 0xFF,
	0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xF8, 0x07, 0xFF,
	0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
	0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
	0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
	0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
};

#endif

#ifndef __HAVE_ARCH_LINUX_LOGO16_RED

unsigned char linux_logo16_red[] __initdata = {
	0x00, 0x90, 0xb0, 0x9c, 0xf7, 0x35, 0x83, 0xa5,
	0x65, 0x8f, 0x98, 0xc9, 0xdb, 0xe1, 0xe7, 0xf8
};

#endif
#ifndef __HAVE_ARCH_LINUX_LOGO16_GREEN

unsigned char linux_logo16_green[] __initdata = {
	0x00, 0x90, 0xb0, 0x9c, 0xf7, 0x2e, 0x83, 0xa5,
	0x65, 0x6e, 0x98, 0x89, 0xbf, 0xac, 0xda, 0xf8
};

#endif
#ifndef __HAVE_ARCH_LINUX_LOGO16_BLUE

unsigned char linux_logo16_blue[] __initdata = {
	0x00, 0x90, 0xaf, 0x9c, 0xf7, 0x2b, 0x82, 0xa5,
	0x65, 0x41, 0x97, 0x1e, 0x60, 0x29, 0xa5, 0xf8
};

#endif
#ifndef __HAVE_ARCH_LINUX_LOGO16

unsigned char linux_logo16[] __initdata = {
	0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa,
	0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xa1, 0x11, 0x11,
	0x61, 0x16, 0x66, 0x66, 0x11, 0x11, 0x11, 0x11,
	0x11, 0x11, 0x1a, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa,
	0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa,
	0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa,
	0xaa, 0xaa, 0xaa, 0xaa, 0x33, 0xa8, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x87, 0x77, 0x77, 0x77, 0x77,
	0x77, 0x77, 0x73, 0x33, 0x33, 0x3a, 0xaa, 0xaa,
	0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa,
	0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa,
	0xaa, 0xaa, 0xa3, 0x33, 0x33, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x77, 0x77, 0x77, 0x77,
	0x77, 0x27, 0x77, 0x77, 0x77, 0x33, 0x3a, 0xaa,
	0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa,
	0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa,
	0xaa, 0xa3, 0x33, 0x33, 0x30, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x55, 0x50, 0x08, 0x33, 0x77, 0x77,
	0x77, 0x72, 0x72, 0x27, 0x77, 0x77, 0x33, 0x33,
	0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa,
	0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa,
	0xa3, 0x33, 0x33, 0x77, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x58, 0x85, 0x00, 0x11, 0x11, 0xaa,
	0xa3, 0x37, 0x77, 0x72, 0x22, 0x22, 0x77, 0x73,
	0x33, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa,
	0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xa3,
	0x33, 0x37, 0x77, 0x33, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x56, 0x85, 0x00, 0x06, 0x66, 0x11,
	0x11, 0x1a, 0xa3, 0x37, 0x77, 0x72, 0x22, 0x77,
	0x73, 0x33, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa,
	0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0x33,
	0x33, 0x33, 0x33, 0x30, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x55, 0x00, 0x00, 0x06, 0x66, 0x66,
	0x66, 0x66, 0x11, 0x1a, 0xa3, 0x77, 0x72, 0x22,
	0x77, 0x73, 0x3a, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa,
	0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0x33, 0x33,
	0x33, 0x33, 0x33, 0xa0, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x11, 0x11,
	0x66, 0x66, 0x66, 0x66, 0x11, 0xa3, 0x77, 0x22,
	0x22, 0x77, 0x33, 0x33, 0xaa, 0xaa, 0xaa, 0xaa,
	0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0x33, 0x33, 0x33,
	0x33, 0x3a, 0xa1, 0x10, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x77, 0x33,
	0xaa, 0x11, 0x16, 0x66, 0x66, 0x61, 0x1a, 0x37,
	0x22, 0x22, 0x77, 0x33, 0x3a, 0xaa, 0xaa, 0xaa,
	0xaa, 0xaa, 0xaa, 0xaa, 0xa3, 0x33, 0x33, 0x33,
	0x3a, 0xa1, 0x11, 0x10, 0x00, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x05, 0x00, 0x00, 0x00, 0x02, 0x22,
	0x22, 0x77, 0x3a, 0x11, 0x66, 0x66, 0x66, 0x1a,
	0x37, 0x22, 0x22, 0x77, 0x33, 0x3a, 0xaa, 0xaa,
	0xaa, 0xaa, 0xaa, 0xaa, 0x33, 0x33, 0x33, 0x3a,
	0xa1, 0x11, 0x11, 0x10, 0x00, 0x00, 0x50, 0x00,
	0x00, 0x05, 0x80, 0x50, 0x00, 0x00, 0x07, 0x72,
	0x22, 0x22, 0x22, 0x73, 0xa1, 0x66, 0x66, 0x61,
	0x1a, 0x77, 0x22, 0x27, 0x73, 0x33, 0xaa, 0xaa,
	0xaa, 0xaa, 0xaa, 0xaa, 0x33, 0x33, 0x3a, 0xaa,
	0x11, 0x11, 0x1a, 0xa0, 0x08, 0x71, 0x05, 0x00,
	0x00, 0x12, 0x22, 0x50, 0x00, 0x00, 0x07, 0x77,
	0x77, 0x72, 0x22, 0x22, 0x27, 0x31, 0x16, 0x66,
	0x61, 0x13, 0x77, 0x22, 0x77, 0x33, 0x3a, 0xaa,
	0xaa, 0xaa, 0xaa, 0xa3, 0x33, 0x33, 0xaa, 0xa1,
	0x11, 0x1a, 0x33, 0x70, 0x07, 0x2e, 0x70, 0x00,
	0x01, 0x44, 0x42, 0x60, 0x00, 0x00, 0x02, 0x22,
	0x22, 0x22, 0x22, 0x22, 0x22, 0x27, 0x31, 0x66,
	0x66, 0x61, 0xa3, 0x72, 0x22, 0x77, 0x33, 0xaa,
	0xaa, 0xaa, 0xa3, 0x33, 0x33, 0xaa, 0xaa, 0x11,
	0x1a, 0x33, 0x77, 0x30, 0x04, 0x82, 0x40, 0x00,
	0x54, 0x48, 0x54, 0x40, 0x00, 0x00, 0x01, 0xaa,
	0x32, 0x22, 0x22, 0x22, 0x22, 0x22, 0x22, 0x31,
	0x66, 0x66, 0x11, 0x37, 0x22, 0x27, 0x73, 0x3a,
	0xaa, 0xaa, 0xa3, 0x33, 0x3a, 0xaa, 0xaa, 0xaa,
	0xa3, 0x77, 0xaa, 0x10, 0x50, 0x08, 0x46, 0x05,
	0x54, 0x80, 0x50, 0x42, 0x00, 0x00, 0x08, 0x66,
	0x66, 0x1a, 0x32, 0x22, 0x22, 0x22, 0x22, 0x27,
	0x31, 0x66, 0x66, 0x13, 0x72, 0x22, 0x77, 0x33,
	0xaa, 0xaa, 0xaa, 0x33, 0xaa, 0xa1, 0xaa, 0xa3,
	0x37, 0xa1, 0x1a, 0x30, 0x50, 0x06, 0x26, 0x00,
	0x54, 0x00, 0x00, 0x44, 0x00, 0x00, 0x08, 0xe2,
	0xee, 0xee, 0xee, 0xee, 0xee, 0xee, 0x22, 0x22,
	0x27, 0xa6, 0x66, 0x61, 0xa7, 0x72, 0x27, 0x73,
	0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0x33,
	0x31, 0x11, 0x37, 0x70, 0x02, 0x00, 0xab, 0xbb,
	0xb6, 0x00, 0x00, 0xf4, 0x00, 0x00, 0xee, 0xee,
	0xee, 0xee, 0xee, 0xee, 0xee, 0xee, 0xee, 0x22,
	0x22, 0x23, 0x16, 0x66, 0x1a, 0x37, 0x22, 0x77,
	0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xa3, 0x3a,
	0x11, 0xa7, 0x33, 0x10, 0x04, 0x09, 0xbd, 0xdd,
	0xbd, 0xd0, 0x04, 0x45, 0x00, 0x0e, 0xee, 0xee,
	0xee, 0xee, 0xee, 0xee, 0xee, 0xee, 0xee, 0x22,
	0x22, 0x22, 0x71, 0x66, 0x66, 0x13, 0x72, 0x27,
	0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0xaa, 0x33, 0x11,
	0xa3, 0x73, 0xa1, 0x60, 0x08, 0xbd, 0xdd, 0xdd,
	0xdd, 0xdd, 0xdb, 0x90, 0x00, 0x02, 0xec, 0xee,
	0xee, 0xee, 0xee, 0xee, 0xee, 0xee, 0xce, 0x22,
	0x22, 0x22, 0x27, 0xa6, 0x66, 0x61, 0x37, 0x27,
	0x1a, 0xaa, 0xaa, 0xaa, 0xaa, 0xa3, 0xa1, 0x1a,
	0x33, 0xa1, 0x16, 0x60, 0x0b, 0xbd, 0xdd, 0xdd,
	0xcd, 0xdd, 0xdd, 0xd9, 0x00, 0x00, 0xec, 0xcc,
	0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xce, 0xa2,
	0x22, 0x22, 0x22, 0x7a, 0x66, 0x66, 0x13, 0x77,
	0x1a, 0xaa, 0xaa, 0xaa, 0xaa, 0x3a, 0x11, 0x33,
	0xaa, 0x11, 0x66, 0x60, 0x9b, 0xdd, 0xdd, 0xdd,
	0xcd, 0xdd, 0xdb, 0xb9, 0x00, 0x00, 0xec, 0xcc,
	0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xee, 0x61,
	0x72, 0x22, 0x22, 0x22, 0xa1, 0x66, 0x61, 0x37,
	0x1a, 0xaa, 0xaa, 0xaa, 0xa3, 0xa1, 0x13, 0x3a,
	0x11, 0x11, 0x11, 0x10, 0x5b, 0xdd, 0xdd, 0xdc,
	0xdd, 0xdd, 0xbd, 0xd9, 0x00, 0x00, 0xec, 0xcc,
	0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xee, 0x86,
	0x17, 0x22, 0x22, 0x22, 0x23, 0x16, 0x66, 0xaa,
	0xaa, 0xa3, 0x3a, 0xaa, 0xaa, 0x1a, 0x3a, 0xa1,
	0x11, 0x11, 0x1a, 0x70, 0x05, 0xbd, 0xdd, 0xdd,
	0xdb, 0x5b, 0xdd, 0xb0, 0x00, 0x60, 0x2e, 0xcc,
	0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xe6, 0x88,
	0x66, 0x32, 0x22, 0x22, 0x22, 0x36, 0x66, 0x11,
	0x33, 0x33, 0x3a, 0xaa, 0x11, 0xaa, 0xaa, 0xa1,
	0x11, 0x1a, 0x3a, 0x60, 0x02, 0x99, 0xbb, 0xb9,
	0x9b, 0xbb, 0xbc, 0x22, 0x00, 0x86, 0x5e, 0xcc,
	0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xe1, 0x68,
	0x86, 0x63, 0x22, 0x22, 0x22, 0x2a, 0x66, 0x66,
	0x33, 0x33, 0xaa, 0xaa, 0x1a, 0xaa, 0xaa, 0x11,
	0x1a, 0xa7, 0x68, 0x80, 0x02, 0x2b, 0xbd, 0xbb,
	0xbb, 0xb9, 0x22, 0x22, 0x00, 0x06, 0x6e, 0xcc,
	0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xc7, 0xa6,
	0x88, 0x86, 0x32, 0x22, 0x22, 0x27, 0xa6, 0x66,
	0x33, 0x3a, 0xaa, 0xa1, 0xaa, 0xaa, 0xa1, 0x11,
	0xa3, 0xa6, 0x88, 0x80, 0x02, 0x22, 0x9b, 0xbb,
	0xbb, 0x22, 0x24, 0xf4, 0x60, 0x00, 0x0c, 0xcc,
	0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xc2, 0x21,
	0x68, 0x88, 0x63, 0x22, 0x22, 0x22, 0x71, 0x66,
	0x33, 0x3a, 0x11, 0x11, 0xaa, 0xaa, 0x11, 0xaa,
	0x71, 0x88, 0x88, 0x00, 0x02, 0xe2, 0x26, 0x99,
	0x22, 0x22, 0x4f, 0xf4, 0x40, 0x00, 0x0c, 0xcc,
	0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0x22, 0x22,
	0x16, 0x88, 0x86, 0xa2, 0x22, 0x22, 0x27, 0x11,
	0x33, 0xa1, 0x11, 0x11, 0xaa, 0x31, 0x1a, 0xa3,
	0x68, 0x88, 0x81, 0x00, 0x54, 0x42, 0x22, 0x22,
	0x22, 0x44, 0xff, 0xff, 0x48, 0x00, 0x00, 0x99,
	0xbb, 0xbb, 0xbb, 0xbb, 0xbb, 0x99, 0x22, 0x22,
	0x21, 0x88, 0x88, 0x6a, 0x22, 0x22, 0x22, 0x31,
	0x3a, 0xa1, 0x11, 0x1a, 0xa3, 0x11, 0x33, 0x36,
	0x88, 0x86, 0x30, 0x00, 0x4f, 0x44, 0x22, 0x22,
	0x24, 0xff, 0xff, 0xff, 0x44, 0x00, 0x00, 0x99,
	0xbb, 0xbb, 0xbb, 0xbb, 0xbb, 0x95, 0x22, 0x72,
	0x22, 0x18, 0x88, 0x86, 0x32, 0x22, 0x22, 0x27,
	0xaa, 0x11, 0x11, 0x1a, 0x31, 0x13, 0x33, 0x68,
	0x88, 0x6a, 0x00, 0x02, 0x4f, 0x4f, 0x42, 0x24,
	0x4f, 0xff, 0xff, 0xff, 0xf4, 0x50, 0x00, 0x99,
	0xbb, 0xbb, 0xbb, 0xbb, 0xbb, 0x99, 0x22, 0x73,
	0x72, 0x26, 0x88, 0x88, 0x63, 0x22, 0x22, 0x22,
	0x11, 0x11, 0x11, 0xa3, 0xa1, 0x73, 0xa6, 0x88,
	0x81, 0xa5, 0x00, 0x04, 0x4f, 0x4f, 0x44, 0x4f,
	0xff, 0xff, 0xff, 0xff, 0xf4, 0x40, 0x00, 0x99,
	0xbb, 0xbb, 0xbb, 0xbb, 0xbb, 0x99, 0x12, 0x27,
	0xaa, 0x22, 0x68, 0x55, 0x86, 0x72, 0x22, 0x22,
	0x11, 0x11, 0x1a, 0x33, 0x13, 0x3a, 0x18, 0x88,
	0x1a, 0x10, 0x00, 0x44, 0x4f, 0x4f, 0xff, 0x4f,
	0xff, 0xff, 0xff, 0xff, 0xff, 0xf0, 0x00, 0x99,
	0xbb, 0xbb, 0xbb, 0xbb, 0xbb, 0x99, 0x61, 0x22,
	0x3a, 0xa2, 0x26, 0x85, 0x58, 0x67, 0x22, 0x22,
	0x61, 0x61, 0x1a, 0x7a, 0x37, 0x31, 0x88, 0x81,
	0x11, 0x00, 0x05, 0xe4, 0x44, 0xff, 0xff, 0xff,
	0x4f, 0xf4, 0x44, 0xff, 0xff, 0xf5, 0x00, 0x99,
	0xbb, 0xbb, 0xbb, 0xbb, 0xbb, 0x99, 0x88, 0x12,
	0x2a, 0xaa, 0x72, 0x68, 0x55, 0x81, 0x22, 0x22,
	0x66, 0x61, 0xa3, 0x33, 0x73, 0x16, 0x88, 0x11,
	0x10, 0x00, 0x08, 0x74, 0x44, 0x4f, 0x44, 0x44,
	0xf4, 0xf4, 0x44, 0x44, 0xe2, 0x44, 0x00, 0x99,
	0xbb, 0xbb, 0xbb, 0xbb, 0xbb, 0x99, 0x88, 0x81,
	0x22, 0xaa, 0xa7, 0x26, 0x85, 0x88, 0x12, 0x22,
	0x66, 0x61, 0x37, 0xa7, 0x3a, 0x66, 0x66, 0x11,
	0x80, 0x00, 0x0a, 0x72, 0x44, 0x4f, 0x44, 0x4f,
	0xff, 0x44, 0x44, 0x22, 0x22, 0x24, 0x00, 0x99,
	0xbb, 0xbb, 0xbb, 0xbb, 0xbb, 0x99, 0x85, 0x88,
	0x12, 0x2a, 0xaa, 0x22, 0x68, 0x58, 0x63, 0x22,
	0x66, 0x1a, 0x73, 0x77, 0x31, 0x66, 0x61, 0x11,
	0x00, 0x00, 0x07, 0x44, 0xff, 0x4f, 0xf4, 0x4f,
	0xff, 0x4f, 0x44, 0xf4, 0x42, 0x22, 0x40, 0x9b,
	0xbb, 0xbb, 0xbb, 0xbb, 0xbb, 0xb9, 0x85, 0x55,
	0x81, 0x27, 0xaa, 0xa2, 0x78, 0x88, 0x86, 0x72,
	0x66, 0x13, 0x77, 0x73, 0x11, 0x66, 0x61, 0x76,
	0x00, 0x50, 0x84, 0xf4, 0xff, 0x4f, 0xf4, 0xff,
	0xff, 0x4f, 0x44, 0xff, 0x4f, 0x42, 0x40, 0x9b,
	0xbb, 0xbb, 0xbb, 0xbb, 0xbb, 0xb9, 0x68, 0x55,
	0x58, 0x12, 0x3a, 0xaa, 0x23, 0x88, 0x88, 0xa7,
	0x66, 0xa7, 0x77, 0x7a, 0x16, 0x66, 0x1a, 0x15,
	0x05, 0x00, 0x4f, 0xf4, 0xff, 0x4f, 0xf4, 0xff,
	0xff, 0x4f, 0x44, 0xff, 0x4f, 0x44, 0x24, 0x9b,
	0xbb, 0xbb, 0xbb, 0xbb, 0xbb, 0xb9, 0x26, 0x55,
	0x55, 0x81, 0x23, 0xaa, 0x32, 0x18, 0x88, 0x6a,
	0x61, 0x37, 0x77, 0x31, 0x66, 0x66, 0x17, 0x60,
	0x05, 0x08, 0x4f, 0xf4, 0xff, 0x4f, 0xf4, 0xff,
	0xff, 0x4f, 0x44, 0xff, 0x4f, 0x4f, 0x4e, 0x99,
	0xbb, 0xbb, 0xbb, 0xbb, 0xbb, 0x99, 0xa2, 0x65,
	0x55, 0x58, 0xa2, 0x7a, 0xa2, 0x26, 0x88, 0x61,
	0x61, 0x32, 0x27, 0xa1, 0x66, 0x61, 0x31, 0x60,
	0x00, 0x04, 0x4f, 0xf4, 0xff, 0x44, 0x44, 0xff,
	0xff, 0x4f, 0x44, 0xff, 0x4f, 0x44, 0xf4, 0x99,
	0xbb, 0xbb, 0xbb, 0xbb, 0xbb, 0x9b, 0xaa, 0x26,
	0x55, 0x55, 0x87, 0x27, 0x33, 0x27, 0x68, 0x61,
	0x1a, 0x72, 0x27, 0xa6, 0x66, 0x6a, 0x71, 0x00,
	0x80, 0x84, 0xff, 0xf4, 0xff, 0x44, 0x44, 0xff,
	0xff, 0x4f, 0x44, 0xff, 0x4f, 0x44, 0xf4, 0x99,
	0x9b, 0x9b, 0x99, 0xb9, 0xb9, 0x99, 0xaa, 0xa2,
	0x85, 0x55, 0x56, 0x22, 0x27, 0x22, 0x36, 0x66,
	0x13, 0x22, 0x23, 0x16, 0x86, 0x63, 0x73, 0x00,
	0x00, 0x44, 0xf4, 0xf4, 0xff, 0x44, 0x44, 0xff,
	0xff, 0x4f, 0x44, 0xff, 0x4f, 0x4f, 0x4f, 0x99,
	0x9b, 0x99, 0x99, 0x99, 0xb9, 0x99, 0xaa, 0xaa,
	0x28, 0x55, 0x58, 0x12, 0x22, 0x22, 0x21, 0x11,
	0xa3, 0x27, 0x7a, 0x66, 0x86, 0x17, 0x75, 0x05,
	0x05, 0xff, 0xf4, 0xf4, 0xff, 0x44, 0x44, 0xff,
	0xff, 0x4f, 0x44, 0x4f, 0x4f, 0x44, 0x4f, 0x99,
	0x99, 0x99, 0x99, 0x99, 0x99, 0x99, 0x3a, 0xaa,
	0xa2, 0x85, 0x58, 0x67, 0x72, 0x22, 0x27, 0xa1,
	0x37, 0x27, 0x7a, 0x68, 0x86, 0xa2, 0x70, 0x00,
	0x02, 0xff, 0xf4, 0xf4, 0xff, 0x44, 0x44, 0x4f,
	0xff, 0x4f, 0x44, 0xf4, 0xf4, 0xf4, 0xf4, 0x99,
	0x99, 0x99, 0x99, 0x99, 0x99, 0x99, 0x23, 0xaa,
	0xa7, 0x78, 0x88, 0x81, 0x77, 0x22, 0x27, 0x3a,
	0x72, 0x73, 0x71, 0x68, 0x66, 0x32, 0x50, 0x00,
	0x04, 0x4f, 0xf4, 0xf4, 0xff, 0x44, 0x44, 0x4f,
	0xff, 0x4f, 0x44, 0xf4, 0xf4, 0xf4, 0x44, 0x95,
	0x99, 0x99, 0x99, 0x99, 0x99, 0x55, 0x12, 0x3a,
	0xaa, 0x21, 0x88, 0x81, 0x77, 0x27, 0x73, 0x73,
	0x72, 0x33, 0x36, 0x86, 0x61, 0x72, 0x00, 0x00,
	0x04, 0x44, 0xf4, 0xf4, 0xf4, 0x44, 0x44, 0x4f,
	0xff, 0x4f, 0x44, 0xff, 0x4f, 0x4f, 0x44, 0x55,
	0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x8a, 0x27,
	0xaa, 0x77, 0x68, 0x61, 0x23, 0x71, 0x11, 0x3a,
	0x27, 0xa3, 0x36, 0x86, 0x61, 0x20, 0x00, 0x00,
	0x04, 0xf4, 0xf4, 0xf4, 0xf4, 0x44, 0x44, 0x4f,
	0xff, 0x4f, 0x44, 0xff, 0x4f, 0x4f, 0x41, 0x59,
	0x99, 0x99, 0x99, 0x99, 0x99, 0x95, 0x58, 0x77,
	0x27, 0x32, 0x36, 0x63, 0x23, 0x71, 0x66, 0x11,
	0x27, 0x13, 0xa6, 0x86, 0x6a, 0x20, 0x00, 0x50,
	0x04, 0x4f, 0x4f, 0x4f, 0x4f, 0x44, 0x44, 0x4f,
	0xff, 0x4f, 0x44, 0xff, 0x4f, 0x4f, 0x41, 0x99,
	0x9b, 0xbb, 0xbb, 0xbb, 0xb9, 0x99, 0x68, 0x13,
	0x32, 0x22, 0x73, 0xa7, 0x2a, 0x31, 0x88, 0x66,
	0x7a, 0x13, 0x18, 0x66, 0x63, 0x20, 0x00, 0x06,
	0x0f, 0x4f, 0x4f, 0x4f, 0x4f, 0x44, 0x44, 0x4f,
	0xff, 0x4f, 0x44, 0xff, 0x4f, 0x4f, 0x49, 0x95,
	0xa9, 0xa9, 0x99, 0x97, 0x92, 0x99, 0x65, 0x6a,
	0x17, 0x22, 0x23, 0x72, 0x27, 0xaa, 0x88, 0x88,
	0xa1, 0x17, 0x68, 0x66, 0x67, 0x70, 0x00, 0x05,
	0x0f, 0x4f, 0x4f, 0x4f, 0x4f, 0x44, 0x44, 0x4f,
	0xff, 0x4f, 0x44, 0xff, 0xf4, 0xf4, 0x49, 0x9c,
	0x2e, 0xee, 0xee, 0xee, 0xee, 0xa9, 0x65, 0x8a,
	0x1a, 0xaa, 0x37, 0x72, 0x27, 0x37, 0x88, 0x88,
	0x11, 0x17, 0x68, 0x66, 0x67, 0x10, 0x9d, 0xd0,
	0x84, 0x44, 0xff, 0x4f, 0x4f, 0x44, 0xf4, 0x4f,
	0xff, 0x4f, 0x44, 0xff, 0xf4, 0xf4, 0x4f, 0x69,
	0xcc, 0xee, 0xee, 0xee, 0xec, 0x99, 0x88, 0x63,
	0x61, 0x68, 0x61, 0x72, 0x22, 0x7a, 0x68, 0x88,
	0x11, 0x17, 0x88, 0x66, 0x12, 0x1b, 0xdd, 0xdd,
	0x02, 0x44, 0x4f, 0x4f, 0x4f, 0x44, 0x44, 0x4f,
	0xff, 0x4f, 0x44, 0xff, 0xff, 0x4f, 0x4c, 0xc5,
	0x0c, 0xc1, 0x11, 0x1c, 0xc0, 0x26, 0x66, 0x17,
	0x66, 0x88, 0x88, 0x12, 0x22, 0x23, 0xa8, 0x88,
	0x11, 0x13, 0x88, 0x66, 0x17, 0xbb, 0xdd, 0xdd,
	0xd0, 0x8f, 0xff, 0xf4, 0xf4, 0x44, 0xf4, 0x4f,
	0xff, 0x4f, 0x44, 0xf4, 0x4f, 0x44, 0xdd, 0xdd,
	0x00, 0x00, 0x00, 0x05, 0x9d, 0x21, 0x66, 0x27,
	0xa6, 0x65, 0x58, 0x67, 0x22, 0x27, 0x28, 0x88,
	0x11, 0xaa, 0x86, 0x68, 0x1a, 0xbb, 0xdd, 0xdd,
	0xdb, 0x05, 0xf4, 0xf4, 0xf4, 0xf4, 0x44, 0x4f,
	0xff, 0x4f, 0x44, 0xf4, 0xf4, 0xf4, 0xdd, 0xdb,
	0x00, 0x00, 0x00, 0x00, 0xdd, 0xda, 0x66, 0x22,
	0x71, 0x15, 0x55, 0x81, 0x22, 0x22, 0x76, 0x88,
	0x11, 0x31, 0x88, 0x88, 0xab, 0xbd, 0xdd, 0xdd,
	0xdd, 0x00, 0x04, 0x44, 0xff, 0xff, 0x4f, 0x4f,
	0xff, 0x4f, 0x44, 0xf4, 0xf4, 0x44, 0xdd, 0xdb,
	0x00, 0x00, 0x00, 0x0b, 0xdd, 0xda, 0x11, 0x22,
	0x23, 0x68, 0x55, 0x86, 0x22, 0x22, 0x7a, 0x88,
	0x1a, 0x71, 0x88, 0x89, 0xbb, 0xdd, 0xdd, 0xdd,
	0xdd, 0xd0, 0x00, 0x4f, 0x44, 0xff, 0x4f, 0x4f,
	0xff, 0x4f, 0x44, 0xf4, 0xff, 0xe2, 0xdd, 0xdb,
	0x90, 0x00, 0x05, 0xbd, 0xdd, 0xb8, 0x63, 0x22,
	0x27, 0xa6, 0x55, 0x88, 0x77, 0x22, 0x22, 0x88,
	0x1a, 0x28, 0xbd, 0xdb, 0xdd, 0xdd, 0xdd, 0xdd,
	0xdd, 0xdb, 0x00, 0x07, 0x44, 0x4f, 0x4f, 0x4f,
	0xff, 0x4f, 0x44, 0x4f, 0x4f, 0x22, 0xdd, 0xdb,
	0xbb, 0x9b, 0xbb, 0xbd, 0xdd, 0xd5, 0x86, 0x22,
	0x22, 0x77, 0x85, 0x88, 0x17, 0x22, 0x22, 0x88,
	0xaa, 0x2b, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd,
	0xdd, 0xdd, 0x00, 0x00, 0x54, 0x4f, 0x4f, 0x4f,
	0xff, 0x4f, 0x44, 0xf4, 0x44, 0x22, 0xbd, 0xdd,
	0xbb, 0xbb, 0xbb, 0xdd, 0xdd, 0xdd, 0x88, 0x72,
	0x27, 0x22, 0x88, 0x88, 0x67, 0x72, 0x22, 0x18,
	0x33, 0x2d, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd,
	0xdd, 0xdd, 0xd0, 0x00, 0x05, 0x4f, 0x4f, 0x4f,
	0xff, 0x4f, 0x44, 0x44, 0x4f, 0x22, 0xbd, 0xdd,
	0xdb, 0xbb, 0xdd, 0xdd, 0xdd, 0xdd, 0x88, 0x17,
	0x27, 0x72, 0x68, 0x88, 0x87, 0x32, 0x22, 0x36,
	0x37, 0x2d, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd,
	0xdd, 0xdd, 0xd5, 0x00, 0x00, 0x4f, 0x4f, 0x4f,
	0xff, 0xf4, 0xf4, 0xf4, 0xf4, 0x22, 0xbb, 0xdd,
	0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xd8, 0x67,
	0x72, 0x77, 0x38, 0x88, 0x83, 0x37, 0x22, 0x26,
	0x72, 0x2b, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd,
	0xdd, 0xdd, 0xdd, 0x00, 0x00, 0x4f, 0x4f, 0x4f,
	0xff, 0xf4, 0xf4, 0xf4, 0x44, 0x25, 0xbb, 0xdd,
	0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xd3,
	0x32, 0x73, 0x76, 0x88, 0x81, 0x33, 0x22, 0x2a,
	0x22, 0x2b, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd,
	0xdd, 0xdd, 0xdd, 0xb0, 0x54, 0x4f, 0x4f, 0x4f,
	0xff, 0xf4, 0xf4, 0xff, 0x44, 0x00, 0xbb, 0xdd,
	0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd,
	0xa7, 0x73, 0x26, 0x88, 0x86, 0x7a, 0x72, 0x27,
	0x22, 0x2b, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd,
	0xdd, 0xdd, 0xdd, 0xdb, 0x44, 0xff, 0x4f, 0x4f,
	0xff, 0xf4, 0xf4, 0x44, 0x40, 0x05, 0xbb, 0xdd,
	0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd,
	0x13, 0x23, 0x21, 0x68, 0x86, 0x17, 0x72, 0x22,
	0x22, 0x2b, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd,
	0xdd, 0xdd, 0xdd, 0xdd, 0x94, 0x44, 0x44, 0x44,
	0x44, 0x44, 0x44, 0x00, 0x00, 0x05, 0xbb, 0xdd,
	0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xb8,
	0x86, 0x22, 0x22, 0x7a, 0x68, 0x81, 0x22, 0x22,
	0x37, 0x7b, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd,
	0xdd, 0xdd, 0xdd, 0xdb, 0xb5, 0x44, 0x44, 0x44,
	0x44, 0x47, 0x00, 0x00, 0x00, 0x05, 0xbd, 0xdd,
	0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xd8, 0x68,
	0x58, 0x72, 0x22, 0x27, 0x18, 0x86, 0x72, 0x22,
	0x1a, 0xbb, 0xbd, 0xdd, 0xdd, 0xdd, 0xdd, 0xdd,
	0xdd, 0xdd, 0xdd, 0xdb, 0xb5, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x09, 0xbb, 0xdd,
	0xdd, 0xdd, 0xdd, 0xdd, 0xdd, 0xb9, 0x18, 0x85,
	0x58, 0x12, 0x22, 0x36, 0x18, 0x88, 0x32, 0x22,
	0x61, 0x3b, 0xbb, 0xbb, 0xbd, 0xdd, 0xdd, 0xdd,
	0xdd, 0xdd, 0xdd, 0xdb, 0xb9, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x09, 0xbb, 0xdd,
	0xdd, 0xdd, 0xdd, 0xdd, 0xb9, 0x7a, 0x68, 0x85,
	0x88, 0x62, 0x27, 0x16, 0x18, 0x88, 0x12, 0x27,
	0x86, 0x18, 0x9b, 0xbb, 0xbb, 0xbb, 0xbb, 0xbd,
	0xdd, 0xdd, 0xdd, 0xbb, 0xb5, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x05, 0xbb, 0xbd,
	0xdd, 0xdd, 0xdb, 0xbb, 0x87, 0x31, 0x68, 0x65,
	0x88, 0x82, 0x23, 0x16, 0x18, 0x88, 0x12, 0x23,
	0x88, 0x67, 0x27, 0xa8, 0x9b, 0xbb, 0xbb, 0xbb,
	0xbd, 0xdd, 0xbb, 0xbb, 0x95, 0x00, 0x00, 0x00,
	0x00, 0x00, 0x00, 0x00, 0x00, 0x05, 0x9b, 0xbb,
	0xbb, 0xbb, 0xbb, 0x96, 0x87, 0x16, 0x68, 0x18,
	0x88, 0x62, 0x31, 0x66, 0x18, 0x88, 0x62, 0x73,
	0x88, 0x63, 0x27, 0x33, 0x65, 0x55, 0x99, 0x9b,
	0xbb, 0xbb, 0xbb, 0x99, 0x55, 0x0a, 0xa1, 0x86,
	0x81, 0x68, 0x88, 0x55, 0x58, 0x85, 0x9b, 0xbb,
	0xbb, 0xbb, 0x95, 0x88, 0x83, 0x66, 0x66, 0x18,
	0x66, 0x82, 0xa1, 0x66, 0x18, 0x88, 0x62, 0x33,
	0x88, 0x81, 0x27, 0x7a, 0x18, 0x58, 0x86, 0x85,
	0x99, 0x99, 0x99, 0x95, 0x53, 0x2a, 0xaa, 0x88,
	0x67, 0x31, 0x68, 0x55, 0x58, 0x85, 0x59, 0xbb,
	0xbb, 0xb9, 0x58, 0x68, 0x83, 0x66, 0x61, 0x16,
	0x66, 0x62, 0x16, 0x66, 0x68, 0x88, 0x62, 0xaa,
	0x88, 0x86, 0x27, 0x77, 0x78, 0x55, 0x88, 0x22,
	0x25, 0x55, 0x95, 0x55, 0x6a, 0xa2, 0x2a, 0x88,
	0x62, 0x27, 0x37, 0x38, 0x88, 0x87, 0x55, 0x59,
	0x95, 0x58, 0x16, 0x88, 0x8a, 0x66, 0x63, 0x68,
	0x86, 0x67, 0x66, 0x66, 0x68, 0x88, 0x12, 0x11,
	0x88, 0x88, 0x72, 0x77, 0x78, 0x85, 0x58, 0x17,
	0x23, 0x32, 0x55, 0x55, 0x81, 0x13, 0x73, 0x66,
	0x62, 0x7a, 0xaa, 0x38, 0x88, 0x58, 0x27, 0x55,
	0x58, 0x32, 0x38, 0x88, 0x81, 0x66, 0xa2, 0x88,
	0x86, 0x61, 0x66, 0x61, 0x66, 0x68, 0x13, 0x11,
	0x88, 0x88, 0x12, 0x22, 0x71, 0x85, 0x58, 0x62,
	0x23, 0xa2, 0x68, 0x88, 0x81, 0x66, 0x88, 0x88,
	0x63, 0x2a, 0xaa, 0x28, 0x88, 0x55, 0x86, 0x61,
	0x66, 0x66, 0x68, 0x88, 0x66, 0x66, 0x77, 0x88,
	0x68, 0x16, 0x66, 0x62, 0x66, 0x68, 0xa1, 0x61,
	0x88, 0x88, 0x62, 0x22, 0x22, 0x85, 0x55, 0x83,
	0x72, 0x37, 0xa8, 0x88, 0x61, 0x66, 0x85, 0x55,
	0x86, 0x23, 0xaa, 0x71, 0x88, 0x85, 0x88, 0x66,
	0x88, 0x86, 0x88, 0x88, 0x16, 0x61, 0x21, 0x88,
	0x66, 0xa6, 0x86, 0x17, 0x66, 0x66, 0x31, 0x61,
	0x88, 0x88, 0x87, 0x72, 0x22, 0x68, 0x55, 0x86,
	0x77, 0x77, 0x36, 0x88, 0x13, 0x68, 0x85, 0x55,
	0x58, 0x12, 0x73, 0x72, 0x76, 0x88, 0x88, 0x68,
	0x88, 0x88, 0x88, 0x66, 0x36, 0x63, 0x26, 0x86,
	0x86, 0x36, 0x86, 0x11, 0x66, 0x66, 0x76, 0x61,
	0x88, 0x88, 0x81, 0x22, 0x22, 0x38, 0x85, 0x58,
	0x37, 0x22, 0x21, 0x68, 0xa2, 0x31, 0x68, 0x55,
	0x55, 0x81, 0x22, 0x22, 0xa8, 0x88, 0x88, 0x68,
	0x86, 0x88, 0x68, 0x81, 0x36, 0x17, 0x21, 0x68,
	0x86, 0x16, 0x66, 0x26, 0x66, 0x61, 0x36, 0x66,
	0x68, 0x88, 0x86, 0x27, 0x22, 0x28, 0x88, 0x88,
	0x17, 0x72, 0x2a, 0x66, 0xa2, 0x22, 0x36, 0x55,
	0x55, 0x58, 0x37, 0x3a, 0x16, 0x66, 0x66, 0x66,
	0x66, 0x18, 0x88, 0x67, 0x16, 0x12, 0x71, 0x68,
	0x81, 0x68, 0x61, 0x76, 0x66, 0x6a, 0x16, 0x66,
	0x88, 0x88, 0x86, 0x77, 0x22, 0x26, 0x88, 0x88,
	0x13, 0x37, 0x71, 0x66, 0xa2, 0x33, 0x2a, 0x85,
	0x55, 0x55, 0x17, 0x73, 0x16, 0x66, 0x66, 0x68,
	0x63, 0x88, 0x88, 0xa2, 0x66, 0xa2, 0xa6, 0x88,
	0x61, 0x68, 0x6a, 0x76, 0x66, 0x6a, 0x66, 0x6a
};

#endif

#else

extern unsigned char linux_logo_red[];
extern unsigned char linux_logo_green[];
extern unsigned char linux_logo_blue[];
extern unsigned char linux_logo[];
extern unsigned char linux_logo_bw[];
extern unsigned char linux_logo16[];

#endif
";
-------------------------------------------------------------

^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: Documentation/linu-logo-HOWTO.txt
  2003-05-13  9:20     ` Documentation/linu-logo-HOWTO.txt cosmos
  2003-05-13  9:57       ` Documentation/linu-logo-HOWTO.txt Geert Uytterhoeven
@ 2003-05-13 13:16       ` Alan Cox
  1 sibling, 0 replies; 32+ messages in thread
From: Alan Cox @ 2003-05-13 13:16 UTC (permalink / raw)
  To: cosmos; +Cc: Linux Kernel Mailing List

On Maw, 2003-05-13 at 10:20, cosmos wrote:
> Hi,
> i have written a doc for the hack of the bootup linux logo.The document
> contains the main program that produces the linux-logo.h header file and the
> aquired measurements for the WIDTH & HEIGHT for the fbcon.c file.
> Can this doc be included in the Documentation of the kernel.

I don't see why not, send it over


^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH] Early init for security modules
  2003-05-13  3:03 [PATCH] Early init for security modules Chris Wright
                   ` (14 preceding siblings ...)
  2003-05-13  3:15 ` Chris Wright
@ 2003-05-13 18:07 ` Sam Ravnborg
  15 siblings, 0 replies; 32+ messages in thread
From: Sam Ravnborg @ 2003-05-13 18:07 UTC (permalink / raw)
  To: linux-kernel, hch, gregkh, linux-security-module

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 = .;				\
+	}


^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH] Early init for security modules
  2003-05-13  3:10 ` Chris Wright
@ 2003-05-14  0:10   ` Greg Ungerer
  0 siblings, 0 replies; 32+ messages in thread
From: Greg Ungerer @ 2003-05-14  0:10 UTC (permalink / raw)
  To: Chris Wright; +Cc: linux-kernel, hch, gregkh, linux-security-module

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:  gerg@snapgear.com
SnapGear Pty Ltd                               PHONE:    +61 7 3435 2888
825 Stanley St,                                  FAX:    +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia              WEB:   www.SnapGear.com


^ permalink raw reply	[flat|nested] 32+ messages in thread

* Re: [PATCH] Early init for security modules
  2003-05-13  5:27       ` Christoph Hellwig
@ 2003-05-20  0:57         ` Chris Wright
  0 siblings, 0 replies; 32+ messages in thread
From: Chris Wright @ 2003-05-20  0:57 UTC (permalink / raw)
  To: Christoph Hellwig, Andi Kleen, linux-kernel, greg, linux-security-module

* Christoph Hellwig (hch@infradead.org) 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

^ permalink raw reply	[flat|nested] 32+ messages in thread

end of thread, other threads:[~2003-05-20  0:46 UTC | newest]

Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-13  3:03 [PATCH] Early init for security modules Chris Wright
2003-05-13  3:07 ` Chris Wright
2003-05-13  3:08 ` Chris Wright
2003-05-13  9:03   ` Russell King
2003-05-13  9:20     ` Documentation/linu-logo-HOWTO.txt cosmos
2003-05-13  9:57       ` Documentation/linu-logo-HOWTO.txt Geert Uytterhoeven
2003-05-13 11:25         ` Documentation/linux-logo-HOWTO.txt cosmos
2003-05-13 13:16       ` Documentation/linu-logo-HOWTO.txt Alan Cox
2003-05-13  3:08 ` [PATCH] Early init for security modules Chris Wright
2003-05-13  3:09 ` Chris Wright
2003-05-13  3:09 ` Chris Wright
2003-05-13  5:56   ` David Mosberger
2003-05-13  3:10 ` Chris Wright
2003-05-13  3:10 ` Chris Wright
2003-05-14  0:10   ` Greg Ungerer
2003-05-13  3:11 ` Chris Wright
2003-05-13  3:12 ` Chris Wright
2003-05-13  3:13 ` Chris Wright
2003-05-13  3:13 ` Chris Wright
2003-05-13  4:45   ` Paul Mackerras
2003-05-13  3:13 ` Chris Wright
2003-05-13  3:14 ` Chris Wright
2003-05-13  3:14 ` Chris Wright
2003-05-13  3:15 ` Chris Wright
2003-05-13  5:03   ` Andi Kleen
2003-05-13  5:20     ` Chris Wright
2003-05-13  5:27       ` Christoph Hellwig
2003-05-20  0:57         ` Chris Wright
2003-05-13  5:28       ` Andi Kleen
2003-05-13  6:16         ` Chris Wright
2003-05-13  6:29           ` Andi Kleen
2003-05-13 18:07 ` Sam Ravnborg

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).