Disklabel on usb hdd wiped on crypto boot
Hello I have run into another strange problem on the Optiplex 745 in the dmesg below. It usually boots with a usb crypto key disk, but if I try to boot with a particular usb hard disk attached it will fail to find the key disk and will instead erase the disklabel on the usb hdd. The data is all OK if the disklabel is restored from file. The external disk in question is a 3 terabyte Seagate Expansion Desk unit (see end of dmesg). I tried another external hdd but it didn't suffer the same problem, and the Seagate wasn't wiped on other crypto machines that I tried it with. Perhaps this is of interest to someone. I'm not sure if it is usb problem or what. Anyhow, I think it might about time this particular machine was decommissioned. Thanks, Peter OpenBSD 5.6-beta (GENERIC.MP) #290: Sat Jul 19 11:29:25 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3193958400 (3045MB) avail mem = 3100217344 (2956MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xf0450 (77 entries) bios0: vendor Dell Inc. version 2.6.4 date 03/01/2010 bios0: Dell Inc. OptiPlex 745 acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP SSDT APIC BOOT ASF! MCFG HPET SSDT SSDT SSDT acpi0: wakeup devices VBTN(S4) PCI0(S5) PCI4(S5) PCI2(S5) PCI3(S5) PCI1(S5) PCI5(S5) PCI6(S5) MOU_(S3) USB0(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Pentium(R) D CPU 3.40GHz, 3389.45 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,EST,CNXT-ID,CX16,xTPR,PDCM,NXE,LONG,LAHF cpu0: 2MB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 199MHz cpu0: mwait min=64, max=64 cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Pentium(R) D CPU 3.40GHz, 3389.04 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,EST,CNXT-ID,CX16,xTPR,PDCM,NXE,LONG,LAHF cpu1: 2MB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 8 acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 4 (PCI4) acpiprt1 at acpi0: bus 2 (PCI2) acpiprt2 at acpi0: bus -1 (PCI3) acpiprt3 at acpi0: bus 1 (PCI1) acpiprt4 at acpi0: bus 3 (PCI5) acpiprt5 at acpi0: bus -1 (PCI6) acpiprt6 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0: PSS acpicpu1 at acpi0: PSS acpibtn0 at acpi0: VBTN cpu0: Enhanced SpeedStep 3389 MHz: speeds: 3400, 2400 MHz memory map conflict 0xbf603c00/0x9fc400 pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 Intel 82Q965 Host rev 0x02 ppb0 at pci0 dev 1 function 0 Intel 82Q965 PCIE rev 0x02: msi pci1 at ppb0 bus 1 vga1 at pci0 dev 2 function 0 Intel 82Q965 Video rev 0x02 intagp0 at vga1 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0 at vga1 drm0 at inteldrm0 inteldrm0: 1024x768 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) Intel 82Q965 Video rev 0x02 at pci0 dev 2 function 1 not configured uhci0 at pci0 dev 26 function 0 Intel 82801H USB rev 0x02: apic 8 int 16 uhci1 at pci0 dev 26 function 1 Intel 82801H USB rev 0x02: apic 8 int 17 ehci0 at pci0 dev 26 function 7 Intel 82801H USB rev 0x02: apic 8 int 22 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 Intel 82801H HD Audio rev 0x02: msi azalia0: codecs: Analog Devices AD1983 audio0 at azalia0 ppb1 at pci0 dev 28 function 0 Intel 82801H PCIE rev 0x02: msi pci2 at ppb1 bus 2 ppb2 at pci0 dev 28 function 4 Intel 82801H PCIE rev 0x02: msi pci3 at ppb2 bus 3 bge0 at pci3 dev 0 function 0 Broadcom BCM5754 rev 0x02, BCM5754/5787 A2 (0xb002): msi, address 00:18:8b:66:ff:e6 brgphy0 at bge0 phy 1: BCM5787 10/100/1000baseT PHY, rev. 0 uhci2 at pci0 dev 29 function 0 Intel 82801H USB rev 0x02: apic 8 int 23 uhci3 at pci0 dev 29 function 1 Intel 82801H USB rev 0x02: apic 8 int 17 uhci4 at pci0 dev 29 function 2 Intel 82801H USB rev 0x02: apic 8 int 18 ehci1 at pci0 dev 29 function 7 Intel 82801H USB rev 0x02: apic 8 int 23 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 Intel EHCI root hub rev 2.00/1.00 addr 1 ppb3 at pci0 dev 30 function 0 Intel 82801BA Hub-to-PCI rev 0xf2 pci4 at ppb3 bus 4 pcib0 at pci0 dev 31 function 0 Intel 82801H LPC rev 0x02 pciide0 at pci0 dev 31 function 2 Intel 82801H SATA rev 0x02: DMA, channel 0 configured to native-PCI, channel 1 configured to native-PCI pciide0: using apic 8 int 20 for native-PCI interrupt wd0 at pciide0 channel 0 drive 0:
Re: Disklabel on usb hdd wiped on crypto boot
On Mon, Jul 21, 2014 at 08:17:19PM +1200, Peter Kane wrote: Hello I have run into another strange problem on the Optiplex 745 in the dmesg below. It usually boots with a usb crypto key disk, but if I try to boot with a particular usb hard disk attached it will fail to find the key disk and will instead erase the disklabel on the usb hdd. The data is all OK if the disklabel is restored from file. The external disk in question is a 3 terabyte Seagate Expansion Desk unit (see end of dmesg). I tried another external hdd but it didn't suffer the same problem, and the Seagate wasn't wiped on other crypto machines that I tried it with. The boot loader searches disks presented by the BIOS for disklabels and softraid meta data. If the bootloader can't find the keydisk while the external 3TB unit is plugged in, then I'd suspect a problem in the way the BIOS handles this particular disk. You can run 'machine diskinfo' at the boot prompt to see how the BIOS presents disks to the boot loader. It's worth noting that Seagate's product page says 3TB volumes use 4K sectors: http://knowledge.seagate.com/articles/en_US/FAQ/005486en?language=en_US I'm not sure why the disklabel on the 3TB volume ends up being deleted...
Re: Disklabel on usb hdd wiped on crypto boot
On 21 July 2014 04:17, Peter Kane pwk...@gmail.com wrote: Hello I have run into another strange problem on the Optiplex 745 in the dmesg below. It usually boots with a usb crypto key disk, but if I try to boot with a particular usb hard disk attached it will fail to find the key disk and will instead erase the disklabel on the usb hdd. The data is all OK if the disklabel is restored from file. sd2 at scsibus5 targ 1 lun 0: Seagate, Expansion Desk, 070B SCSI4 0/direct fixed sd2: 2861588MB, 4096 bytes/sector, 732566645 sectors softraid only works on devices with 512 bytes/sector. Ken The external disk in question is a 3 terabyte Seagate Expansion Desk unit (see end of dmesg). I tried another external hdd but it didn't suffer the same problem, and the Seagate wasn't wiped on other crypto machines that I tried it with. Perhaps this is of interest to someone. I'm not sure if it is usb problem or what. Anyhow, I think it might about time this particular machine was decommissioned. Thanks, Peter OpenBSD 5.6-beta (GENERIC.MP) #290: Sat Jul 19 11:29:25 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3193958400 (3045MB) avail mem = 3100217344 (2956MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.3 @ 0xf0450 (77 entries) bios0: vendor Dell Inc. version 2.6.4 date 03/01/2010 bios0: Dell Inc. OptiPlex 745 acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP SSDT APIC BOOT ASF! MCFG HPET SSDT SSDT SSDT acpi0: wakeup devices VBTN(S4) PCI0(S5) PCI4(S5) PCI2(S5) PCI3(S5) PCI1(S5) PCI5(S5) PCI6(S5) MOU_(S3) USB0(S3) USB1(S3) USB2(S3) USB3(S3) USB4(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Pentium(R) D CPU 3.40GHz, 3389.45 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,EST,CNXT-ID,CX16,xTPR,PDCM,NXE,LONG,LAHF cpu0: 2MB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 199MHz cpu0: mwait min=64, max=64 cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Pentium(R) D CPU 3.40GHz, 3389.04 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,EST,CNXT-ID,CX16,xTPR,PDCM,NXE,LONG,LAHF cpu1: 2MB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 0, remapped to apid 8 acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 4 (PCI4) acpiprt1 at acpi0: bus 2 (PCI2) acpiprt2 at acpi0: bus -1 (PCI3) acpiprt3 at acpi0: bus 1 (PCI1) acpiprt4 at acpi0: bus 3 (PCI5) acpiprt5 at acpi0: bus -1 (PCI6) acpiprt6 at acpi0: bus 0 (PCI0) acpicpu0 at acpi0: PSS acpicpu1 at acpi0: PSS acpibtn0 at acpi0: VBTN cpu0: Enhanced SpeedStep 3389 MHz: speeds: 3400, 2400 MHz memory map conflict 0xbf603c00/0x9fc400 pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 Intel 82Q965 Host rev 0x02 ppb0 at pci0 dev 1 function 0 Intel 82Q965 PCIE rev 0x02: msi pci1 at ppb0 bus 1 vga1 at pci0 dev 2 function 0 Intel 82Q965 Video rev 0x02 intagp0 at vga1 agp0 at intagp0: aperture at 0xd000, size 0x1000 inteldrm0 at vga1 drm0 at inteldrm0 inteldrm0: 1024x768 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0: screen 1-5 added (std, vt100 emulation) Intel 82Q965 Video rev 0x02 at pci0 dev 2 function 1 not configured uhci0 at pci0 dev 26 function 0 Intel 82801H USB rev 0x02: apic 8 int 16 uhci1 at pci0 dev 26 function 1 Intel 82801H USB rev 0x02: apic 8 int 17 ehci0 at pci0 dev 26 function 7 Intel 82801H USB rev 0x02: apic 8 int 22 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 Intel 82801H HD Audio rev 0x02: msi azalia0: codecs: Analog Devices AD1983 audio0 at azalia0 ppb1 at pci0 dev 28 function 0 Intel 82801H PCIE rev 0x02: msi pci2 at ppb1 bus 2 ppb2 at pci0 dev 28 function 4 Intel 82801H PCIE rev 0x02: msi pci3 at ppb2 bus 3 bge0 at pci3 dev 0 function 0 Broadcom BCM5754 rev 0x02, BCM5754/5787 A2 (0xb002): msi, address 00:18:8b:66:ff:e6 brgphy0 at bge0 phy 1: BCM5787 10/100/1000baseT PHY, rev. 0 uhci2 at pci0 dev 29 function 0 Intel 82801H USB rev 0x02: apic 8 int 23 uhci3 at pci0 dev 29 function 1 Intel 82801H USB rev 0x02: apic 8 int 17 uhci4 at pci0 dev 29 function 2 Intel 82801H USB rev 0x02: apic 8 int 18 ehci1 at pci0 dev 29 function 7 Intel 82801H USB rev 0x02: apic 8 int 23 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 Intel EHCI root hub rev 2.00/1.00 addr 1 ppb3 at
Re: Disklabel on usb hdd wiped on crypto boot
sd2: 2861588MB, 4096 bytes/sector, 732566645 sectors I guess that clears that up. Thanks again, Peter
Re: udp checksum zero with inet6 rdr-to
vio0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 hwfeatures=10VLAN_MTU hardmtu 16000 Can you try a current snapshot? Problem persists on 5.6. Further testing suggests that this may only be happening if the packets exit the firewall via an ip6 tunnel (tun(4) interface). I am not seeing the problem between vlans on the same physical network using the same pf rule. Mike Stone
Re: rc.shutdown: No powerdown
running i386-current I noticed that despite having set powerdown=YES in rc.shutdown the system halts with Press any key to reboot. $ cat /etc/rc.shutdown | grep power powerdown=YES # set to YES for powerdown Did the logic change here? Yes, the logic changed. /etc/rc no longer evaluates other scripts, pulling in damage to it's variable space. Use halt -p or shutdown -p if you want to power down. I understand that there is contention over powerdown vs non-powerdown, but perhaps bringing this to the fore will result in a big decision about what to do.
Re: rc.shutdown: No powerdown
From: Theo de Raadt dera...@cvs.openbsd.org Date: Mon, 21 Jul 2014 14:32:16 -0600 running i386-current I noticed that despite having set powerdown=YES in rc.shutdown the system halts with Press any key to reboot. $ cat /etc/rc.shutdown | grep power powerdown=YES # set to YES for powerdown Did the logic change here? Yes, the logic changed. /etc/rc no longer evaluates other scripts, pulling in damage to it's variable space. Use halt -p or shutdown -p if you want to power down. I understand that there is contention over powerdown vs non-powerdown, but perhaps bringing this to the fore will result in a big decision about what to do. Any reason not to turn this into a rc.conf.local setting?
Re: rc.shutdown: No powerdown
From: Theo de Raadt dera...@cvs.openbsd.org Date: Mon, 21 Jul 2014 14:32:16 -0600 running i386-current I noticed that despite having set powerdown=YES in rc.shutdown the system halts with Press any key to reboot. $ cat /etc/rc.shutdown | grep power powerdown=YES # set to YES for powerdown Did the logic change here? Yes, the logic changed. /etc/rc no longer evaluates other scripts, pulling in damage to it's variable space. Use halt -p or shutdown -p if you want to power down. I understand that there is contention over powerdown vs non-powerdown, but perhaps bringing this to the fore will result in a big decision about what to do. Any reason not to turn this into a rc.conf.local setting? Moar buttons?
Re: udp checksum zero with inet6 rdr-to
On Mon, Jul 21, 2014 at 04:25:46PM -0400, Michael Stone wrote: Problem persists on 5.6. Further testing suggests that this may only be happening if the packets exit the firewall via an ip6 tunnel (tun(4) interface). I am not seeing the problem between vlans on the same physical network using the same pf rule. Can you discribe you setup a bit more? What application do you run on tun? aiccu? ifconfig tun? Are the packets forwarded or locally generated? Where and how do you measure the checksum 0? Can you provide tpcdump -X before and after the tunnel encapsulation? On which interface do you redirect? Are those incomming packets on tun? bluhm [demime 1.01d removed an attachment of type application/pgp-signature]
Re: rc.shutdown: No powerdown
Am Mon, 21 Jul 2014 14:32:16 -0600 schrieb Theo de Raadt dera...@cvs.openbsd.org: running i386-current I noticed that despite having set powerdown=YES in rc.shutdown the system halts with Press any key to reboot. $ cat /etc/rc.shutdown | grep power powerdown=YES # set to YES for powerdown Did the logic change here? Yes, the logic changed. /etc/rc no longer evaluates other scripts, pulling in damage to it's variable space. Use halt -p or shutdown -p if you want to power down. I understand that there is contention over powerdown vs non-powerdown, but perhaps bringing this to the fore will result in a big decision about what to do. Thank you, Theo, for the clarification. I guess setting up an alias (s.th. like bye = 'halt -p') will do it as well - though 'halt -p' is not _really_ inconvenient :-) STEFAN
Re: rc.shutdown: No powerdown
From owner-bugs+M22415=deraadt=cvs.openbsd@openbsd.org Mon Jul 21 15:15:06 2014 X-Virus-Scanned: amavisd-new at posteo.de Date: Mon, 21 Jul 2014 23:13:41 +0200 From: Stefan Wollny ste...@wollny.de To: bugs@openbsd.org Subject: Re: rc.shutdown: No powerdown In-Reply-To: 201407212032.s6lkwgsh029...@cvs.openbsd.org References: 201407212032.s6lkwgsh029...@cvs.openbsd.org X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.24; i386-unknown-openbsd5.6) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit List-Help: mailto:majord...@openbsd.org?body=help List-ID: bugs.openbsd.org List-Owner: mailto:owner-b...@openbsd.org List-Post: mailto:bugs@openbsd.org List-Subscribe: mailto:majord...@openbsd.org?body=sub%20bugs List-Unsubscribe: mailto:majord...@openbsd.org?body=unsub%20bugs X-Loop: bugs@openbsd.org Precedence: list Sender: owner-b...@openbsd.org Am Mon, 21 Jul 2014 14:32:16 -0600 schrieb Theo de Raadt dera...@cvs.openbsd.org: running i386-current I noticed that despite having set powerdown=YES in rc.shutdown the system halts with Press any key to reboot. $ cat /etc/rc.shutdown | grep power powerdown=YES # set to YES for powerdown Did the logic change here? Yes, the logic changed. /etc/rc no longer evaluates other scripts, pulling in damage to it's variable space. Use halt -p or shutdown -p if you want to power down. I understand that there is contention over powerdown vs non-powerdown, but perhaps bringing this to the fore will result in a big decision about what to do. Thank you, Theo, for the clarification. I guess setting up an alias (s.th. like bye = 'halt -p') will do it as well - though 'halt -p' is not _really_ inconvenient :-) STEFAN
Re: ChaCha20 implementation in libssl produces incorrect results in some cases
The random tests are encrypting small blocks of data (the first between 0 and 15 bytes per write, the second between 65 and 128) using the same key and IV - this is basically the worst case scenario and the byte-at-a-time algorithm is almost certainly more performant. However, this is not likely to be a good example of real-world use - it probably matches SSH interactive use, although even then the IV/block counter is reset between calls. For SSH bulk you're likely to be encrypting 8-16KB blocks at a time, for SSL up to 16KB blocks and for file encryption, anything up to 2^70 bytes. If you are interested in doing further benchmarks it would be interesting to measure performance for 8KB, 16KB and larger blocks, changing the IV in between. Encrypting/decrypting a single large file (using a single key/IV) would also be an interesting measurement. It appears you are correct. I tested with 100,000 16KB blocks, and the code in OpenBSD is showing a small performance advantage. However, when using clang, the code on the blog seems to do significantly better than with GCC, then, the difference between the two is minuscule. It is also worth noting that the performance of the block optimised code is still going to be well below the performance of a well implemented assembly version. Are you guys waiting for OpenSSL to put out optimized assembly code for ChaCha20 to use? Just to be clear, chacha_encrypt_bytes() is not my code - the original was written by D. J. Bernstein (http://cr.yp.to/chacha.html). I just imported it and applied KNF to it. I'm sorry, I didn't mean to imply you wrote it. I meant to say that the code you guys were currently using just looked awful. Looking at this new code, I also see it has an interesting comment regarding incrementing the counter. Is there any validity to the approach its taking? Would that be more secure for very long streams? It should only make a difference if you encrypt 2^70 bytes using a single key and IV. For the time being I do not see that being a problem. Any sensible application is going to chunk the data and change the IV. Okay, thank you. I had a look around different implementations I could find on GitHub, and it seems each library is taking their own unique approach with increment the nonce/IV. I wonder if this is going to cause interoperability issues. J
Re: udp checksum zero with inet6 rdr-to
On Mon, Jul 21, 2014 at 11:05:54PM +0200, Alexander Bluhm wrote: What application do you run on tun? aiccu? Yes, aiccu. Are the packets forwarded or locally generated? Forwarded. Where and how do you measure the checksum 0? At either the firewall as the packets exit, or at the remote end. Can you provide tpcdump -X before and after the tunnel encapsulation? Sending directly. On which interface do you redirect? At this point I'm using a rule like this: pass in proto udp to [DADDR] port [DPORT] rdr-to [OTHERADDR] port [OTHERPORT] Are those incomming packets on tun? The route is symmetric (so the requests from a local vlan come in directly over the vlan interface, the external requests pass through the tun). Mike Stone
