athn0: device timeout and network hanging with AR9285

2017-10-14 Thread Ax0n
Frequently -- several times per hour when I'm actively doing stuff on my
laptop, the network hangs for perhaps 30-60 seconds. This coincides with
athn0 timeout messages on the console. I don't have much data to back up my
claim that it feels like it's more frequent since the upgrade to 6.2, but
it was happening under 6.1 Stable as well. I notice it more if I am moving
large-ish files around, but that could simply be because my work gets
interrupted.

The drm error in there seems unrelated. I hadn't seen it before 6.2 but
I've had no complaints with the graphics, so I'm not concerned about that
at the moment.

OpenBSD 6.2 (GENERIC.MP) #0: Thu Oct 12 19:53:18 CEST 2017
r...@syspatch-62-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/
GENERIC.MP
real mem = 8227655680 (7846MB)
avail mem = 7971287040 (7602MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xe9d90 (47 entries)
bios0: vendor Acer version "V1.07" date 11/07/2011
bios0: Acer Aspire 5733Z
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP ASF! HPET APIC MCFG SLIC BOOT ASPT DMAR SSDT SSDT
SSDT
acpi0: wakeup devices AZAL(S3) P0P1(S4) EHC1(S3) USB1(S3) USB2(S3) USB3(S3)
USB4(S3) USB5(S3) USB6(S3) USB7(S3) RP01(S4) PEG5(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
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) i5 CPU M 540 @ 2.53GHz, 2527.89 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: TSC frequency 2527894440 Hz
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 133MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz, 2527.44 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 4 (application processor)
cpu2: Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz, 2527.44 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu2: 256KB 64b/line 8-way L2 cache
cpu2: smt 0, core 2, package 0
cpu3 at mainbus0: apid 5 (application processor)
cpu3: Intel(R) Core(TM) i5 CPU M 540 @ 2.53GHz, 2527.44 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,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,AES,NXE,RDTSCP,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 2, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins
, remapped to apid 2
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (P0P2)
acpiprt2 at acpi0: bus 3 (P0P1)
acpiprt3 at acpi0: bus 1 (RP01)
acpiprt4 at acpi0: bus 2 (RP02)
acpiprt5 at acpi0: bus -1 (RP03)
acpiprt6 at acpi0: bus -1 (RP04)
acpiprt7 at acpi0: bus -1 (RP05)
acpiprt8 at acpi0: bus -1 (RP06)
acpiprt9 at acpi0: bus -1 (RP07)
acpiprt10 at acpi0: bus -1 (RP08)
acpiprt11 at acpi0: bus -1 (PEG5)
acpiec0 at acpi0
acpicpu0 at acpi0: C3(350@245 mwait.3@0x20), C2(500@205 mwait.3@0x10),
C1(1000@3 mwait.1), PSS
acpicpu1 at acpi0: C3(350@245 mwait.3@0x20), C2(500@205 mwait.3@0x10),
C1(1000@3 mwait.1), PSS
acpicpu2 at acpi0: C3(350@245 mwait.3@0x20), C2(500@205 mwait.3@0x10),
C1(1000@3 mwait.1), PSS
acpicpu3 at acpi0: C3(350@245 mwait.3@0x20), C2(500@205 mwait.3@0x10),
C1(1000@3 mwait.1), PSS
"pnp0c14" at acpi0 not configured
acpibat0 at acpi0: BAT0 model "Li_Ion_4000mA " serial 716a type Lion oem
"SANYO "
acpiac0 at acpi0: AC unit offline
acpibtn0 at acpi0: PWRB
acpibtn1 at acpi0: LID0
acpibtn2 at acpi0: SLPB
"ETD0500" at acpi0 not configured
"PNP0C14" at acpi0 not configured
"PNP0C14" at acpi0 not configured
acpivideo0 at acpi0: GFX0
acpivout at acpivideo0 not configured
acpivideo1 at acpi0: VGA_
cpu0: Enhanced SpeedStep 2527 MHz: speeds: 2533, 2399, 2266, 2133, 1999,
1866, 1733, 1599, 1466, 1333, 1199 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core Host" rev 0x02
inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics" rev 0x02
drm0 at inteldrm0
intagp0 at inteldrm0
agp0 at 

Re: kernel panic i386

2017-10-14 Thread Philip Guenther
On Sat, Oct 14, 2017 at 6:57 AM, Krzysztof Strzeszewski 
wrote:

> This is very interested "the kernel did non panic".


panic() is an explicit call in the kernel, made when some sanity or
consistency check fails.  Dereferencing a bogus pointer results in a failed
page fault trap and goes to ddb directly without going through panic(), so
there's no "panic message".

(Someone looking for a kernel change to hack on?  How about this: figure
out how to make ddb's "show panic" report something useful when you entered
ddb via a kernel page fault where uvm_fault() returned EFAULT.)



> Where is memcmp in sys? When I run bsd.rd end mount filesystem I can't
> find memcmp.
>

memcmp() is a function inside the kernel, so I'm not sure what your last
statement means.

...

> ddb> trace
> memcmp(d3182800,681,9,1b) at memcmp+0x11
> k7_powernow_init(d31810c0,d0ec2f08,d022931e,d0c70730,d0a217fd) at
> k7_powernow_init+0xf8
> amd_family6_setperf_setup(d0c70730) at amd_family6_setperf_setup+0x1c
> mainbus_attach(0,d31810c0,0) at mainbus_attach+0x15e
> ...


This trace is kinda weird:  k7_powernow_init+0xf8 matches with it being a
call to k7pnow_states(), which does calls memcmp(), but where did the
intermediate stack frame go?  And why are the args to memcmp() so odd?

On top of it, nothing has really changed in the K7 code since 6.1, so the
only real change is the change in compilers from gcc to clang.  The
resulting object code is _substantially_ different: that clang doesn't
inline the memcmp() call is just one aspect.  Is there something in that
code which clang is deciding to optimize in ways that break it?

Philip Guenther


Re: use /dev/arandom on the Linux

2017-10-14 Thread Philip Guenther
On Sat, Oct 14, 2017 at 10:00 AM, Ingo Schwarze  wrote:
...

> RTFS is all well and good, but trying to understand your postings,
> i also tried to RTFM.
>
>   schwarze@isnote $ man urandom
>   man: No entry for urandom in the manual.
>
> This is ungood.
>
> So i looked at random(4) and found multiple issues.
>
>  * srandom and urandom are missing from NAME.  That's particularly
>unfortunate for urandom(4) because that's the best of the four
>for portable software, IIUC.
>

I'm okay with adding urandom for the portability reason.  I'm less inclined
to add srandom: how many years have to pass before we stop documenting it?
Does the timer only start when we remove the /dev entry?



>  * I think we want a strong deprecation notice here, like for
>crypt(3).  We usually put that at the top of the DESCRIPTION,
>such that people won't study all the text before realizing
>that they have to start over with a different page.
>  * Given that these devices are only useful for (some situations)
>of portable code, it seems quite counter-productive to only talk
>about what OpenBSD does, and the failure to make clear which
>of the statements apply to OpenBSD only is even worse.
>  * It should certainly be said that if at all, urandom(4)
>is the one to use.
>  * There is no need to say twice that these devices produce
>high-quality random data.
>  * Add the missing FILES entries.
>  * Kill the reference to the deprecated random(3) APIs.
>  * We don't need to get into the argument whether Linux is an
>operating system or just a kernel.  Instead, we usually mention
>the release something first appeared in.  But i'm too lazy to
>research Linux kernel version numbers, and maybe they are not
>even all that interesting, so i'm just putting the year.
>  * Author names belong in AUTHORS, not HISTORY.  Instead,
>HISTORY should say when ARC4 was introduced here.
>

I agree with all the above.


>  * It's weird to mention who implemented a former algorithm,
>but to not say the same for the current one.
>

I'm pondering whether and why the switch to arc4random stands out.  Was
that the "it doesn't have to be slow, duh!" moment?  If so, it deserves to
be called out for that aspect with the use of arc4 as a "and here's how"
side note.


This patch in likely not perfect yet, there is more weirdness,
> but i don't know the best way to fix that.  If this is a bad
> patch, i hope it triggers a good one.
>
>  * Are the .Xr's to md5(3) and md5(9) still relevant?  How does
>reading md5(3) and md5(9) potentially help somebody who is
>considering to use /dev/urandom?  I'd like to delete these,
>but if we want to keep them, shouldn't we explain why they
>are relevant?
>

Kill'em.  I think they're only there because md5 was used before arc4.


>  * I strongly suspect the sentence "This is a cloned interface"
>is completely misplaced in HISTORY.  But i'm not quite sure
>what it means and whether it is true, so i have no idea
>where to move it.
>

IMO, delete it.  random(4) isn't a cloning device in the D_CLONE sense in
the kernel: multiple opens are indistinguishable.  Even reviewing the
commit where the text was added doesn't really clarify for me what that was
intended to indicate.


> Feedback?  Or even an OK?
>

Other than my hesitance about add ".Nm srandom", this diff appears to be an
improvement to me.  IMO, ok guenther@ and we'll refine it further.

Philip Guenther


iwm fatal firmware error on - current

2017-10-14 Thread Dan Jones
On 6.2 current shortly after boot iwm fails with the error:

iwm0: fatal firmware error
iwm0: could not remove MAC context (error 35)

The device is able to initially connect get an address and connect for a few 
minutes.  Output from ifconfig and dmesg are below.  Let me know what other 
troubleshooting steps will be helpful.

$ ifconfig iwm0
iwm0: flags=8843 mtu 1500
lladdr a4:34:d9:aa:64:d2
index 1 priority 4 llprio 3
groups: wlan
media: IEEE802.11 autoselect (DS1 mode 11g)
status: no network
ieee80211: nwid Home wpakey  wpaprotos wpa2 wpaakms psk 
wpaciphers ccmp wpagroupcipher ccmp
inet 10.0.0.121 netmask 0xff00 broadcast 10.0.0.255


OpenBSD 6.2-current (GENERIC.MP) #147: Fri Oct 13 10:54:52 MDT 2017
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8438796288 (8047MB)
avail mem = 8176173056 (7797MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xd7054000 (65 entries)
bios0: vendor LENOVO version "N1FET50W (1.24 )" date 03/08/2017
bios0: LENOVO 20FB002RUS
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP TCPA SSDT SSDT TPM2 UEFI SSDT SSDT ECDT HPET APIC MCFG 
SSDT SSDT DBGP DBG2 BOOT BATB SLIC SSDT SSDT MSDM DMAR ASF! FPDT UEFI
acpi0: wakeup devices LID_(S4) SLPB(S3) IGBE(S4) EXP9(S4) XHCI(S3)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
acpihpet0 at acpi0: 2399 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz, 2195.78 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
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 24MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz, 2194.90 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
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) i5-6200U CPU @ 2.30GHz, 2194.90 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
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) i5-6200U CPU @ 2.30GHz, 2194.90 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,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT
cpu3: 256KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG0)
acpiprt2 at acpi0: bus -1 (PEG1)
acpiprt3 at acpi0: bus -1 (PEG2)
acpiprt4 at acpi0: bus 2 (EXP1)
acpiprt5 at acpi0: bus 4 (EXP3)
acpiprt6 at acpi0: bus -1 (EXP5)
acpiprt7 at acpi0: bus -1 (EXP9)
acpicpu0 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpicpu1 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpicpu2 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpicpu3 at acpi0: C3(200@1034 mwait.1@0x60), C2(200@151 mwait.1@0x33), 
C1(1000@1 mwait.1), PSS
acpipwrres0 at acpi0: PUBS, resource for XHCI
acpipwrres1 at acpi0: PG00, resource for PEG0
acpipwrres2 at acpi0: PG01, resource for PEG1

