Re: Panic on ZFS startup after crash
On Mon, Jul 21, 2008 at 06:18:10PM -0300, Nenhum_de_Nos wrote: The ZFS code in 7.0 is the same as in HEAD, so no worries. I'm trying zfs myself in a small enviroment at home, but for that I do follow 7-STABLE. there's no need to do that, as based in the above statement ? There might be some small differences, but the patches I provide here will apply to 7.0-RELEASE, 7-STABLE and 8-CURRENT. -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! pgpXtFi29GDZt.pgp Description: PGP signature
Re: ACPI regression on recent 7.0-STABLE: HPET stops working
Quoting John Baldwin [EMAIL PROTECTED]: On Monday 21 July 2008 06:07:52 am Oleg V. Nauman wrote: Quoting Oleg V. Nauman [EMAIL PROTECTED]: Quoting Jeremy Chadwick [EMAIL PROTECTED]: On Sat, Jul 19, 2008 at 10:03:15AM +0300, Oleg V. Nauman wrote: It seems to be something was changed with ACPI support on 7.0-STABLE so my next system upgrade ended with ACPI HPET not working anymore on my ASUS A9Rp laptop. Here is the part of /var/log/dmesg.today dated July 13: FreeBSD 7.0-STABLE #65: Tue Jul 8 22:05:07 EEST 2008 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/oleg2 [..] acpi0: A M I OEMRSDT on motherboard acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21 acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 77f0 (3) failed Timecounter ACPI-safe frequency 3579545 Hz quality 850 acpi_timer0: 32-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 acpi_ec0: Embedded Controller: GPE 0x18 port 0x62,0x66 on acpi0 acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 900 Here is the fresh dmesg output info: FreeBSD 7.0-STABLE #66: Tue Jul 15 22:11:27 EEST 2008 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/oleg2 [..] acpi0: A M I OEMRSDT on motherboard acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21 acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 77f0 (3) failed Timecounter ACPI-safe frequency 3579545 Hz quality 850 acpi_timer0: 32-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 [..] acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 device_attach: acpi_hpet0 attach returned 12 And the part of actual sysctl kern.timecounter output: kern.timecounter.choice: TSC(800) ACPI-safe(850) i8254(0) dummy(-100) kern.timecounter.hardware: ACPI-safe Seems okay here: FreeBSD icarus.home.lan 7.0-STABLE FreeBSD 7.0-STABLE #0: Sat Jul 12 10:53:08 PDT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PDSMI_PLUS_amd64 amd64 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter i8254 frequency 1193182 Hz quality 0 Timecounter ACPI-fast frequency 3579545 Hz quality 1000 Timecounter HPET frequency 14318180 Hz quality 900 Timecounters tick every 1.000 msec kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) i8254(0) dummy(-100) kern.timecounter.hardware: ACPI-fast You sure you haven't upgraded your BIOS or something and forgot to re-enable HPET? No it was not upgraded.. Have no option to enable/disable HPET through BIOS settings though I was unclear a bit or so. There are no ACPI related settings in my laptop's BIOS. Well.. Backout 1.243.2.3 revision of /usr/src/sys/dev/acpica/acpi.c (committed to RELENG_7 at July 10 by jhb) fixes this issue for me: acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 900 kern.timecounter.choice: TSC(800) HPET(900) ACPI-safe(850) i8254(0) dummy(-100) kern.timecounter.hardware: HPET Hopefully it helps to understand what is went wrong there. Ok, so the attempt to allocate the resource is failing for some reason. Can you get output from 'devinfo -r' and 'devinfo -u'? Of course.. The kernel with 1.243.2.2 revision of /usr/src/sys/dev/acpica/acpi.c (so HPET working for me): devinfo -r output: nexus0 apic0 ram0 I/O memory addresses: 0x0-0x9efff 0x10-0x77fc npx0 acpi0 Interrupt request lines: 21 I/O ports: 0x10-0x1f 0x22-0x3f 0x63 0x65 0x67-0x6f 0x72-0x7f 0x80 0x84-0x86 0x88 0x8c-0x8e 0x90-0x9f 0xa2-0xbf 0xe0-0xef 0x250-0x25f 0x40b 0x480-0x4bf 0x4d0-0x4d1 0x4d6 0x500-0x53f 0x800-0x89f 0x900-0x90f 0x910-0x91f 0xc00-0xc01 0xc14 0xc50-0xc51 0xc52 0xc6c 0xc6f 0xcd4-0xcd5 0xcd6-0xcd7 0xcd8-0xcdf 0x4000-0x4004 0x4005-0x40ff I/O memory addresses: 0xc-0xc 0xe-0xf 0xe000-0xefff 0xfec0-0xfec00fff 0xfee0-0xfee00fff 0xfff8-0x cpu0 ACPI I/O ports: 0x814 0x815 coretemp0 p4tcc0 cpufreq0 pcib0 pci0 hostb0 pcib1 pci1 vgapci0 I/O ports: 0x9800-0x98ff I/O memory addresses: 0xc000-0xcfff 0xfe1f-0xfe1f
sleeping without queue ?
Hello! My attempt to build openoffice.org-3 seems to be hanging. Pressing Ctrl-T produces: load: 0.11 cmd: tcsh 79759 [sleeping without queue] 0.00u 0.00s 0% 0k (tcsh is used by OOo's build-script). What is this sleeping without queue state, and why is process in it for so long? This is an 4-CPU amd64 system with 4Gb of RAM. Only 16% of the swap is currently in use and the box seems to be perfectly fine otherwise. Uptime is 55 days, two different X-sessions are functional... The kernel is FreeBSD 7.0-STABLE #0: Sat Mar 8 16:02:37. Thanks! -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sleeping without queue ?
Mikhail Teterin wrote: Hello! My attempt to build openoffice.org-3 seems to be hanging. Pressing Ctrl-T produces: load: 0.11 cmd: tcsh 79759 [sleeping without queue] 0.00u 0.00s 0% 0k (tcsh is used by OOo's build-script). What is this sleeping without queue state, and why is process in it for so long? This is an 4-CPU amd64 system with 4Gb of RAM. Only 16% of the swap is currently in use and the box seems to be perfectly fine otherwise. Uptime is 55 days, two different X-sessions are functional... The kernel is FreeBSD 7.0-STABLE #0: Sat Mar 8 16:02:37. Thanks! What is the process backtrace? Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.1 and BIND exploit
Brett Glass wrote: At 02:24 PM 7/21/2008, Kevin Oberman wrote: Don't forget that ANY server that caches data, including an end system running a caching only server is vulnerable. Actually, there is an exception to this. A forward only cache/resolver is only as vulnerable as its forwarder(s). This is a workaround for the vulnerability for folks who have systems that they cannot easily upgrade: point at a trusted forwarder that's patched. We're also looking at using dnscache from the djbdns package. I'm curious, is djbdns exploitable, too? Does it randomize the source ports of UDP queries? Of course, all solutions that randomize ports are really just security by obscurity, because by shuffling ports you're hiding the way to poison your cache... a little. True, but there is currently no better solution, AFAIK. The problem is inherent in the way DNS queries work. Best regards Oliver -- Oliver Fromme, secnetix GmbH Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd That's what I love about GUIs: They make simple tasks easier, and complex tasks impossible. -- John William Chambless ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.1 and BIND exploit
On Tue, Jul 22, 2008 at 05:52:42PM +0200, Oliver Fromme wrote: I'm curious, is djbdns exploitable, too? Does it randomize the source ports of UDP queries? Apparently, djbdns had randomization of the source ports a long time ago... Of course, all solutions that randomize ports are really just security by obscurity, because by shuffling ports you're hiding the way to poison your cache... a little. True, but there is currently no better solution, AFAIK. The problem is inherent in the way DNS queries work. Yes indeed. If I understand all this correctly, it's because the transaction ID that has to be sent back is only 2 bytes long, and if the query port doesn't change as well with every query, that can be cracked in milliseconds: sending 65536 DNS queries to a constant port is just way too easy! The namespace is way too small, and there's no way to fix this by switching to, say, 4 bytes or even more for the transaction ID without breaking existing resolvers; actually without breaking the protocol itself. Best regards Oliver cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sleeping without queue ?
Kris Kennaway написав(ла): Mikhail Teterin wrote: Hello! My attempt to build openoffice.org-3 seems to be hanging. Pressing Ctrl-T produces: load: 0.11 cmd: tcsh 79759 [sleeping without queue] 0.00u 0.00s 0% 0k (tcsh is used by OOo's build-script). What is this sleeping without queue state, and why is process in it for so long? This is an 4-CPU amd64 system with 4Gb of RAM. Only 16% of the swap is currently in use and the box seems to be perfectly fine otherwise. Uptime is 55 days, two different X-sessions are functional... The kernel is FreeBSD 7.0-STABLE #0: Sat Mar 8 16:02:37. Thanks! What is the process backtrace? Hard to say... The process ID 79759. According to ps(1), that PID exists: 79759 p6 DE+0:00,00 /bin/tcsh -fc /meow/ports/editors/openoffice.org-3/work/BEB300_m3/solver/300/unxfbsdx.pro/bin/makedepend @/tmp/mk2WUYYi ../../../unxfbsdx.pro/misc/s_addincol.dpcc According to gdb, it does not: gdb 79759 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd...79759: No such file or directory. Interestingly, the file mentioned in the command-line -- the s_addincol.dpcc -- does not exist anywhere under /meow/ports/editors/openoffice.org-3/work -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
unable to use gmirror on supermicro 5015b-mt
These are new boxes. http://www.supermicro.com/products/system/1U/5015/SYS-5015B-MT.cfm core 2 Q6600 CPU 8Gb 667 RAM Boxes were memtested from Fri-Mon okay. 6.3-RELEASE (amd64) installs fine. Build cycle okay. Running (no load) for a week or so. However, when I try to configure gmirror they hang on boot. After some fiddling it appears issuing #kldload geom_mirror hangs the boxes very hard. Ping response stops (after 3), no CAD response, CDROM draw doesn't open! This may well be a foolish thing to do but another (different) amd64 box doesn't hang. I don't believe this to be amd64 specific, I suspect that there's something strange about this hardware. There are very many BIOS options and I feel like I've tried them all without getting anywhere. I'm on holiday this week and I've borrowed a box to test. Any suggestions would be welcome. I'll (re)try anything but I need help to stay focused. Before you ask, no I cannot try 7.0-RELEASE, but that's a whole other thread (which may bear fruit more quickly). I already dropped the RAM to 2Gb and disabled the memory remap in the BIOS. dmesg after sig [AHCI disabled, SATA legacy mode] Thanks -- ian j hart %dmesg Copyright (c) 1992-2008 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 6.3-RELEASE #0: Wed Jan 16 01:43:02 UTC 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP ACPI APIC Table: PTLTD APIC Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM)2 Quad CPUQ6600 @ 2.40GHz (2394.02-MHz K8-class CPU) Origin = GenuineIntel Id = 0x6fb Stepping = 11 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe3bdSSE3,RSVD2,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF Cores per package: 4 real memory = 2145845248 (2046 MB) avail memory = 2059509760 (1964 MB) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0 Version 2.0 irqs 0-23 on motherboard ioapic1 Version 2.0 irqs 24-47 on motherboard kbd1 at kbdmux0 ath_hal: 0.9.20.3 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) hptrr: HPT RocketRAID controller driver v1.1 (Jan 16 2008 01:41:13) acpi0: PTLTDXSDT on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 cpu2: ACPI CPU on acpi0 cpu3: ACPI CPU on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge irq 16 at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 pcib2: ACPI PCI-PCI bridge at device 0.0 on pci1 pci2: ACPI PCI bus on pcib2 uhci0: UHCI (generic) USB controller port 0x1820-0x183f irq 16 at device 26.0 on pci0 uhci0: [GIANT-LOCKED] usb0: UHCI (generic) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: UHCI (generic) USB controller port 0x1840-0x185f irq 17 at device 26.1 on pci0 uhci1: [GIANT-LOCKED] usb1: UHCI (generic) USB controller on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: UHCI (generic) USB controller port 0x1860-0x187f irq 18 at device 26.2 on pci0 uhci2: [GIANT-LOCKED] usb2: UHCI (generic) USB controller on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ehci0: EHCI (generic) USB 2.0 controller mem 0xd8601000-0xd86013ff irq 18 at device 26.7 on pci0 ehci0: [GIANT-LOCKED] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: EHCI (generic) USB 2.0 controller on ehci0 usb3: USB revision 2.0 uhub3: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 6 ports with 6 removable, self powered pcib3: ACPI PCI-PCI bridge irq 16 at device 28.0 on pci0 pci5: ACPI PCI bus on pcib3 pcib4: ACPI PCI-PCI bridge irq 16 at device 28.4 on pci0 pci13: ACPI PCI bus on pcib4 em0: Intel(R) PRO/1000 Network Connection Version - 6.7.2 port 0x2000-0x201f mem 0xd800-0xd801 irq 16 at device 0.0 on pci13 em0: Ethernet address: 00:30:48:64:22:fa pcib5: ACPI PCI-PCI bridge irq 17 at device 28.5 on pci0 pci15: ACPI PCI bus on pcib5 em1: Intel(R) PRO/1000 Network Connection Version - 6.7.2 port 0x3000-0x301f mem 0xd820-0xd821 irq 17 at device 0.0 on pci15 em1: Ethernet address: 00:30:48:64:22:fb uhci3: UHCI (generic) USB controller port 0x1880-0x189f irq 23 at device 29.0 on pci0 uhci3:
Re: Panic on ZFS startup after crash
On Tue, July 22, 2008 06:07, Pawel Jakub Dawidek wrote: On Mon, Jul 21, 2008 at 06:18:10PM -0300, Nenhum_de_Nos wrote: The ZFS code in 7.0 is the same as in HEAD, so no worries. I'm trying zfs myself in a small enviroment at home, but for that I do follow 7-STABLE. there's no need to do that, as based in the above statement ? There might be some small differences, but the patches I provide here will apply to 7.0-RELEASE, 7-STABLE and 8-CURRENT. -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! ok, but my main wonder was about to be using the most new but stable zfs code :) do I keep running stable ? thanks, matheus -- We will call you cygnus, The God of balance you shall be ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sleeping without queue ?
On Tue, Jul 22, 2008 at 12:13:25PM -0400, Mikhail Teterin wrote: Kris Kennaway ???(??): Mikhail Teterin wrote: Hello! My attempt to build openoffice.org-3 seems to be hanging. Pressing Ctrl-T produces: load: 0.11 cmd: tcsh 79759 [sleeping without queue] 0.00u 0.00s 0% 0k (tcsh is used by OOo's build-script). What is this sleeping without queue state, and why is process in it for so long? This is an 4-CPU amd64 system with 4Gb of RAM. Only 16% of the swap is currently in use and the box seems to be perfectly fine otherwise. Uptime is 55 days, two different X-sessions are functional... The kernel is FreeBSD 7.0-STABLE #0: Sat Mar 8 16:02:37. Thanks! What is the process backtrace? Hard to say... The process ID 79759. According to ps(1), that PID exists: 79759 p6 DE+0:00,00 /bin/tcsh -fc /meow/ports/editors/openoffice.org-3/work/BEB300_m3/solver/300/unxfbsdx.pro/bin/makedepend @/tmp/mk2WUYYi ../../../unxfbsdx.pro/misc/s_addincol.dpcc According to gdb, it does not: gdb 79759 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd...79759: No such file or directory. Syntax appears wrong; gdb [program] 79759 would be what you want. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.1 and BIND exploit
On Tue, Jul 22, 2008 at 05:52:42PM +0200, Oliver Fromme wrote: Brett Glass wrote: At 02:24 PM 7/21/2008, Kevin Oberman wrote: Don't forget that ANY server that caches data, including an end system running a caching only server is vulnerable. Actually, there is an exception to this. A forward only cache/resolver is only as vulnerable as its forwarder(s). This is a workaround for the vulnerability for folks who have systems that they cannot easily upgrade: point at a trusted forwarder that's patched. We're also looking at using dnscache from the djbdns package. I'm curious, is djbdns exploitable, too? Does it randomize the source ports of UDP queries? AFAIK Dan Bernstein first spelled out the fundamental problems with DNS response forgery in 2001. He implemented dnscache to randomize source ports and IDs from the beginning, via a cryptographic quality RNG. See for instance this page, much of it written in 2003: http://cr.yp.to/djbdns/forgery.html He rubs a lot of people the wrong way, but I think he has usually proved to be right on security issues. I also think that modular design of security-sensitive tools is the way to go, with his DNS tools as with Postfix. -- Clifton -- Clifton Royston -- [EMAIL PROTECTED] / [EMAIL PROTECTED] President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sleeping without queue ?
Jeremy Chadwick написав(ла): On Tue, Jul 22, 2008 at 12:13:25PM -0400, Mikhail Teterin wrote: Kris Kennaway написав(ла): Mikhail Teterin wrote: Hello! My attempt to build openoffice.org-3 seems to be hanging. Pressing Ctrl-T produces: load: 0.11 cmd: tcsh 79759 [sleeping without queue] 0.00u 0.00s 0% 0k (tcsh is used by OOo's build-script). What is this sleeping without queue state, and why is process in it for so long? This is an 4-CPU amd64 system with 4Gb of RAM. Only 16% of the swap is currently in use and the box seems to be perfectly fine otherwise. Uptime is 55 days, two different X-sessions are functional... The kernel is FreeBSD 7.0-STABLE #0: Sat Mar 8 16:02:37. What is the process backtrace? Hard to say... The process ID 79759. According to ps(1), that PID exists: 79759 p6 DE+0:00,00 /bin/tcsh -fc /meow/ports/editors/openoffice.org-3/work/BEB300_m3/solver/300/unxfbsdx.pro/bin/makedepend @/tmp/mk2WUYYi ../../../unxfbsdx.pro/misc/s_addincol.dpcc According to gdb, it does not: [...] Syntax appears wrong; gdb [program] 79759 would be what you want. Yes, indeed. The result is similar, though: % gdb /bin/tcsh 79759 [...] Attaching to program: /bin/tcsh, process 79759 ptrace: No such process. /meow/ports/79759: No such file or directory. Thanks, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
unable to boot 7.0-RELEASE cdrom on supermicro 5015b-mt
Same hardware as my other thread. http://www.supermicro.com/products/system/1U/5015/SYS-5015B-MT.cfm [using 2Gb RAM and SATA in legacy mode] I'd like to focus only on making the CDROM boot complete. Summary: hangs just after the CPUs are launched. 6.2-RELEASE works okay, no AHCI support 6.3-RELEASE works okay 7.0-RELEASE hangs 7.0-STABLE-200806-SNAPSHOT hangs 8.0-CURRENT-200806-SNAPSHOT hangs I thought I could do a binary search using the current snapshot boot-only CDs but they only go back to March. Are there any older ones available? Thanks -- ian j hart ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.1 and BIND exploit
Clifton Royston wrote: I also think that modular design of security-sensitive tools is the way to go, with his DNS tools as with Postfix. Dan didn't write postfix, he wrote qmail. If you're interested in a resolver-only solution (and that is not a bad way to go) then you should evaluate dns/unbound. It is a lightweight resolver-only server that has a good security model and already implements query port randomization. It also has the advantage of being maintained, and compliant to 21st Century DNS standards including DNSSEC (which, btw, is the real solution to the response forgery problem, it just can't be deployed universally before 8/5). hth, Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: unable to boot 7.0-RELEASE cdrom on supermicro 5015b-mt
On Tue, Jul 22, 2008 at 05:27:52PM +0100, ian j hart wrote: Same hardware as my other thread. http://www.supermicro.com/products/system/1U/5015/SYS-5015B-MT.cfm [using 2Gb RAM and SATA in legacy mode] I'd like to focus only on making the CDROM boot complete. Summary: hangs just after the CPUs are launched. 6.2-RELEASE works okay, no AHCI support 6.3-RELEASE works okay 7.0-RELEASE hangs 7.0-STABLE-200806-SNAPSHOThangs 8.0-CURRENT-200806-SNAPSHOT hangs I thought I could do a binary search using the current snapshot boot-only CDs but they only go back to March. Are there any older ones available? Have you tried disabling ACPI to see if it makes any sort of difference? Also, AHCI should work just fine on those systems -- I know because I have fairly extensive experience with Supermicro hardware, although what you're using is newer than what I presently have. I don't know why you're setting Compatible/Legacy mode on your controller (you mention doing this in your other thread as well). Below is what we use on our systems; factory defaults, then make the following changes. (The G-LAN1 OPROM option you can do whatever you want with -- it's specific to our environment). * Main * Date -- Set to GMT, not local time!!! * Serial ATA -- SATA Controller Mode -- Enhanced -- SATA AHCI -- Enabled * Advanced * Boot Features -- Quiet Mode -- Disabled -- Enable Multimedia Timer -- Enabled * PCI Configuration -- Onboard G-LAN1 OPROM -- Disabled -- Large Disk Access Mode -- Other * Advanced Processor Options -- Intel(R) Virtualization Technology -- Enabled -- C1 Enhanced Mode -- Enabled -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.1 and BIND exploit
cpghost wrote: Yes indeed. If I understand all this correctly, it's because the transaction ID that has to be sent back is only 2 bytes long, 2 bits, 16 bytes. and if the query port doesn't change as well with every query, that can be cracked in milliseconds: sending 65536 DNS queries to a constant port is just way too easy! The namespace is way too small, and there's no way to fix this by switching to, say, 4 bytes or even more for the transaction ID without breaking existing resolvers; actually without breaking the protocol itself. That's more or less accurate, yes. Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sleeping without queue ?
Jeremy Chadwick wrote: On Tue, Jul 22, 2008 at 12:13:25PM -0400, Mikhail Teterin wrote: Kris Kennaway ???(??): Mikhail Teterin wrote: Hello! My attempt to build openoffice.org-3 seems to be hanging. Pressing Ctrl-T produces: load: 0.11 cmd: tcsh 79759 [sleeping without queue] 0.00u 0.00s 0% 0k (tcsh is used by OOo's build-script). What is this sleeping without queue state, and why is process in it for so long? This is an 4-CPU amd64 system with 4Gb of RAM. Only 16% of the swap is currently in use and the box seems to be perfectly fine otherwise. Uptime is 55 days, two different X-sessions are functional... The kernel is FreeBSD 7.0-STABLE #0: Sat Mar 8 16:02:37. Thanks! What is the process backtrace? Hard to say... The process ID 79759. According to ps(1), that PID exists: 79759 p6 DE+0:00,00 /bin/tcsh -fc /meow/ports/editors/openoffice.org-3/work/BEB300_m3/solver/300/unxfbsdx.pro/bin/makedepend @/tmp/mk2WUYYi ../../../unxfbsdx.pro/misc/s_addincol.dpcc According to gdb, it does not: gdb 79759 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd...79759: No such file or directory. Syntax appears wrong; gdb [program] 79759 would be what you want. Well, I mean kernel backtrace. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sleeping without queue ?
Kris Kennaway написав(ла): Well, I mean kernel backtrace. Can I obtain that remotely and without restarting/panicking the box? Thanks, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sleeping without queue ?
Mikhail Teterin wrote: Kris Kennaway написав(ла): Well, I mean kernel backtrace. Can I obtain that remotely and without restarting/panicking the box? Thanks, -mi kgdb on /dev/mem or procstat Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.1 and BIND exploit
On Tue, Jul 22, 2008 at 09:37:14AM -0700, Doug Barton wrote: Clifton Royston wrote: I also think that modular design of security-sensitive tools is the way to go, with his DNS tools as with Postfix. Dan didn't write postfix, he wrote qmail. I know, but I think qmail sucks. Wietse didn't write a DNS server or I'd probably be using that. :-) If you're interested in a resolver-only solution (and that is not a bad way to go) then you should evaluate dns/unbound. It is a lightweight resolver-only server that has a good security model and already implements query port randomization. It also has the advantage of being maintained, and compliant to 21st Century DNS standards including DNSSEC (which, btw, is the real solution to the response forgery problem, it just can't be deployed universally before 8/5). Sounds interesting; is it a caching resolver? I'm not totally convinced DNSSEC would solve everything (though it would solve the current vulnerability) but I'm not sure I follow the arguments pro and con. -- Clifton -- Clifton Royston -- [EMAIL PROTECTED] / [EMAIL PROTECTED] President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.1 and BIND exploit
On Tue, Jul 22, 2008 at 09:39:20AM -0700, Doug Barton wrote: cpghost wrote: Yes indeed. If I understand all this correctly, it's because the transaction ID that has to be sent back is only 2 bytes long, 2 bits, 16 bytes. ^ Think you mean those the other way! and if the query port doesn't change as well with every query, that can be cracked in milliseconds: sending 65536 DNS queries to a constant port is just way too easy! The namespace is way too small, and there's no way to fix this by switching to, say, 4 bytes or even more for the transaction ID without breaking existing resolvers; actually without breaking the protocol itself. That's more or less accurate, yes. Doug I just saw mention in Infoworld - adequate details of the exploit were guessed by another developer and then confirmed. They're now circulating, so I think we can expect engineered attacks soon. All: Upgrade your servers today, do not wait. -- Clifton -- Clifton Royston -- [EMAIL PROTECTED] / [EMAIL PROTECTED] President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sleeping without queue ?
Kris Kennaway написав(ла): Mikhail Teterin wrote: Kris Kennaway написав(ла): Well, I mean kernel backtrace. Can I obtain that remotely and without restarting/panicking the box? Thanks, kgdb on /dev/mem or procstat [EMAIL PROTECTED]:~ (107) kgdb /boot/kernel/kernel /dev/mem [...] (kgdb) bt #0 0x in ?? () Error accessing memory address 0x0: Bad address. Even less luck with procstat: [EMAIL PROTECTED]:~ (108) locate procstat [EMAIL PROTECTED]:~ (109) procstat procstat: Невідома команда. [EMAIL PROTECTED]:~ (110) man procstat No manual entry for procstat I'm sorry, but you'll need to be more specific. What should I type? Thanks, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.1 and BIND exploit
Clifton Royston wrote: On Tue, Jul 22, 2008 at 09:39:20AM -0700, Doug Barton wrote: cpghost wrote: Yes indeed. If I understand all this correctly, it's because the transaction ID that has to be sent back is only 2 bytes long, 2 bits, 16 bytes. ^ Think you mean those the other way! Oops, ELACKOFCAFFEINE and if the query port doesn't change as well with every query, that can be cracked in milliseconds: sending 65536 DNS queries to a constant port is just way too easy! The namespace is way too small, and there's no way to fix this by switching to, say, 4 bytes or even more for the transaction ID without breaking existing resolvers; actually without breaking the protocol itself. That's more or less accurate, yes. Doug I just saw mention in Infoworld - adequate details of the exploit were guessed by another developer and then confirmed. They're now circulating, so I think we can expect engineered attacks soon. All: Upgrade your servers today, do not wait. Agreed on both counts. -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.1 and BIND exploit
Doug Barton wrote: Clifton Royston wrote: I also think that modular design of security-sensitive tools is the way to go, with his DNS tools as with Postfix. Dan didn't write postfix, he wrote qmail. If you're interested in a resolver-only solution (and that is not a bad way to go) then you should evaluate dns/unbound. It is a lightweight resolver-only server that has a good security model and already implements query port randomization. It also has the advantage of being maintained, and compliant to 21st Century DNS standards including DNSSEC Are there any plans to enable DNSSEC capability in the resolver built into FreeBSD? (which, btw, is the real solution to the response forgery problem, it just can't be deployed universally before 8/5). That big announcement Dan Kaminsky was going to make at the Blackhat Conference in August? Unfortunately the cat has already been let out of the bag: http://blog.invisibledenizen.org/2008/07/kaminskys-dns-issue-accidentally-leaked.html There's no implementation of DNS that can be any /more/ proof against this than BIND+latest patches because the problem is intrinsic to the design of the DNS protocol. You'ld better be patched up or using alternative DNS implementations equally secure already. Even so that just increases the search space from about 16bits to about 30bits, which should make it not really feasible given current network and server capabilities. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: FreeBSD 7.1 and BIND exploit
Matthew Seaman wrote: Are there any plans to enable DNSSEC capability in the resolver built into FreeBSD? The server is already capable of it. I'm seriously considering enabling the define to make the CLI tools (dig/host/nslookup) capable as well (there is already an OPTION for this in ports). The problem is that _using_ DNSSEC requires configuration changes in named.conf, and more importantly, configuration of trust anchors (even for the command line stuff) since the root is not signed. It's not hard to do that with the DLV system that ISC has in place, and I would be willing to create a conf file that shows how to do that for users to include if they choose to. I am not comfortable enabling it by default (not yet anyway), it's too big of a POLA issue. Doug -- This .signature sanitized for your protection ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.1 and BIND exploit
--On Tuesday, July 22, 2008 09:37:14 -0700 Doug Barton [EMAIL PROTECTED] wrote: Clifton Royston wrote: I also think that modular design of security-sensitive tools is the way to go, with his DNS tools as with Postfix. Dan didn't write postfix, he wrote qmail. I think his point was that djbdns is modular just like Postfix is modular - not that Dan wrote both. I'm pretty sure everyone on the planet knows that Weitse wrote/maintains Postfix. If djbdns was as easy to setup as Postfix is, I'd use it too. If you're interested in a resolver-only solution (and that is not a bad way to go) then you should evaluate dns/unbound. It is a lightweight resolver-only server that has a good security model and already implements query port randomization. It also has the advantage of being maintained, and compliant to 21st Century DNS standards including DNSSEC (which, btw, is the real solution to the response forgery problem, it just can't be deployed universally before 8/5). What happens on 8/5? -- Paul Schmehl As if it wasn't already obvious, my opinions are my own and not those of my employer. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: unable to boot 7.0-RELEASE cdrom on supermicro 5015b-mt
On Tuesday 22 July 2008 17:37:24 Jeremy Chadwick wrote: On Tue, Jul 22, 2008 at 05:27:52PM +0100, ian j hart wrote: Same hardware as my other thread. http://www.supermicro.com/products/system/1U/5015/SYS-5015B-MT.cfm [using 2Gb RAM and SATA in legacy mode] I'd like to focus only on making the CDROM boot complete. Summary: hangs just after the CPUs are launched. 6.2-RELEASE works okay, no AHCI support 6.3-RELEASE works okay 7.0-RELEASE hangs 7.0-STABLE-200806-SNAPSHOT hangs 8.0-CURRENT-200806-SNAPSHOT hangs I thought I could do a binary search using the current snapshot boot-only CDs but they only go back to March. Are there any older ones available? Have you tried disabling ACPI to see if it makes any sort of difference? Yes, but I'm happy to re-try. Which method is best? Or is it 1 + 2 or 3? 1) BIOS 2) Beastie menu option 3) loader prompt set hint Also, AHCI should work just fine on those systems -- I know because I have fairly extensive experience with Supermicro hardware, although what you're using is newer than what I presently have. I don't know why you're setting Compatible/Legacy mode on your controller (you mention doing this in your other thread as well). Because I don't know what's wrong yet and AHCI support is newer than SATA support and this is a newish board? [At least 6.2 doesn't seem to support it and it has an AHCI legacy option!] I'd be happy to swap this over. Slight problem; the drives get renumbered, so I'd rather not swap back and forth. Below is what we use on our systems; factory defaults, then make the following changes. (The G-LAN1 OPROM option you can do whatever you want with -- it's specific to our environment). * Main * Date -- Set to GMT, not local time!!! * Serial ATA -- SATA Controller Mode -- Enhanced -- SATA AHCI -- Enabled * Advanced * Boot Features -- Quiet Mode -- Disabled -- Enable Multimedia Timer -- Enabled * PCI Configuration -- Onboard G-LAN1 OPROM -- Disabled -- Large Disk Access Mode -- Other * Advanced Processor Options -- Intel(R) Virtualization Technology -- Enabled -- C1 Enhanced Mode -- Enabled I've got as close as I can to this. This board also has an AHCI legacy option [disabled] which hides ports 5 and 6. I also disabled quickboot and POST errors. I assume multimedia timer is the same as HPET. Doesn't seem to be any disk translation option. I took the fans off 'flat out'. Thanks for your help. -- ian j hart ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.1 and BIND exploit
--On Tuesday, July 22, 2008 10:27:42 -0700 Doug Barton [EMAIL PROTECTED] wrote: Matthew Seaman wrote: Are there any plans to enable DNSSEC capability in the resolver built into FreeBSD? The server is already capable of it. I'm seriously considering enabling the define to make the CLI tools (dig/host/nslookup) capable as well (there is already an OPTION for this in ports). The problem is that _using_ DNSSEC requires configuration changes in named.conf, and more importantly, configuration of trust anchors (even for the command line stuff) since the root is not signed. It's not hard to do that with the DLV system that ISC has in place, and I would be willing to create a conf file that shows how to do that for users to include if they choose to. I am not comfortable enabling it by default (not yet anyway), it's too big of a POLA issue. I just played around with it recently. It's not that easy to understand initially *and* the trust anchors thing is a royal PITA. Once you implement DNSSEC you *must* generate keys every 30 days. So, I think, if you're going to enable it by default, there needs to be a script in periodic that will do all the magic to change keys every 30 days. Maybe put vars in /etc/rc.conf to override the default key lengths and other portions of the commands that could change per installation. If I were to implement it, I'd write a shell script to turn the keys over and cron it because doing it manually every 30 days ain't gonna happen. Too many ways to forget to do it. (I did the same for the root servers so that named.ca gets updated automagically every month.) But until root is signed, it's not worth it for those of us who don't have dedicated staff doing dns only. -- Paul Schmehl As if it wasn't already obvious, my opinions are my own and not those of my employer. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.1 and BIND exploit
If you're interested in a resolver-only solution (and that is not a bad way to go) then you should evaluate dns/unbound. It is a lightweight resolver-only server that has a good security model and already implements query port randomization. It also has the advantage of being maintained, and compliant to 21st Century DNS standards including DNSSEC (which, btw, is the real solution to the response forgery problem, it just can't be deployed universally before 8/5). I've been trying out unbound-1.0.1 on a 7.0-STABLE box (2.67 GHz i86, uniprocessor, 32 bit mode, 2 GB memory). Don't know what I'm doing wrong so far - but I've been unable to scale Unbound to more than a couple of hundred q/s. Any more than that and I get serious (several hundred ms) delays on lots of queries, including stuff which is known to be in the cache. I'll be doing some more Unbound tests the next few days. For now, both CNS and PowerDNS handle our load (around 2.5K q/s) fine. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.1 and BIND exploit
Doug Barton wrote: Matthew Seaman wrote: Are there any plans to enable DNSSEC capability in the resolver built into FreeBSD? The server is already capable of it. I'm seriously considering enabling the define to make the CLI tools (dig/host/nslookup) capable as well (there is already an OPTION for this in ports). Forgive me for being obtuse. What I meant was the capability to enable checking signatures on DNS RRs as a routine effect of getnameinfo() etc. by modifying resolver(3) routines or similar locally, without needing a DNSSEC enabled recursive resolver listed in resolv.conf? I've a feeling the answer is no, but I haven't been able to find anything definitive. Which I suppose simply means that if you're in the habit of, for example, taking your laptop into the coffee shop and getting on line there then you need to run your own instance of named on your laptop rather than blindly trusting whatever servers the coffee shop provides via their DHCP. The problem is that _using_ DNSSEC requires configuration changes in named.conf, and more importantly, configuration of trust anchors (even for the command line stuff) since the root is not signed. It's not hard to do that with the DLV system that ISC has in place, and I would be willing to create a conf file that shows how to do that for users to include if they choose to. I am not comfortable enabling it by default (not yet anyway), it's too big of a POLA issue. I sense a business opportunity in providing DLV there. I'm wondering why the likes of Verisign (including Thawte and Geotrust), Comodo group and GoDaddy aren't circling like vultures over a dead wildebeest. Perhaps they are. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: sleeping without queue ?
Kostik Belousov написав(ла): Did you switched to the process before doing backtrace (using the proc pid command)? Ok, thanks. Did not know about this one. Here: ... (kgdb) proc 79759 (kgdb) bt #0 sched_switch (td=0xff01286dc000, newtd=0xff00010ce000, flags=2) at /var/src/sys/kern/sched_4bsd.c:928 #1 0x in ?? () #2 0x802f1108 in mi_switch (flags=678281216, newtd=0x2) at /var/src/sys/kern/kern_synch.c:442 #3 0x80318513 in sleepq_check_timeout () at /var/src/sys/kern/subr_sleepqueue.c:519 #4 0x80318c85 in sleepq_timedwait (wchan=0x80688408) at /var/src/sys/kern/subr_sleepqueue.c:597 #5 0x802f16a2 in _sleep (ident=0x80688408, lock=0x0, priority=0, wmesg=0x804f3059 vmo_de, timo=1) at /var/src/sys/kern/kern_synch.c:224 #6 0x8043036b in vm_object_deallocate (object=0xff0053024a90) at /var/src/sys/vm/vm_object.c:509 #7 0x8042920e in vm_map_delete (map=0xff0015ba4b60, start=18446742979242478224, end=140737488355328) at /var/src/sys/vm/vm_map.c:2315 #8 0x804293df in vm_map_remove (map=0xff0015ba4b60, start=0, end=140737488355328) at /var/src/sys/vm/vm_map.c:2423 #9 0x8042b813 in vmspace_exit (td=0xff01286dc000) at /var/src/sys/vm/vm_map.c:324 #10 0x802c8cff in exit1 (td=0xff01286dc000, rv=0) at /var/src/sys/kern/kern_exit.c:294 #11 0x802ca08e in sys_exit (td=Variable td is not available. ) at /var/src/sys/kern/kern_exit.c:98 #12 0x8045a700 in syscall (frame=0xb0d89c70) at /var/src/sys/amd64/amd64/trap.c:852 #13 0x8043f38b in Xfast_syscall () at /var/src/sys/amd64/amd64/exception.S:290 #14 0x00080095f34c in ?? () Previous frame inner to this frame (corrupt stack?) What is the exact version of the system ? Note that procstat appeared in the late RELENG_7. FreeBSD 7.0-STABLE #0: Sat Mar 8 16:02:37 EST 2008 Also, show the output of ps axl pid. UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 79759 79758 0 96 0 016 - DE+ p60:00,00 /bin/tcsh -fc /meow/ports/editors/openoffice.org-3/work/BEB300_m3/solver/300/unxfbsdx.pro/bin/ma Yours, -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sleeping without queue ?
On Tue, Jul 22, 2008 at 03:26:29PM -0400, Mikhail Teterin wrote: Kostik Belousov написав(ла): Did you switched to the process before doing backtrace (using the proc pid command)? Ok, thanks. Did not know about this one. Here: ... (kgdb) proc 79759 (kgdb) bt #0 sched_switch (td=0xff01286dc000, newtd=0xff00010ce000, flags=2) at /var/src/sys/kern/sched_4bsd.c:928 #1 0x in ?? () #2 0x802f1108 in mi_switch (flags=678281216, newtd=0x2) at /var/src/sys/kern/kern_synch.c:442 #3 0x80318513 in sleepq_check_timeout () at /var/src/sys/kern/subr_sleepqueue.c:519 #4 0x80318c85 in sleepq_timedwait (wchan=0x80688408) at /var/src/sys/kern/subr_sleepqueue.c:597 #5 0x802f16a2 in _sleep (ident=0x80688408, lock=0x0, priority=0, wmesg=0x804f3059 vmo_de, timo=1) at /var/src/sys/kern/kern_synch.c:224 #6 0x8043036b in vm_object_deallocate (object=0xff0053024a90) at /var/src/sys/vm/vm_object.c:509 From this frame, please, print the object (like p *object) and likewise, print the object that is at the head of the object-shadow_head list. Another question is what scheduler do you use ? #7 0x8042920e in vm_map_delete (map=0xff0015ba4b60, start=18446742979242478224, end=140737488355328) at /var/src/sys/vm/vm_map.c:2315 #8 0x804293df in vm_map_remove (map=0xff0015ba4b60, start=0, end=140737488355328) at /var/src/sys/vm/vm_map.c:2423 #9 0x8042b813 in vmspace_exit (td=0xff01286dc000) at /var/src/sys/vm/vm_map.c:324 #10 0x802c8cff in exit1 (td=0xff01286dc000, rv=0) at /var/src/sys/kern/kern_exit.c:294 #11 0x802ca08e in sys_exit (td=Variable td is not available. ) at /var/src/sys/kern/kern_exit.c:98 #12 0x8045a700 in syscall (frame=0xb0d89c70) at /var/src/sys/amd64/amd64/trap.c:852 #13 0x8043f38b in Xfast_syscall () at /var/src/sys/amd64/amd64/exception.S:290 #14 0x00080095f34c in ?? () Previous frame inner to this frame (corrupt stack?) What is the exact version of the system ? Note that procstat appeared in the late RELENG_7. FreeBSD 7.0-STABLE #0: Sat Mar 8 16:02:37 EST 2008 Also, show the output of ps axl pid. UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 79759 79758 0 96 0 016 - DE+ p60:00,00 /bin/tcsh -fc /meow/ports/editors/openoffice.org-3/work/BEB300_m3/solver/300/unxfbsdx.pro/bin/ma It makes sense to show the whole ps axl output. Yours, -mi pgpAvegd51ob6.pgp Description: PGP signature
Re: sleeping without queue ?
On Tue, Jul 22, 2008 at 01:09:28PM -0400, Mikhail Teterin wrote: Kris Kennaway написав(ла): Mikhail Teterin wrote: Kris Kennaway написав(ла): Well, I mean kernel backtrace. Can I obtain that remotely and without restarting/panicking the box? Thanks, kgdb on /dev/mem or procstat [EMAIL PROTECTED]:~ (107) kgdb /boot/kernel/kernel /dev/mem [...] (kgdb) bt #0 0x in ?? () Error accessing memory address 0x0: Bad address. Even less luck with procstat: [EMAIL PROTECTED]:~ (108) locate procstat [EMAIL PROTECTED]:~ (109) procstat procstat: Нев?дома команда. [EMAIL PROTECTED]:~ (110) man procstat No manual entry for procstat I'm sorry, but you'll need to be more specific. What should I type? Thanks, Did you switched to the process before doing backtrace (using the proc pid command) ? What is the exact version of the system ? Note that procstat appeared in the late RELENG_7. Also, show the output of ps axl pid. pgpHpbt1prlWo.pgp Description: PGP signature
Re: sleeping without queue ?
Kostik Belousov написав(ла):
On Tue, Jul 22, 2008 at 03:26:29PM -0400, Mikhail Teterin wrote:
Kostik Belousov написав(ла):
Did you switched to the process before doing backtrace (using the proc
pid
command)?
Ok, thanks. Did not know about this one. Here:
...
(kgdb) proc 79759
(kgdb) bt
#0 sched_switch (td=0xff01286dc000, newtd=0xff00010ce000,
flags=2) at /var/src/sys/kern/sched_4bsd.c:928
#1 0x in ?? ()
#2 0x802f1108 in mi_switch (flags=678281216, newtd=0x2) at
/var/src/sys/kern/kern_synch.c:442
#3 0x80318513 in sleepq_check_timeout () at
/var/src/sys/kern/subr_sleepqueue.c:519
#4 0x80318c85 in sleepq_timedwait (wchan=0x80688408) at
/var/src/sys/kern/subr_sleepqueue.c:597
#5 0x802f16a2 in _sleep (ident=0x80688408, lock=0x0,
priority=0, wmesg=0x804f3059 vmo_de, timo=1) at
/var/src/sys/kern/kern_synch.c:224
#6 0x8043036b in vm_object_deallocate
(object=0xff0053024a90) at /var/src/sys/vm/vm_object.c:509
From this frame, please, print the object (like p *object) and
likewise, print the object that is at the head of the object-shadow_head
list.
kgdb /usr/obj/var/src/sys/SILVER-SMP/kernel.debug /dev/mem
[GDB will not be able to debug user-mode threads:
/usr/lib/libthread_db.so: Undefined symbol ps_pglobal_lookup]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as amd64-marcel-freebsd.
There is no member named pathname.
Reading symbols from /opt/modules/fuse.ko...done.
Loaded symbols for /opt/modules/fuse.ko
Reading symbols from /opt/modules/rtc.ko...done.
Loaded symbols for /opt/modules/rtc.ko
Reading symbols from /boot/kernel/snd_ich.ko...Reading symbols from
/boot/kernel/snd_ich.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/snd_ich.ko
Reading symbols from /boot/kernel/msdosfs.ko...Reading symbols from
/boot/kernel/msdosfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/msdosfs.ko
#0 0x in ?? ()
(kgdb) frame 6
Error accessing memory address 0x0: Bad address.
(kgdb) pid 79759
Undefined command: pid. Try help.
(kgdb) proc 79759
(kgdb) frame 6
#6 0x8043036b in vm_object_deallocate
(object=0xff0053024a90) at /var/src/sys/vm/vm_object.c:509
509 pause(vmo_de, 1);
(kgdb) p *object
$1 = {mtx = {lock_object = {lo_name = 0x804f21c4 vm object,
lo_type = 0x804f3018 standard object, lo_flags = 21168128,
lo_witness_data = {
lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4,
mtx_recurse = 0}, object_list = {tqe_next = 0xff0005018a90,
tqe_prev = 0xff00539a6850}, shadow_head = {lh_first =
0xff005d3afa90}, shadow_list = {le_next = 0x0, le_prev =
0xff005d2cd048}, memq = {
tqh_first = 0xff007eb9fa58, tqh_last = 0xff007f864820}, root
= 0xff007ee14d38, size = 427, generation = 66, ref_count = 2,
shadow_count = 1,
type = 0 '\0', flags = 256, pg_color = 0, paging_in_progress = 0,
resident_page_count = 44, backing_object = 0x0, backing_object_offset =
0, pager_object_list = {
tqe_next = 0x0, tqe_prev = 0x0}, cache = 0x0, handle = 0x0, un_pager
= {vnp = {vnp_size = 576646}, devp = {devp_pglist = {tqh_first = 0x8cc86,
tqh_last = 0x0}}, swp = {swp_bcount = 576646}}}
(kgdb) p (object-shadow_head)
$2 = {lh_first = 0xff005d3afa90}
(kgdb) p *object-shadow_head.lh_first
$3 = {mtx = {lock_object = {lo_name = 0x804f21c4 vm object,
lo_type = 0x804f3018 standard object, lo_flags = 21168128,
lo_witness_data = {
lod_list = {stqe_next = 0x0}, lod_witness = 0x0}}, mtx_lock = 4,
mtx_recurse = 0}, object_list = {tqe_next = 0xff0066c32340,
tqe_prev = 0xff012f673ac0}, shadow_head = {lh_first = 0x0},
shadow_list = {le_next = 0x0, le_prev = 0xff0053024ad0}, memq = {
tqh_first = 0xff007779f9a0, tqh_last = 0xff0077c04140}, root
= 0xff0077c04130, size = 387, generation = 3, ref_count = 1,
shadow_count = 0,
type = 0 '\0', flags = 8452, pg_color = 0, paging_in_progress = 0,
resident_page_count = 2, backing_object = 0xff0053024a90,
backing_object_offset = 163840,
pager_object_list = {tqe_next = 0x0, tqe_prev = 0x0}, cache = 0x0,
handle = 0x0, un_pager = {vnp = {vnp_size = 365278}, devp = {devp_pglist = {
tqh_first = 0x592de, tqh_last = 0x0}}, swp = {swp_bcount = 365278}}}
Another question is what scheduler do you use ?
options SCHED_4BSD # 4BSD scheduler
options PREEMPTION # Enable kernel thread preemption
Also, show the output of ps axl pid.
UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND
6.3-RELEASE-p3 recurring panics on multiple SM PDSMi+
We have 10 SuperMicro PDSMi+ 5015M-MTs that are panic'ing every few days. This started shortly after upgrade from 6.2-RELEASE to 6.3-RELEASE with freebsd-update. Other than switching to a debugging kernel, a little sysctl tuning, and patching with freebsd-update, they are stock. The debugging kernel was built from source that is also being patched with freebsd-update. These systems are running postfix and Courier imapd for an ISP with a userbase on the order of 10^4 users. They use gmirror, but the mailstore is over NFS. That NFS server is under pretty high load. All of the servers with this app and load pattern are panic'ing. I have little experience with kernel debugging, but the box in question is out of our farm and available for testing, and I am motivated to cooperate. :-) The full debugging kernel options I used are: include SMP options KDB options KDB_TRACE options DDB options BREAK_TO_DEBUGGER options WITNESS options WITNESS_SKIPSPIN db trace Tracing pid 71182 tid 100325 td 0xcc08b180 kdb_enter(c095f294) at kdb_enter+0x2b panic(c09768ad,1000,1400,c145bc88,1000,...) at panic+0x127 kmem_malloc(c14680c0,1000,102,eba6a8cc,c07e3fa5,...) at kmem_malloc+0x89 page_alloc(c1453780,1000,eba6a8bf,102,c06b8a84,...) at page_alloc+0x1a slab_zalloc(c1453780,102,c14537e0,c1453780,c1460d5c,...) at slab_zalloc+0xa1 uma_zone_slab(c1453780,2) at uma_zone_slab+0xf0 uma_zalloc_bucket(c1453780,2) at uma_zalloc_bucket+0x11c uma_zalloc_arg(c1453780,0,2) at uma_zalloc_arg+0x24c cache_enter(cd02c220,c9e62880,eba6a9fc) at cache_enter+0xa6 nfs_readdirplusrpc(cd02c220,eba6aa60,cc0ab880) at nfs_readdirplusrpc+0x6a6 nfs_doio(cd02c220,dce59668,cc0ab880,cc08b180,dce59668,...) at nfs_doio+0x20f nfs_bioread(cd02c220,eba6acb0,0,cc0ab880) at nfs_bioread+0xa64 nfs_readdir(eba6ac90) at nfs_readdir+0xe6 VOP_READDIR_APV(c09ebbc0,eba6ac90) at VOP_READDIR_APV+0x38 getdirentries(cc08b180,eba6ad04) at getdirentries+0x146 syscall(3b,3b,3b,9085f00,9085f00,...) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (196, FreeBSD ELF32, getdirentries), eip = 0xb825a79b, esp = 0xbfbfa1fc, ebp = 0xbfbfa228 --- Royce -- Royce D. Williams - http://royce.ws/ I don't like that man. I must get to know him better. - A. Lincoln ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.1 and BIND exploit
Date: Tue, 22 Jul 2008 12:52:15 -0500 From: Paul Schmehl [EMAIL PROTECTED] Sender: [EMAIL PROTECTED] --On Tuesday, July 22, 2008 10:27:42 -0700 Doug Barton [EMAIL PROTECTED] wrote: Matthew Seaman wrote: Are there any plans to enable DNSSEC capability in the resolver built into FreeBSD? The server is already capable of it. I'm seriously considering enabling the define to make the CLI tools (dig/host/nslookup) capable as well (there is already an OPTION for this in ports). The problem is that _using_ DNSSEC requires configuration changes in named.conf, and more importantly, configuration of trust anchors (even for the command line stuff) since the root is not signed. It's not hard to do that with the DLV system that ISC has in place, and I would be willing to create a conf file that shows how to do that for users to include if they choose to. I am not comfortable enabling it by default (not yet anyway), it's too big of a POLA issue. I just played around with it recently. It's not that easy to understand initially *and* the trust anchors thing is a royal PITA. No one is likely to argue with that statement! Once you implement DNSSEC you *must* generate keys every 30 days. So, I think, if you're going to enable it by default, there needs to be a script in periodic that will do all the magic to change keys every 30 days. Maybe put vars in /etc/rc.conf to override the default key lengths and other portions of the commands that could change per installation. No, you don't HAVE to generate keys every 30 days, but you should if you want real security. Still, for a while, until the infrastructure is complete enough to make DNSSEC really of value to the end user, just getting signed domains with keys published in an easily accessed place is at least getting things started and getting the infrastructure moving. Rolling keys is a rather tricky operation where mistakes, once DNSSEC makes it to the end user, would be disastrous, so it would require a couple of scripts, one to set a new key and another to remove the old one. You need both key present for a period of time. If I were to implement it, I'd write a shell script to turn the keys over and cron it because doing it manually every 30 days ain't gonna happen. Too many ways to forget to do it. (I did the same for the root servers so that named.ca gets updated automagically every month.) And that is FAR less important than the signatures. (named.ca could be updated once a year and be just fine.) But until root is signed, it's not worth it for those of us who don't have dedicated staff doing dns only. Work continues on getting the root signed, but it .com and .net that present the really big problems. The root delay is mostly political, not technical. .com and .net are both. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpvlKF3Qz7qt.pgp Description: PGP signature
Re: 6.3-RELEASE-p3 recurring panics on multiple SM PDSMi+
Royce Williams wrote: db trace Tracing pid 71182 tid 100325 td 0xcc08b180 kdb_enter(c095f294) at kdb_enter+0x2b panic(c09768ad,1000,1400,c145bc88,1000,...) at panic+0x127 kmem_malloc(c14680c0,1000,102,eba6a8cc,c07e3fa5,...) at kmem_malloc+0x89 You forgot to include the panic, but this is probably the kmem_map too small panic. It says that your kernel ran out of memory, and the solution is to fix that situation by giving more memory to the kernel. Increase the vm.kmem_size tunable until your system stops running out of memory on your workload. Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.1 and BIND exploit
--On Tuesday, July 22, 2008 13:07:20 -0700 Kevin Oberman [EMAIL PROTECTED] wrote: Once you implement DNSSEC you *must* generate keys every 30 days. So, I think, if you're going to enable it by default, there needs to be a script in periodic that will do all the magic to change keys every 30 days. Maybe put vars in /etc/rc.conf to override the default key lengths and other portions of the commands that could change per installation. No, you don't HAVE to generate keys every 30 days, but you should if you want real security. For me that means must. :-) Someone needs to write a really good tutorial on dnssec. The bits and pieces are scattered about the web, but explanations of now to publish your keys, to whom they need to be published and what is involved in the ongoing maintenance are lacking. Especially a clear explanation of what is required to run both keyed and legacy dns at the same time. Still, for a while, until the infrastructure is complete enough to make DNSSEC really of value to the end user, just getting signed domains with keys published in an easily accessed place is at least getting things started and getting the infrastructure moving. Where do you publish the keys? Rolling keys is a rather tricky operation where mistakes, once DNSSEC makes it to the end user, would be disastrous, so it would require a couple of scripts, one to set a new key and another to remove the old one. You need both key present for a period of time. I'd not read that. Can you explain? I thought you simply overwrote the existing keys with the new ones (in the zone file.) In fact I was thinking that an $INCLUDE would make a great deal more sense. I didn't realize you had to retain the old keys for a while. That complicates matters significantly. BTW, I think without those scripts (or at least examples) you'll find adoption will be a great deal slower. Many people that need to run dns are far from experts and often intimidated by its complexity - especially the complexity of dnssec. -- Paul Schmehl As if it wasn't already obvious, my opinions are my own and not those of my employer. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI regression on recent 7.0-STABLE: HPET stops working
On Tuesday 22 July 2008 04:37:51 am Oleg V. Nauman wrote: Quoting John Baldwin [EMAIL PROTECTED]: On Monday 21 July 2008 06:07:52 am Oleg V. Nauman wrote: Quoting Oleg V. Nauman [EMAIL PROTECTED]: Quoting Jeremy Chadwick [EMAIL PROTECTED]: On Sat, Jul 19, 2008 at 10:03:15AM +0300, Oleg V. Nauman wrote: It seems to be something was changed with ACPI support on 7.0-STABLE so my next system upgrade ended with ACPI HPET not working anymore on my ASUS A9Rp laptop. Here is the part of /var/log/dmesg.today dated July 13: FreeBSD 7.0-STABLE #65: Tue Jul 8 22:05:07 EEST 2008 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/oleg2 [..] acpi0: A M I OEMRSDT on motherboard acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21 acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 77f0 (3) failed Timecounter ACPI-safe frequency 3579545 Hz quality 850 acpi_timer0: 32-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 acpi_ec0: Embedded Controller: GPE 0x18 port 0x62,0x66 on acpi0 acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 900 Here is the fresh dmesg output info: FreeBSD 7.0-STABLE #66: Tue Jul 15 22:11:27 EEST 2008 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/oleg2 [..] acpi0: A M I OEMRSDT on motherboard acpi0: Overriding SCI Interrupt from IRQ 9 to IRQ 21 acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 77f0 (3) failed Timecounter ACPI-safe frequency 3579545 Hz quality 850 acpi_timer0: 32-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 [..] acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 device_attach: acpi_hpet0 attach returned 12 And the part of actual sysctl kern.timecounter output: kern.timecounter.choice: TSC(800) ACPI-safe(850) i8254(0) dummy(-100) kern.timecounter.hardware: ACPI-safe Seems okay here: FreeBSD icarus.home.lan 7.0-STABLE FreeBSD 7.0-STABLE #0: Sat Jul 12 10:53:08 PDT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PDSMI_PLUS_amd64 amd64 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter i8254 frequency 1193182 Hz quality 0 Timecounter ACPI-fast frequency 3579545 Hz quality 1000 Timecounter HPET frequency 14318180 Hz quality 900 Timecounters tick every 1.000 msec kern.timecounter.choice: TSC(-100) HPET(900) ACPI-fast(1000) i8254(0) dummy(-100) kern.timecounter.hardware: ACPI-fast You sure you haven't upgraded your BIOS or something and forgot to re-enable HPET? No it was not upgraded.. Have no option to enable/disable HPET through BIOS settings though I was unclear a bit or so. There are no ACPI related settings in my laptop's BIOS. Well.. Backout 1.243.2.3 revision of /usr/src/sys/dev/acpica/acpi.c (committed to RELENG_7 at July 10 by jhb) fixes this issue for me: acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 900 kern.timecounter.choice: TSC(800) HPET(900) ACPI-safe(850) i8254(0) dummy(-100) kern.timecounter.hardware: HPET Hopefully it helps to understand what is went wrong there. Ok, so the attempt to allocate the resource is failing for some reason. Can you get output from 'devinfo -r' and 'devinfo -u'? ... Will not provide with full listings but just a diff comparing two states (this good one with HPET working and bad w/o it): rainhaven# diff devinfo.r.good devinfo.r.bad 177,179d176 acpi_hpet0 I/O memory addresses: 0xfed0-0xfed003ff rainhaven# diff devinfo.u.good devinfo.u.bad 128c128 0xfed0-0xfed003ff (acpi_hpet0) --- 0xfed0-0xfed003ff (ichsmb0) So kernel with 1.243.2.3 revision of /usr/src/sys/dev/acpica/acpi.c allocates the region required to ichsmb0 instead HPET (it not helps to ichsmb0 because it never was working on my laptop but it is another story I think). Thank you for looking into. Hmm, so ichsmb0 doesn't show up at all in your earlier dmesg. Try this change, it restores the probe orders to be more of what they used to be and just gives CPUs a really high probe order so that they should be after other devices. Index: acpi.c === RCS file: /usr/cvs/src/sys/dev/acpica/acpi.c,v retrieving revision 1.248 diff -u -r1.248 acpi.c --- acpi.c 7 Apr 2008 18:35:11 - 1.248 +++ acpi.c 22 Jul 2008 19:12:56 - @@ -1531,8 +1531,7 @@ * 1. I/O port and memory system resource holders * 2. Embedded controllers (to
Re: 6.3-RELEASE-p3 recurring panics on multiple SM PDSMi+
Kris Kennaway wrote, on 7/22/2008 12:12 PM: Royce Williams wrote: db trace Tracing pid 71182 tid 100325 td 0xcc08b180 kdb_enter(c095f294) at kdb_enter+0x2b panic(c09768ad,1000,1400,c145bc88,1000,...) at panic+0x127 kmem_malloc(c14680c0,1000,102,eba6a8cc,c07e3fa5,...) at kmem_malloc+0x89 You forgot to include the panic Is there is a way to get the panic after dropping into the debugger? This serial console setup has no scrollback, so I couldn't see the preceding text. but this is probably the kmem_map too small panic. Ah, I see this now, at faq/book.html#KMEM-MAP-TOO-SMALL: Compile your own kernel, and add the VM_KMEM_SIZE_MAX to your kernel configuration file, increasing the maximum size to 400 MB (options VM_KMEM_SIZE_MAX=419430400). 400 MB appears to be sufficient for machines with up to 6 GB of memory. It says that your kernel ran out of memory, and the solution is to fix that situation by giving more memory to the kernel. Increase the vm.kmem_size tunable until your system stops running out of memory on your workload. Comparing the FAQ, kern_malloc.c and your mentioning it as tunable, please clarify: is the Right Thing to do to use vm.kmem_size, or vm.kmem_size_max? I tried vm.kmem_size_max, which yields: # sysctl -a | grep kmem vm.kmem_size: 419430400 vm.kmem_size_max: 419430400 vm.kmem_size_scale: 3 Should I contribute some additional language to the FAQ, saying that the vm.kmem_size[_max] tunable can be used without recompiling the kernel? Royce -- Royce D. Williams - http://royce.ws/ Reproof should not exhaust its power upon petty failings. - S. Johnson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ACPI regression on recent 7.0-STABLE: HPET stops working
On 2008-07-22 00:00, John Baldwin wrote: On Monday 21 July 2008 06:07:52 am Oleg V. Nauman wrote: Well.. Backout 1.243.2.3 revision of /usr/src/sys/dev/acpica/acpi.c (committed to RELENG_7 at July 10 by jhb) fixes this issue for me: acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 900 kern.timecounter.choice: TSC(800) HPET(900) ACPI-safe(850) i8254(0) dummy(-100) kern.timecounter.hardware: HPET Hopefully it helps to understand what is went wrong there. Ok, so the attempt to allocate the resource is failing for some reason. Can you get output from 'devinfo -r' and 'devinfo -u'? FWIW, I've tried acpi.c revs 1.243.2.1 through 1.243.2.3, and all give the same result: acpi_hpet0: High Precision Event Timer iomem 0xfe80-0xfe8003ff on acpi0 device_attach: acpi_hpet0 attach returned 12 E.g. it looks like bus_alloc_resource_any() in acpi_hpet_attach() fails, but no idea why? Anyway, devinfo -r and -u give: nexus0 apic0 ram0 I/O memory addresses: 0x0-0x9efff 0x10-0x1eed npx0 acpi0 Interrupt request lines: 9 I/O ports: 0x10-0x1f 0x22-0x3f 0x44-0x5f 0x62-0x63 0x65-0x6f 0x74-0x7f 0x91-0x93 0xa2-0xbf 0xe0-0xef 0x290-0x297 0x400-0x47f 0x4d0-0x4d1 0x500-0x50f 0x800-0x805 I/O memory addresses: 0xf-0xf 0x1eee-0x1eef 0xfe80-0xfe8000ff 0xfea0-0xfea000ff 0xfec0-0xfecf 0xfee0-0xfeef 0xfff8-0xfffe 0x-0x cpu0 ACPI I/O ports: 0x414 0x415 acpi_perf0 est0 p4tcc0 cpufreq0 acpi_button0 acpi_sysresource0 pcib0 pci0 hostb0 I/O memory addresses: 0xe800-0xefff hostb1 hostb2 hostb3 hostb4 hostb5 pcib1 pci1 vgapci0 I/O memory addresses: 0xf400-0xf7ff 0xfb00-0xfbff re0 Interrupt request lines: 18 I/O ports: 0xf000-0xf0ff I/O memory addresses: 0xfdfff000-0xfdfff0ff miibus0 rgephy0 re1 Interrupt request lines: 19 I/O ports: 0xf200-0xf2ff I/O memory addresses: 0xfdffe000-0xfdffe0ff miibus1 rgephy1 atapci0 Interrupt request lines: 20 I/O ports: 0xf400-0xf4ff 0xfb00-0xfb0f 0xfc00-0xfc03 0xfd00-0xfd07 0xfe00-0xfe03 0xff00-0xff07 ata2 ad4 subdisk4 ata3 ad6 subdisk6 atapci1 I/O ports: 0x170-0x177 0x1f0-0x1f7 0x376 0x3f6 0xfa00-0xfa0f ata0 Interrupt request lines: 14 ata1 Interrupt request lines: 15 uhci0 Interrupt request lines: 21 I/O ports: 0xf900-0xf91f usb0 uhub0 uhci1 I/O ports: 0xf800-0xf81f usb1 uhub1 uhci2 I/O ports: 0xf700-0xf71f usb2 uhub2 uhci3 I/O ports: 0xf600-0xf61f usb3 uhub3 ehci0 I/O memory addresses: 0xfdffd000-0xfdffd0ff usb4 uhub4 isab0 isa0 atkbdc0 I/O ports: 0x60 0x64 atkbd0 Interrupt request lines: 1 sc0 vga0 I/O ports: 0x3c0-0x3df I/O memory addresses: 0xa-0xb orm0 I/O memory addresses: 0xc-0xcf7ff pmtimer0 acpi_sysresource1 acpi_sysresource2 pci_link0 pci_link1 pci_link2 pci_link3 pci_link4 pci_link5 pci_link6 pci_link7 pci_link8 pci_link9 pci_link10 pci_link11 acpi_sysresource3 atpic0 atdma0 attimer0 attimer1 npxisa0 uart0 Interrupt request lines: 4 I/O ports: 0x3f8-0x3ff uart1 Interrupt request lines: 3 I/O ports:
Re: FreeBSD 7.1 and BIND exploit
Date: Tue, 22 Jul 2008 15:30:53 -0500 From: Paul Schmehl [EMAIL PROTECTED] --On Tuesday, July 22, 2008 13:07:20 -0700 Kevin Oberman [EMAIL PROTECTED] wrote: Once you implement DNSSEC you *must* generate keys every 30 days. So, I think, if you're going to enable it by default, there needs to be a script in periodic that will do all the magic to change keys every 30 days. Maybe put vars in /etc/rc.conf to override the default key lengths and other portions of the commands that could change per installation. No, you don't HAVE to generate keys every 30 days, but you should if you want real security. For me that means must. :-) Someone needs to write a really good tutorial on dnssec. The bits and pieces are scattered about the web, but explanations of now to publish your keys, to whom they need to be published and what is involved in the ongoing maintenance are lacking. Especially a clear explanation of what is required to run both keyed and legacy dns at the same time. I can't imagine why anyone would want to run both. Resolvers which don't know how to check signatures simple don't do so and everything still works. A pretty good, though somewhat outdated tutorial can be found in NIST SP800-81. It's pretty readable and tells you how to generate keys and sign a zone properly. http://csrc.nist.gov/publications/nistpubs/800-81/SP800-81.pdf Still, for a while, until the infrastructure is complete enough to make DNSSEC really of value to the end user, just getting signed domains with keys published in an easily accessed place is at least getting things started and getting the infrastructure moving. Where do you publish the keys? I have not done so at this time. We have a DNS system that does not quite support DNSSEC, although that should be resolved shortly. NIST simply puts theirs on a web page. This is not a good long-term answer, but is adequate for growing the infrastructure and letting people play with it. DNSSEC really needs to be ready now, but it's simply not, so we need to get some sort of start and more experience in using it. I have a test server that is signed and that I am playing with and I hope that I will be able to sign our production zones in the next few months. Our plan is to buy a network appliance to do the key generation, signing and key rolls. Rolling keys is a rather tricky operation where mistakes, once DNSSEC makes it to the end user, would be disastrous, so it would require a couple of scripts, one to set a new key and another to remove the old one. You need both key present for a period of time. I'd not read that. Can you explain? I thought you simply overwrote the existing keys with the new ones (in the zone file.) In fact I was thinking that an $INCLUDE would make a great deal more sense. I didn't realize you had to retain the old keys for a while. That complicates matters significantly. Since data in cached, you can't simply replace the key and not have failures when the cached old keys are used to try to verify newly received data. You need to have the old key remain valid for the length of your longest TTL. Note: I am not a DNSSEC expert at all. I have been playing with it for over a year, but have been unable to actually use it in production because of our DNS management software which does not support DNSSEC. Hopefully everything I said is correct, but it would be best to verify things before basing much on it. BTW, I think without those scripts (or at least examples) you'll find adoption will be a great deal slower. Many people that need to run dns are far from experts and often intimidated by its complexity - especially the complexity of dnssec. I completely agree that you are right. DNSSEC is not trivial to manage and, while managing it does not require any detailed knowledge of how it works, it does take careful planning and some education for those who will be working with it. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751 pgpttofZiTPsb.pgp Description: PGP signature
Re: 6.3-RELEASE-p3 recurring panics on multiple SM PDSMi+
Royce Williams wrote: Kris Kennaway wrote, on 7/22/2008 12:12 PM: Royce Williams wrote: db trace Tracing pid 71182 tid 100325 td 0xcc08b180 kdb_enter(c095f294) at kdb_enter+0x2b panic(c09768ad,1000,1400,c145bc88,1000,...) at panic+0x127 kmem_malloc(c14680c0,1000,102,eba6a8cc,c07e3fa5,...) at kmem_malloc+0x89 You forgot to include the panic Is there is a way to get the panic after dropping into the debugger? This serial console setup has no scrollback, so I couldn't see the preceding text. You can either show msgbuf, or x/x panicstr and then x/s 0x where that is the hex value from the previous step. The latter only diplays the format string and not the arguments, but on i386 you can read them off from the panic() line in the stack trace. Actually on i386 the panicstr is the first argument (0xc09768ad here). but this is probably the kmem_map too small panic. Ah, I see this now, at faq/book.html#KMEM-MAP-TOO-SMALL: Compile your own kernel, and add the VM_KMEM_SIZE_MAX to your kernel configuration file, increasing the maximum size to 400 MB (options VM_KMEM_SIZE_MAX=419430400). 400 MB appears to be sufficient for machines with up to 6 GB of memory. It says that your kernel ran out of memory, and the solution is to fix that situation by giving more memory to the kernel. Increase the vm.kmem_size tunable until your system stops running out of memory on your workload. Comparing the FAQ, kern_malloc.c and your mentioning it as tunable, please clarify: is the Right Thing to do to use vm.kmem_size, or vm.kmem_size_max? kmem_size_max is used for automatically tuning based on RAM size. To increase the actual value explicitly you just need to tune vm.kmem_size. I tried vm.kmem_size_max, which yields: # sysctl -a | grep kmem vm.kmem_size: 419430400 vm.kmem_size_max: 419430400 vm.kmem_size_scale: 3 Should I contribute some additional language to the FAQ, saying that the vm.kmem_size[_max] tunable can be used without recompiling the kernel? Yes, that would be fantastic! I would also note that the loader tunable is usually more convenient since it doesn't require a kernel recompile, and probably reword the claim about 400MB: the memory needed depends very much on the workload you are giving your kernel, so the best advice is to increase the value until you determine empirically how much you need (i.e. the memory exhaustion stops). You can also use 400M notation for loader tunables which is often more convenient. Thanks, Kris Kris ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: unable to boot 7.0-RELEASE cdrom on supermicro 5015b-mt
On Tue, Jul 22, 2008 at 06:47:34PM +0100, ian j hart wrote: On Tuesday 22 July 2008 17:37:24 Jeremy Chadwick wrote: On Tue, Jul 22, 2008 at 05:27:52PM +0100, ian j hart wrote: Same hardware as my other thread. http://www.supermicro.com/products/system/1U/5015/SYS-5015B-MT.cfm [using 2Gb RAM and SATA in legacy mode] I'd like to focus only on making the CDROM boot complete. Summary: hangs just after the CPUs are launched. 6.2-RELEASE works okay, no AHCI support 6.3-RELEASE works okay 7.0-RELEASE hangs 7.0-STABLE-200806-SNAPSHOThangs 8.0-CURRENT-200806-SNAPSHOT hangs I thought I could do a binary search using the current snapshot boot-only CDs but they only go back to March. Are there any older ones available? Have you tried disabling ACPI to see if it makes any sort of difference? Yes, but I'm happy to re-try. Which method is best? Or is it 1 + 2 or 3? 1) BIOS 2) Beastie menu option 3) loader prompt set hint Item #2 is the easiest. You should really be able to leave the BIOS settings at their defaults (Factory Defaults) and have this system work on FreeBSD. Items #2 and #3 are the same. The loader menu option for disabling ACPI simply sets the hint. Also, AHCI should work just fine on those systems -- I know because I have fairly extensive experience with Supermicro hardware, although what you're using is newer than what I presently have. I don't know why you're setting Compatible/Legacy mode on your controller (you mention doing this in your other thread as well). Because I don't know what's wrong yet and AHCI support is newer than SATA support and this is a newish board? [At least 6.2 doesn't seem to support it and it has an AHCI legacy option!] I'd be happy to swap this over. Slight problem; the drives get renumbered, so I'd rather not swap back and forth. You *absolutely* should have AHCI enabled. There's a lot of reasons why, too. I highly recommend avoiding the SATA Compatible mode. AHCI should work fine on FreeBSD 6.3 as well as 7.0 -- I know, because we have many Supermicro boards running those versions which do have AHCI enabled. Please use it, and stick with it. Here's added proof that AHCI works fine on 6.3: $ dmesg -a | grep -i ahci atapci1: Intel AHCI controller port 0x30e8-0x30ef,0x30dc-0x30df,0x30e0-0x30e7,0x30d8-0x30db,0x30b0-0x30bf mem 0xe400-0xe7ff irq 19 at device 31.2 on pci0 atapci1: AHCI Version 01.10 controller with 4 ports detected $ uname -r -s FreeBSD 6.3-PRERELEASE The adX device renumbering is expected. There are workarounds for this, but I recommend you simply enable AHCI. Do not keep toggling it on/off. Below is what we use on our systems; factory defaults, then make the following changes. (The G-LAN1 OPROM option you can do whatever you want with -- it's specific to our environment). * Main * Date -- Set to GMT, not local time!!! * Serial ATA -- SATA Controller Mode -- Enhanced -- SATA AHCI -- Enabled * Advanced * Boot Features -- Quiet Mode -- Disabled -- Enable Multimedia Timer -- Enabled * PCI Configuration -- Onboard G-LAN1 OPROM -- Disabled -- Large Disk Access Mode -- Other * Advanced Processor Options -- Intel(R) Virtualization Technology -- Enabled -- C1 Enhanced Mode -- Enabled I've got as close as I can to this. This board also has an AHCI legacy option [disabled] which hides ports 5 and 6. I also disabled quickboot and POST errors. I assume multimedia timer is the same as HPET. Doesn't seem to be any disk translation option. I took the fans off 'flat out'. Okay, I've had a chance to review the board manual that comes with the X7SBi. You should set the following: Serial ATA: Enabled Native Mode Operation: Serial ATA SATA AHCI: Enabled SATA AHCI Legacy: Disabled The name SATA AHCI Legacy a horrible name for what it does. The ICH9 itself has support for 6 SATA ports, but (if I remember correctly, based on reading some Intel design documents) there are extra registers you have to tweak to get those ports to work, and the OS has to be fully aware of how to do that. The BIOS option simply disables SATA ports 5 and 6 altogether; the underlying OS never sees them. I'd recommend keeping that setting Disabled (the default) unless you have disks on those ports (I don't see how, since it's a 4-disk system!). I don't think this option is what's causing you problems, though. Multimedia Timer is indeed HPET. Looks like they changed the name to be more reflective of what it actually is. The Large Disk Access mode does appear to be missing from that BIOS, probably for a good reason. I can enable/disable it on our boards with no repercussions (the options are DOS and Other, which is why I choose Other). I'm not entirely sure what it does. As for your problem... If the
Re: FreeBSD 7.1 and BIND exploit
--On Tuesday, July 22, 2008 10:27:42 -0700 Doug Barton [EMAIL PROTECTED] wrote: Matthew Seaman wrote: Are there any plans to enable DNSSEC capability in the resolver built into FreeBSD? The server is already capable of it. I'm seriously considering enabling the define to make the CLI tools (dig/host/nslookup) capable as well (there is already an OPTION for this in ports). The problem is that _using_ DNSSEC requires configuration changes in named.conf, and more importantly, configuration of trust anchors (even fo r the command line stuff) since the root is not signed. It's not hard to do that with the DLV system that ISC has in place, and I would be willing to create a conf file that shows how to do that for users to include if they choose to. I am not comfortable enabling it by default (not yet anyway), it 's too big of a POLA issue. I just played around with it recently. It's not that easy to understand initially *and* the trust anchors thing is a royal PITA. Once you implement DNSSEC you *must* generate keys every 30 days. So, I thin k, if you're going to enable it by default, there needs to be a script in period ic that will do all the magic to change keys every 30 days. Maybe put vars in /etc/rc.conf to override the default key lengths and other portions of the commands that could change per installation. WRONG. You need to re-sign the zone an expire period before the signatures expire. You need to generate new keys periodically but no where near every 30 days. KSKs annually. This is what the TLD's are doing and that is a very conservative exposure period. In practice it could be multiple years between key rollovers. The reason it is done this frequently is so humans don't forget what they need to do. ZSKs are generally weaker than KSKs but again they don't need to be done monthly. If I were to implement it, I'd write a shell script to turn the keys over and cron it because doing it manually every 30 days ain't gonna happen. Too many ways to forget to do it. (I did the same for the root servers so that named. ca gets updated automagically every month.) But until root is signed, it's not worth it for those of us who don't have dedicated staff doing dns only. There are solutions to the root not being signed. If all the TLD were signed the trust anchor work load would not be too great to managed by hand. For those that want a single trust anchor solution there is DLV. Sign your zone. Add it to a DLV. Ask you parent to sign their zone. If you don't sign you parent has no insentive to sign. This can be driven bottom up. That is one of the reasons why DLV was invented to provide incentive for the parent zones to sign. Mark -- Paul Schmehl As if it wasn't already obvious, my opinions are my own and not those of my employer. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.1 and BIND exploit
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --enig5488BAD5E4511AF4D0C2864A Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Doug Barton wrote: Matthew Seaman wrote: =20 Are there any plans to enable DNSSEC capability in the resolver built = into FreeBSD? =20 The server is already capable of it. I'm seriously considering enabling= =20 the define to make the CLI tools (dig/host/nslookup) capable as well=20 (there is already an OPTION for this in ports). Forgive me for being obtuse. What I meant was the capability to enable c= hecking signatures on DNS RRs as a routine effect of getnameinfo() etc. by modifying resolver(3) routines or similar locally, without needing a DNSSEC enabled recursive resolver listed in resolv.conf? I've a feeling the answer is no, but I haven't been able to find anything definitive. Which I suppose simply means that if you're in the habit of, for example,= =20 taking your laptop into the coffee shop and getting on line there then yo= u=20 need to run your own instance of named on your laptop rather than blindly= =20 trusting whatever servers the coffee shop provides via their DHCP. Use a local (on machine) validating caching nameserver. The problem is that _using_ DNSSEC requires configuration changes in=20 named.conf, and more importantly, configuration of trust anchors (eve= n=20 for the command line stuff) since the root is not signed. It's not hard= =20 to do that with the DLV system that ISC has in place, and I would be=20 willing to create a conf file that shows how to do that for users to=20 include if they choose to. I am not comfortable enabling it by default = (not yet anyway), it's too big of a POLA issue. I sense a business opportunity in providing DLV there. I'm wondering why= the likes of Verisign (including Thawte and Geotrust), Comodo group and=20 GoDaddy aren't circling like vultures over a dead wildebeest. Perhaps th= ey=20 are. You only need one DLV. ISC is offering the service for free. Donations welcome as it does cost to run the service. Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW --enig5488BAD5E4511AF4D0C2864A Content-Type: application/pgp-signature; name=signature.asc Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREIAAYFAkiGKPIACgkQ8Mjk52CukIxbWACfTVCDPVViUJ0NTd5GLMMVU8bD xXkAniwbkPNqgVZYLi4a/5aQHYFxBHSo =T6Z8 -END PGP SIGNATURE- --enig5488BAD5E4511AF4D0C2864A-- -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.1 and BIND exploit
On Tue, Jul 22, 2008 at 05:52:42PM +0200, Oliver Fromme wrote: Brett Glass wrote: At 02:24 PM 7/21/2008, Kevin Oberman wrote: Don't forget that ANY server that caches data, including an end system running a caching only server is vulnerable. Actually, there is an exception to this. A forward only cache/resolver is only as vulnerable as its forwarder(s). This is a workaround for the vulnerability for folks who have systems that they cannot easily upgrade: point at a trusted forwarder that's patched. We're also looking at using dnscache from the djbdns package. I'm curious, is djbdns exploitable, too? Does it randomize the source ports of UDP queries? AFAIK Dan Bernstein first spelled out the fundamental problems with DNS response forgery in 2001. He implemented dnscache to randomize source ports and IDs from the beginning, via a cryptographic quality RNG. See for instance this page, much of it written in 2003: http://cr.yp.to/djbdns/forgery.html And the IETF was working on a solution well before that. One that addressed not only off path attacks but also addressed on path attacks. One that worked with kernels that only supported limited numbers of file desriptors. One that worked regardless on the number of concurrent outstanding queries. That solution is called DNSSEC. We looked at what Dan did and said it didn't go far enough and that it has implementation issues at high query rates that can't be solved just by throwing more cpu at the problem. The problems are inherent to how UDP works. He rubs a lot of people the wrong way, but I think he has usually proved to be right on security issues. Dan is often right. However a different, more encompassing, solution was choosen. I also think that modular design of security-sensitive tools is the way to go, with his DNS tools as with Postfix. -- Clifton -- Clifton Royston -- [EMAIL PROTECTED] / [EMAIL PROTECTED] President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED] -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.1 and BIND exploit
On Tue, Jul 22, 2008 at 12:52:15PM -0500, Paul Schmehl wrote:
--On Tuesday, July 22, 2008 10:27:42 -0700 Doug Barton
[EMAIL PROTECTED] wrote:
Matthew Seaman wrote:
Are there any plans to enable DNSSEC capability in the resolver built
into FreeBSD?
The server is already capable of it. I'm seriously considering enabling the
define to make the CLI tools (dig/host/nslookup) capable as well (there is
already an OPTION for this in ports).
The problem is that _using_ DNSSEC requires configuration changes in
named.conf, and more importantly, configuration of trust anchors (even for
the command line stuff) since the root is not signed. It's not hard to do
that with the DLV system that ISC has in place, and I would be willing to
create a conf file that shows how to do that for users to include if they
choose to. I am not comfortable enabling it by default (not yet anyway), it's
too big of a POLA issue.
I just played around with it recently. It's not that easy to understand
initially *and* the trust anchors thing is a royal PITA.
I completely agree on both points. To give you some idea of how much of
an annoyance DNSSEC is, a friend of mine who used to work at Nominum
stated that one of their software engineers, when signing, on had a
clause appended to his employee agreement stating he would not be
required to work on DNSSEC code, due to the absurd complexity of it all.
For what it's worth, I went looking into DNSSEC last week, and after a
few hours of skimming then reading, I concluded it's over-engineered and
adds too much hassle for it to be considered a worthwhile upgrade. In
no way am I putting down the need for security, but the added complexity
is what's going to turn people off to this, and because of such, very
likely ignore it. You can call me ignorant/lazy -- I welcome such --
but I guarantee others feel the same way.
DNS, for most people, is expected to be a simple thing. They like it
to be simple, and it's generally not rocket science. People have come
to expect that, and while I think most are willing to accept change
(take TSIG for example), it has to be easy to set up, simple to
maintain, troubleshooting outlined step-by-step with easy-to-follow
output, and in the case of a hard failure, the documentation easy to
understand.
This is not the case with DNSSEC; I feel like I'm setting up a bloody
IPsec VPN. IPsec: AH or ESP across tunnel/transport using AES or 3DES
with IKE/ISAKMP or static secrets, and don't forget GRE. DNSSEC: trust
anchors with lookaside validation, SEP, DNSKEY, DLV, RRSIG, ZSK and its
phases, KSK and its phases, etc...
There's the how to make it work in 6 minutes PDF by the ISC, which
appears to have been made/used for/as presentation material -- meaning
you're missing the verbal explanations that go along with each item.
There's also inconsistencies in configuration syntax within the PDF,
making you wonder how much time someone put into it.
There also appears to be an assumption made throughout all of the
documentation that I've read: that your recursive and non-recursive DNS
servers are separate. I'm still trying to understand why that
assumption is made; sure, the majority of the enterprise-class world
has segregated DNS servers (public authoritative vs. internal recursive
resolvers), but the runner-up would be administrators who simply run
BIND on their servers and use two simple configuration lines:
acl trusted { my.net.block/cidr; 127.0.0.1; };
options {
allow-recursion { trusted; }
};
If DNSSEC really requires that your recursive and non-recursive servers
be separate, then it will fail.
And I still cannot get over the fact that this HOWTO is 47 pages long:
http://www.nlnetlabs.nl/dnssec_howto/
Let's not forget this packet flow diagram, which is quite legible and
easy to understand:
http://www.nlnetlabs.nl/dnssec_howto/dnspktdemo.png
Once you implement DNSSEC you *must* generate keys every 30 days. So, I
think, if you're going to enable it by default, there needs to be a
script in periodic that will do all the magic to change keys every 30
days. Maybe put vars in /etc/rc.conf to override the default key lengths
and other portions of the commands that could change per installation.
I believe you're talking about re-signing the zones. The duration is
adjustable, but 30 days appears to be what the documentation and howto
site defaults to/recommends using:
http://www.isc.org/sw/bind/arm95/man.dnssec-signzone.html
http://www.nlnetlabs.nl/dnssec_howto/#x1-240002.4
But until root is signed, it's not worth it for those of us who don't
have dedicated staff doing dns only.
Bingo.
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
Re: FreeBSD 7.1 and BIND exploit
Jeremy, I can't agree with you more, for some reason
crypto people seem to believe that in order to drive
a car you should have to know how to rebuild a carb.
Makes no sense.
The funny part is that your comparison with setting up
IPsec is the same thing that I compare these things to.
Back in 2003 I tried to set up a shared key IPSEC dhcp
at home, basically I'd just make a key and sneaker-net it
to the hosts that wanted to connect, after about 6 hours
I just gave up and used wep.
*sigh*
-Alfred
* Jeremy Chadwick [EMAIL PROTECTED] [080722 18:59] wrote:
On Tue, Jul 22, 2008 at 12:52:15PM -0500, Paul Schmehl wrote:
--On Tuesday, July 22, 2008 10:27:42 -0700 Doug Barton
[EMAIL PROTECTED] wrote:
Matthew Seaman wrote:
Are there any plans to enable DNSSEC capability in the resolver built
into FreeBSD?
The server is already capable of it. I'm seriously considering enabling the
define to make the CLI tools (dig/host/nslookup) capable as well (there is
already an OPTION for this in ports).
The problem is that _using_ DNSSEC requires configuration changes in
named.conf, and more importantly, configuration of trust anchors (even
for
the command line stuff) since the root is not signed. It's not hard to do
that with the DLV system that ISC has in place, and I would be willing to
create a conf file that shows how to do that for users to include if they
choose to. I am not comfortable enabling it by default (not yet anyway),
it's
too big of a POLA issue.
I just played around with it recently. It's not that easy to understand
initially *and* the trust anchors thing is a royal PITA.
I completely agree on both points. To give you some idea of how much of
an annoyance DNSSEC is, a friend of mine who used to work at Nominum
stated that one of their software engineers, when signing, on had a
clause appended to his employee agreement stating he would not be
required to work on DNSSEC code, due to the absurd complexity of it all.
For what it's worth, I went looking into DNSSEC last week, and after a
few hours of skimming then reading, I concluded it's over-engineered and
adds too much hassle for it to be considered a worthwhile upgrade. In
no way am I putting down the need for security, but the added complexity
is what's going to turn people off to this, and because of such, very
likely ignore it. You can call me ignorant/lazy -- I welcome such --
but I guarantee others feel the same way.
DNS, for most people, is expected to be a simple thing. They like it
to be simple, and it's generally not rocket science. People have come
to expect that, and while I think most are willing to accept change
(take TSIG for example), it has to be easy to set up, simple to
maintain, troubleshooting outlined step-by-step with easy-to-follow
output, and in the case of a hard failure, the documentation easy to
understand.
This is not the case with DNSSEC; I feel like I'm setting up a bloody
IPsec VPN. IPsec: AH or ESP across tunnel/transport using AES or 3DES
with IKE/ISAKMP or static secrets, and don't forget GRE. DNSSEC: trust
anchors with lookaside validation, SEP, DNSKEY, DLV, RRSIG, ZSK and its
phases, KSK and its phases, etc...
There's the how to make it work in 6 minutes PDF by the ISC, which
appears to have been made/used for/as presentation material -- meaning
you're missing the verbal explanations that go along with each item.
There's also inconsistencies in configuration syntax within the PDF,
making you wonder how much time someone put into it.
There also appears to be an assumption made throughout all of the
documentation that I've read: that your recursive and non-recursive DNS
servers are separate. I'm still trying to understand why that
assumption is made; sure, the majority of the enterprise-class world
has segregated DNS servers (public authoritative vs. internal recursive
resolvers), but the runner-up would be administrators who simply run
BIND on their servers and use two simple configuration lines:
acl trusted { my.net.block/cidr; 127.0.0.1; };
options {
allow-recursion { trusted; }
};
If DNSSEC really requires that your recursive and non-recursive servers
be separate, then it will fail.
And I still cannot get over the fact that this HOWTO is 47 pages long:
http://www.nlnetlabs.nl/dnssec_howto/
Let's not forget this packet flow diagram, which is quite legible and
easy to understand:
http://www.nlnetlabs.nl/dnssec_howto/dnspktdemo.png
Once you implement DNSSEC you *must* generate keys every 30 days. So, I
think, if you're going to enable it by default, there needs to be a
script in periodic that will do all the magic to change keys every 30
days. Maybe put vars in /etc/rc.conf to override the default key lengths
and other portions of the commands that could change per installation.
I believe you're talking about re-signing the zones. The duration is
adjustable,
Re: FreeBSD 7.1 and BIND exploit
--On July 23, 2008 10:46:43 AM +1000 Mark Andrews [EMAIL PROTECTED] wrote: I just played around with it recently. It's not that easy to understand initially *and* the trust anchors thing is a royal PITA. Once you implement DNSSEC you *must* generate keys every 30 days. So, I thin k, if you're going to enable it by default, there needs to be a script in period ic that will do all the magic to change keys every 30 days. Maybe put vars in /etc/rc.conf to override the default key lengths and other portions of the commands that could change per installation. WRONG. You need to re-sign the zone an expire period before the signatures expire. You need to generate new keys periodically but no where near every 30 days. OK. I misspoke. I got the 30 days from Andrew Clegg's presentation and confused keys with signatures. But still, you have to resign *every* zone every 30 days. Signatures have lifespans “Born-on” date – 1 hour prior to running dnssecsignzone Expiration date – 30 days after running dnssecsignzone Expired signatures lead to zones that will not validate! I followed Clegg's presentation to try out dnssec. Then there's this: Any time you modify a zone – or at least every 30 days (minus TTL) you must re-run dnssecsignzone If you don't 1) Zone data will be stale 2) Zone data will be GONE So, for me, that's three zones I have to mess with every 30 days. Then Clegg says the the ZSK keys should be changed every quarter and the KSK keys every year. So I have to resign monthly, regen ZSK keys quarterly and regen KSK keys annually, and I have to do this without breaking any of my zones so that they stop resolving for periods long enough to clear out caches. How is the average person supposed to understand this, much less do it correctly? Don't misunderstand me, Mark, I'm all for security. But this ain't easy, and the online information only confuses the issue. Clegg also says this: When finished: 2 ZSK files (.key and .private) 2 KSK files (.key and .private) 2 zonefiles (unsigned and .signed) So, do I have to have two zone files or not? As someone who is trying to understand this new technology, I have to tell you, the online documentation isn't written for non dns-gurus. I'll be happy to sign my zones, but not until I understand how it works, what the ramifications are and what my maintenance responsibilities are. Paul Schmehl If it isn't already obvious, my opinions are my own and not those of my employer.
Re: 6.3-RELEASE-p3 recurring panics on multiple SM PDSMi+
On Tue, Jul 22, 2008 at 11:45:30AM -0800, Royce Williams wrote: We have 10 SuperMicro PDSMi+ 5015M-MTs that are panic'ing every few days. This started shortly after upgrade from 6.2-RELEASE to 6.3-RELEASE with freebsd-update. I was having similar problems on some servers using 6.2-psomething, which also use an NFS server heavily (for shared configuration files), until I started using the same vmem.kmem_size tunable Kris is recommending. That seemed to solve the problem for me. (I just slapped it up to 512M rather than try to binary search for some optimum value.) -- Clifton -- Clifton Royston -- [EMAIL PROTECTED] / [EMAIL PROTECTED] President - I and I Computing * http://www.iandicomputing.com/ Custom programming, network design, systems and network consulting services ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.3-RELEASE-p3 recurring panics on multiple SM PDSMi+
On Tue, Jul 22, 2008 at 11:45:30AM -0800, Royce Williams wrote: We have 10 SuperMicro PDSMi+ 5015M-MTs that are panic'ing every few days. This started shortly after upgrade from 6.2-RELEASE to 6.3-RELEASE with freebsd-update. We use the same hardware (board and chassis), and have no such problems running both RELENG_6 and RELENG_7. I don't think your issue is specific to the board or chassis. Kris's explanation makes a lot more sense. :-) -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 7.1 and BIND exploit
Lots of good discussion on this thread, I'm going to cherry-pick some things to respond to. Kevin Oberman wrote: And, if you are not sure how good a job it does (and I am not), you should use the OARC test to check how well it works: dig +short porttest.dns-oarc.net TXT If the result is not GOOD, it's not good enough. You can test a remote server by adding @remote-server to the dig command. The server may be specified by name or IP address. This is good, I would not specify a name server to test by hostname though, you're hitting a chicken/egg problem if you do. There is also https://www.dns-oarc.net/oarc/services/dnsentropy if your desktop is behind the resolver you want to test. Paul Schmehl wrote: I just played around with it recently. It's not that easy to understand initially *and* the trust anchors thing is a royal PITA. The trust anchors thing is made mega easier if you use the DLV service provided by ISC. If you want to configure specific trust anchors yourself, you really need to know what you're doing first. Once you implement DNSSEC you *must* generate keys every 30 days. You are talking about signing a zone you are authoritative for. I am talking about enabling DNSSEC for the named that comes with FreeBSD and by default is configured as a resolver only. So, I think, if you're going to enable it by default, there needs to be a script in periodic that will do all the magic to change keys every 30 days. I would certainly never write, and I can't imagine that I would ever approve such a script. There are too many moving parts to setting good DNSSEC key policy for me to be comfortable with a cookie-cutter approach. Jeremy Chadwick wrote: For what it's worth, I went looking into DNSSEC last week, and after a few hours of skimming then reading, I concluded it's over-engineered and adds too much hassle for it to be considered a worthwhile upgrade. I could certainly sympathize with an argument that parts of the DNSSEC spec are over-engineered. The problem however is that the DNS, more than any other Internet system that I can think of, has so many corner cases that they almost seem to be the norm sometimes, and more than any other service it has been engineered to accommodate them. Personally I was in favor of the flag day approach to DNSSEC deployment 7 years ago, and was told that's not how we do things in DNS. The corner cases have gotten worse since then, not better. DNS, for most people, is expected to be a simple thing. And back in the good old days it could be. Those days are over. (Arguably they ended in 1995, but I digress.) There also appears to be an assumption made throughout all of the documentation that I've read: that your recursive and non-recursive DNS servers are separate. I'm still trying to understand why that assumption is made; Because we've been telling people to do that since, oh, say, the '90's? There are very good reasons to do that, I'm not going to belabor them here. The simplest way to understand the justification is that by their very nature authoritative service operates in the UNtrusted world, and you would like your name resolution to happen in a more or less TRUSTED way. The two goals are antithetical. Matthew Seaman wrote: Forgive me for being obtuse. What I meant was the capability to enable checking signatures on DNS RRs as a routine effect of getnameinfo() etc. by modifying resolver(3) routines or similar locally, without needing a DNSSEC enabled recursive resolver listed in resolv.conf? I've a feeling the answer is no, but I haven't been able to find anything definitive. Ok, how is this: no. :) But seriously folks, the problem here is that you're talking about 3 completely separate spheres of operation, which for 99.9% of Internet users are all operating under the control of different people. I'll take it as a given that the members of this list understand what authoritative name service is, and that in order for DNSSEC to work you have to sign the zone that is on the authoritative name server. Interestingly enough, that is the easy part. The second sphere is the resolving name server (often erroneously referred to as a caching server) that goes out into the wide world and gathers answers to queries generated by users on its network. The third sphere is the stub resolver located on your little computer. What you're asking is, can we have a stub resolver in FreeBSD that will do the DNSSEC thing regardless of what kind of resolving name server it's sitting behind? (Please note that I and others have made the argument for a long time now that there is actually a fourth sphere, the application itself. More people agree with that idea now than did in the past, but the question is still what to do about it.) So, here is the problem (actually, problemS) with that. First, the authoritative server is just spitting out bits, it really has no knowledge of what it's sending (let's leave nasty stuff like
