* 2.5.44-ac3 oops (usb related?)
From: Stefan Schwandter @ 2002-10-26 9:39 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 161 bytes --]
Hi!
reboot segfaults with 2.5.44-ac3 (and 2.5.44 vanilla). I've appended
ksymoops output (from -ac3).
regards, Stefan
--
----> http://www.shockfrosted.org
[-- Attachment #2: oops.txt --]
[-- Type: text/plain, Size: 4729 bytes --]
ksymoops 2.4.6 on i686 2.5.44-ac3. Options used
-V (default)
-k /proc/ksyms (default)
-l /proc/modules (default)
-o /lib/modules/2.5.44-ac3/ (default)
-m /boot/System.map-2.5.44-ac3 (default)
Warning: You did not tell me where to find symbol information. I will
assume that the log matches the kernel and modules that are running
right now and I'll use the default options above for symbol resolution.
If the current kernel and/or modules do not match the log, you can get
more accurate output by telling me the kernel version and where to find
map, modules, ksyms etc. ksymoops -h explains the options.
Oct 26 11:10:31 TK150122 kernel: Machine check exception polling timer started.
Oct 26 11:10:31 TK150122 kernel: WARNING: unexpected IO-APIC, please mail
Oct 26 11:10:31 TK150122 kernel: 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
Oct 26 11:30:26 TK150122 kernel: c0237335
Oct 26 11:30:26 TK150122 kernel: Oops: 0000
Oct 26 11:30:26 TK150122 kernel: CPU: 0
Oct 26 11:30:26 TK150122 kernel: EIP: 0060:[driver_detach+53/80] Not tainted
Oct 26 11:30:26 TK150122 kernel: EFLAGS: 00010246
Oct 26 11:30:26 TK150122 kernel: eax: 00000000 ebx: c523fcd0 ecx: c0430170 edx: 00000000
Oct 26 11:30:26 TK150122 kernel: esi: 00000000 edi: e08cea40 ebp: e08ba000 esp: de8cdf4c
Oct 26 11:30:26 TK150122 kernel: ds: 0068 es: 0068 ss: 0068
Oct 26 11:30:26 TK150122 kernel: Stack: e08ceaa0 e08cea40 e08ceaa4 c0237558 e08cea40 e08cea40 e08ceaa0 df185000
Oct 26 11:30:26 TK150122 kernel: c0237958 e08cea40 e08cea40 e08ba000 c02379fb e08cea40 fffffff0 e08bb453
Oct 26 11:30:26 TK150122 kernel: e08cea40 c011a2b7 fffffff0 e08ba000 df185000 bfffeda8 c0119510 e08ba000
Oct 26 11:30:26 TK150122 kernel: Call Trace:
Oct 26 11:30:26 TK150122 kernel: [<e08ceaa0>] usb_bus_type+0x0/0x80 [usbcore]
Oct 26 11:30:26 TK150122 kernel: [<e08cea40>] usb_generic_driver+0x0/0x60 [usbcore]
Oct 26 11:30:26 TK150122 kernel: [<e08ceaa4>] usb_bus_type+0x4/0x80 [usbcore]
Oct 26 11:30:26 TK150122 kernel: [<e08cea40>] usb_generic_driver+0x0/0x60 [usbcore]
Oct 26 11:30:26 TK150122 kernel: [<e08cea40>] usb_generic_driver+0x0/0x60 [usbcore]
Oct 26 11:30:26 TK150122 kernel: [<e08ceaa0>] usb_bus_type+0x0/0x80 [usbcore]
Oct 26 11:30:26 TK150122 kernel: [<e08cea40>] usb_generic_driver+0x0/0x60 [usbcore]
Oct 26 11:30:26 TK150122 kernel: [<e08cea40>] usb_generic_driver+0x0/0x60 [usbcore]
Oct 26 11:30:26 TK150122 kernel: [<e08cea40>] usb_generic_driver+0x0/0x60 [usbcore]
Oct 26 11:30:26 TK150122 kernel: [<e08bb453>] usb_exit+0x13/0x30 [usbcore]
Oct 26 11:30:26 TK150122 kernel: [<e08cea40>] usb_generic_driver+0x0/0x60 [usbcore]
Oct 26 11:30:26 TK150122 kernel: Code: 8b 32 8d 47 28 39 c2 75 d5 5b 5e 5f c3 8d b4 26 00 00 00 00
Using defaults from ksymoops -t elf32-i386 -a i386
>>ebx; c523fcd0 <_end+4d80518/203d78a8>
>>ecx; c0430170 <kbd_sysrq_xlate+30/80>
>>edi; e08cea40 <[ehci-hcd].data.end+1/1621>
>>ebp; e08ba000 <[usbcore]usb_create_driverfs_intf_files+30/40>
>>esp; de8cdf4c <_end+1e40e794/203d78a8>
Trace; e08ceaa0 <[ehci-hcd].data.end+61/1621>
Trace; e08cea40 <[ehci-hcd].data.end+1/1621>
Trace; e08ceaa4 <[ehci-hcd].data.end+65/1621>
Trace; e08cea40 <[ehci-hcd].data.end+1/1621>
Trace; e08cea40 <[ehci-hcd].data.end+1/1621>
Trace; e08ceaa0 <[ehci-hcd].data.end+61/1621>
Trace; e08cea40 <[ehci-hcd].data.end+1/1621>
Trace; e08cea40 <[ehci-hcd].data.end+1/1621>
Trace; e08cea40 <[ehci-hcd].data.end+1/1621>
Trace; e08bb453 <[usbcore]proc_bulk+1d3/220>
Trace; e08cea40 <[ehci-hcd].data.end+1/1621>
Code; 00000000 Before first symbol
00000000 <_EIP>:
Code; 00000000 Before first symbol
0: 8b 32 mov (%edx),%esi
Code; 00000002 Before first symbol
2: 8d 47 28 lea 0x28(%edi),%eax
Code; 00000005 Before first symbol
5: 39 c2 cmp %eax,%edx
Code; 00000007 Before first symbol
7: 75 d5 jne ffffffde <_EIP+0xffffffde>
Code; 00000009 Before first symbol
9: 5b pop %ebx
Code; 0000000a Before first symbol
a: 5e pop %esi
Code; 0000000b Before first symbol
b: 5f pop %edi
Code; 0000000c Before first symbol
c: c3 ret
Code; 0000000d Before first symbol
d: 8d b4 26 00 00 00 00 lea 0x0(%esi,1),%esi
Oct 26 11:32:46 TK150122 kernel: Machine check exception polling timer started.
Oct 26 11:32:46 TK150122 kernel: WARNING: unexpected IO-APIC, please mail
Oct 26 11:32:46 TK150122 kernel: 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
1 warning issued. Results may not be reliable.
^ permalink raw reply
* Re: usb-mount (hotplug + desktop hooks)
From: Oliver Neukum @ 2002-10-26 9:35 UTC (permalink / raw)
To: linux-hotplug
In-Reply-To: <marc-linux-hotplug-103558971618973@msgid-missing>
Am Samstag, 26. Oktober 2002 01:46 schrieb David Brownell:
> I happened across this the other day:
>
> http://users.actrix.co.nz/michael/usbmount.html
>
> Take hotplug, add scripts and "sudo", and the device
> appears magically on your desktop.
>
> Comments?
The obvious one. It's a race for the same reason usbd
was racy.
The hotplug invocation is not serialised for starters.
There are other problems as well.
It's a very useful hack for a PC, but it's not a generic
solution for a multiuser system.
Besides, it's not new. The same was done with devfsd
a long time ago, if that subsystem may be mentioned
here.
Regards
Oliver
-------------------------------------------------------
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
^ permalink raw reply
* Re: One for the Security Guru's
From: Rogier Wolff @ 2002-10-26 9:44 UTC (permalink / raw)
To: Henning P. Schmiedehausen; +Cc: linux-kernel
In-Reply-To: <ap8f36$8ge$1@forge.intermeta.de>
On Thu, Oct 24, 2002 at 09:38:46AM +0000, Henning P. Schmiedehausen wrote:
> Get the real thing. Checkpoint. PIX. But that's a little
> more expensive than "xxx firewall based on Linux".
PIX? Is that the one that breaks TCP/IP when an ACK is lost on
the side that the data is coming from?
Roger
--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* The Worlds Ecosystem is a stable system. Stable systems may experience *
* excursions from the stable situation. We are currently in such an *
* excursion: The stable situation does not include humans. ***************
^ permalink raw reply
* [RFC] [PATCH] 2.5.44 bootloader fix
From: Eric W. Biederman @ 2002-10-26 9:49 UTC (permalink / raw)
To: mingo; +Cc: linux-kernel
Ingo when you changed the gdt in arch/i386/boot/setup.S you broke
a number of bootloaders. And especially you broke code that is documented
in Documentation/i386/boot.txt to work.
code32_start:
A 32-bit flat-mode routine *jumped* to immediately after the
transition to protected mode, but before the kernel is
uncompressed. No segments, except CS, are set up; you should
set them up to KERNEL_DS (0x18) yourself.
After completing your hook, you should jump to the address
that was in this field before your boot loader overwrote it.
A number of bootloaders were affected, the only well known one was
loadlin.
The following patches fixes that problem by design.
1) It changes the interface from lgdt blah ljmp mov blah %ds blah to
lgdt blah mov blah %ds ljmp blah. Which means all information
about a gdt can be kept in a single file simplifying maintenance.
2) To make the code more straight forward to write, and look at
the SMP entry point is made a seperate code path from the boot up
entry point. They now only share code through subroutines.
This patch has been tested with loadlin this does fix the problem.
What I am proposing is an interface change. The only known bootloader
this does not fix is gujin and the fix of loading segments earlier is
trivial, and fully backwards compatible. The advantage of this patch
is that no future changes to the kernel's gdt will affect bootloaders.
Please take a look, and if you don't have any objections, apply.
Eric
boot/compressed/head.S | 32 ++++------
boot/compressed/misc.c | 3 -
boot/setup.S | 30 +++++++---
kernel/head.S | 146 ++++++++++++++++++++++++++++++-------------------
kernel/trampoline.S | 14 +---
5 files changed, 134 insertions, 91 deletions
diff -uNr linux-2.5.44/arch/i386/boot/compressed/head.S linux-2.5.44.loadlin-fix/arch/i386/boot/compressed/head.S
--- linux-2.5.44/arch/i386/boot/compressed/head.S Fri Oct 11 22:22:19 2002
+++ linux-2.5.44.loadlin-fix/arch/i386/boot/compressed/head.S Fri Oct 25 05:38:56 2002
@@ -28,22 +28,17 @@
.globl startup_32
+/*
+ * On entry, %esi points to the real-mode code as a 32-bit pointer.
+ * %ds, %es, %fs, %gs, %ss 32bit data segment base=0 mask=0xffffffff
+ */
startup_32:
cld
cli
- movl $(__KERNEL_DS),%eax
- movl %eax,%ds
- movl %eax,%es
- movl %eax,%fs
- movl %eax,%gs
-
- lss stack_start,%esp
- xorl %eax,%eax
-1: incl %eax # check that A20 really IS enabled
- movl %eax,0x000000 # loop forever if it isn't
- cmpl %eax,0x100000
- je 1b
-
+/*
+ * Setup the stack
+ */
+ movl stack_start, %esp
/*
* Initialize eflags. Some BIOS's leave bits like NT set. This would
* confuse the debugger if this code is traced.
@@ -73,8 +68,8 @@
jnz 3f
popl %esi # discard address
popl %esi # real mode pointer
- xorl %ebx,%ebx
- ljmp $(__KERNEL_CS), $0x100000
+ movl $0x100000, %ebp
+ jmpl *%ebp
/*
* We come here, if we were loaded high.
@@ -101,7 +96,8 @@
popl %eax # hcount
movl $0x100000,%edi
cli # make sure we don't get interrupted
- ljmp $(__KERNEL_CS), $0x1000 # and jump to the move routine
+ movl $0x1000, %ebp
+ jmpl *%ebp # and jump to the move routine
/*
* Routine (template) for moving the decompressed kernel in place,
@@ -123,6 +119,6 @@
rep
movsl
movl %ebx,%esi # Restore setup pointer
- xorl %ebx,%ebx
- ljmp $(__KERNEL_CS), $0x100000
+ movl $0x100000, %ebp
+ jmpl *%ebp
move_routine_end:
diff -uNr linux-2.5.44/arch/i386/boot/compressed/misc.c linux-2.5.44.loadlin-fix/arch/i386/boot/compressed/misc.c
--- linux-2.5.44/arch/i386/boot/compressed/misc.c Fri Oct 11 22:22:09 2002
+++ linux-2.5.44.loadlin-fix/arch/i386/boot/compressed/misc.c Fri Oct 25 04:36:22 2002
@@ -298,8 +298,7 @@
struct {
long * a;
- short b;
- } stack_start = { & user_stack [STACK_SIZE] , __KERNEL_DS };
+ } stack_start = { & user_stack [STACK_SIZE] };
static void setup_normal_output_buffer(void)
{
diff -uNr linux-2.5.44/arch/i386/boot/setup.S linux-2.5.44.loadlin-fix/arch/i386/boot/setup.S
--- linux-2.5.44/arch/i386/boot/setup.S Sat Oct 19 00:57:56 2002
+++ linux-2.5.44.loadlin-fix/arch/i386/boot/setup.S Fri Oct 25 05:29:10 2002
@@ -63,6 +63,10 @@
#define SIG1 0xAA55
#define SIG2 0x5A5A
+/* Segments used by setup.S */
+#define __SETUP_CS 0x10
+#define __SETUP_DS 0x18
+
INITSEG = DEF_INITSEG # 0x9000, we move boot here, out of the way
SYSSEG = DEF_SYSSEG # 0x1000, system loaded at 0x10000 (65536).
SETUPSEG = DEF_SETUPSEG # 0x9020, this is the current segment
@@ -842,11 +846,19 @@
jmp flush_instr
flush_instr:
- xorw %bx, %bx # Flag to indicate a boot
xorl %esi, %esi # Pointer to real-mode code
movw %cs, %si
subw $DELTA_INITSEG, %si
shll $4, %esi # Convert to 32-bit pointer
+
+# Setup the data segments
+ movw $__SETUP_DS, %ax
+ movw %ax, %ds
+ movw %ax, %es
+ movw %ax, %fs
+ movw %ax, %gs
+ movw %ax, %ss
+
# NOTE: For high loaded big kernels we need a
# jmpi 0x100000,__KERNEL_CS
#
@@ -859,7 +871,7 @@
.byte 0x66, 0xea # prefix + jmpi-opcode
code32: .long 0x1000 # will be set to 0x100000
# for big kernels
- .word __KERNEL_CS
+ .word __SETUP_CS
# Here's a bunch of information about your current kernel..
kernel_version: .ascii UTS_RELEASE
@@ -1053,13 +1065,13 @@
# Descriptor tables
#
-# NOTE: if you think the GDT is large, you can make it smaller by just
-# defining the KERNEL_CS and KERNEL_DS entries and shifting the gdt
-# address down by GDT_ENTRY_KERNEL_CS*8. This puts bogus entries into
-# the GDT, but those wont be used so it's not a problem.
+# NOTE: This descriptor table is completely seperate from the descriptor
+# table used by the kernel. The descriptor numbers it uses are well
+# known and some bootloaders break if you change these entries.
#
gdt:
- .fill GDT_ENTRY_KERNEL_CS,8,0
+ .word 0, 0, 0, 0 # dummy
+ .word 0, 0, 0, 0 # unused
.word 0xFFFF # 4Gb - (0x100000*0x1000 = 4Gb)
.word 0 # base address = 0
@@ -1072,11 +1084,13 @@
.word 0x9200 # data read/write
.word 0x00CF # granularity = 4096, 386
# (+5th nibble of limit)
+gdt_end:
+
idt_48:
.word 0 # idt limit = 0
.word 0, 0 # idt base = 0L
gdt_48:
- .word GDT_ENTRY_KERNEL_CS*8 + 16 - 1 # gdt limit
+ .word gdt_end - gdt - 1 # gdt limit
.word 0, 0 # gdt base (filled in later)
diff -uNr linux-2.5.44/arch/i386/kernel/head.S linux-2.5.44.loadlin-fix/arch/i386/kernel/head.S
--- linux-2.5.44/arch/i386/kernel/head.S Fri Oct 11 22:21:31 2002
+++ linux-2.5.44.loadlin-fix/arch/i386/kernel/head.S Fri Oct 25 05:36:23 2002
@@ -40,45 +40,24 @@
* swapper_pg_dir is the main page directory, address 0x00101000
*
* On entry, %esi points to the real-mode code as a 32-bit pointer.
+ * %ds, %es, %ss, %fs, %gs 32bit data segment base=0 mask=0xffffffff
*/
-startup_32:
+ENTRY(startup_32)
+ cld
+ cli
/*
* Set segments to known values
*/
- cld
- movl $(__KERNEL_DS),%eax
+ lgdt gdt_48-__PAGE_OFFSET
+ ljmp $__KERNEL_CS,$1f-__PAGE_OFFSET
+1: movl $__KERNEL_DS, %eax
movl %eax,%ds
movl %eax,%es
movl %eax,%fs
movl %eax,%gs
-#ifdef CONFIG_SMP
- orw %bx,%bx
- jz 1f
+ movl %eax,%ss
/*
- * New page tables may be in 4Mbyte page mode and may
- * be using the global pages.
- *
- * NOTE! If we are on a 486 we may have no cr4 at all!
- * So we do not try to touch it unless we really have
- * some bits in it to set. This won't work if the BSP
- * implements cr4 but this AP does not -- very unlikely
- * but be warned! The same applies to the pse feature
- * if not equally supported. --macro
- *
- * NOTE! We have to correct for the fact that we're
- * not yet offset PAGE_OFFSET..
- */
-#define cr4_bits mmu_cr4_features-__PAGE_OFFSET
- cmpl $0,cr4_bits
- je 3f
- movl %cr4,%eax # Turn on paging options (PSE,PAE,..)
- orl cr4_bits,%eax
- movl %eax,%cr4
- jmp 3f
-1:
-#endif
-/*
* Initialize page tables
*/
movl $pg0-__PAGE_OFFSET,%edi /* initialize page tables */
@@ -106,15 +85,6 @@
/* Set up the stack pointer */
lss stack_start,%esp
-#ifdef CONFIG_SMP
- orw %bx,%bx
- jz 1f /* Initial CPU cleans BSS */
- pushl $0
- popfl
- jmp checkCPUtype
-1:
-#endif CONFIG_SMP
-
/*
* Clear BSS first so that there are no surprises...
* No need to cld as DF is already clear from cld above...
@@ -167,6 +137,85 @@
rep
movsl
1:
+ call checkCPUtype
+ call start_kernel
+L6:
+ hlt # main should never return here, but
+ jmp L6 # just in case, we know what happens.
+
+
+#ifdef CONFIG_SMP
+/*
+ * We enter here from trampoline.S
+ */
+ENTRY(secondary_startup_32)
+/*
+ * Set eflags to a safe state
+ */
+ cld
+ cli
+/*
+ * Set segmetns to known values
+ */
+ movl $__KERNEL_DS, %eax
+ movl %eax, %ds
+ movl %eax, %es
+ movl %eax, %fs
+ movl %eax, %gs
+ movl %eax, %ss
+
+/*
+ * New page tables may be in 4Mbyte page mode and may
+ * be using the global pages.
+ *
+ * NOTE! If we are on a 486 we may have no cr4 at all!
+ * So we do not try to touch it unless we really have
+ * some bits in it to set. This won't work if the BSP
+ * implements cr4 but this AP does not -- very unlikely
+ * but be warned! The same applies to the pse feature
+ * if not equally supported. --macro
+ *
+ * NOTE! We have to correct for the fact that we're
+ * not yet offset PAGE_OFFSET..
+ */
+#define cr4_bits mmu_cr4_features-__PAGE_OFFSET
+ cmpl $0,cr4_bits
+ je 3f
+ movl %cr4,%eax # Turn on paging options (PSE,PAE,..)
+ orl cr4_bits,%eax
+ movl %eax,%cr4
+
+/*
+ * Enable paging
+ */
+3:
+ movl $swapper_pg_dir-__PAGE_OFFSET,%eax
+ movl %eax,%cr3 /* set the page table pointer.. */
+ movl %cr0,%eax
+ orl $0x80000000,%eax
+ movl %eax,%cr0 /* ..and set paging (PG) bit */
+ jmp 1f /* flush the prefetch-queue */
+1:
+ movl $1f,%eax
+ jmp *%eax /* make sure eip is relocated */
+1:
+ /* Set up the stack pointer */
+ lss stack_start,%esp
+/*
+ * Initialize eflags. Some BIOS's leave bits like NT set. This would
+ * confuse the debugger if this code is traced.
+ * XXX - best to initialize before switching to protected mode.
+ */
+ pushl $0
+ popfl
+
+ call checkCPUtype
+ call initialize_secondary
+L7: hlt # initialize_secondary should never return here, but
+ jmp L7 # just in case, we know what happens.
+
+#endif /* CONFIG_SMP */
+
checkCPUtype:
movl $-1,X86_CPUID # -1 for no CPUID initially
@@ -230,7 +279,6 @@
movl %eax,%cr0
call check_x87
- incb ready
lgdt cpu_gdt_descr
lidt idt_descr
ljmp $(__KERNEL_CS),$1f
@@ -243,21 +291,7 @@
xorl %eax,%eax
lldt %ax
cld # gcc2 wants the direction flag cleared at all times
-#ifdef CONFIG_SMP
- movb ready, %cl
- cmpb $1,%cl
- je 1f # the first CPU calls start_kernel
- # all other CPUs call initialize_secondary
- call initialize_secondary
- jmp L6
-1:
-#endif
- call start_kernel
-L6:
- jmp L6 # main should never return here, but
- # just in case, we know what happens.
-
-ready: .byte 0
+ ret
/*
* We depend on ET to be correct. This checks for 287/387.
@@ -356,6 +390,10 @@
.fill NR_CPUS-1,6,0 # space for the other GDT descriptors
+# boot GDT descriptor used before paging is enabled
+gdt_48:
+ .word GDT_ENTRIES*8-1 # gdt limit
+ .long cpu_gdt_table-__PAGE_OFFSET # gdt base
/*
* This is initialized to create an identity-mapping at 0-8M (for bootup
* purposes) and another mapping of the 0-8M area at virtual address
diff -uNr linux-2.5.44/arch/i386/kernel/trampoline.S linux-2.5.44.loadlin-fix/arch/i386/kernel/trampoline.S
--- linux-2.5.44/arch/i386/kernel/trampoline.S Fri Oct 11 22:21:41 2002
+++ linux-2.5.44.loadlin-fix/arch/i386/kernel/trampoline.S Fri Oct 25 04:49:31 2002
@@ -12,10 +12,6 @@
* In fact we don't actually need a stack so we don't
* set one up.
*
- * We jump into the boot/compressed/head.S code. So you'd
- * better be running a compressed kernel image or you
- * won't get very far.
- *
* On entry to trampoline_data, the processor is in real mode
* with 16-bit addressing and 16-bit data. CS has some value
* and IP is zero. Thus, data addresses need to be absolute
@@ -23,12 +19,13 @@
*
* If you work on this file, check the object module with objdump
* --full-contents --reloc to make sure there are no relocation
- * entries except for the gdt one..
+ * entries except for the gdt one, and secondary_startup_32..
*/
#include <linux/linkage.h>
#include <asm/segment.h>
#include <asm/page.h>
+#include <asm/desc.h>
.data
@@ -40,7 +37,6 @@
mov %cs, %ax # Code and data in the same place
mov %ax, %ds
- mov $1, %bx # Flag an SMP trampoline
cli # We should be safe anyway
movl $0xA5A5A5A5, trampoline_data - r_base
@@ -54,8 +50,8 @@
lmsw %ax # into protected mode
jmp flush_instr
flush_instr:
- ljmpl $__KERNEL_CS, $0x00100000
- # jump to startup_32 in arch/i386/kernel/head.S
+ ljmpl $__KERNEL_CS, $(secondary_startup_32 - __PAGE_OFFSET)
+ # jump to secondary_startup_32 in arch/i386/kernel/head.S
idt_48:
.word 0 # idt limit = 0
@@ -67,7 +63,7 @@
#
gdt_48:
- .word 0x0800 # gdt limit = 2048, 256 GDT entries
+ .word GDT_ENTRIES*8-1 # gdt limit
.long cpu_gdt_table-__PAGE_OFFSET # gdt base = gdt (first SMP CPU)
.globl trampoline_end
^ permalink raw reply
* Re: undefined sqrt()
From: Ruslan U. Zakirov @ 2002-10-26 10:07 UTC (permalink / raw)
To: linux-c-programming
TSS> Glynn,
TSS> Thanks for the explanation. I understand now. After getting your explanation, I did a bit of web browsing to try to find a page that tells me what libraries I need for which header files, but
TSS> I haven't been too successful. Do you know of a URL where I could find that info?
TSS> Thanks,
TSS> Sean
Hello!
There are two sections in man sqrt.
1) Library: In this section described which library you must link with
your program.
2) Sinopsis: Here specified file where you can find prototype of
function. This file(s) you must include in your project.
Good luck.
_______________________________________________________________________
Sorry for my English.
^ permalink raw reply
* Re: Posix capabilities
From: Pavel Machek @ 2002-10-20 14:16 UTC (permalink / raw)
To: Theodore Ts'o, linux-kernel
In-Reply-To: <20021017122056.GB13573@think.thunk.org>
Hi!
> > Ah, ok... I thought that things work like this: the capabilities support
> > already is in the kernel, and to give an app a particular capability,
> > one has to add a particalar extended attribute to the application
> > executable. So I'm wrong here it seems?
>
> First of all, you can't use a standard user extended attribute, since
> anyone with write access to the file will be allowed to set the
> extended attribute. This isn't good if you're going to be granting
What are extended attributes good for, then?
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
^ permalink raw reply
* Re: Linux Security Protection System
From: Pavel Machek @ 2002-10-20 14:14 UTC (permalink / raw)
To: Bosko Radivojevic; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.44.0210161607590.28724-100000@falcon.etf.bg.ac.yu>
Hi!
> Filesystem Access Domain subsystem allows restriction of accessible
> filesystem parts for both individual users and programs. Now you can
> restrict user activities to only its home, mailbox etc. Filesystem Access
> Domains works on device, dir and individual file granularity.
>
> IP Labeling lists enable restriction on allowed network connections on per
> program basis. From now on, you may configure your policy so that no one
> except your favorite MTA can connect to remote port 25
How do you handle ptrace()? Per-program security seems -- quite
strange to me. Either you completely disallow ptrace(), or I can not
seee how per-program security can be usefull...
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
^ permalink raw reply
* Clean up nbd.c
From: Pavel Machek @ 2002-10-21 9:52 UTC (permalink / raw)
To: Rusty trivial patch monkey Russell, kernel list
Hi!
I've never seen any of those errors, so I guess its okay to convert
them to BUG_ONs. It makes code look better [I'm nbd
maintainer, and approve it ;-)]. Please apply,
Pavel
--- clean/drivers/block/nbd.c 2002-10-20 16:22:38.000000000 +0200
+++ linux/drivers/block/nbd.c 2002-10-20 18:25:41.000000000 +0200
@@ -65,10 +65,8 @@
/* #define DEBUG( s ) printk( s )
*/
-#ifdef PARANOIA
static int requests_in;
static int requests_out;
-#endif
static int nbd_open(struct inode *inode, struct file *file)
{
@@ -261,18 +259,8 @@
printk(KERN_ALERT "req should never be null\n" );
goto out;
}
-#ifdef PARANOIA
- if (lo != req->rq_disk->private_data) {
- printk(KERN_ALERT "NBD: request corrupted!\n");
- continue;
- }
- if (lo->magic != LO_MAGIC) {
- printk(KERN_ALERT "NBD: nbd_dev[] corrupted: Not enough magic\n");
- goto out;
- }
-#endif
+ BUG_ON(lo->magic != LO_MAGIC);
nbd_end_request(req);
-
}
out:
return;
@@ -282,12 +270,7 @@
{
struct request *req;
-#ifdef PARANOIA
- if (lo->magic != LO_MAGIC) {
- printk(KERN_ERR "NBD: nbd_dev[] corrupted: Not enough magic when clearing!\n");
- return;
- }
-#endif
+ BUG_ON(lo->magic != LO_MAGIC);
do {
req = NULL;
@@ -333,11 +316,9 @@
if (lo->flags & NBD_READ_ONLY)
FAIL("Write on read-only");
}
-#ifdef PARANOIA
- if (lo->magic != LO_MAGIC)
- FAIL("nbd[] is not magical!");
+ BUG_ON(lo->magic != LO_MAGIC);
requests_in++;
-#endif
+
req->errors = 0;
blkdev_dequeue_request(req);
spin_unlock_irq(q->queue_lock);
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
^ permalink raw reply
* Re: [PATCH] pre-decoded wchan output
From: Pavel Machek @ 2002-10-21 23:08 UTC (permalink / raw)
To: Robert Love; +Cc: Christoph Hellwig, torvalds, linux-kernel, riel
In-Reply-To: <1034885077.718.595.camel@phantasy>
Hi!
> > Can't you just left the old, nuerical one in even if CONFIG_KALLSYMS
> > ise set? One ifdef less and far less surprises..
>
> But why? Save the call to get_wchan()...
Yes, and force users to update procps for no good reason. And "new"
procps will still need code to deal with get_wchan themselves... Plus
you loose information by killing get_wchan() -- two different wait
points in one function seems very possible to me.
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
^ permalink raw reply
* Re: [PATCH 2/2] High-res-timers part 2 (x86 platform code) take 6
From: Pavel Machek @ 2002-10-23 9:38 UTC (permalink / raw)
To: george anzinger; +Cc: Linus Torvalds, linux-kernel@vger.kernel.org
In-Reply-To: <3DAFB303.4543C579@mvista.com>
Hi!
> This patch, in conjunction with the "core" high-res-timers
> patch implements high resolution timers on the i386
> platforms. The high-res-timers use the periodic interrupt
> to "remind" the system to look at the clock. The clock
This scares me:
+#define fail_message \
+"High-res-timers:
>-<--><-->-<-->-<-->-<--><-->-<-->-<-->-<-->-<-->-<-->-<-->-<\n"\
+"High-res-timers: >Failed to find the ACPI pm timer
<\n"\
+"High-res-timers: >-<--><-->-<-->-<-->-<-->Boot will fail in
Calibrate Delay <\n"\
+"High-res-timers: >Supply a valid default pm timer address
<\n"\
+"High-res-timers: >or get your BIOS to turn on ACPI support.
<\n"\
+"High-res-timers: >See CONFIGURE help for more information.
<\n"\
+"High-res-timers:
>-<--><-->-<-->-<-->-<--><-->-<-->-<-->-<-->-<-->-<-->-<-->-<\n"
Does that mean our boot has now so much junk in it that we start
adding ascii art for "important" messages?
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
^ permalink raw reply
* Re: [PATCH] fixes for building kernel using Intel compiler
From: Pavel Machek @ 2002-10-21 9:21 UTC (permalink / raw)
To: Andi Kleen
Cc: Nakajima, Jun, David S. Miller, torvalds, linux-kernel,
Mallick, Asit K, Saxena, Sunil
In-Reply-To: <20021019042929.A18070@wotan.suse.de>
Hi!
> BTW do you have any benchmark / code size results to share with
> Intel compiler vs gcc 3.2 ? How much does it give ?
Also does it work properly after compiling with icc? Working well with
second compiler would be pretty good news for both kernel and icc...
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
^ permalink raw reply
* Re: Posix capabilities
From: Pavel Machek @ 2002-10-20 14:18 UTC (permalink / raw)
To: Neil Schemenauer; +Cc: swan, linux-kernel
In-Reply-To: <20021017204317.GA4286@glacier.arctrix.com>
Hi!
> See my "capwrap" module:
>
> http://arctrix.com/nas/linux/capwrap.tar.gz
>
> To allow SCHED_FIFO you would need to give the process the CAP_SYS_NICE
> capability. CAP_SYS_NICE is bit 23 (800000 in hex). Create a text file
> with the following line and make it root suid:
>
> &/usr/bin/someprogram 800000
>
> If the capwrap module is loaded the kernel will recognize the file as a
> "capability wrapper" and grant the specified capabilities to the
> executable while running with the uid of the current user.
>
> The capwrap module isn't fancy but is works and is simple. It doesn't
> require any special filesystem. Since I'm no kernel hacker I don't know
> if it's suitable for inclusion in the main tree. I would appreciate any
> comments people have regarding it.
I did similar thing using elf .note section... But this seems elegant
too. Perhaps you want to push it for inclusion?
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
^ permalink raw reply
* Re: kexec for 2.5.44 (Who do I send this to?)
From: Pavel Machek @ 2002-10-20 19:09 UTC (permalink / raw)
To: Eric W. Biederman
Cc: linux-kernel, Suparna Bhattacharya, Petr Vandrovec, fastboot,
Werner Almesberger
In-Reply-To: <m1y98uyc1a.fsf@frodo.biederman.org>
Hi!
> The kexec code has gone through a fairly decent review, and all known bugs
> are resolved. There are still BIOS's that don't work after you have
> run a kernel but that is an entirely different problem.
Looks good... Few comments follow.
> @@ -1128,6 +1159,26 @@
> printk (KERN_INFO "APIC error on CPU%d: %02lx(%02lx)\n",
> smp_processor_id(), v , v1);
> irq_exit();
> +}
> +
> +void stop_apics(void)
> +{
> + /* By resetting the APIC's we disable the nmi watchdog */
> +#if CONFIG_SMP
> + /*
> + * Stop all CPUs and turn off local APICs and the IO-APIC, so
> + * other OSs see a clean IRQ state.
> + */
> + smp_send_stop();
> +#else
> + disable_local_APIC();
> +#endif
> +#if defined(CONFIG_X86_IO_APIC)
> + if (smp_found_config) {
> + disable_IO_APIC();
> + }
> +#endif
> + disconnect_bsp_APIC();
> }
>
Perhaps this should be done using driverfs callbacks?
> --- linux-2.5.44/arch/i386/kernel/i8259.c Fri Oct 11 22:22:19 2002
> +++ linux-2.5.44.x86kexec/arch/i386/kernel/i8259.c Sat Oct 19 01:04:36 2002
> @@ -246,10 +246,34 @@
> return 0;
> }
>
> +static void i8259A_remove(struct device *dev)
> +{
> + /* Restore the i8259A to it's legacy dos setup.
> + * The kernel won't be using it any more, and it
> + * just might make reboots, and kexec type applications
> + * more stable.
> + */
> + outb(0xff, 0x21); /* mask all of 8259A-1 */
> + outb(0xff, 0xA1); /* mask all of 8259A-1 */
> +
> + outb_p(0x11, 0x20); /* ICW1: select 8259A-1 init */
> + outb_p(0x08, 0x21); /* ICW2: 8259A-1 IR0-7 mappend to 0x8-0xf */
> + outb_p(0x01, 0x21); /* Normal 8086 auto EOI mode */
> +
> + outb_p(0x11, 0xA0); /* ICW1: select 8259A-2 init */
> + outb_p(0x08, 0xA1); /* ICW2: 8259A-2 IR0-7 mappend to 0x70-0x77 */
> + outb_p(0x01, 0xA1); /* Normal 8086 auto EOI mode */
> +
> + udelay(100); /* wait for 8259A to initialize */
> +
> + /* Should I unmask interrupts here? */
> +}
> +
> static struct device_driver i8259A_driver = {
> .name = "pic",
> .bus = &system_bus_type,
> .resume = i8259A_resume,
> + .remove = i8259A_remove,
> };
>
Here you did it right.
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
^ permalink raw reply
* Re: [PATCH] linux-2.5.43_vsyscall_A0
From: Pavel Machek @ 2002-10-24 11:24 UTC (permalink / raw)
To: Andi Kleen
Cc: Jeff Dike, john stultz, Linus Torvalds, andrea, lkml,
george anzinger, Stephen Hemminger
In-Reply-To: <20021019031002.GA16404@averell>
Hi!
> > > Since no one really brought up any issues with the code itself
> > > (correct me if I'm wrong), here is the i386 vsyscall gettimeofday port
> > > I sent last night, synced up and ready for integration.
> >
> > This vsyscall implementation breaks UML. Any app that's run inside UML
> > that uses vsyscalls will get the host's vsyscalls rather than the UML
> > vsyscalls.
>
> Ugh.
>
> Guess you'll have some problems then with UML on x86-64, which always uses
> vgettimeofday. But it's only used for gettimeofday() currently, perhaps it's
> not that bad when the UML child runs with the host's time.
Well, if you want to use UML for time shifting (pretty common use,
AFAICS)...
> I guess it would be possible to add some support for UML
> to map own code over the vsyscall reserved locations. UML would need
> to use the syscalls then. But it'll be likely ugly.
I guess this is the right solution. [Or UML could simply unmap that
area and handle the faults...].
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
^ permalink raw reply
* Re: [PATCH] linux-2.5.43_vsyscall_A0
From: Pavel Machek @ 2002-10-24 11:24 UTC (permalink / raw)
To: Jeff Dike
Cc: Andi Kleen, john stultz, Linus Torvalds, andrea, lkml,
george anzinger, Stephen Hemminger
In-Reply-To: <200210190450.XAA06161@ccure.karaya.com>
Hi!
> > Guess you'll have some problems then with UML on x86-64, which always
> > uses vgettimeofday. But it's only used for gettimeofday() currently,
> > perhaps it's not that bad when the UML child runs with the host's
> > time.
>
> It's not horrible, but it's still broken. There are people who depend
> on UML being able to keep its own time separately from the host.
>
> > I guess it would be possible to add some support for UML to map own
> > code over the vsyscall reserved locations. UML would need to use the
> > syscalls then. But it'll be likely ugly.
>
> Yeah, it would be.
>
> My preferred solution would be for libc to ask the kernel where the vsyscall
> area is. That's reasonably clean and virtualizable. Andrea doesn't like it
> because it adds a few instructions to the vsyscall address calculation.
But sandboxed application could still "guess" where vsyscall address
is and get the data it is not supposed to get, right?
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
^ permalink raw reply
* Re: Bug: swsusp in 2.5.42: "Scheduling while atomic"
From: Pavel Machek @ 2002-10-23 9:05 UTC (permalink / raw)
To: Hu Gang; +Cc: EricAltendorf, Linux Kernel
In-Reply-To: <20021018092521.3180fd42.hugang@soulinfo.com>
Hi!
> |[1.] One line summary of the problem:
> |
> |Scheduling while atomic debug message during swsusp
> |
> |[2.] Full description of the problem/report:
> |
> |While swsusp'ing to disk, vast quantities of error messages are echoed to the
> |console, along the lines of the following pulled from /var/log/messages:
>
> This Problem is net lay resume recall problem. Try this patch, From
> |my test it can works in net card device, but it can not work in
> |sound card device.
With this and CONFIG_PREEMPT on, do you see any "scheduling while
atomic" messages? I do not think this can fix them completely...
Pavel
> -------------------------
> --- linus-2.5/kernel/suspend.c Fri Oct 18 09:22:36 2002
> +++ linus-2.5-suspend/kernel/suspend.c Thu Oct 17 20:42:08 2002
> @@ -627,7 +627,7 @@
> /* Make disk drivers accept operations, again */
> static void drivers_unsuspend(void)
> {
> - device_resume(RESUME_RESTORE_STATE);
> + /* device_resume(RESUME_RESTORE_STATE); */
> device_resume(RESUME_ENABLE);
> }
>
> @@ -655,7 +655,7 @@
> static void drivers_resume(int flags)
> {
> if (flags & RESUME_PHASE1) {
> - device_resume(RESUME_RESTORE_STATE);
> + /* device_resume(RESUME_RESTORE_STATE); */
> device_resume(RESUME_ENABLE);
> }
> if (flags & RESUME_PHASE2) {
>
>
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
^ permalink raw reply
* Re: APM work around for bad bios.
From: Pavel Machek @ 2002-10-21 9:08 UTC (permalink / raw)
To: Hiroshi Miura; +Cc: sfr, linux-kernel
In-Reply-To: <20021017172155.BCA3F11782A@triton2>
Hi!
> I use CASIO CASSIOPEIA FIVA 101 and 103. (http://www.da-cha.org/fiva/fiva.html)
> this use Cyrix MediaGX and Award BIOS.
> This APM BIOS report broken value for dseg_len.
> it asumes granularity is 1.
>
> I made a work around for this situation.
>
> * if (cseg_len < bios.offset) BIOS report BAD len value.
> -- segment length must be always larger than code offset
>
> * if (dseg_len <= 0x40 ) BIOS asumes granularity =1.
> -- 0x40 * 4kB = 64kB, my pc reports 0x40.
>
>
> diff -urB -x .config -x '*.[oasS]' -x '*.in' -x '*.rej' -x '*.orig' linux-2.5.43-orig/arch/i386/kernel/apm.c linux-2.5.43/arch/i386/kernel/apm.c
> --- linux-2.5.43-orig/arch/i386/kernel/apm.c 2002-10-12 13:21:05.000000000 +0900
> +++ linux-2.5.43/arch/i386/kernel/apm.c 2002-10-14 21:36:14.000000000 +0900
> @@ -1980,6 +2141,14 @@
> (apm_info.bios.cseg_16_len - 1) & 0xffff);
> _set_limit((char *)&cpu_gdt_table[i][APM_DS >> 3],
> (apm_info.bios.dseg_len - 1) & 0xffff);
> + /* workaround for broken BIOSes */
> + if (apm_info.bios.cseg_len <= apm_info.bios.offset)
> + _set_limit((char *)&cpu_gdt_table[i][APM_CS >> 3], 64 * 1024 -1);
Maybe add printk KERN_WARNING "apm: broken bios -- code segment too
short, assuming 64k"
> + if (apm_info.bios.dseg_len <= 0x40) { /* 0x40 * 4kB == 64kB */
> + /* for the BIOS that assumes granularity = 1 */
> + cpu_gdt_table[i][APM_DS >> 3].b |= 0x800000;
> + printk(KERN_NOTICE "apm: we set the
> granularity of dseg.\n");
Maybe better KERN_WARNING "apm: broken bios -- assuming granularity 1
on dseg"
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
^ permalink raw reply
* Re: [patch] thread-aware coredumps, 2.5.43-C3
From: Pavel Machek @ 2002-10-21 15:17 UTC (permalink / raw)
To: Mark Gross
Cc: Andi Kleen, Ingo Molnar, Alexander Viro, S Vamsikrishna,
Ulrich Drepper, linux-kernel, NPT library mailing list
In-Reply-To: <200210171958.23198.markgross@thegnar.org>
Hi!
> > I want the x86 CPU error code, which often has interesting clues on the
> > problem. trapno would be useful too. I suspect other CPUs have similar
> > extended state for exceptions.
> >
> > I usually hack my kernel to printk() it, but having it in the coredump
> > would be more general and you can look at it later.
> >
> > Eventually (in a future kernel) I would love to have the exception
> > handler save the last branch debugging registers of the CPU and the let the
> > core dumper put that into the dump too. Then you could easily
> > figure out what the program did shortly before the crash.
> >
> > -Andi
>
> Having the last branch before a crash would be cool. Its easy to
> add note
How do you get that info in the first place? I do not think CPU stores
info about last branch it did...
Pavel
--
Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?
^ permalink raw reply
* Re: One for the Security Guru's
From: Rogier Wolff @ 2002-10-26 10:38 UTC (permalink / raw)
To: Stephen Satchell, hps, linux-kernel
In-Reply-To: <20021025134723.GZ15886@ns>
On Fri, Oct 25, 2002 at 09:47:23AM -0400, Stephen Frost wrote:
> Eh, it depends on how you look at it, but... The cisco includes support
> for checking out high-level protocols, such as HTTP. Basically you can
So, your PIX is looking at the HTTP requests, and it is validating
them. Fine. Now what is the largest HTTP request that you're going
to allow? 1k? 10k? 100k?
The PIX is NOT filtering the size of the HTTP request. It will happily
allow a multimegabyte request to come through. Is that exploiting a bug
in your http server? You don't know. And the PIX doesn't help.
When I encountered a PIX, multimegabyte HTTP requests were valid, and
the PIX screwed them up. A slight thinko on the side of the PIX
programmers.
The PIX HTTP filtering may give you some extra controls (I hear you can
do URL based filtering.... Wow!). Don't you have that control on your
webserver?
Roger.
--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* The Worlds Ecosystem is a stable system. Stable systems may experience *
* excursions from the stable situation. We are currently in such an *
* excursion: The stable situation does not include humans. ***************
^ permalink raw reply
* OT Re: One for the Security Guru's
From: Rogier Wolff @ 2002-10-26 10:40 UTC (permalink / raw)
To: Henning P. Schmiedehausen; +Cc: linux-kernel
In-Reply-To: <ap8fjq$8ia$1@forge.intermeta.de>
On Thu, Oct 24, 2002 at 09:47:38AM +0000, Henning P. Schmiedehausen wrote:
> James Stevenson <james@stev.org> writes:
>
> >can read / write disks. Thus you could recompile your own kernel
>
> Don't put a compiler on the box.
Don't you have a compiler at home? I do.
Roger.
--
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
* The Worlds Ecosystem is a stable system. Stable systems may experience *
* excursions from the stable situation. We are currently in such an *
* excursion: The stable situation does not include humans. ***************
^ permalink raw reply
* Re: rmap for 2.4.19-strict-vm-overcommit?
From: Amit Shah @ 2002-10-26 10:35 UTC (permalink / raw)
To: Rik van Riel; +Cc: linux-mm
In-Reply-To: <Pine.LNX.4.44L.0210251349570.1995-100000@imladris.surriel.com>
Hi Ric,
On Fri, 25 Oct 2002 13:50:15 -0200 (BRST)
Rik van Riel <riel@conectiva.com.br> wrote:
RVR> On Fri, 25 Oct 2002, Amit Shah wrote:
RVR>
RVR> > Is there an rmap patch for 2.4.19-strict-vm-overcommit?
RVR>
RVR> The combination of rmap and strict overcommit is in -ac
I would've liked if I got a separate patch that I could apply against my
2.4.19-overcommit.
Also: any indications that overcommit and/or rmap might be included in the
standard 2.4 kernel?
---
If you don't strike oil in twenty minutes, stop boring.
Amit Shah
http://amitshah.nav.to/
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/
^ permalink raw reply
* Re: a-linux: Kernel panic: No init found
From: Konstantin Boldyshev @ 2002-10-26 10:36 UTC (permalink / raw)
To: Darius Stout; +Cc: linux-assembly
In-Reply-To: <20021024182717.63201.qmail@web40207.mail.yahoo.com>
On Thu, 24 Oct 2002, Darius Stout wrote:
> ../bootdisk.bash a-linux.img /home/download1/alinux/asmutils-0.17 /mnt
> > new_boot.img
I guess that you are doing something very wrong here.
First, you need kernel binary.
Then, you need to compile asmutils.
In the end, to generate bootdisk, something like:
./bootdisk.bash bzImage /home/download/alinux/asmutils-0.17/src /mnt >boot.img
--
Regards,
Konstantin
^ permalink raw reply
* Re: One for the Security Guru's
From: Henning P. Schmiedehausen @ 2002-10-26 10:43 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <apcaub$ov5$1@cesium.transmeta.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
>Followup to: <1035539042.23977.24.camel@forge>
>By author: Henning Schmiedehausen <hps@intermeta.de>
>In newsgroup: linux.dev.kernel
>> >
>> > A. If there's a buffer overflow in the SSL Accelerator box the firewall
>> > wont do you much good (it helps, but only a little).
>>
>> This is a hardware device. Hardware as in "silicon". I very much doubt
>> that you can run "general purpose programs" on a device specifically
>> designed to do crypto. And this is _not_ just an "embedded Linux on ix86
>> with a crypto chip".
>>
>Hardware devices have bugs, too. Furthermore, most devices marketed
>as "hardware" still have programmable stuff underneath. Trust me.
Of course they have. I'm not that dumb. :-) I won't expect any piece
of silicon speak http, snmp and have configureable ip adresses without
any programming. I do had my share of Cisco router fun.... :-)
But my point is, that these beasts normally don't run a general
purpose operating system and that they're much less prone to buffer
overflow or similar attacks, simply because they don't use popular
software with known bugs (e.g. OpenSSL) or these functions (like
doing crypto) are in hardware.
If you have a processor that sets up an ASIC to do "insert https here,
use this key, remove http there", you might be able to attack the IP
stack running on the processor which gets the packets from the wire
and puts them back onto the wire. But you won't be able to trick any
bug or overflow in the crypto routines into opening a root shell on
the ASIC. :-)
Especially if there is no such thing as a /bin/sh binary on the
bugger. And even if you _do_; you still only have a shell on the
accelerator. Not on the application server.
If you ask me "how can you trust such a device if you can't look at
the source; well, I don't have to. I can tell the customer "this
device has been approved by <insert your certification authority here>
and you pay gobs of cash for simply having this certified device".
Replace "device" with "certificate" and you have the same thing as
getting your web server key certification from Verisign or Thawte.
You pay money and get a "trusted device".
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
^ permalink raw reply
* Re: Major Bug in Alsa 0.9 for over 1 year
From: karsten wiese @ 2002-10-26 10:37 UTC (permalink / raw)
To: Clemens Ladisch; +Cc: kreuzritter2000, alsa-devel
In-Reply-To: <Pine.HPX.4.33n.0210251450120.5597-100000@studcom.urz.uni-halle.de>
--- Clemens Ladisch <clemens@ladisch.de> schrieb: >
Karsten Wiese wrote:
> > > insmod snd-cs4232
> > > Using
> /lib/modules/2.4.19/kernel/sound/isa/cs423x/snd-cs4232.o
> > >
> /lib/modules/2.4.19/kernel/sound/isa/cs423x/snd-cs4232.o:
> > > unresolved symbol
> > > snd_card_new_R506deba1
> >
> > the "_R506deba1" makes me think snd-cs4232.o is
> compiled with module
> > versionnumbers
> > and the module, snd_card_new lives in, haS been made
> without module version
> > numbers.
>
> No, that's caused by using insmod. Using modprobe instead
> ensures that all
> required modules are loaded.
right, but none the less the "_R506deba1" in
"snd_card_new_R506deba1" means the requesting module needs
"version information on module symbols". if the use of
"version information on module symbols" is not consistent
across kernel & modules, this message can occure.
karsten
__________________________________________________________________
Gesendet von Yahoo! Mail - http://mail.yahoo.de
Möchten Sie mit einem Gruß antworten? http://grusskarten.yahoo.de
-------------------------------------------------------
This SF.net email is sponsored by: ApacheCon, November 18-21 in
Las Vegas (supported by COMDEX), the only Apache event to be
fully supported by the ASF. http://www.apachecon.com
^ permalink raw reply
* Re: One for the Security Guru's
From: Henning P. Schmiedehausen @ 2002-10-26 10:46 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <20021026114452.B16359@bitwizard.nl>
Rogier Wolff <R.E.Wolff@BitWizard.nl> writes:
>On Thu, Oct 24, 2002 at 09:38:46AM +0000, Henning P. Schmiedehausen wrote:
>> Get the real thing. Checkpoint. PIX. But that's a little
>> more expensive than "xxx firewall based on Linux".
>PIX? Is that the one that breaks TCP/IP when an ACK is lost on
>the side that the data is coming from?
Depends on your PIX OS. As with any other OS, there are bugs and you
should monitor the vendor mailing lists for updates and fixes.
It did broke SACK once. There was an update and the problem was
solved. Thats what a vendor is for.
Regards
Henning
What did you think? That I fall bait to this troll? :-)
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH hps@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 info@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.