Re: A stupid question, re: xargs(1)

2017-10-14 Thread Jim Rowan

> On Oct 14, 2017, at 4:02 PM, Abel Abraham Camarillo Ojeda 
>  wrote:
> 
> find . |  grep something | more filters | perl -ne 'chomp; print
> "$_\0"'  | xargs -0 ...

Nice!  *Now* can we stop talking about it?

Re: A stupid question, re: xargs(1)

2017-10-14 Thread Abel Abraham Camarillo Ojeda
On Sat, Oct 14, 2017 at 12:02 PM, Raul Miller  wrote:
> On Sat, Oct 14, 2017 at 10:26 AM, Marc Espie  wrote:
>> the find -print0 / xargs -0 couple was designed to solve that problem
>> a long time ago in one specific case.
>
> I suppose the other angle to take would be the addition of a null
> delimiter option for other command line utilities.
>

find . |  grep something | more filters | perl -ne 'chomp; print
"$_\0"'  | xargs -0 ...

> Put differently: if it's "broken by design" then there's no real
> non-broken motives for avoiding incompatibilities with that design.
>
> Which is *not* to say that my kneejerk reactions are the right
> approach: Other people's insight's are important. But: short term
> buy-in, less so (though can't be ignored in the long run).
>
> Thanks,
>
> --
> Raul
>



Re: dump to remote system

2017-10-14 Thread Philip Guenther
On Sat, Oct 14, 2017 at 11:18 AM, Federico Giannici 
wrote:

> I'd like to do a"dump" of a filesystem to a remote machine.
>
> The dump command man page says to use "-f user@host:file", but sniffing
> the network traffic I have found that it tries to connect to the 514 TCP
> port, the rsh protocol port. But it seems to me that rsh has been removed
> from OpenBSD since a lot of time...
>
> Am I correct?
>
> What is the current solution today?
>

If you follow the manpage cross-reference to rcmd(3) you'll find that if
the RSH environment variable is set then its value will be used as the
program to execute to do the transfer/connection instead of using the
shell/tcp port directly.  Setting RSH=/usr/bin/ssh in the environment of
dump should get you what you need.

As for the manpage, since dump(8) and rmt(8) are the only remaining
programs in tree that use rcmd(3), maybe duplicating that info into their
manpages is now the Right Thing.  Ingo?

Philip Guenther


Re: vmd: alpine-virt guest, clock synchronization issue

2017-10-14 Thread Shane Harbour

On 10/14/2017 13:01, x9p wrote:

Hi,

While running Alpine-virt 3.6.2 VM guest under OpenBSD 6.1 host, i noticed
the clock frequency is 2x slower on the guest machine. This can be a
problem for applications that relies on accurate time.

Even after sync clock with ntpd inside alpine-virt guest, it gets
out-of-sync a few seconds later. I get on the guest about half the clock
frequency of the host.

Anyone having similar problems?

cheers.

x9p



I've noticed the same thing on my laptop running an amd64 6.2 install. 
It was really very slow to install and slow via console and ssh now that 
I've got it running.  I just thought it was something I had done/was 
doing.  Even with ntpd running, it's now way behind.


Regards,
Shane



vmd: alpine-virt guest, clock synchronization issue

2017-10-14 Thread x9p
Hi,

While running Alpine-virt 3.6.2 VM guest under OpenBSD 6.1 host, i noticed
the clock frequency is 2x slower on the guest machine. This can be a
problem for applications that relies on accurate time.

Even after sync clock with ntpd inside alpine-virt guest, it gets
out-of-sync a few seconds later. I get on the guest about half the clock
frequency of the host.

Anyone having similar problems?

cheers.

x9p



Re: OpenBSD 6.2 AMD64, crashed during reboot.

2017-10-14 Thread Todd
I had a bit of trouble upgrading my vultr account.  The fix for me was
updating the name of the desired kernel in /etc/boot.conf

On Sat, Oct 14, 2017 at 6:27 AM, Özgür Kazancci 
wrote:

> Hey everyone.
>
> I've a VPS on Vultr that was running OpenBSD 6.1 smoothly, since a month.
>
> Today I mounted the URL of OpenBSD 6.2 amd64 iso in through Control Panel,
> rebooted the VPS, made a fresh 6.2 installation to my VPS. The installation
> went fine. (Only a single / partition: 60 GB).
>
> After the first boot, via Console on Vultr, I installed nano, and then made
> some sshd tweaks in sshd.conf for my need (changed the default port,
> removed root login, et cetera). Gave a reboot in the console, and bam!
> Kernel crashed.
>
> Took the screenshots, just wanted to share the outputs here, so that, it'd
> perhaps help OpenBSD, eliminating a bug or something.
>
> Please find the attached files containing the mentioned screenshots.
>
> Best,
> Özgür.
>


dump to remote system

2017-10-14 Thread Federico Giannici

I'd like to do a"dump" of a filesystem to a remote machine.

The dump command man page says to use "-f user@host:file", but sniffing 
the network traffic I have found that it tries to connect to the 514 TCP 
port, the rsh protocol port. But it seems to me that rsh has been 
removed from OpenBSD since a lot of time...


Am I correct?

What is the current solution today?

Thanks.

P.S.
Maybe the dump/restore man pages should be updated accordingly...



Re: A stupid question, re: xargs(1)

2017-10-14 Thread Raul Miller
On Sat, Oct 14, 2017 at 10:26 AM, Marc Espie  wrote:
> the find -print0 / xargs -0 couple was designed to solve that problem
> a long time ago in one specific case.

I suppose the other angle to take would be the addition of a null
delimiter option for other command line utilities.

Put differently: if it's "broken by design" then there's no real
non-broken motives for avoiding incompatibilities with that design.

Which is *not* to say that my kneejerk reactions are the right
approach: Other people's insight's are important. But: short term
buy-in, less so (though can't be ignored in the long run).

Thanks,

-- 
Raul



Re: use /dev/arandom on the Linux

2017-10-14 Thread Ingo Schwarze
Hi Philipp, hi Markus,

Philip Guenther wrote on Sat, Oct 14, 2017 at 12:05:55AM -0700:
> On Fri, Oct 13, 2017 at 11:54 PM, Mohammad BadieZadegan > arandom entropy is better than urandom and I need arandom for better
>> entropy and better speed in comparison about /dev/random.

> Umm, I don't understand.  /dev/arandom was an OpenBSD "innovation" that we
> have since regretted and rescinded: on modern OpenBSD, /dev/arandom and
> /dev/urandom behave *exactly the same*.  Go look in sys/dev/rnd.c and
> you'll see that the minor device number is ignored.

RTFS is all well and good, but trying to understand your postings,
i also tried to RTFM.

  schwarze@isnote $ man urandom
  man: No entry for urandom in the manual.

This is ungood.

So i looked at random(4) and found multiple issues.

 * srandom and urandom are missing from NAME.  That's particularly
   unfortunate for urandom(4) because that's the best of the four
   for portable software, IIUC.
 * I think we want a strong deprecation notice here, like for
   crypt(3).  We usually put that at the top of the DESCRIPTION,
   such that people won't study all the text before realizing
   that they have to start over with a different page.
 * Given that these devices are only useful for (some situations)
   of portable code, it seems quite counter-productive to only talk
   about what OpenBSD does, and the failure to make clear which
   of the statements apply to OpenBSD only is even worse.
 * It should certainly be said that if at all, urandom(4)
   is the one to use.
 * There is no need to say twice that these devices produce
   high-quality random data.
 * Add the missing FILES entries.
 * Kill the reference to the deprecated random(3) APIs.
 * We don't need to get into the argument whether Linux is an
   operating system or just a kernel.  Instead, we usually mention
   the release something first appeared in.  But i'm too lazy to
   research Linux kernel version numbers, and maybe they are not
   even all that interesting, so i'm just putting the year.
 * Author names belong in AUTHORS, not HISTORY.  Instead,
   HISTORY should say when ARC4 was introduced here.
 * It's weird to mention who implemented a former algorithm,
   but to not say the same for the current one.

This patch in likely not perfect yet, there is more weirdness,
but i don't know the best way to fix that.  If this is a bad
patch, i hope it triggers a good one.

 * Are the .Xr's to md5(3) and md5(9) still relevant?  How does
   reading md5(3) and md5(9) potentially help somebody who is
   considering to use /dev/urandom?  I'd like to delete these,
   but if we want to keep them, shouldn't we explain why they
   are relevant?
 * I strongly suspect the sentence "This is a cloned interface"
   is completely misplaced in HISTORY.  But i'm not quite sure
   what it means and whether it is true, so i have no idea
   where to move it.

Feedback?  Or even an OK?
  Ingo


Index: random.4
===
RCS file: /cvs/src/share/man/man4/random.4,v
retrieving revision 1.31
diff -u -p -r1.31 random.4
--- random.410 Sep 2015 17:55:21 -  1.31
+++ random.414 Oct 2017 16:59:14 -
@@ -28,34 +28,62 @@
 .Os
 .Sh NAME
 .Nm random ,
-.Nm arandom
+.Nm arandom ,
+.Nm srandom ,
+.Nm urandom
 .Nd random data source devices
 .Sh SYNOPSIS
 .In sys/types.h
 .In dev/rndvar.h
 .Sh DESCRIPTION
-The various
+These devices are deprecated.
+Use the
+.Xr arc4random 3
+family of functions instead, which can be called in almost all
+coding environments, including
+.Xr pthreads 3 ,
+.Xr chroot 2 ,
+and
+.Xr pledge 2 ,
+and which avoids accessing a device every time.
+.Pp
+On
+.Ox ,
+all these various
 .Nm
-devices produce high quality random output data.
+devices behave identically and produce high quality pseudo-random
+output data.
 Entropy data is collected from system activity (such as disk, network,
 and clock device interrupts), and then used to key the
 ChaCha stream cipher to generate the output.
-All the random devices are expected to provide high quality
-pseudo-random output data.
 .Pp
+On other operating systems, some devices may exhibit various defects.
+For example,
+.Nm
+and
+.Nm srandom
+might block, or
+.Nm random
+might only return data from hardware random generators.
 The
-.Xr arc4random 3
-function in userland libraries should be used instead, as it works
-without the need to access these devices every time.
+.Nm arandom
+variant is a deprecated
+.Ox
+extension that should no longer be used.
+.Pp
+If using one of these devices cannot be avoided in a portable
+program, prefer
+.Nm urandom .
 .Sh FILES
 .Bl -tag -width /dev/arandom -compact
 .It Pa /dev/random
 .It Pa /dev/arandom
+.It Pa /dev/srandom
+.It Pa /dev/urandom
 .El
 .Sh SEE ALSO
 .Xr arc4random 3 ,
 .Xr md5 3 ,
-.Xr random 3 ,
 .Xr amdpm 4 ,
 .Xr glxsb 4 ,
 .Xr pchb 4 ,
@@ -64,11 +92,17 @@ without the need to access these devices
 .Sh HISTORY
 A
 .Nm

Re: "athn0: could not load firmware" for AR9271

2017-10-14 Thread Tim Stewart
Maximilian Pichler  writes:

> The dmesg is the same as previously (this is on the APU), except for:
> athn0 at pci5 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 2 int 16
> athn0: AR9280 rev 2 (2T2R), ROM rev 22, address xx:xx:xx:xx:xx:e2

I'm debugging some issues with my wle200nx in a PC Engines apu2c4, and I
have a very similar dmesg output:

  athn0 at pci4 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 5 int 16
  athn0: AR9280 rev 2 (2T2R), ROM rev 22, address 04:f0:21:26:d3:28

I am curious, is it expected that the first line says "Atheros AR9281"
and the second says "AR9280"?  In particular, athn(4) makes the AR9281
sound less capable:

  The AR9281 is a single-chip PCIe 802.11n solution.  It exists in PCIe
  Mini Card (XB91) and half Mini Card (HB91) form factors.  It operates in
  the 2GHz spectrum and supports 1 transmit path and 2 receiver paths
  (1T2R).

I will reply with more details if I can better quantify the issues I'm
having.

-TimS

--
Tim Stewart
---
Mail:   t...@stoo.org
Matrix: @tim:stoo.org



Re: Security question / idea

2017-10-14 Thread Niels Kobschaetzki

> On 14. Oct 2017, at 16:26, Bryan C. Everly  wrote:
> 
> Hi misc@,
> 
> In playing around with Libreboot and Coreboot, my belief that physical
> access to the hardware really ups an attacker’s ability to win against most
> security has been massively reinforced.  For example, someone with enough
> practice could take my Thinkpad T500 apart, force flash the BIOS (as I have
> been doing), reassemble it and put it back on my desk in ten to fifteen
> minutes (or maybe faster). The payload they flash could easily include a
> root kit and keylogger which would mitigate the advantage of Full Disk
> Encryption (because they could grab your passphrase keystrokes and send
> them off to the mother ship). So my happy little bubble that FDE would give
> me protection against all but a brute force attack has been popped.
> 
> Here’s my thought. What if we modified our boot code to do a hash of the
> BiOS and stored it persistently across boots?  Then we could compare it
> this time to the last value and take some action / issue some warning that
> something changed. It would be mildly annoying if you actually did just
> update your BIOS to a new version but that would be a small trade off in my
> mind at least.
> 
> The sticking point is this - where do you store the previous hash?  If we
> stored it outside of the FDE container, the attacker could just rewrite it
> on boot and we wouldn’t be able to detect a change. Put it inside the FDE
> and you would have to type your passphrase (sending it to the attacker) to
> read it.
> 
> So now to my ask - would a feature like this be of any interest to others?
> If so, any thoughts on how to securely persist the hash to solve the
> problem I describe above?
> 
> Thanks for any and all feedback.

Isn’t that something like Anti Evil Maid?
http://theinvisiblethings.blogspot.de/2011/09/anti-evil-maid.html?m=1


Niels

Re: A stupid question, re: xargs(1)

2017-10-14 Thread Marc Espie
As Theo said already, the main issue there is that it's totally
non-standard, so you end up writing scripts that won't work
anywhere but on OpenBSD.

The problem you're trying to solve is quoting in shell.
It's basically broken by design. There will always be fun patterns
in names that do various fun things in shell.

the find -print0 / xargs -0 couple was designed to solve that problem
a long time ago in one specific case.

Yep, it does not play with filters in the middle.

So what ? you can create a list with the specific case of *newlines* using
lots of shell constructs

e.g., find . | while read i; do ...; printf "$i\0"; done|xargs -0
is yet another way to skin this cat.

In general, when I need to do this kind of things, I get a "scripting"
language that doesn't have any of those issues, for instance perl.



Security question / idea

2017-10-14 Thread Bryan C. Everly
Hi misc@,

In playing around with Libreboot and Coreboot, my belief that physical
access to the hardware really ups an attacker’s ability to win against most
security has been massively reinforced.  For example, someone with enough
practice could take my Thinkpad T500 apart, force flash the BIOS (as I have
been doing), reassemble it and put it back on my desk in ten to fifteen
minutes (or maybe faster). The payload they flash could easily include a
root kit and keylogger which would mitigate the advantage of Full Disk
Encryption (because they could grab your passphrase keystrokes and send
them off to the mother ship). So my happy little bubble that FDE would give
me protection against all but a brute force attack has been popped.

Here’s my thought. What if we modified our boot code to do a hash of the
BiOS and stored it persistently across boots?  Then we could compare it
this time to the last value and take some action / issue some warning that
something changed. It would be mildly annoying if you actually did just
update your BIOS to a new version but that would be a small trade off in my
mind at least.

The sticking point is this - where do you store the previous hash?  If we
stored it outside of the FDE container, the attacker could just rewrite it
on boot and we wouldn’t be able to detect a change. Put it inside the FDE
and you would have to type your passphrase (sending it to the attacker) to
read it.

So now to my ask - would a feature like this be of any interest to others?
If so, any thoughts on how to securely persist the hash to solve the
problem I describe above?

Thanks for any and all feedback.

-- 

Thanks,
Bryan


Re: kernel panic i386

2017-10-14 Thread Krzysztof Strzeszewski
This is very interested "the kernel did non panic". Where is memcmp in 
sys? When I run bsd.rd end mount filesystem I can't find memcmp.



http://wklej.org/hash/e5591ccc88f/

.
.
.
cpu0 at mainbus0: (uniprocessor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
uvm_fault(0xd0c230c0, 0xd0f2f000, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at  memcmp+0x11:    repe cmpsl  (%esi),%es:(%edi)


ddb> show panic
the kernel did not panic

ddb> trace
memcmp(d3182800,681,9,1b) at memcmp+0x11
k7_powernow_init(d31810c0,d0ec2f08,d022931e,d0c70730,d0a217fd) at 
k7_powernow_i

nit+0xf8
amd_family6_setperf_setup(d0c70730) at amd_family6_setperf_setup+0x1c
mainbus_attach(0,d31810c0,0) at mainbus_attach+0x15e
config_attach(0,d0c0335c,0,0) at config_attach+0x184
config_rootfound(d09cb92c,0) at config_rootfound+0xc0
cpu_configure(944dfcd2,ec,ecf000,0,d02004ce) at cpu_configure+0x29
main(0,0,0,0,0) at main+0x478
ddb>




Regards,
Krzych


W dniu 14.10.2017 o 11:58, Philip Guenther pisze:
On Fri, Oct 13, 2017 at 12:21 PM, Krzysztof Strzeszewski 
> wrote:


When I upgrade 6.1 to 6.2 in my futro s400 i have kernel panic.


It's unfortunate that no one has submitted to dm...@openbsd.org 
 the dmesg from that hardware since February 
2016.  Please consider doing so every time you upgrade your kernel, so 
that we have a record of what is working.


 ...

cpu0 at mainbus0: (uniprocessor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
uvm_fault(0xd0c589b0, 0xd0f32000, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at      memcmp+0x11:    repe cmpsl (%esi),%es:(%edi)
ddb>


https://www.openbsd.org/ddb.html

Without a backtrace, all we can see is that a copy operation in the 
kernel faulted, with no indication of *which* copy operation did so.



Philip Guenther





X on OpenBSD security question

2017-10-14 Thread tinkr
Any comments on the security of using X in OpenBSD would be much appreciated, 
when running X with machdep.allowaperture=0 , or higher.

This is with background of the general buzz that X is terribly unsecure and 
anyone security-minded not even should touch it with a stick, e.g. a userland X 
program could root the system, a userland X program can tap into keypresses and 
do any UI manipulations to any other X program, X's code base is so bloated 
it's obvious it's unsecure - actually what about it, with Xorg on OpenBSD in 
particular?

How much damage can a bug/break/exploit in an X program cause to the user, the 
system, and other X programs?

Is Xorg bloated?

A discussion thread here 
https://www.reddit.com/r/openbsd/comments/76c4jh/x_on_openbsd_ultimate_security_question_thread/
 .

Re: kernel panic i386

2017-10-14 Thread Philip Guenther
On Fri, Oct 13, 2017 at 12:21 PM, Krzysztof Strzeszewski 
wrote:

> When I upgrade 6.1 to 6.2 in my futro s400 i have kernel panic.
>

It's unfortunate that no one has submitted to dm...@openbsd.org the dmesg
from that hardware since February 2016.  Please consider doing so every
time you upgrade your kernel, so that we have a record of what is working.

 ...

> cpu0 at mainbus0: (uniprocessor)
> mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
> uvm_fault(0xd0c589b0, 0xd0f32000, 0, 1) -> e
> kernel: page fault trap, code=0
> Stopped at  memcmp+0x11:repe cmpsl  (%esi),%es:(%edi)
> ddb>
>

 https://www.openbsd.org/ddb.html

Without a backtrace, all we can see is that a copy operation in the kernel
faulted, with no indication of *which* copy operation did so.


Philip Guenther


RE: A stupid question, re: xargs(1)

2017-10-14 Thread leo_tck
"Andreas Kusalananda Kähäri"  write:
>
> Another thing to avoid is having too exotic filenames.

Or always passing file names through vis(3) before writing them.

Though that's probably not as simple as it sounds.

--schaafuit.



Re: A stupid question, re: xargs(1)

2017-10-14 Thread Andreas Kusalananda Kähäri
On Sat, Oct 14, 2017 at 08:44:08AM +, Raul Miller wrote:
> On Sat, Oct 14, 2017 at 3:08 AM, Andreas Kusalananda Kähäri
>  wrote:
> > find . -type f -mtime -1 \
> > -exec grep -q -E 'pattern1' {} ';' \
> > -exec shasum {} +
> 
> That's cute, but it winds up spinning up a process for every file
> (actually, in your example, two processes for every file). I generally
> want to avoid doing that.

Only one, the grep, is run on each file.  The shasum will be run on as
many files as possible that passes the grep test.  This is the way to do
it without having to rely on the filenames produced by "grep -l" being
parseable.

Another thing to avoid is having too exotic filenames.

-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.



Re: kernel panic i386

2017-10-14 Thread Krzysztof Strzeszewski

I changed only name kernel :)


W dniu 14.10.2017 o 01:13, Mike Larkin pisze:

On Fri, Oct 13, 2017 at 09:21:37PM +0200, Krzysztof Strzeszewski wrote:

Hi,
When I upgrade 6.1 to 6.2 in my futro s400 i have kernel panic.


Try 6.1 stock kernel and see if that works. Then at least we know if we
introduced a regression.

Nobody knows (or cares) what NROOT is.

-ml




http://wklej.org/hash/e590382de31/

boot>
booting hd0a:/bsd: 8154312+2282500+166852+0+1097728
[680614+82+489520+501323]=0xcc233c
entry point at 0x2000d4

[ using 1671996 bytes of bsd ELF symbol table ]
Copyright (c) 1982, 1986, 1989, 1991, 1993
 The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2017 OpenBSD. All rights reserved.
https://www.OpenBSD.org

OpenBSD 6.2 (GENERIC) #163: Tue Oct  3 19:51:20 MDT 2017
dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: AMD Athlon(tm) Processor ("AuthenticAMD" 686-class, 256KB L2
cache) 1.01 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,MPC,MMXX,3DNOW2,3DNOW
real mem  = 1039613952 (991MB)
avail mem = 1005654016 (959MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 02/14/07, BIOS32 rev. 0 @ 0xfaa30, SMBIOS rev.
2.2 @ 0xf (31 entries)
bios0: vendor Phoenix Technologies, LTD version "6.00PG Rev. 4.00.0H"
date 02/14/2007
bios0: FUJITSU SIEMENS FUTRO S400
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP SSDT
acpi0: wakeup devices USB0(S5) USB1(S5) USB2(S5) USB3(S5) AMR0(S4)
UAR1(S5) PCI0(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: C1(@1 halt!), PSS
acpitz0 at acpi0: critical temperature is 100 degC
acpibtn0 at acpi0: PWRB
"PNP0401" at acpi0 not configured
"PNP0C0B" at acpi0 not configured
bios0: ROM list: 0xc/0xc000 0xcc000/0x4000! 0xd/0x1000
cpu0 at mainbus0: (uniprocessor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
uvm_fault(0xd0c589b0, 0xd0f32000, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at  memcmp+0x11:repe cmpsl  (%esi),%es:(%edi)
ddb>







http://wklej.org/hash/e590382de31/

# dmesg
OpenBSD 6.1-stable (NROOT) #12: Fri Oct 13 17:15:13 CEST 2017
 krz...@nroot.pl:/usr/src/sys/arch/i386/compile/NROOT
cpu0: AMD Athlon(tm) Processor ("AuthenticAMD" 686-class, 256KB L2
cache) 1.01 GHz
cpu0:
FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE,MPC,MMXX,3DNOW2,3DNOW
real mem  = 1039613952 (991MB)
avail mem = 1006993408 (960MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: date 05/14/08, BIOS32 rev. 0 @ 0xfaa30, SMBIOS rev.
2.2 @ 0xf (31 entries)
bios0: vendor Phoenix Technologies, LTD version "6.00PG Rev. 4.00.0Q"
date 05/14/2008
bios0: FUJITSU SIEMENS FUTRO S400
acpi0 at bios0: rev 0
acpi0: sleep states S0 S1 S4 S5
acpi0: tables DSDT FACP SSDT
acpi0: wakeup devices USB0(S5) USB1(S5) USB2(S5) USB3(S5) AMR0(S4) PCI0(S5)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiprt0 at acpi0: bus 0 (PCI0)
acpicpu0 at acpi0: C1(@1 halt!), PSS
acpitz0 at acpi0: critical temperature is 100 degC
acpibtn0 at acpi0: PWRB
"PNP0C0B" at acpi0 not configured
bios0: ROM list: 0xc/0xc000 0xcc000/0x4000! 0xd/0x1800
0xd2000/0x1000
cpu0 at mainbus0: (uniprocessor)
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: PowerNow! K7 1001 MHz: speeds: 1000 800 667 MHz
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "SiS 741 PCI" rev 0x03
sisagp0 at pchb0
agp0 at sisagp0: aperture at 0xe800, size 0x400
ppb0 at pci0 dev 1 function 0 "SiS 86C202 AGP" rev 0x00
pci1 at ppb0 bus 1
vga1 at pci1 dev 0 function 0 "SiS 6330 VGA" rev 0x00
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
pcib0 at pci0 dev 2 function 0 "SiS 85C503 System" rev 0x25
pciide0 at pci0 dev 2 function 5 "SiS 5513 EIDE" rev 0x00: 741: DMA,
channel 0 configured to compatibility, channel 1 configured to compatibility
wd0 at pciide0 channel 0 drive 0: 
wd0: 16-sector PIO, LBA48, 57231MB, 117210240 sectors
wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 2
pciide0: channel 1 ignored (disabled)
ohci0 at pci0 dev 3 function 0 "SiS 5597/5598 USB" rev 0x0f: irq 4,
version 1.0, legacy support
ohci1 at pci0 dev 3 function 1 "SiS 5597/5598 USB" rev 0x0f: irq 3,
version 1.0, legacy support
ehci0 at pci0 dev 3 function 3 "SiS 7002 USB" rev 0x00: irq 7
ehci0: timed out waiting for BIOS
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "SiS EHCI root hub" rev
2.00/1.00 addr 1
em0 at pci0 dev 7 function 0 "Intel 82546EB" rev 0x01: irq 10, address
00:11:0a:5b:69:e8
em1 at pci0 dev 7 function 1 "Intel 82546EB" rev 0x01: irq 11, address

Re: Automatically restarting services/daemons after crash

2017-10-14 Thread Philip Guenther
On Sat, Oct 14, 2017 at 1:15 AM, Luke Small  wrote:

> I am not certain about Braille, but what I am sure of is there is no
> incremental process to guessing a 64 bit datum that changes every single
> execution.


I'll note that in OpenBSD, stack cookies are the size of a register, so
they're only 32bits on archs like i386, armv7, macppc, etc.

(If someone is interested in expanding them to 64bits on 32bits archs, they
should step up and do the engineering: make some performance measurement of
their existing system, implement the larger cookie via changes to gcc,
clang, or both, then compare the performance afterwards.)


> I typically don't state a fact unless I am willing to die if I am
> incorrect. At least https://en.m.wikipedia.org/wiki/Blind_return_oriented_
> programming seems to state so. I dont fully trust wikipedia.


So, circling back, uh, I'm not sure what this means for the original
discussion.  You're totally confident that OpenBSD's defenses are perfect
and that therefore we can safely restart daemons?  *If* that's what you're
saying then, well, I continue to disagree with your conclusion and though I
find your confidence in OpenBSD to be heartening, I believe it to be an
over reach.

Philip Guenther


Re: A stupid question, re: xargs(1)

2017-10-14 Thread Raul Miller
On Sat, Oct 14, 2017 at 3:08 AM, Andreas Kusalananda Kähäri
 wrote:
> find . -type f -mtime -1 \
> -exec grep -q -E 'pattern1' {} ';' \
> -exec shasum {} +

That's cute, but it winds up spinning up a process for every file
(actually, in your example, two processes for every file). I generally
want to avoid doing that.

Thanks though,

-- 
Raul



Re: A stupid question, re: xargs(1)

2017-10-14 Thread Raul Miller
On Sat, Oct 14, 2017 at 1:08 AM, Philip Guenther  wrote:
> You want a version of xargs that, instead of requiring special handling for
> 5 characters legal in filenames (quote, double-quote, backslash, space, tab,
> newline), will be completely unable to handle exactly one of those
> characters (newline)?  Easy: create this two line shell script under some
> convenient name and use it instead:

Not completely unable, but when working with files supplied by other
people, spaces in file names are common, apostrophes less so but still
present. Quotes, backslashes and tabs quite rare, and I have never
encountered file names containing newlines.

> #!/bin/sh
> sed 's!\(.\)!\\\1!g' | xargs "$@"

Thanks, I'll try that - or a variation - next time. I wish it had
occurred to me, but I'm kind of slow sometimes.

> My personal preference is to pick either of the following options:
> a) don't use any of those characters in filenames and just use xargs bare
> b) go directly into perl or C once I reach the limit of -0 option handling
>
> IMO, (a) makes sense for stuff you control the name of, (b) for stuff where
> you don't.  The set of people I trust to create filenames containing space,
> tabs, or quotes, but not newlines is *empty*.

I guess I deal with a different kind of person than you.

Thanks again,

-- 
Raul



RE: A stupid question, re: xargs(1)

2017-10-14 Thread leo_tck
"Raul Miller"  wrote:
>
> And if I search, I can find a tremendous variety of other elaborate
> approaches, including replacements for xargs. So it's not like this is
> not a real issue, nor is it like this isn't something that grows new
> handlings on an ongoing basis.

Unfortunately, especially in the modern world, alternatives keep popping 
up where none are really needed. Made that mistake plenty of time in my
lunix days, reinventing something only to then discover that there was a
simpler way to do things that I should've used.

Now, I'm not saying your problem isn't real: indeed, I'm sure it's the
kind of corner case where UNIX shows its age.

I don't think bloating already funky programs like xargs(1) with more
options is the solution though. IMO, you'd indeed better be looking for
a replacement.

Or writing one.

 --schaafuit.



Re: Automatically restarting services/daemons after crash

2017-10-14 Thread Luke Small
I am not certain about Braille, but what I am sure of is there is no
incremental process to guessing a 64 bit datum that changes every single
execution. I typically don't state a fact unless I am willing to die if I
am incorrect. At least
https://en.m.wikipedia.org/wiki/Blind_return_oriented_programming seems to
state so. I dont fully trust wikipedia.
On Sat, Oct 14, 2017 at 3:06 AM Philip Guenther  wrote:

> On Sat, Oct 14, 2017 at 12:49 AM, Luke Small  wrote:
>
>> If that's true, then why has Theo been  speaking of the brop problems,
>> when they begin with an incremental canary discovery that becomes all but
>> impossible to guess when it becomes a random 4 byte datum each time rather
>> than a datum that remains the same each restart?
>>
>
> Because we are creatively optimistic pessimists: we can imagine
> possibilities for how other might be able to get around our defenses.
> Please watch review the presentation and read the source!
>
>
>
>> Braille should already be impossible to run on such a system, unless
>> maybe a restart was not the result of an exec.
>>
>
> The word "should" indicates that you are not certain.  How would you go
> about proving it?  What would you do if you couldn't?
>
> Philip Guenther
>
>


Re: Automatically restarting services/daemons after crash

2017-10-14 Thread Philip Guenther
On Sat, Oct 14, 2017 at 12:49 AM, Luke Small  wrote:

> If that's true, then why has Theo been  speaking of the brop problems,
> when they begin with an incremental canary discovery that becomes all but
> impossible to guess when it becomes a random 4 byte datum each time rather
> than a datum that remains the same each restart?
>

Because we are creatively optimistic pessimists: we can imagine
possibilities for how other might be able to get around our defenses.
Please watch review the presentation and read the source!



> Braille should already be impossible to run on such a system, unless maybe
> a restart was not the result of an exec.
>

The word "should" indicates that you are not certain.  How would you go
about proving it?  What would you do if you couldn't?

Philip Guenther


Re: Automatically restarting services/daemons after crash

2017-10-14 Thread Luke Small
If that's true, then why has Theo been  speaking of the brop problems, when
they begin with an incremental canary discovery that becomes all but
impossible to guess when it becomes a random 4 byte datum each time rather
than a datum that remains the same each restart?

Braille should already be impossible to run on such a system, unless maybe
a restart was not the result of an exec.


Re: The dlopen manual lacks RTLD_TRACE info

2017-10-14 Thread Philip Guenther
On Wed, Oct 4, 2017 at 5:59 PM, Nan Xiao  wrote:
>
> I find the ldd program actually uses "RTLD_TRACE" when calling
> "dlopen":
> dlhandle = dlopen(buf, RTLD_TRACE);
>
> While the manual (https://man.openbsd.org/dlopen.3) seems doesn't
> provide introduction of RTLD_TRACE. Should OpenBSD manual add
> RTLD_TRACE info?
>

Nah.  This is an internal interface whose behavior we do not provide
stability for.  Indeed, I know of at least one corner-case bug in its
current behavior.  We do not generally document the behavior of internal
interfaces (though we strive to document even internal syscalls).  For
example, dlctl(3)'s description is basically just "this exists", which is
basically useless...

Philip Guenther


Re: Looking for libraries

2017-10-14 Thread Stuart Henderson
On 2017-10-14, Nigel Taylor  wrote:
> On 10/13/17 22:09, Per-Olov Sjöholm wrote:
>> Hi
>> 
>> I just upgraded to 6.2…
>> 
>> Anyone that knows what packages I can find the following libs in:
>> libpthread.so.22.0
>> libc.so.88.0
>> libm.so.9.0
>> 
>> I used this https://beta1.bredbandskollen.se/download/bbk_cli_openbsd 
>>  on 6.0, but 
>> don’t have a copy of the “pkg_info” output from 6.0 that I used.
>> 
>> 
>> 
>> Tnx in advance
>> /Peo
>> 
>
> Any references to those libraries means the packages 
> haven't been upgraded to 6.2

bbk_cli_openbsd isn't a package, it's a third-party binary built for
OpenBSD 6.0. The people providing it should re-build for a current version
of OpenBSD, or provide source so you can build yourself (and build it for
arches other than amd64).

> $ tar -tzvf 6.0/amd64/base60.tgz ./usr/lib/lib{c,pthread,m}.so.*  
> -r--r--r--  1 root bin3355741 Mar  4  2017 ./usr/lib/libc.so.89.2

That's a later snapshot, 6.0 release was from summer 2016 and used libc.so.88.0.




Re: A stupid question, re: xargs(1)

2017-10-14 Thread Andreas Kusalananda Kähäri
On Fri, Oct 13, 2017 at 11:52:11PM +, Raul Miller wrote:
> On Fri, Oct 13, 2017 at 7:37 PM, edgar  wrote:
> > Perhaps a real life example of what you have been doing with xargs before
> > and after your change would be helpful.
> 
> That's tough, since when I was working on this issue I didn't have
> time to think about xargs and now that I have time to think about
> xargs the examples are distant memories.
> 
> That said, something on the order of this:
> 
> find . -type f -mtime -1 -print0 | xargs -0 egrep -l pattern1 | xargs shasum

find . -type f -mtime -1 \
-exec grep -q -E 'pattern1' {} ';' \
-exec shasum {} +

You almost never have to use xargs with find if you know how -exec
works.


Cheers,

> 
> Anyways, I think I fixed it that time by removing all the files with
> problematic names, and another time by using a while loop instead of
> the second xargs, and a third time by writing a perl program, and the
> fourth time using grep -v ' ' in the pipeline, and probably a few
> dozen other hacks over the years...
> 
> And if I search, I can find a tremendous variety of other elaborate
> approaches, including replacements for xargs. So it's not like this is
> not a real issue, nor is it like this isn't something that grows new
> handlings on an ongoing basis.
> 
> What I'm trying to understand is why there's no simple fix. And maybe
> this really is just one of those things that will never get fixed.
> 
> Thanks,
> 
> -- 
> Raul
> 

-- 
Andreas Kusalananda Kähäri,
National Bioinformatics Infrastructure Sweden (NBIS),
Uppsala University, Sweden.



Re: use /dev/arandom on the Linux

2017-10-14 Thread Philip Guenther
On Fri, Oct 13, 2017 at 11:54 PM, Mohammad BadieZadegan  wrote:

> arandom entropy is better than urandom and I need arandom for better
> entropy and better speed in comparison about /dev/random.
>

Umm, I don't understand.  /dev/arandom was an OpenBSD "innovation" that we
have since regretted and rescinded: on modern OpenBSD, /dev/arandom and
/dev/urandom behave *exactly the same*.  Go look in sys/dev/rnd.c and
you'll see that the minor device number is ignored.

If your question is "how do I make my Linux kernel suck less?" then you
need to ask that on a Linux forum...or expect the answer "install OpenBSD!"


Philip Guenther


Re: Automatically restarting services/daemons after crash

2017-10-14 Thread Philip Guenther
On Fri, Oct 13, 2017 at 11:54 PM, Philip Guenther 
wrote:

> On Fri, Oct 13, 2017 at 11:43 PM, Luke Small  wrote:
>
>> I am not versed in operating systems as well as you, but I would think
>> that stack and buffer canaries would differ from each execution.
>>
>
> I suggest you examine the source, OR BETTER, examine actual processes
> under a debugger, where you will discover THAT THEY ALREADY DO.
>

This is also described in presentations posted to
 https://www.openbsd.org/events.html

Theo's latest is good place to start, with the emphasis on "start".
There's a lot of ground already covered!


Philip Guenther


Re: use /dev/arandom on the Linux

2017-10-14 Thread Mohammad BadieZadegan
arandom entropy is better than urandom and I need arandom for better
entropy and better speed in comparison about /dev/random.

On Sat, Oct 14, 2017 at 10:18 AM, Philip Guenther 
wrote:

> On Fri, Oct 13, 2017 at 11:28 PM, Mohammad BadieZadegan <
> mbzade...@gmail.com> wrote:
>
>> Hi everybody, I need /dev/arandom on some Linux, How can I use
>> /dev/arandom
>> on the Linux Kernel OS?
>> Which way is the fast way?
>>
>
> Don't use /dev/arandom: use /dev/urandom instead.
>
> You have a program whose source you have lost?  Then "ln -s urandom
> /dev/arandom" to make arandom a symlink to urandom.
>
> Philip Guenther
>
>


-- 
[image: http://unixuser.us] 


Re: Automatically restarting services/daemons after crash

2017-10-14 Thread Philip Guenther
On Fri, Oct 13, 2017 at 11:43 PM, Luke Small  wrote:

> I am not versed in operating systems as well as you, but I would think
> that stack and buffer canaries would differ from each execution.
>

I suggest you examine the source, OR BETTER, examine actual processes under
a debugger, where you will discover THAT THEY ALREADY DO.

Stop trying to teach your grandmother to suck eggs.


Philip Guenther


Re: use /dev/arandom on the Linux

2017-10-14 Thread Philip Guenther
On Fri, Oct 13, 2017 at 11:28 PM, Mohammad BadieZadegan  wrote:

> Hi everybody, I need /dev/arandom on some Linux, How can I use /dev/arandom
> on the Linux Kernel OS?
> Which way is the fast way?
>

Don't use /dev/arandom: use /dev/urandom instead.

You have a program whose source you have lost?  Then "ln -s urandom
/dev/arandom" to make arandom a symlink to urandom.

Philip Guenther


Re: Automatically restarting services/daemons after crash

2017-10-14 Thread Luke Small
I am not versed in operating systems as well as you, but I would think that
stack and buffer canaries would differ from each execution.


use /dev/arandom on the Linux

2017-10-14 Thread Mohammad BadieZadegan
Hi everybody, I need /dev/arandom on some Linux, How can I use /dev/arandom
on the Linux Kernel OS?
Which way is the fast way?