xhci related kernel panic
Hi everyone,
I had to type this off the screen. My USB keyboard does not work
at the ddb prompt so I cannot provide more information.
xhci_pipe_open: pipe=0x80493000 addr=2 depth=1 port=9 speed=2
xhci0: dev 1 dci 3 (epAddr=0x81)
xhci0: speed 1 mps 8 rhport 9 route 0x0
xhci0: max ESIT payload = 8, average TRB length = 8
xhci0: xhci_cmd_configure_ep
xhci_abort_xfer: xfer=0xff021e3482d0 err=CANCELLED
xhci0: error stopping ep (3)
xhci0: xhci_cmd_configure_ep
xhci_pipe_open: pipe=0x80493000 addr=2 depth=1 port=9 speed=2
xhci0: dev 1 dci 3 (epAddr=0x81)
xhci0: speed 1 mps 8 rhport 9 route 0x0
uvm_fault(0xff01e7f04b60, 0x0, 0, 2) - e
kernel: page fault trap, code=0
Stopped at xhci_pipe_init+0x1d7: movl %ecx,0(%rax)
ddb{3}
I built the kernel today and this started happening. My previous
build was from the 2nd of Novemember. I believe xhci was disabled
at that time.
The panic only happens if I have a USB device connected during boot
(either my mouse or keyboard). If I plug them in incrementally once
I reach the login prompt, the system does not panic.
I am providing a dmesg below captured with XHCI_DEBUG enabled.
This dmesg was captured by booting with no USB devices attached, then
manually attaching my USB mouse and keyboard.
Is there anything else I could do to help debug this?
OpenBSD 5.6-current (GENERIC.MP) #7: Sun Nov 9 12:19:51 GMT 2014
r...@pancakes.2f30.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 7450062848 (7104MB)
avail mem = 7247908864 (6912MB)
warning: no entropy supplied by boot loader
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xec1e0 (76 entries)
bios0: vendor American Megatrends Inc. version 1.03 date 06/18/2014
bios0: Shuttle Inc. XH81V
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT SLIC SSDT SSDT MCFG HPET SSDT SSDT
acpi0: wakeup devices PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4)
PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) PXSX(S4) RP06(S4) PXSX(S4) RP07(S4)
PXSX(S4) RP08(S4) [...]
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) Core(TM) i3-4360 CPU @ 3.70GHz, 3691.97 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 99MHz
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i3-4360 CPU @ 3.70GHz, 3691.47 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
cpu2 at mainbus0: apid 1 (application processor)
cpu2: Intel(R) Core(TM) i3-4360 CPU @ 3.70GHz, 3691.47 MHz
cpu2:
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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 1, core 0, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Core(TM) i3-4360 CPU @ 3.70GHz, 3691.47 MHz
cpu3:
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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (RP01)
acpiprt2 at acpi0: bus 2 (RP03)
acpiprt3 at acpi0: bus 3 (RP04)
acpiprt4 at acpi0: bus -1 (PEG0)
acpiec0 at acpi0: not present
acpicpu0 at acpi0: C1, PSS
acpicpu1 at acpi0: C1, PSS
acpicpu2 at acpi0: C1, PSS
acpicpu3 at acpi0: C1, PSS
acpipwrres0 at acpi0: FN00, resource for FAN0
acpipwrres1 at acpi0: FN01, resource for FAN1
acpipwrres2 at acpi0: FN02, resource for FAN2
acpipwrres3 at acpi0: FN03, resource for FAN3
acpipwrres4 at acpi0: FN04, resource for
Re: xhci related kernel panic
Hi, ../../../../dev/usb/xhci.c:1109 2c26: 4a 8d 14 ba lea(%rdx,%r15,4),%rdx 2c2a: 48 8d 44 10 01 lea0x1(%rax,%rdx,1),%rax 2c2f: 49 8b 84 c5 b8 05 00mov0x5b8(%r13,%rax,8),%rax 2c36: 00 2c37: 89 08 mov%ecx,(%rax) That's also the relevant objdump section.
xhci problems on Thinkpad X240
Hi, my X240 has 2 USB3.0 ports. I use one of them to connect a urtwn(4) usb wifi dongle since the internal intel wifi is not (yet) supported. After the recent commit to enable xhci, I tried to switch the BIOS USB3 support mode from 'disabled' to 'auto'. This make urtwn0 attach to the xhci hub, but it doesn't work (device timeout). See dmesg below. detaching and re-attaching it doesn't make a difference. OpenBSD 5.6-current (GENERIC.MP) #44: Sun Nov 9 14:41:25 CET 2014 matth...@nebraska.herrb.net:/usr/obj/GENERIC.MP real mem = 8246276096 (7864MB) avail mem = 8022933504 (7651MB) warning: no entropy supplied by boot loader mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdcd3d000 (60 entries) bios0: vendor LENOVO version GIET73WW (2.23 ) date 04/10/2014 bios0: LENOVO 20ALCTO1WW acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC DBGP ECDT HPET APIC MCFG SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT PCCT SSDT TCPA UEFI MSDM ASF! BATB FPDT UEFI SSDT DMAR acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) EHC1(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz, 1995.71 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz, 1995.38 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz, 1995.38 MHz cpu2: 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz, 1995.38 MHz cpu3: 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 2 (EXP1) acpiprt3 at acpi0: bus 3 (EXP2) acpiprt4 at acpi0: bus -1 (EXP3) acpicpu0 at acpi0: C3, C1, PSS acpicpu1 at acpi0: C3, C1, PSS acpicpu2 at acpi0: C3, C1, PSS acpicpu3 at acpi0: C3, C1, PSS acpipwrres0 at acpi0: PUBS, resource for XHCI, EHC1 acpitz0 at acpi0: critical temperature is 200 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 model 45N1773 serial 16792 type LION oem SANYO acpibat1 at acpi0: BAT1 model 45N1738 serial 3066 type LION oem LGC acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0 cpu0: Enhanced SpeedStep 1995 MHz: speeds: 2701, 2700, 2600, 2400, 2300, 2100, 2000, 1800, 1700, 1600, 1400, 1300, 1100, 1000, 800, 756 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 Intel Core 4G Host rev 0x0b vga1 at pci0 dev 2 function 0 Intel HD Graphics rev 0x0b intagp at vga1 not configured inteldrm0 at vga1 drm0 at inteldrm0 drm: Memory usable by graphics device = 2048M error: [drm:pid0:i915_write32] *ERROR* Unknown unclaimed register before writing to 10 error: [drm:pid0:intel_dp_set_link_train] *ERROR* Timed out waiting for DP idle patterns error: [drm:pid0:i915_write32] *ERROR* Unknown unclaimed register before writing to 64040 inteldrm0: 1366x768 wsdisplay0 at vga1 mux 1: console (std, vt100 emulation) wsdisplay0:
Re: xhci related kernel panic
Hello Dimitris,
On 09/11/14(Sun) 12:39, Dimitris Papastamos wrote:
Hi everyone,
I had to type this off the screen. My USB keyboard does not work
at the ddb prompt so I cannot provide more information.
xhci_pipe_open: pipe=0x80493000 addr=2 depth=1 port=9 speed=2
xhci0: dev 1 dci 3 (epAddr=0x81)
xhci0: speed 1 mps 8 rhport 9 route 0x0
xhci0: max ESIT payload = 8, average TRB length = 8
xhci0: xhci_cmd_configure_ep
xhci_abort_xfer: xfer=0xff021e3482d0 err=CANCELLED
xhci0: error stopping ep (3)
xhci0: xhci_cmd_configure_ep
xhci_pipe_open: pipe=0x80493000 addr=2 depth=1 port=9 speed=2
xhci0: dev 1 dci 3 (epAddr=0x81)
xhci0: speed 1 mps 8 rhport 9 route 0x0
uvm_fault(0xff01e7f04b60, 0x0, 0, 2) - e
kernel: page fault trap, code=0
Stopped atxhci_pipe_init+0x1d7: movl %ecx,0(%rax)
ddb{3}
Thanks for the report. I just committed a fix for this. The problem
was in the code closing the pipe. This would only matter for devices
closing opening multiple times their pipes, like mouses or keyboards
when they are opened/closed.
Please let met know if you still have a problem.
Martin
Re: xhci related kernel panic
On Sun, Nov 09, 2014 at 03:01:47PM +0100, Martin Pieuchot wrote: Thanks for the report. I just committed a fix for this. The problem was in the code closing the pipe. This would only matter for devices closing opening multiple times their pipes, like mouses or keyboards when they are opened/closed. Please let met know if you still have a problem. I can confirm it is working now. Thanks for the quick fix! :)
patch: crash on large files
Hi, our patch implementation supports lines with a maximum of 8192 chars, which should be reasonably large enough. If files cannot be patched in memory, they are written into temporary files -- also known as plan b. For plan b, the maximum line length is 1024, which is still more than enough. At least for real life use cases. FYI: The buffer size is used to create the temporary files in a RAM way. Every line takes 1024 bytes so it's quite easy to jump around in that file and fetch lines. Unfortunately this limit is not properly checked while performing a plan b patch. Here is how to reproduce: First, prepare two files which are 1024 chars in size in one line and differ. The first one contains lots of c's, the other lots of d's. Finally, create a diff. $ tr '\0' c /dev/zero | dd bs=1k count=1 of=file1 $ tr '\0' d /dev/zero | dd bs=1k count=1 of=file2 $ diff -Nau file1 file2 file.diff Now try to patch it (-x 8 enforces plan b): $ patch -x 8 -Np1 -i file.diff Hmm... Looks like a unified diff to me... The text leading up to this was: -- |--- file1 Sun Nov 9 17:49:14 2014 |+++ file2 Sun Nov 9 17:49:18 2014 -- Floating point exception (core dumped) $ _ This fix is not as comprehensive as what GNU patch did. They totally removed the line length limitations -- something that sounds interesting but probably not common enough to encounter. At least not common enough for me to actually address the limitations. Instead, just make sure that we properly bail out if lines are too long. Tobias Index: inp.c === RCS file: /cvs/src/usr.bin/patch/inp.c,v retrieving revision 1.38 diff -u -p -r1.38 inp.c --- inp.c 8 Oct 2014 04:06:23 - 1.38 +++ inp.c 9 Nov 2014 16:45:33 - @@ -381,6 +381,8 @@ plan_b(const char *filename) revision); } fseek(ifp, 0L, SEEK_SET); /* rewind file */ + if (maxlen BUFFERSIZE) + fatal(lines too long\n); lines_per_buf = BUFFERSIZE / maxlen; tireclen = maxlen; tibuf[0] = malloc(BUFFERSIZE + 1);
Re: xhci problems on Thinkpad X240
Matthieu Herrb writes: Hi, my X240 has 2 USB3.0 ports. I use one of them to connect a urtwn(4) usb wifi dongle since the internal intel wifi is not (yet) supported. After the recent commit to enable xhci, I tried to switch the BIOS USB3 support mode from 'disabled' to 'auto'. This make urtwn0 attach to the xhci hub, but it doesn't work (device timeout). See dmesg below. detaching and re-attaching it doesn't make a difference. I have the same setup (x240 with urtwn) and ran into the same issue. OpenBSD 5.6-current (GENERIC.MP) #44: Sun Nov 9 14:41:25 CET 2014 matth...@nebraska.herrb.net:/usr/obj/GENERIC.MP real mem = 8246276096 (7864MB) avail mem = 8022933504 (7651MB) warning: no entropy supplied by boot loader mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdcd3d000 (60 entries) bios0: vendor LENOVO version GIET73WW (2.23 ) date 04/10/2014 bios0: LENOVO 20ALCTO1WW acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC DBGP ECDT HPET APIC MCFG SSDT SSDT SSDT SSDT SSDT SSDT SSDT SSDT PCCT SSDT TCPA UEFI MSDM ASF! BATB FPDT UEFI SSDT DMAR acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP2(S4) XHCI(S3) EHC1(S3) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz, 1995.71 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz, 1995.38 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz, 1995.38 MHz cpu2: 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 1, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz, 1995.38 MHz cpu3: 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,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,BMI1,HLE,AVX2,SMEP,BMI2,ERMS,INVPCID,RTM cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 2 (EXP1) acpiprt3 at acpi0: bus 3 (EXP2) acpiprt4 at acpi0: bus -1 (EXP3) acpicpu0 at acpi0: C3, C1, PSS acpicpu1 at acpi0: C3, C1, PSS acpicpu2 at acpi0: C3, C1, PSS acpicpu3 at acpi0: C3, C1, PSS acpipwrres0 at acpi0: PUBS, resource for XHCI, EHC1 acpitz0 at acpi0: critical temperature is 200 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 model 45N1773 serial 16792 type LION oem SANYO acpibat1 at acpi0: BAT1 model 45N1738 serial 3066 type LION oem LGC acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0 cpu0: Enhanced SpeedStep 1995 MHz: speeds: 2701, 2700, 2600, 2400, 2300, 2100, 2000, 1800, 1700, 1600, 1400, 1300, 1100, 1000, 800, 756 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 Intel Core 4G Host rev 0x0b vga1 at pci0 dev 2 function 0 Intel HD Graphics rev 0x0b intagp at vga1 not configured inteldrm0 at vga1 drm0 at inteldrm0 drm: Memory usable by graphics device = 2048M error: [drm:pid0:i915_write32] *ERROR* Unknown unclaimed register before writing to 10 error: [drm:pid0:intel_dp_set_link_train] *ERROR* Timed out waiting for DP idle
rwho on OpenBSD 5.6
Hi all, I just updated to OpenBSD 5.6 and I was happy to see that rcp, rsh, rshd, rwho, rwhod, etc have been removed (at least according to the Changelog). However, the upgrade instructions fail to mention that files like /etc/rc.d/rwhod or /usr/bin/rwho should be removed. Sören.
mg: exit code cleanup
mg(1) calls 'exit(1)' on failure, but 'exit(GOOD)' on success. In my
opinion it would be more readable to just use 'exit(0)' for a normal
exit. (If there really is the need for a define, EXIT_SUCCESS would be a
better fit anyways, and EXIT_* should be applied consistently.)
Also, the MALLOCROUND() macro is unused and can be removed.
See diff below; no binary change.
cheers,
natano
Index: main.c
===
RCS file: /cvs/src/usr.bin/mg/main.c,v
retrieving revision 1.72
diff -u -r1.72 main.c
--- main.c 22 Mar 2014 11:05:37 - 1.72
+++ main.c 9 Nov 2014 19:19:24 -
@@ -235,7 +235,7 @@
|| eyesno(Modified buffers exist; really exit) == TRUE) {
vttidy();
closetags();
- exit(GOOD);
+ exit(0);
}
return (TRUE);
}
Index: sysdef.h
===
RCS file: /cvs/src/usr.bin/mg/sysdef.h,v
retrieving revision 1.16
diff -u -r1.16 sysdef.h
--- sysdef.h15 Sep 2008 16:11:35 - 1.16
+++ sysdef.h9 Nov 2014 19:19:14 -
@@ -15,12 +15,9 @@
#include signal.h
#defineKBLOCK 8192/* Kill grow.*/
-#defineGOOD0 /* Good exit status. */
typedef intRSIZE; /* Type for file/region sizes*/
typedef short KCHAR; /* Type for internal keystrokes */
-
-#define MALLOCROUND(m) (m+=7,m=~7)/* round up to 8 byte boundary */
struct fileinfo {
uid_t fi_uid;
Re: rwho on OpenBSD 5.6
I just updated to OpenBSD 5.6 and I was happy to see that rcp, rsh, rshd, rwho, rwhod, etc have been removed (at least according to the Changelog). However, the upgrade instructions fail to mention that files like /etc/rc.d/rwhod or /usr/bin/rwho should be removed. How much of a catastrophy is this? Question for the community: Do you want the upgrade instructions to be 100% useful, or 100% complete?
Re: LibreSSL: GOST ciphers implementation
The libcrypto parts of the GOST ciphers have been commited, and barring any objection from the usual LibreSSL suspects, will be enabled in the not-so-far-away future. The libssl parts are still under consideration. I have one concern and one question about them: - I understand from the ``FIXME IANA'' comments that the various cipher and extension IDs used by GOST are not official yet. Are these values generally agreed upon by the websites which serve content using GOST algorithms? - Speaking of which, do you have any GOST-enabled websites we can use to confirm interoperability? TIA, Miod
Re: rwho on OpenBSD 5.6
On Sun, Nov 09, 2014 at 01:36:59PM -0700, Theo de Raadt wrote: I just updated to OpenBSD 5.6 and I was happy to see that rcp, rsh, rshd, rwho, rwhod, etc have been removed (at least according to the Changelog). However, the upgrade instructions fail to mention that files like /etc/rc.d/rwhod or /usr/bin/rwho should be removed. How much of a catastrophy is this? Question for the community: Do you want the upgrade instructions to be 100% useful, or 100% complete? 100% complete should be the goal. I expect a system that is upgraded from 5.5 to 5.6 (following the upgrade documentation) to be in the _exact_ same state as a clean 5.6 installation, barring changes local to the system. Kind regards, Job
Re: rwho on OpenBSD 5.6
Le Dimanche 9 Novembre 2014 21:36 CET, Theo de Raadt dera...@cvs.openbsd.org a écrit: I just updated to OpenBSD 5.6 and I was happy to see that rcp, rsh, rshd, rwho, rwhod, etc have been removed (at least according to the Changelog). However, the upgrade instructions fail to mention that files like /etc/rc.d/rwhod or /usr/bin/rwho should be removed. How much of a catastrophy is this? Question for the community: Do you want the upgrade instructions to be 100% useful, or 100% complete? Hi, IMHO, first useful then complete . -- Eric JACQUOT
Re: rwho on OpenBSD 5.6
On 2014/11/09 22:08, Job Snijders wrote: On Sun, Nov 09, 2014 at 01:36:59PM -0700, Theo de Raadt wrote: I just updated to OpenBSD 5.6 and I was happy to see that rcp, rsh, rshd, rwho, rwhod, etc have been removed (at least according to the Changelog). However, the upgrade instructions fail to mention that files like /etc/rc.d/rwhod or /usr/bin/rwho should be removed. How much of a catastrophy is this? Question for the community: Do you want the upgrade instructions to be 100% useful, or 100% complete? 100% complete should be the goal. I expect a system that is upgraded from 5.5 to 5.6 (following the upgrade documentation) to be in the _exact_ same state as a clean 5.6 installation, barring changes local to the system. I disagree. Consider the case of default MTA or default web server. I expect the upgrade instructions to show me how to upgrade the system keeping it running as before as much as possible. If I wanted it to work how it does on a clean install, I'd just do a clean install...
Re: LibreSSL: GOST ciphers implementation
2014-11-09 23:38 GMT+03:00 Miod Vallat m...@online.fr: The libcrypto parts of the GOST ciphers have been commited, and barring any objection from the usual LibreSSL suspects, will be enabled in the not-so-far-away future. The libssl parts are still under consideration. I have one concern and one question about them: - I understand from the ``FIXME IANA'' comments that the various cipher and extension IDs used by GOST are not official yet. Are these values generally agreed upon by the websites which serve content using GOST algorithms? These values are provided as 'temporal private values till IANA provides registered values'. http://tc26.ru/methods/recommendation/%D0%A2%D0%9A26TLS.pdf page 12 (sorry, Russian only). - Speaking of which, do you have any GOST-enabled websites we can use to confirm interoperability? Yes. https://zakupki.gov.ru/ is compatible with -2001 version of standards. CryptoPro provides the following sites to test compatibility with -2012 version: http://tlsgost-2001auth.cryptopro.ru/ http://tlsgost-256auth.cryptopro.ru/ http://tlsgost-512auth.cryptopro.ru/ http://tlsgost-2001.cryptopro.ru/ http://tlsgost-256.cryptopro.ru/ http://tlsgost-512.cryptopro.ru/ Each of the sites contains buttons that will lead to ports :443, :1443, etc. (one per curve) to verify interoperability with their software. -- With best wishes Dmitry
Re: rwho on OpenBSD 5.6
Stuart Henderson st...@openbsd.org wrote: On 2014/11/09 22:08, Job Snijders wrote: On Sun, Nov 09, 2014 at 01:36:59PM -0700, Theo de Raadt wrote: I just updated to OpenBSD 5.6 and I was happy to see that rcp, rsh, rshd, rwho, rwhod, etc have been removed (at least according to the Changelog). However, the upgrade instructions fail to mention that files like /etc/rc.d/rwhod or /usr/bin/rwho should be removed. How much of a catastrophy is this? Question for the community: Do you want the upgrade instructions to be 100% useful, or 100% complete? 100% complete should be the goal. I expect a system that is upgraded from 5.5 to 5.6 (following the upgrade documentation) to be in the _exact_ same state as a clean 5.6 installation, barring changes local to the system. I disagree. Consider the case of default MTA or default web server. I expect the upgrade instructions to show me how to upgrade the system keeping it running as before as much as possible. If I wanted it to work how it does on a clean install, I'd just do a clean install... The old binaries won't run on the new kernel anyway. When the default has been changed but the old default remains, the upgrade instructions should say so and say what to do to change the default. You can continue running the old default if you want. When the old software has been removed completely, the old binaries are useless anyway. The instructions should be complete, but nobody should ever run who on a 5.6 system. Therefore you could claim running rwho is undefined, so it doesn't matter whether it still exists or not. Maybe this isn't such a good idea if /usr/bin comes before /usr/local/bin in your path. -- Martin Brandenburg
Re: rwho on OpenBSD 5.6
On 2014/11/09 21:41, Martin Brandenburg wrote: Stuart Henderson st...@openbsd.org wrote: On 2014/11/09 22:08, Job Snijders wrote: On Sun, Nov 09, 2014 at 01:36:59PM -0700, Theo de Raadt wrote: I just updated to OpenBSD 5.6 and I was happy to see that rcp, rsh, rshd, rwho, rwhod, etc have been removed (at least according to the Changelog). However, the upgrade instructions fail to mention that files like /etc/rc.d/rwhod or /usr/bin/rwho should be removed. How much of a catastrophy is this? Question for the community: Do you want the upgrade instructions to be 100% useful, or 100% complete? 100% complete should be the goal. I expect a system that is upgraded from 5.5 to 5.6 (following the upgrade documentation) to be in the _exact_ same state as a clean 5.6 installation, barring changes local to the system. I disagree. Consider the case of default MTA or default web server. I expect the upgrade instructions to show me how to upgrade the system keeping it running as before as much as possible. If I wanted it to work how it does on a clean install, I'd just do a clean install... The old binaries won't run on the new kernel anyway. When the default Very often, the old binaries will still run, at least within a couple of releases. There are some special cases where they won't (like the time_t flag day), but they aren't all that frequent, that's why they're called flag days. has been changed but the old default remains, the upgrade instructions should say so and say what to do to change the default. You can continue running the old default if you want. When the old software has been removed completely, the old binaries are useless anyway. I was answering the specific point about the _exact_ same state as a clean 5.6 installation there. There are some specific cases where it makes a lot of sense to tell people to rm things (e.g. base program moved to ports). And some cases where it really doesn't matter (old gcc-lib, site_perl dirs), people who particularly want a cleaned-up system will use find, others won't care. And some like this where it could probably go either way.. The instructions should be complete, but nobody should ever run who on a 5.6 system. Therefore you could claim running rwho is undefined, so it doesn't matter whether it still exists or not. Maybe this isn't such a good idea if /usr/bin comes before /usr/local/bin in your path. -- Martin Brandenburg
Re: LibreSSL: GOST ciphers implementation
... and while I'm mopping this code, I believe the following change is correct: Index: gostr341001_pmeth.c === RCS file: /cvs/src/lib/libssl/src/crypto/gost/gostr341001_pmeth.c,v retrieving revision 1.4 diff -u -p -r1.4 gostr341001_pmeth.c --- gostr341001_pmeth.c 9 Nov 2014 19:28:44 - 1.4 +++ gostr341001_pmeth.c 9 Nov 2014 22:03:37 - @@ -316,7 +316,7 @@ static int gost01_VKO_key(EVP_PKEY * pub case NID_id_tc26_gost3411_2012_512: GOST_bn2le(X, hashbuf, 64); GOST_bn2le(Y, hashbuf + 64, 64); - STREEBOG256(hashbuf, 128, key); + STREEBOG512(hashbuf, 128, key); ret = 1; break; default:
Re: LibreSSL: GOST ciphers implementation
2014-11-10 1:04 GMT+03:00 Miod Vallat m...@online.fr: ... and while I'm mopping this code, I believe the following change is correct: Index: gostr341001_pmeth.c === RCS file: /cvs/src/lib/libssl/src/crypto/gost/gostr341001_pmeth.c,v retrieving revision 1.4 diff -u -p -r1.4 gostr341001_pmeth.c --- gostr341001_pmeth.c 9 Nov 2014 19:28:44 - 1.4 +++ gostr341001_pmeth.c 9 Nov 2014 22:03:37 - @@ -316,7 +316,7 @@ static int gost01_VKO_key(EVP_PKEY * pub case NID_id_tc26_gost3411_2012_512: GOST_bn2le(X, hashbuf, 64); GOST_bn2le(Y, hashbuf + 64, 64); - STREEBOG256(hashbuf, 128, key); + STREEBOG512(hashbuf, 128, key); ret = 1; break; default: No. The generated session key should be exactly 256 bits long - it is used for GOST 28147-89 later. -- With best wishes Dmitry
Re: rwho on OpenBSD 5.6
On Sun, Nov 09, 2014 at 10:02:32PM +, Stuart Henderson wrote: I was answering the specific point about the _exact_ same state as a clean 5.6 installation there. There are some specific cases where it makes a lot of sense to tell people to rm things (e.g. base program moved to ports). And some cases where it really doesn't matter (old gcc-lib, site_perl dirs), people who particularly want a cleaned-up system will use find, others won't care. And some like this where it could probably go either way.. If during the upgrade you decide to continue using the then non-default MTA I consider that a local change. Documentation helps identify which parts of your system are non-5.6-default. In the case of rwho friends it should have been documentated, and probably a 'rm' hint should have been provided. Kind regards, Job
Re: LibreSSL: GOST ciphers implementation
- I understand from the ``FIXME IANA'' comments that the various cipher and extension IDs used by GOST are not official yet. Are these values generally agreed upon by the websites which serve content using GOST algorithms? These values are provided as 'temporal private values till IANA provides registered values'. http://tc26.ru/methods/recommendation/%D0%A2%D0%9A26TLS.pdf page 12 (sorry, Russian only). That's authorative enough for me. - Speaking of which, do you have any GOST-enabled websites we can use to confirm interoperability? Yes. https://zakupki.gov.ru/ is compatible with -2001 version of standards. CryptoPro provides the following sites to test compatibility with -2012 version: [...] Thanks!
Re: rwho on OpenBSD 5.6
On Sun, Nov 09, 2014 at 10:02:32PM +, Stuart Henderson wrote: I was answering the specific point about the _exact_ same state as a clean 5.6 installation there. There are some specific cases where it makes a lot of sense to tell people to rm things (e.g. base program moved to ports). And some cases where it really doesn't matter (old gcc-lib, site_perl dirs), people who particularly want a cleaned-up system will use find, others won't care. And some like this where it could probably go either way.. If during the upgrade you decide to continue using the then non-default MTA I consider that a local change. Documentation helps identify which parts of your system are non-5.6-default. In the case of rwho friends it should have been documentated, and probably a 'rm' hint should have been provided. Kind regards, The right way to express your dissapointment with the current handling of current.html, is to submit changes to the web pages before others do. Not complaints. Changes. The complaint department is down the hall.
Re: rwho on OpenBSD 5.6
On Sun, Nov 09, 2014 at 01:36:59PM -0700, Theo de Raadt wrote: I just updated to OpenBSD 5.6 and I was happy to see that rcp, rsh, rshd, rwho, rwhod, etc have been removed (at least according to the Changelog). However, the upgrade instructions fail to mention that files like /etc/rc.d/rwhod or /usr/bin/rwho should be removed. How much of a catastrophy is this? Question for the community: Do you want the upgrade instructions to be 100% useful, or 100% complete? 100% complete should be the goal. I expect a system that is upgraded from 5.5 to 5.6 (following the upgrade documentation) to be in the _exact_ same state as a clean 5.6 installation, barring changes local to the system. Such strong words. Basically, you are requesting others to do a lot of work. It must be easy to sit in your chair and demand that others meet your expectations.
LibreSSL GOST code cleanup
The following diff attempts to polish the GOST code in libcrypto and add
many missing error checks (probably not exhaustive, but a good start).
A few KNF changes are included because I'm a tad too lazy to manually
split the diff at this point...
Important changes are mostly:
- VKO_compute_key() is no longer void and can instead return failure.
- unchecked allocations in too many routines to mention /-:
- unchecked BN operations in gost2001_do_sign(), gost2001_do_verify(),
VKO_compute_key().
I am also considering fixing the gost2001_do_sign() interface violation
(it frees something which has been allocated by its caller), if only to
make it match gost2001_do_verify(), which leaves the responsibility to
the caller; but that will happen in a later diff.
Miod
Index: evp/e_gost2814789.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/evp/e_gost2814789.c,v
retrieving revision 1.2
diff -u -p -r1.2 e_gost2814789.c
--- evp/e_gost2814789.c 9 Nov 2014 23:06:50 - 1.2
+++ evp/e_gost2814789.c 9 Nov 2014 23:10:04 -
@@ -87,27 +87,31 @@ gost2814789_ctl(EVP_CIPHER_CTX *ctx, int
}
}
-static int gost2814789_init_key(EVP_CIPHER_CTX *ctx, const unsigned char *key,
- const unsigned char *iv, int enc)
+static int
+gost2814789_init_key(EVP_CIPHER_CTX *ctx, const unsigned char *key,
+const unsigned char *iv, int enc)
{
EVP_GOST2814789_CTX *c = ctx-cipher_data;
return Gost2814789_set_key(c-ks, key, ctx-key_len * 8);
}
-int gost2814789_set_asn1_params(EVP_CIPHER_CTX * ctx, ASN1_TYPE * params)
+int
+gost2814789_set_asn1_params(EVP_CIPHER_CTX *ctx, ASN1_TYPE *params)
{
int len = 0;
unsigned char *buf = NULL;
unsigned char *p = NULL;
EVP_GOST2814789_CTX *c = ctx-cipher_data;
- GOST_CIPHER_PARAMS *gcp = GOST_CIPHER_PARAMS_new();
ASN1_OCTET_STRING *os = NULL;
- if (!gcp) {
- GOSTerr(GOST_F_GOST89_SET_ASN1_PARAMETERS,
ERR_R_MALLOC_FAILURE);
+ GOST_CIPHER_PARAMS *gcp = GOST_CIPHER_PARAMS_new();
+
+ if (gcp == NULL) {
+ GOSTerr(GOST_F_GOST89_SET_ASN1_PARAMETERS,
+ ERR_R_MALLOC_FAILURE);
return 0;
}
- if (!ASN1_OCTET_STRING_set(gcp-iv, ctx-iv, ctx-cipher-iv_len)) {
+ if (ASN1_OCTET_STRING_set(gcp-iv, ctx-iv, ctx-cipher-iv_len) == 0) {
GOST_CIPHER_PARAMS_free(gcp);
GOSTerr(GOST_F_GOST89_SET_ASN1_PARAMETERS, ERR_R_ASN1_LIB);
return 0;
@@ -117,17 +121,24 @@ int gost2814789_set_asn1_params(EVP_CIPH
len = i2d_GOST_CIPHER_PARAMS(gcp, NULL);
p = buf = malloc(len);
- if (!buf) {
+ if (buf == NULL) {
GOST_CIPHER_PARAMS_free(gcp);
- GOSTerr(GOST_F_GOST89_SET_ASN1_PARAMETERS,
ERR_R_MALLOC_FAILURE);
+ GOSTerr(GOST_F_GOST89_SET_ASN1_PARAMETERS,
+ ERR_R_MALLOC_FAILURE);
return 0;
}
i2d_GOST_CIPHER_PARAMS(gcp, p);
GOST_CIPHER_PARAMS_free(gcp);
os = ASN1_OCTET_STRING_new();
-
- if (!os || !ASN1_OCTET_STRING_set(os, buf, len)) {
+ if (os == NULL) {
+ free(buf);
+ GOSTerr(GOST_F_GOST89_SET_ASN1_PARAMETERS,
+ ERR_R_MALLOC_FAILURE);
+ return 0;
+ }
+ if (ASN1_OCTET_STRING_set(os, buf, len) == 0) {
+ ASN1_OCTET_STRING_free(os);
free(buf);
GOSTerr(GOST_F_GOST89_SET_ASN1_PARAMETERS, ERR_R_ASN1_LIB);
return 0;
Index: gost/gost89imit_pmeth.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/gost/gost89imit_pmeth.c,v
retrieving revision 1.2
diff -u -p -r1.2 gost89imit_pmeth.c
--- gost/gost89imit_pmeth.c 9 Nov 2014 23:06:52 - 1.2
+++ gost/gost89imit_pmeth.c 9 Nov 2014 23:10:05 -
@@ -115,20 +115,26 @@ pkey_gost_mac_keygen(EVP_PKEY_CTX *ctx,
}
keydata = malloc(32);
+ if (keydata == NULL) {
+ GOSTerr(GOST_F_PKEY_GOST_MAC_KEYGEN, ERR_R_MALLOC_FAILURE);
+ return 0;
+ }
memcpy(keydata, data-key, 32);
EVP_PKEY_assign(pkey, NID_id_Gost28147_89_MAC, keydata);
return 1;
}
-static int pkey_gost_mac_ctrl(EVP_PKEY_CTX *ctx, int type, int p1, void *p2)
+static int
+pkey_gost_mac_ctrl(EVP_PKEY_CTX *ctx, int type, int p1, void *p2)
{
struct gost_mac_pmeth_data *data = EVP_PKEY_CTX_get_data(ctx);
switch (type) {
case EVP_PKEY_CTRL_MD:
if (EVP_MD_type(p2) != NID_id_Gost28147_89_MAC) {
- GOSTerr(GOST_F_PKEY_GOST_MAC_CTRL,
GOST_R_INVALID_DIGEST_TYPE);
+ GOSTerr(GOST_F_PKEY_GOST_MAC_CTRL,
+ GOST_R_INVALID_DIGEST_TYPE);
return 0;
}
data-md = p2;
Index:
Re: rwho on OpenBSD 5.6
On Mon, Nov 10, 2014 at 7:36 AM, Theo de Raadt dera...@cvs.openbsd.org wrote: Question for the community: Do you want the upgrade instructions to be 100% useful, or 100% complete? Neither; 100% is unrealistic. Getting '90%' on either measure exceeds my expectations. The only expectation that I have is that any significant changes likely to cause problems are flagged - and that's already covered in the FAQ: http://www.openbsd.org/faq/upgrade56.html#headsup The amount of work and commitment that goes into maintaining the list of changes is impressive (e.g. http://www.openbsd.org/plus56.html and the summary http://www.openbsd.org/56.html). All I can say is thank you.
Re: rwho on OpenBSD 5.6
Neither; 100% is unrealistic. Getting '90%' on either measure exceeds my expectations. The same percentage of flights would be acceptable? I think that problem has been highlighted and we now belongs to all users to check and submit oversights. My 2 cents, Regards, -- Eric JACQUOT
Re: rwho on OpenBSD 5.6
Agreed that 100% is the goal - and I'm prepared to try and help achieve this. I already think what is done is pretty damn good - it far exceeds *my* expectations. You've obviously never flown in Australia. 100% of flights *do not* leave on time. There are errors and glitches - but fortunately nothing catastrophic. Getting back to topic, is having an old binary (rwhod) not deleted during an upgrade catastrophic? I don't think so. I can't fault the current process for OpenBSD. Cheers, Michael On Mon, Nov 10, 2014 at 11:20 AM, Eric JACQUOT ejacq...@delfic.org wrote: Neither; 100% is unrealistic. Getting '90%' on either measure exceeds my expectations. The same percentage of flights would be acceptable? I think that problem has been highlighted and we now belongs to all users to check and submit oversights. My 2 cents, Regards, -- Eric JACQUOT
Re: rwho on OpenBSD 5.6
On 11/09/14 16:07, Job Snijders wrote: On Sun, Nov 09, 2014 at 01:36:59PM -0700, Theo de Raadt wrote: I just updated to OpenBSD 5.6 and I was happy to see that rcp, rsh, rshd, rwho, rwhod, etc have been removed (at least according to the Changelog). However, the upgrade instructions fail to mention that files like /etc/rc.d/rwhod or /usr/bin/rwho should be removed. How much of a catastrophy is this? Question for the community: Do you want the upgrade instructions to be 100% useful, or 100% complete? 100% complete should be the goal. I expect a system that is upgraded from 5.5 to 5.6 (following the upgrade documentation) to be in the _exact_ same state as a clean 5.6 installation, barring changes local to the system. wow. See the third paragraph of any of the upgrade documents from 3.7 until 5.5. I removed that paragraph this release because I figured it was probably self-evident to people who understood which end of their digestive tract to put the fresh food into. Perhaps I overestimated. I would invite you to give it a shot. Start with current.html, plus56.html, anything else you wish. Not a lot of the developers really care a lot about the document, so they won't have been keeping current.html super accurate, you are basically on your own. You will have a lot of testing to do. You will note that while deleting rwhod was undoubtedly exciting for developers, actually putting it on current.html -- so I could put it on upgrade56.html -- was not nearly as much fun and never happened When you get it all done...look at your work. Can you imagine someone following it for 50 machines they support? How about 500? Can they use it for all of the 17 or so platforms OpenBSD supports? Can they do it from a remote site with no console access? is it the _exact_ same as a fresh install? Oh, to add to the realism, do it while holding down a full-time+ job, a few other volunteer activities, and cool-ass vehicles that beg to be driven any time the weather doesn't suck and a significant other you like to spend time with. BTW: if you fuck it up, you will cause a lot of people all over the world to have really really bad days. So don't fuck up. No pressure or anything. And in less than six months, you get to do it again. The good news is, if you do a half-way decent job, only two people complain: you and one other person (the other person does many things to contribute to the project, however), and you get lots of positive feedback. Can you make a better one than me? Give it a shot. Really. It's win all around. If you succeed, the community wins. Do a great job, I can go spend my time on other things. Win all around. :) The goal of the upgradeXX.html document -- as *I* see it -- is to provide enough information for real administrators of real systems to take their systems from a functional state of the previous release to a functional state of the current release, and leave them in a good state for the NEXT release cycle, too (lather, rinse, repeat, indefinitely). The idea is to be concise enough that the job can be done quickly and easily, and yet provide enough details so that virtually all users can figure out if they have edge cases which might cause them problems. Is the upgraded system identical to a fresh install? No; not a goal of mine. Will there be ashes left over? Yes. I think rwho and friends probably should have been removed as part of that huge list of files to delete, but the negative consequences of not deleting rwho are basically zero. And someone who's infrastructure depends on it might just be happy to find that it still runs on some platforms and might give them a little more time to fix their systems. That's why we aren't obsessive about deleting old library files, too -- you may well have applications, either as packages or things you compiled on your own -- which will still work on the upgraded system and may actually be really important for that system to continue to work (or even boot!) until the updated applications are installed. Does it work always? No, but if it saves the butt of a few administrators, it is almost certainly a net gain. Nick.
Re: rwho on OpenBSD 5.6
Getting back to topic, is having an old binary (rwhod) not deleted during an upgrade catastrophic? I don't think so. You would be mistaken. Wars have been fought over less -- by the absolutists.
Re: LibreSSL: GOST ciphers implementation
- I understand from the ``FIXME IANA'' comments that the various cipher and extension IDs used by GOST are not official yet. Are these values generally agreed upon by the websites which serve content using GOST algorithms? These values are provided as 'temporal private values till IANA provides registered values'. http://tc26.ru/methods/recommendation/%D0%A2%D0%9A26TLS.pdf page 12 (sorry, Russian only). That's authorative enough for me. Piping in .. authorative enough for me as well. IANA and IETF deliberately drag the feet when their pocketbooks haven't been stroked in the right ways.
Re: LibreSSL GOST code cleanup
Hello,
2014-11-10 2:12 GMT+03:00 Miod Vallat m...@online.fr:
The following diff attempts to polish the GOST code in libcrypto and add
many missing error checks (probably not exhaustive, but a good start).
I knew that I'm not perfect, but I didn't know the depth of my imperfectness...
I will review your changes later with greater care.
I am also considering fixing the gost2001_do_sign() interface violation
(it frees something which has been allocated by its caller), if only to
make it match gost2001_do_verify(), which leaves the responsibility to
the caller; but that will happen in a later diff.
That should be ok.
Few comments below.
@@ -102,36 +105,44 @@ int gost2001_compute_public(GOST_KEY * e
[..]
- }
- ok = 256;
+ if (GOST_KEY_set_public_key(ec, pub_key) == 0)
+ goto err;
+ ok = 256; /* XXX */
This skipped through my review/refactoring. This function can be
changed to return 1
in non-error cases.
+
+ if (ok == 0) {
err:
@@ -151,70 +168,94 @@ ECDSA_SIG *gost2001_do_sign(BIGNUM * md,
r = newsig-r;
group = GOST_KEY_get0_group(eckey);
order = BN_CTX_get(ctx);
- EC_GROUP_get_order(group, order, ctx);
+ if (order == NULL)
+ goto err;
+ if (EC_GROUP_get_order(group, order, ctx) == 0) {
+ /*
+* XXX EC_GROUP_get_order() will return 0 if successful but
+* XXX order == 0. But then BN_mod below would fail anyway.
+*/
+ goto err;
+ }
In theory it is fine to add
if (BN_is_zero(order)) goto err;
On the other hand no GOST curves/keys should have order == 0.
[...]
+ if (ctx != NULL) {
+ BN_CTX_end(ctx);
+ BN_CTX_free(ctx);
+ }
+ BN_free(md);/* XXX */
Yes, this probably should be fixed also.
@@ -234,88 +277,145 @@ int gost2001_do_verify(BIGNUM * md, ECDS
X = BN_CTX_get(ctx);
R = BN_CTX_get(ctx);
v = BN_CTX_get(ctx);
+ if (v == NULL)
+ goto err;
- EC_GROUP_get_order(group, order, ctx);
+ if (EC_GROUP_get_order(group, order, ctx) == 0) {
+ /*
+* XXX EC_GROUP_get_order() will return 0 if successful but
+* XXX order == 0. But then BN_mod below would fail anyway.
+*/
+ goto err;
+ }
Same as in gost2001_do_sign.
+int
+VKO_compute_key(BIGNUM *X, BIGNUM *Y, const GOST_KEY *pkey, GOST_KEY
*priv_key,
+const BIGNUM *ukm)
{
[...]
+ if (EC_GROUP_get_order(group, order, ctx) == 0) {
+ /*
+* XXX EC_GROUP_get_order() will return 0 if successful but
+* XXX order == 0. But then BN_mod_mul below would fail
anyway.
+*/
+ goto err;
+ }
And again. You can add a check, but if it fails, the problem is elsewhere.
-int gost2001_keygen(GOST_KEY * ec)
+int
+gost2001_keygen(GOST_KEY *ec)
{
BIGNUM *order = BN_new(), *d = BN_new();
const EC_GROUP *group = GOST_KEY_get0_group(ec);
- EC_GROUP_get_order(group, order, NULL);
+ int rc = 0;
+
+ if (order == NULL || d == NULL)
+ goto err;
+ if (EC_GROUP_get_order(group, order, NULL) == 0) {
+ /*
+* XXX EC_GROUP_get_order() will return 0 if successful but
+* XXX order == 0. But then BN_rand_range below would fail
+* XXX anyway.
+*/
+ goto err;
+ }
And again.
--
With best wishes
Dmitry
