* [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: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 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: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 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: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 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: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: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: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: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
* 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 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: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
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).