Re: Performance Clang

[Michael McConville]

Damian McGuckin wrote:
> On Tue, 25 Apr 2017, Marc Espie wrote:
> > Apparently, it seems that lld might be better behaved than binutils
> > ld in *some* respects like speed and memory consumption in *some*
> > cases...
> > 
> > we'll see.
> 
> Doesn't Clang have superior (and integrated) static analysis tools?

Yes, but that's orthogonal to the speed and correctness of compilation.

Re: Performance Clang

[Michael McConville]

Heiko wrote:
> I noticed that with clang it needs 109 minutes for "make build" and
> before with gcc 32 minutes.
> 
> Is this a normal behavior?

An email from Miod that gets cited often:

https://marc.info/?l=openbsd-misc&m=137530560232232&w=2

Re: cvs up permission denied?

[Michael McConville]

Todd Mortimer wrote:
> I noticed that my nightly cvs update job failed last night with the
> error:
> 
> E can't create temporary directory /tmp/cvs-serv71983
> error  Permission denied
> 
> I have tried both 
> 
> anon...@obsdacvs.cs.toronto.edu:/cvs
> and 
> anon...@anoncvs1.ca.openbsd.org:/cvs
> 
> I have tried updating both -stable 6.0 and -current with the same
> result.
> 
> This looks like it is originating from the server side, but I could be
> looking at it wrong. 
> 
> Is this just me? Or is anyone else having a similar problem?

I had the same problem yesterday using the UToronto mirror with a recent
snapshot.

Re: Thinkpad X220, can't control screen brightness via keyboard

[Michael McConville]

misc nick wrote:
> To be more precise, i can't control screen brightness by pressing 
> Fn + Home (increase) or Fn + End (decrease). These are thinkpad's
> shortcuts for controlling brightness. Controlling brightness
> by command line works.
> 
> The shortcuts worked in OpenBSD 5.9.

Hm... they still work for me.

Here's my dmesg:


OpenBSD 6.0-current (GENERIC.MP) #2422: Wed Sep  7 13:25:15 MDT 2016
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4156157952 (3963MB)
avail mem = 4025704448 (3839MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdae9c000 (68 entries)
bios0: vendor LENOVO version "8DET54WW (1.24 )" date 10/18/2011
bios0: LENOVO 429042U
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SLIC SSDT SSDT SSDT HPET APIC MCFG ECDT ASF! TCPA SSDT 
SSDT UEFI UEFI UEFI
acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP4(S4) EXP7(S4) EHC1(S3) 
EHC2(S3) HDEF(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-2540M CPU @ 2.60GHz, 797.55 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,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,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 99MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.1.2, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Core(TM) i5-2540M CPU @ 2.60GHz, 797.41 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,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,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 2 (application processor)
cpu2: Intel(R) Core(TM) i5-2540M CPU @ 2.60GHz, 797.41 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,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
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) i5-2540M CPU @ 2.60GHz, 797.41 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,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,NXE,LONG,LAHF,PERF,ITSC,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, 24 pins
acpimcfg0 at acpi0 addr 0xf800, bus 0-63
acpiec0 at acpi0
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 5 (EXP4)
acpiprt5 at acpi0: bus 13 (EXP5)
acpiprt6 at acpi0: bus -1 (EXP7)
acpicpu0 at acpi0: C3(350@104 io@0x415), C1(1000@1 halt), PSS
acpicpu1 at acpi0: C3(350@104 io@0x415), C1(1000@1 halt), PSS
acpicpu2 at acpi0: C3(350@104 io@0x415), C1(1000@1 halt), PSS
acpicpu3 at acpi0: C3(350@104 io@0x415), C1(1000@1 halt), PSS
acpipwrres0 at acpi0: PUBS, resource for EHC1, EHC2
acpitz0 at acpi0: critical temperature is 99 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
"PNP0303" at acpi0 not configured
"LEN0020" at acpi0 not configured
"SMO1200" at acpi0 not configured
acpibat0 at acpi0: BAT0 model "42T4867" serial  2119 type LION oem "SANYO"
acpiac0 at acpi0: AC unit online
acpithinkpad0 at acpi0
"PNP0C14" at acpi0 not configured
"PNP0C14" at acpi0 not configured
acpidock0 at acpi0: GDCK not docked (0)
acpivideo0 at acpi0: VID_
acpivout at acpivideo0 not configured
acpivideo1 at acpi0: VID_
cpu0: Enhanced SpeedStep 797 MHz: speeds: 2601, 2600, 2400, 2200, 2000, 1800, 
1600, 1400, 1200, 1000, 800 MHz
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 "Intel Core 2G Host" rev 0x09
inteldrm0 at pci0 dev 2 function 0 "Intel HD Graphics 3000" rev 0x09
drm0 at inteldrm0
inteldrm0: msi
inteldrm0: 1366x768
wsdisplay0 at inteldrm0 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
"Intel 6 Series MEI" rev 0x04 at pci0 dev 22 function 0 not configured
puc0 at pci0 dev 22 function 3 "Intel 6 Series KT" rev 0x04: ports: 1 com
com4 at puc0 port 0 apic 2 int 19: ns16550a, 16 byte fifo
com4: probed fifo depth: 0 bytes
em0 at pci0 dev 25 function 0 "Intel

Re: No automatic start of privoxy

[Michael McConville]

Stefan Wollny wrote:
> I have the following in /etc/rc.conf.local:
> pkg_scripts=freshclam clamd messagebus avahi_daemon privoxy squid cupsd
> 
> BUT: 'privoxy' does not start at system-startup as the other progs do.

'rcctl start tor' started failing mysteriously when I installed the
latest snapshot yesterday. Likely related.

Re: Performance of Firefox and Chromium

[Michael McConville]

Mihai Popescu wrote:
> > Javascript may not be the fastest language around
> 
> A language has nothing to do with speed of execution!

In many ways, it does. That discussion's off-topic for this list,
though. I'm happy to have it privately.

Re: Performance of Firefox and Chromium

[Michael McConville]

Alex Poslavsky wrote:
> Firefox saves its cache to ~/.cache, I mounted that as tmpfs and that
> seemed to make it a bit faster as well. Off course you loose all your
> cached stuff on reboot.

By many (most?) accounts, tmpfs is actually slower than an SSD. It's
presumably faster than a spinning disk, though.

Re: Creating a blog using OpenBSD: technology choices and security considerations

[Michael McConville]

David Lou wrote:
> (btw, isn't the "built-in" httpd webserver just Apache? Google seems
> to tell me that they're synonyms)

Nope, Apache was bundled a long time ago and was replaced with Nginx,
which was replaced with httpd in July 2014. httpd is an HTTP server that
is developed in the OpenBSD source tree.

Re: systrace removed? Why?

[Michael McConville]

arrowscr...@mail.com wrote:
> I know about the pledge(2) development, but systrace and pledge are
> not mutually exclusive. Pledge need to be used inline, where systrace
> can be used as a command line tool. 
> 
> If you remove it, many scripts that use systrace for privilege
> reduction will broke.

I guess the question is: how many people actually use systrace in
scripts? Probably very very few.

> Of course, you can put it on packages, but if you follow this logic,
> shouldn't other tools be also removed and be on packages? banner(1)
> for example, is kind useless. The cpan(1) pkg manager from perl also
> could be in packages. Same with sqlite3, I think. Or telnet, since
> almost no one uses it anymore. Etc.

I'm pretty sure that you can't package systrace because it needs to be
supported by the kernel. I expect that that's part of the reason why it
was removed: axing it simplifies and quickens the kernel.

Re: Getting started with an OpenBSD Desktop...

[Michael McConville]

Implausibility wrote:
> I know how to install things via the ports, but traversing the
> directory structure to find useful packages is painful.  If there's a
> more friendly way to search for and discover new/interesting ports
> packages, I'd appreciate a link.

'pkg_info -Q $YOUR_QUERY' will show package names containing
$YOUR_QUERY.

Re: Smokeping performance

[Michael McConville]

Steve Shockley wrote:
> I have several machines running Smokeping on OpenBSD 5.8 amd64 to
> monitor latency through several web proxy servers.  I have a lot of
> frequent monitors (mostly curl) so performance is degrading.  Opening
> one of the Smokeping web pages can take 30-45 seconds at times, but
> from what I can see I'm not CPU or disk bound.  So do I just have too
> many connections open at once?  Is there anything I can do to improve
> performance without scaling out to more machines?  Thanks.

Does the syslog suggest that you're running out of mbufs, file
descriptors, or anything similar? I know the following sysctl variables
are sometimes bumped in those cases:

kern.maxfiles
kern.somaxconn
kern.maxclusters

But ensure that you actually need to.

How many connections does systat say you have?

Re: OS is leaking DNS

[Michael McConville]

Adam Smith wrote:
> Relevant info:
> 
> 1. OpenBSD-amd64 snapshot (install59.iso) with sha256sum of
>5e8020ce150e0fba17b1eef7acc8c27d10845288b9d8c82315bd6826dc94669d and
>dated March 27, 2016
>(installed OpenBSD as desktop OS)
> 2. openvpn-2.3.10
> 3. firefox
> 4. enabled DHCP during installation of OS
> 5. edit /etc/resolv.conf.tail to include my preferred public DNS servers
> 6. computer connects directly to cable modem supplied by ISP, meaning
>my machine receives dynamic IP addresses from my ISP
> 7. computer is standalone, not part of network
> 
> After my computer is connected to VPN tunnel, I start Firefox and surf
> to https://www.dns-oarc.net/oarc/services/dnsentropy where I click on
> the button that says "Test My DNS".
> 
> The IP address of my ISP appears in the results. It means that OpenBSD
> operating system leaks DNS.
> 
> How to fix the problem, please?

See resolv.conf.tail(5). Its contents are *appended* to
/etc/resolv.conf, so if your DHCP lease suggests a DNS server, your
system will try that one before those listed in /etc/resolv.conf.tail.

Re: Ruby 1.9.3 package on OpenBSD 5.9 (snapshots) missing

[Michael McConville]

ML mail wrote:
> I just noticed that there is no Ruby version 1.9.3 package anymore in
> OpenBSD 5.9 (snapshots) although there is still version 1.8.7... Any
> ideas why? or was it simply forgotten?

https://marc.info/?t=14402593751&r=1&w=2

In the future, marc.info and your search engine of choice are good means
of answering such questions.

Re: wireshark illegal instruction on older systems

[Michael McConville]

Peter Kay wrote:
> Wireshark, running on -current, is dumping core ('illegal
> instruction') on two separate pentium ii systems here. It's fine on a
> Core2Duo running i386.
> 
> I'm presuming it's using pentium 3 or later instructions/SSE2 etc. Has
> anyone else seen this before I look at it?

Can you run it in GDB and trigger the crash? That seems like the easiest
way to get the offending instruction.

I know we had to handle something like this in lang/go recently. There
was a discussion on ports@.

Re: openbsd on an ibm power 5

[Michael McConville]

Maciej Jan Broniarz wrote:
> I have an IBM INTELLISTATION 285 POWER 5+ and i was thinkig about
> running OpenBSD on it. Has anyone tried it before and would so kind as
> to share his experience?

I think we only support Apple PowerPC machines (the macppc port). I've
often wondered how easily this could be ported to more recent POWER
machines, but I seriously doubt it'd run out of the box.

Re: I'm curious, why is queue() in style()

[Michael McConville]

Luke Small wrote:
> It seems to complicate things. Is there a security reason to use those
> functions?

They've been around for forever and have been audited. If someone rolls
their own ADT implemenation, it's far more likely to have security
problems.

Re: style

[Michael McConville]

Chris Bennett wrote:
> > This has the downside that if you add another level of indentation, you
> > either have to break the alignment or change every line.
> 
> No, that's definitely not OK at all. I sure wouldn't want to review
> diff's with code changes and full of style changes also.
> 
> > So there are a
> > bunch of variants.
> > 
> 
> 
> > style(9) seems to recommend just using tabs:
> > 
> > > Put a tab after the first word, i.e., use ‘int^Ix;’ and ‘struct^Ifoo
> > > *x;’.
> > 
> > That can get ugly and hard to read, though.
> 
> So I can change the code,make all that work great, following
> the existing code style. And then change the style. At that point,
> why bother? Better things for everyone to do.

I was never suggesting that you bother changing existing declarations.

Re: style

[Michael McConville]

Chris Bennett wrote:
> Should it be done like this?
> 
> int lflag
> int*rflag
> int sflag
> int from_remote
> char  **blist
> int*blist_size
> int blist_addrs
> char ***boof

Close, but you only use spaces there. They usually start
with tabs and then align with spaces, like:

> int  lflag
> int *rflag
> int  sflag
> int  from_remote
> char   **blist
> int *blist_size
> int  blist_addrs
> char  ***boof

This has the downside that if you add another level of indentation, you
either have to break the alignment or change every line. So there are a
bunch of variants.

style(9) seems to recommend just using tabs:

> Put a tab after the first word, i.e., use ‘int^Ix;’ and ‘struct^Ifoo
> *x;’.

That can get ugly and hard to read, though.

Re: FAQ 10.4.2 why días(1)? typo

[Michael McConville]

Halim Srama wrote:
> In the first sentence of this FAQ:
> http://www.openbsd.org/faq/faq10.html#doas
> 
> I think there is a word missing:
> "passwords should not shared"
> should be:
> "passwords should not be shared"
> 
> I have searched the archives and didn't find any report about this.

Committed. Thanks!

That said, the sentence could probably be worded more elegantly...

Re: manpage typo / poll(2)

[Michael McConville]

d.l...@openmailbox.org wrote:
> hi, i think this is a bug/typo in the poll(2) example: FD_SET
> becomes two arguments.
> 
> [demime 1.01d removed an attachment of type text/x-diff which had a name of 
> mypatch.diff]

Your attachment got stripped. It's easiest just to include it at the
bottom of your message.

Re: (pretty trivial) FAQ 4 diff suggestions

[Michael McConville]

ropers wrote:
> Feel free to reject the below without comment if these changes are not
> deemed improvements:

Thanks! I just incorporated a couple of these. I'll look through the
rest soon.

> --- faq4.html.orig2015-12-20 21:56:34.565914000 +0100
> +++ faq4.html2015-12-21 23:33:22.311786584 +0100
> @@ -90,7 +90,7 @@
>  4.1 - Overview of the OpenBSD installation procedure
> 
>  
> -OpenBSD has long been respected for its simple and straight forward
> +OpenBSD has long been respected for its simple and straightforward
>  installation process, which is very consistent across all platforms.
> 
>  
> @@ -131,8 +131,8 @@
>  boot).
> 
>  Writing a file system image to disk (miniroot):
> -Typically, these are written to a USB device to boot up the install
> -kernel.
> +Here, either installXX.fs or minirootXX.fs is written
> +to—typically—a USB device to boot up the install kernel.
> 
>  
> 
> @@ -666,9 +666,10 @@
>  common passwords people think are really clever.
> 
>  
> -You will later be given a chance to create an administrative account and
> -disable remote (SSH) access to the root account, but you still want a
> -good password on your root account.
> +You will later be given a chance to create an administrative account.
> +If you create one, you will be asked—and the default will
> be—to
> +disable remote (SSH) access to the root account, but regardless of your
> +choices, you still want a good password on your root account.
> 
>  
>  
> @@ -1626,7 +1627,7 @@
> 
>  
>  All partitions which have native FFS partitions on them should be within
> -the OpenBSD fdisk(8) partition, however
> +their drive's OpenBSD fdisk(8) partition, however
>  non-OpenBSD partitions can (and
>  usually should) be outside the OpenBSD fdisk partition.
> 
> @@ -1635,8 +1636,8 @@
>  here.
> 
>  
> -More information on why partitioning is beneficial and strategy for
> -creating a good partitioning plan are below.
> +More information on why partitioning is beneficial and a strategy for
> +creating a good partitioning plan is found  href="#Partitioning">below.
> 
>  
>  The OpenBSD installer will attempt to auto-partition your

Re: HUAWEI dongle

[Michael McConville]

Michael McConville wrote:
> Read, James C wrote:
> > I just installed 5.8, I know my dongle is detected and correctly
> > switched to the right mode because
> > 
> > a) I can see in dmesg output that the device is detected and
> > labelled ugen0
> 
> See ugen(4). Basically, the dongle isn't supported.

There was recently a good discussion about which WiFi dongles are
reliably supported. I'd suggest finding cheap well-reviewed options
online and searching their names on the list archives.

> > b) I can see the led light continuously on the dongle, this only
> > happens in other environments I've used the dongle in when the
> > dongle is no longer in mass storage mode (light flashes when in mass
> > storage mode)
> > 
> > However, when I ifconfig I get nothing.

Re: HUAWEI dongle

[Michael McConville]

Read, James C wrote:
> I just installed 5.8, I know my dongle is detected and correctly switched to
> the right mode because
> 
> a) I can see in dmesg output that the device is detected and labelled ugen0

See ugen(4). Basically, the dongle isn't supported.

> b) I can see the led light continuously on the dongle, this only happens in
> other environments I've used the dongle in when the dongle is no longer in
> mass storage mode (light flashes when in mass storage mode)
> 
> However, when I ifconfig I get nothing.

Re: dpb build box performance suggestions.

[Michael McConville]

Christian Weisgerber wrote:
> On 2015-12-16, Tati Chevron  wrote:
> 
> > Our couple of build machines are both fairly standard core i5 boxes
> > with 16 gb of RAM, and Corsair SSDs.  The RAM seems to make more
> > difference than anything else, because you can set the work
> > directory to a ramdisk, and do the entire build without touching the
> > disk.
> 
> Have you done actual comparisons?  With SSDs, I don't expect a
> significant difference.  (There is none for doing a "make build" of
> the base system.)

FWIW: A few days ago, we added additional zeroing to tmpfs and were
discussing its performance. Another dev mentioned that their SSD is
already typically faster than tmpfs.

NetBSD in vmd

[Michael McConville]

mlarkin mentioned that he got this working. Which NetBSD releases and
kernel versions have people used? I got a 7.0 netbsd-GENERIC kernel to
boot, but it hung and made the host machine almost completely
non-responsive. This is on a system built from source a couple hours
ago.

Re: QIV is faster in Linux

[Michael McConville]

Alan Corey wrote:
> If I could get logs from the mplayers would that help?  I tried but it
> didn't work so I skipped it.  I don't know how to profile on Linux.
> The machine has 4 gigs of RAM.

No idea. I don't have time to help with this, but someone else might.

Re: QIV is faster in Linux

[Michael McConville]

Alan Corey wrote:
> I'm thinking this is graphics slowness or filesystem slowness.  Both
> OpenBSD and Debian both have working mplayers, I don't know if that
> could log something useful about throughput.

Filesystems slowness seems unlikely to me. I'd guess that it's because
of the rendering acceleration. Maybe we don't support what Linux uses in
that case, or there's an ifdef somewhere that gives us a sluggish
fallback.

It could also be because of a pathological memory allocation pattern.
They have a much bigger performance impact on OpenBSD because of the
memory sanitization.

The list goes on. You really can't know without profiling.

That said, remember that things like this are almost always a little
faster on Linux.

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Michael McConville]

Joel Rees wrote:
> Daniel Ouellet wrote:
> > > Secondly, this whole thread should have ended long ago.
> >
> > So why you keep it going then.
> >
> > Let it die please
> 
> Flame wars are educational, for readers with an open mind.

Flame wars and crypto speculation also make a lot of noise and drive
more focused readers off the list. See the misc-like list of a common
anonymity network for a prime example of this.

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Michael McConville]

Ted Unangst wrote:
> Michael McConville wrote:
> > Jason Barbier wrote:
> > > szs wrote:
> > > > Not for security.
> > > > For privacy.
> > > 
> > > It is a read only site, the privacy you seek is breached as soon as
> > > you make a DNS call to openbsd.org
> > 
> > There are still some privacy benefits to using HTTPS. It will confound a
> > lot of simple filtering and monitoring software, and what you're reading
> > on the site is pretty obfuscated. It also helps security on sketchy
> > networks.
> 
> Note that simple length correlation is enough to determine what you're
> reading. And this isn't even "NSA intern" difficult, it's "NSA internship
> interview question" difficult.

Yes, but it is certainly "Websense" difficult, "Verizon traffic
monetization dept." difficult, "nosy VPN/exit node operator" difficult,
and "guy in cafe with Wireshark" difficult.

I'll stop responding publicly, though.

Re: letsencrypt && https && openbsd.org = https://www.openbsd.org/

[Michael McConville]

Jason Barbier wrote:
> szs wrote:
> > Not for security.
> > For privacy.
> 
> It is a read only site, the privacy you seek is breached as soon as
> you make a DNS call to openbsd.org

There are still some privacy benefits to using HTTPS. It will confound a
lot of simple filtering and monitoring software, and what you're reading
on the site is pretty obfuscated. It also helps security on sketchy
networks.

HTTPS isn't a perfect solution, but it's something. Especially when ISPs
are starting to inject beacons into HTTP requests and more closely
observe usage.

That said, I suspect none of the sysadmins have the time or interest,
and that's understandable.

Re: Zotac ZBOX-CI540

[Michael McConville]

bluesun08 wrote:
> I own a Zotac ZBOX-CI540. The installation of 5.8 works without any
> problems.
> 
> But when i reboot the ZBOX the system won't start. The HDD light
> appear but the system don't find the HDD and hangs.

Please share a dmesg. Let us or Freenode know if you need help with
that.

Network programs that only report error codes

[Michael McConville]

I realized that this has peeved me since I started Unixing. So, if you
know of anything in base that doesn't print network error strings,
please share publicly and I'll try to add them.

Re: Crash in gnome-control-center on latest amd64 snapshot / packages

[Michael McConville]

Bryan C. Everly wrote:
> Hi,
> 
> I've managed to get Gnome running on a Macbook Pro Retina 13 (Macbook 11,1)
> and all seems well with some exceptions.  The primary among them is a crash
> of gnome-control-center on startup.
> 
> When I run it from the terminal, I get a "Floating point exception" and gdb
> shows:
> 
> Program received signal SIGFPE, Arithmetic exception.
> 
> I've attached a corefile if that is helpful.  If anyone can point me to
> what I need to do in order to gather more diagnostic info, I'd be happy to
> pull whatever is needed.
> 
> Thanks,
> Bryan
> 
> [demime 1.01d removed an attachment of type application/octet-stream which 
> had a name of gnome-control-ce.core]

The corefile attachment got stripped. It's easiest to share a URL.

Also, it'd likely be far more useful with debug symbols. That involves
using "env CFLAGS=' -g' make build && doas make install" or something
similar in the port's directory.

Regardless, my gut reaction is that this is an issue with GNOME and not
OpenBSD.

Thanks,
Mike

Re: which in /dev/* for tethering to android?

[Michael McConville]

Jason Adams wrote:
> On 11/28/2015 02:07 PM, luke...@onemodel.org wrote:
> > Or, is the issue that I need to think differently about and somehow
> > be using ifconfig, urndis, or umsm? 
> 
> How old is this phone?
> 
> Almost anything built in the last 3 years has wifi tethering built in.
> Just turn that on and connect to the phone's wifi hotspot. No wires.

IIRC, there are issues with certain versions of OpenBSD DHCP clients
paired with certain versions of Android DHCP servers. I haven't had
problems for about a year, though.

Just a heads up.

Re: Request for a package & a feature

[Michael McConville]

Loïc BLOT wrote:
> 3. OpenBSD doesn't have a DHCPv6/PD client and It's commonly used by
> operators. Also, dibbler is not available in ports, whereas it works
> perfect if you add a little portability patch to fix some paths
> /var/lib => /var/db . Is this possible to import dibbler in ports tree
> for next OpenBSD release, or if you get some time to have a DHCPv6/PD
> OpenBSD tool (with custom options :D) ?

Does the wide-dhcpv6 port do what you want?

Re: The kernels of *BSD include nonfree firmware blobs?

[Michael McConville]

Drivers run on the CPU, firmware runs on the peripheral device (e.g. the
network card or hard drive). BSDs reject driver blobs because they run
with the same privilege and in the same address space as the rest of the
kernel. Because of this, they can meddle with or corrupt the kernel.

Before asking questions like this in the future:

 1. Do more research
 2. Don't use such inflammatory phrasing

français wrote:
> The Free Software Foundation (FSF) says that:
> 
> "FreeBSD, NetBSD, and OpenBSD all include instructions for obtaining nonfree
> programs in their ports system. In addition, their kernels include nonfree
> firmware blobs.
> 
> Nonfree firmware programs used with Linux, the kernel, are called
> “blobs”,
> and that's how we use the term. In BSD parlance, the term “blob” means
> something else: a nonfree driver. OpenBSD and perhaps other BSD
> distributions (called “projects” by BSD developers) have the policy of
> not
> including those. That is the right policy, as regards drivers; but when the
> developers say these distributions “contain no blobs”, it causes a
> misunderstanding. They are not talking about firmware blobs.
> 
> No BSD distribution has policies against proprietary binary-only firmware
> that might be loaded even by free drivers."
> 
> The affirmations of FSF that I cited above are falses?
> 
> With spying revelations, it is well-known that non-free firmware can contain
> backdoors. ( just one recent example:
> http://www.wired.com/2015/02/nsa-firmware-hacking/ )
> 
> I would feel a lot safer if the kernel and packages were fully free,
> containing no non-free drivers nor non-free "firmware".

Re: Install snapshot failes

[Michael McConville]

Carsten Kunze wrote:
> installing a todays amd64 snapshot with image install58.fs ends with
> "installboot: No blocks to load". What can be the problem?

There were some slightly unstable changes made to installboot yesterday.
It'll probably be fixed quickly. I'd wait and install a newer snapshot
soon.

Re: Roundrobin Trunking on 5.8

[Michael McConville]

Kevin Chadwick wrote:
> > I have upgraded a system from 5.6 to 5.8 and found that whilst the
> > children of a trunk port show output in tcpdump, the trunk port itself
> > whilst looking ok in ifconfig gives no aggregated roundrobin output at
> > all. Any ideas why?
> 
> Sorry, it's not 5.8 but 5.8-current i386 most recent snapshot (for
> the ace pledge!!).

Obvious question, but: did you go 5.6 -> 5.8 or 5.6 -> 5.7 -> 5.8?

Re: OpenBSD as a pentester PC?

[Michael McConville]

Mohammad BadieZadegan wrote:
> I have OpenBSD on my Notebook since 2 years ago and I don't want to
> switch other OS for my business pentest project. I need some pentest
> tools for my project like metasploit, fuzzers, ..etc but I could not
> find them on OpenBSD package list
> ! By default
> does OpenBSD support metasploit installing (or any attack tools) or
> defer them for security purpose? I want to have one OS on my note book
> for all purpose(business+home). Is that I must switch to other OS?
> (That I don't like at all!)

Here's a recent thread on this topic, started by Bryan (who already
replied here):

https://marc.info/?t=143776937300012&r=1&w=2

Re: [OpenBSD and GUIs]

[Michael McConville]

français wrote:
> Is good idea to create a user-friendly and easy-to-use variant of
> OpenBSD second the hardcore OpenBSD user community?
> 
> If no, because?

My opinion: this would be useful to a lot of people, but don't expect
help from upstream.

Things like the lack of Linux capabilities would make it harder to
gracefully manage WiFi etc. I'm not sure whether these are solved
problems.

We already have stable GNOME and XFCE ports, so there's an easy entry
point. Alternatively, you could make a custom environment like
Crunchbang. As little modification as possible (maybe just a shell
script run after install?) would be ideal.

> GUI is for wimps second the currently opinion of hardcore OpenBSD user
> community?
> 
> If yes because?

I think most people use some kind of GUI, albeit usually minimalist
ones.

Re: crash with -current

[Michael McConville]

Sonic wrote:
> On Mon, Nov 2, 2015 at 12:19 PM, Martin Pieuchot  wrote:
> > Do you have an idea how to reproduce this crash?  Which program are you
> > running that uses bpf?
> 
> Not using bpf at all (that I know of), just a straightforward firewall
> - pf, dhcpd, unbound.
> 
> The nasty little "em0: watchdog timeout -- resetting", reported on
> 10-4-15 bug is also back - triggered by using a bittorrent client on
> one of my desktops. The above reported crash happened while streaming
> some Netflix. I'm inclined to suspect the em driver is hosed again.

Yeah, my gut reaction was that this was something to do with the recent
em changes rather than BPF. I don't think the BPF code has changed
recently. BPF is hooked into network interfaces pretty directly, so if
some packet data was being freed too early by a race condition, this
seems like a conceivable way we'd find out.

My speculative 2¢.

Re: Any opinion, policy or conclusion about easy and accessible MAC implementations like tomoyo or SMACK?

[Michael McConville]

> Is there any opinion, policy or conclusion about newer & easier MAC
> implementation like Tomoyo or SMACK?

$ man pledge

That said, pledge is for trusted programs exposed to untrusted remote
input, which differs from MAC frameworks meant to tame sketchy binaries.

Re: Per cpu utilization & KERN_CPTIME2 support in sysctl(8)

[Michael McConville]

Benny Lofgren wrote:
> On 2015-10-28 15:32, Michael McConville wrote:
> > Andrei-Marius Radu wrote:
> >>
> >> Is there anyone else who thinks this is needed/a good idea ?
> > 
> > For what it's worth, I was porting htop recently and I think I
> > remember it being painful to work without KERN_CPTIME2. I'd have to
> > look back (and look at this diff), though.
> 
> +1 on this, I would definitely find this useful.
> 
> Michael, as far as I can tell KERN_CPTIME2 is already in the kernel.
> As I understand it, it is just support for access via sysctl(8) that
> is lacking. But maybe htop uses that rather than sysctl(3)? Doesn't
> seem likely though.

Right, my bad. It must have been something else in htop's FreeBSD or
Linux code that I had to work around.

Re: Per cpu utilization & KERN_CPTIME2 support in sysctl(8)

[Michael McConville]

Andrei-Marius Radu wrote:
> Hello,
> 
> I wanted to make per cpu utilization graphs (using some perl scripts)
> so I ended up making this small patch (against -current) for sysctl(8)
> to add support for KERN_CPTIME2.
> 
> The per cpu utilization graphs problem can be solved in other ways, for
> example I found this old symon thread:
> marc.info/?l=openbsd-misc&m=116655627129555&w=2 however I think having
> KERN_CPTIME2 support is good anyway.
> 
> Is there anyone else who thinks this is needed/a good idea ?

For what it's worth, I was porting htop recently and I think I remember
it being painful to work without KERN_CPTIME2. I'd have to look back
(and look at this diff), though.

This should probably go to the tech@ list, by the way.

Thanks!

> Index: src/sbin/sysctl/sysctl.c
> ===
> RCS file: /cvs/src/sbin/sysctl/sysctl.c,v
> retrieving revision 1.211
> diff -u -p -u -r1.211 sysctl.c
> --- src/sbin/sysctl/sysctl.c18 Apr 2015 18:28:37 -  1.211
> +++ src/sbin/sysctl/sysctl.c28 Oct 2015 13:55:08 -
> @@ -215,6 +215,7 @@ int sysctl_emul(char *, char *, int);
>  #ifdef CPU_CHIPSET
>  int sysctl_chipset(char *, char **, int *, int, int *);
>  #endif
> +int sysctl_cptime2(char *, char **, int *, int, int *);
>  void vfsinit(void);
> 
>  char *equ = "=";
> @@ -412,6 +413,9 @@ parse(char *string, int flags)
> special |= LONGARRAY;
> lal = CPUSTATES;
> break;
> +   case KERN_CPTIME2:
> +   sysctl_cptime2(string, &bufp, mib, flags,
> &type);
> +   return;
> case KERN_SEMINFO:
> len = sysctl_seminfo(string, &bufp, mib, flags,
> &type);
> if (len < 0)
> @@ -2759,6 +2763,80 @@ sysctl_emul(char *string, char *newval,
> return (0);
> 
> 
> +}
> +
> +int
> +sysctl_cptime2(char *string, char **bufpp, int mib[], int flags, int
> *typep)
> +{
> +   int local_mib[2], ncpu, i, cpu;
> +   size_t len;
> +   u_int64_t cp_time2[CPUSTATES];
> +   char *second, *third;
> +   const char *errstr;
> +
> +   local_mib[0] = CTL_HW;
> +   local_mib[1] = HW_NCPU;
> +   len = sizeof(ncpu);
> +   if (sysctl(local_mib, 2, &ncpu, &len, NULL, 0) == -1) {
> +   err(1, "%s can't get number of cpus (hw.ncpu)", string);
> +   return (0);
> +   }
> +
> +   len = sizeof(cp_time2);
> +   second = strchr(string, '.');
> +   if (!second) {
> +   errx(1, "%s: can't get mib second level name", string);
> +   return (0);
> +   }
> +   second++;
> +   third = strchr(second, '.');
> +   if (!third) {
> +   for (i = 0; i < ncpu; i++) {
> +   mib[2] = i;
> +   if (sysctl(mib, 3, &cp_time2, &len, NULL, 0) ==
> -1) {
> +   warn("%s.%d can't get cpu states",
> string, i);
> +   continue;
> +   }
> +
> +   printf("%s.%d=%ld,%ld,%ld,%ld,%ld\n", string, i,
> +   cp_time2[CP_USER],
> +   cp_time2[CP_NICE],
> +   cp_time2[CP_SYS],
> +   cp_time2[CP_INTR],
> +   cp_time2[CP_IDLE]
> +   );
> +   }
> +   }
> +   else {
> +   third++;
> +   if (ncpu > 1) {
> +   cpu = strtonum(third, 0, ncpu - 1, &errstr);
> +   }
> +   else {
> +   cpu = strtonum(third, 0, 0, &errstr);
> +   }
> +   if (errstr) {
> +   errx(1, "%s: third level '%s' %s", string,
> third,
> +   errstr);
> +   return (0);
> +   }
> +
> +   mib[2] = cpu;
> +   if (sysctl(mib, 3, &cp_time2, &len, NULL, 0) == -1) {
> +   warn("%s.%d can't get cpu states", string, i);
> +   return (0);
> +   }
> +
> +   printf("%s=%ld,%ld,%ld,%ld,%ld\n", string,
> +   cp_time2[CP_USER],
> +   cp_time2[CP_NICE],
> +   cp_time2[CP_SYS],
> +   cp_time2[CP_INTR],
> +   cp_time2[CP_IDLE]
> +   );
> +   }
> +
> +   return (1);
>  }
> 
>  static int
> Index: src/sbin/sysctl/sysctl.8
> ===
> RCS file: /cvs/src/sbin/sysctl/sysctl.8,v
> retrieving revision 1.187
> diff -u -p -u -r1.187 sysctl.8
> --- src/sbin/sysctl/sysctl.83 Oct 2015 09:17:13 -   1.187
> +++ src/sbin/sysctl/sysctl.828 Oct 2015 13:55:08 -
> @@ -153,6 +153,7 @@ a

Re: does src include sys ?

[Michael McConville]

Tuyosi Takesima wrote:
> today i first time follow current .
> 
> # cd /usr
> # export CVSROOT=anon...@anoncvs.jp.openbsd.org:/cvs
> # cvs -d$CVSROOT checkout -P src
>   cvs -d$CVSROOT checkout -P sys<---
> 1)quetion
> is [cvs -d$CVSROOT checkout -P sys] needless ?
> 
> 
> and
> Faq write about only src not touch sys .
> # cd /usr/src
> # export CVSROOT=anon...@anoncvs.jp.openbsd.org:/cvs
> # cvs -d$CVSROOT up -Pd
> 2)qustion
> does src include sys ?

Yes, you only need to check out src. (And xenocara, if you want to build
X.)

Re: OpenBGPd error /bsd: bgpd(): syscall 105

[Michael McConville]

Atanas Vladimirov wrote:
> Snapshot from sep 30 bgpd didn't startup:
> Oct  1 08:32:28 ns /bsd: bgpd(28055): syscall 105
> Oct  1 08:32:28 ns bgpd[29697]: handle_pollfd: poll fd: Undefined error: 0
> Oct  1 08:32:28 ns bgpd[29697]: RDE: Lost connection to SE
> Oct  1 08:32:28 ns bgpd[27739]: handle_pollfd: poll fd: No such file or
> directory
> Oct  1 08:32:28 ns bgpd[29697]: handle_pollfd: poll fd: Undefined error: 0
> Oct  1 08:32:28 ns bgpd[29697]: RDE: Lost connection to SE control
> Oct  1 08:32:28 ns bgpd[27739]: main: Lost connection to SE
> Oct  1 08:32:28 ns bgpd[27739]: Lost child: session engine terminated;
> signal 9

This looks like a result of the new tame(2)ing. Below are the tame calls
that were just added to bgpd, according to Theo's diff.

Syscall 105 is setsockopt(2). Both "unix" and "inet" allow it. However,
the man page notes that "inet" restricts setsockopt significantly.
Because this error looks like it's happening within a setsockopt call,
maybe that's the issue. Changing "inet" to "unix" could potentially fix
it, as could refactoring the bgpd code.

I may have time to look into this more later.


Index: usr.sbin/bgpd/rde.c
===
RCS file: /cvs/src/usr.sbin/bgpd/rde.c,v
retrieving revision 1.339
diff -u -p -u -r1.339 rde.c
--- usr.sbin/bgpd/rde.c 21 Sep 2015 09:47:15 -  1.339
+++ usr.sbin/bgpd/rde.c 28 Sep 2015 20:15:11 -
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "bgpd.h"
 #include "mrt.h"
@@ -185,6 +186,9 @@ rde_main(int debug, int verbose)
setresgid(pw->pw_gid, pw->pw_gid, pw->pw_gid) ||
setresuid(pw->pw_uid, pw->pw_uid, pw->pw_uid))
fatal("can't drop privileges");
+
+   if (tame("malloc unix cmsg", NULL) == -1)
+   err(1, "tame");
 
signal(SIGTERM, rde_sighdlr);
signal(SIGINT, rde_sighdlr);
Index: usr.sbin/bgpd/session.c
===
RCS file: /cvs/src/usr.sbin/bgpd/session.c,v
retrieving revision 1.340
diff -u -p -u -r1.340 session.c
--- usr.sbin/bgpd/session.c 4 Aug 2015 14:46:38 -   1.340
+++ usr.sbin/bgpd/session.c 28 Sep 2015 20:15:11 -
@@ -219,6 +219,9 @@ session_main(int debug, int verbose)
setresuid(pw->pw_uid, pw->pw_uid, pw->pw_uid))
fatal("can't drop privileges");
 
+   if (tame("malloc inet cmsg", NULL) == -1)
+   err(1, "tame");
+
signal(SIGTERM, session_sighdlr);
signal(SIGINT, session_sighdlr);
signal(SIGPIPE, SIG_IGN);

Re: Which hardware to keep the level of trust ?

[Michael McConville]

Jean-Francois Simon wrote:
> After having read infos about breaking into bios and other type of
> attacks, has anyone info on which hardware best suits OpenBSD to avoid
> unpleasanties ?
> 
> I was thinking of PIC 32 Microchip but surely difficult to implement
> an OS running into it able to handle normal desktop activities. On the
> other hand I have absolutely no trust in public brands of motherboards
> since they allow bios update.
> 
> If one had to find a hardware most difficult to compromize which one
> would you take ?

OpenBSD isn't generally developed to defend against physical attacks.
Also, most firmware (e.g. BIOS) is, well, firmware, and is therefore
outside the scope of the OS.

Re: top(1), ps(1): per-process CPU time accounting wrong?

[Michael McConville]

Timo Buhrmester wrote:
> On -current amd64 (GENERIC and GENERIC.MP), per-process CPU time
> accounting seems wrong to me, judging from watching top(1) and ps(1)
> while compiling stuff.
> 
> [...]
> 
> Occasionally the pertinent programs do show up, but with *very* little 
> apparent CPU usage:
> | load averages:  2.87,  2.00,  1.63 flap.localdomain 
> 23:47:19
> | 38 processes: 36 idle, 2 on processor
> | CPU0 states: 60.0% user,  0.0% nice,  0.0% system,  0.0% interrupt, 40.0% 
> idle
> | CPU1 states: 42.3% user,  0.0% nice,  0.0% system,  0.0% interrupt, 57.7% 
> idle
> | Memory: Real: 49M/1139M act/tot Free: 2077M Cache: 643M Swap: 0K/2224M
> | 
> |   PID USERNAME PRI NICE  SIZE   RES STATE WAIT  TIMECPU COMMAND
> | 11425 root  640   19M   20M onproc- 0:00  0.29% cc1
> | 14278 root  -60 4380K 5172K sleep piperd0:00  0.10% as
> |  7894 root  180 2268K 4388K sleep pause 0:01  0.05% make
> | 19935 root  100  528K 1492K sleep wait  0:00  0.05% cc

When building software, you usually have a lot of compiler processes
coming and going. The CPU utilization stats (in the header) are more
averaged than the process list stats. So, when building you're likely to
see a lot of CPU utilization in the per-CPU stats but no offending
process in the list.

Re: top(1), ps(1): per-process CPU time accounting wrong?

[Michael McConville]

Timo Buhrmester wrote:
> On -current amd64 (GENERIC and GENERIC.MP), per-process CPU time
> accounting seems wrong to me, judging from watching top(1) and ps(1)
> while compiling stuff.
> 
> The system is under load, building an OpenBSD release, but top(1) and
> ps(1) look like there's not much going on: Most of the time, top(1)
> (with idle processes hidden) shows the load and CPU usage, but no
> processes that are actually consuming the CPU time:
> | load averages:  2.97,  2.06,  1.66 flap.localdomain 
> 23:47:04
> | 38 processes: 36 idle, 2 on processor
> | CPU0 states: 50.7% user,  0.0% nice, 15.4% system,  0.2% interrupt, 33.7% 
> idle
> | CPU1 states: 34.1% user,  0.0% nice,  9.4% system,  0.0% interrupt, 56.5% 
> idle
> | Memory: Real: 36M/1127M act/tot Free: 2088M Cache: 643M Swap: 0K/2224M
> | 
> |   PID USERNAME PRI NICE  SIZE   RES STATE WAIT  TIMECPU COMMAND

There's just over one core being consumed here. If there's one hungry
single-threaded process, its load can appear split between multiple
cores because it gets context switched a bunch of times in each sampling
interval.

Re: spamassasin large CPU usage on new snapshot and a huge bayes_toks file not reported in df

[Michael McConville]

k...@kurawa.no-ip.org wrote:
> Adam Wolk  wrote:
> > After deleting the file, restarting the service processing a single
> > email brought the DB to reported size 37.9M, few emails later it's
> > already reported as 113M I have a hunch that it will bloat again
> > really fast.
> 
> try to disable bayes, set parameter "use_bayes 0" and placed into the
> server-wide local.cf configuration file.

I administrate a mail server running Debian Jessie that uses the shell
script method of calling SpamAssassin from Postfix. It uses a ton of
CPU, so I don't think this is an OpenBSD problem.

That said, you probably shouldn't disable Bayesian filtering. IIUC,
that's the main point of using SpamAssassin, and it's necessary to block
almost all spam.

Re: bluetooth keyboard [was:Re: Intel Edison]

[Michael McConville]

(Was eaten by mailing list problems - resending.)

ludovic coues wrote:
> 2015-08-28 12:32 GMT+02:00 Quartz :
> > Just out of curiosity, are there any plans to support bluetooth at
> > some point in the future?
> 
> From what I heard, there was some support in the past. But people
> stopped to update the code, it rotted with time and it was removed. So
> I assume that bluetooth might be supported again if someone show
> enough interest in doing so.

tedu deleted it at a hackathon last year:

http://undeadly.org/cgi?action=article&sid=20140729070721

I know FreeBSD's Bluetooth implementation is tied into some sort of
plugin-ish network stack framework that the devs (Theo, IIRC) don't
like, so it can't be ported. I don't know about the situation with
NetBSD.

Anecdotally, it seems like Bluetooth isn't used much these days.

Re: lidsuspend does not work anymore on 5.8 snapshot, garbles screen, zzz suspend works fine (longer)

[Michael McConville]

Michael McConville wrote:
> I'm having a similar issue on today's AMD64 snapshot on a ThinkPad
> X210.
> 
> When I opened it the screen stayed black and there were no signs of
> life other than the battery indicator. Pressing keys did nothing. I
> had to power cycle.
> 
> The only relevant syslog entry was:
> 
> > Jul 29 13:29:22 thinkpad apmd: system suspending

For what it's worth, I've had this happen once or twice in the past
couple days. I'm running new snapshots.

Re: Ubiquiti EdgeRouter Lite

[Michael McConville]

Michael McConville wrote:
> This spring, I asked a few OpenBSD MIPS devs about the project's
> interest in a MIPS32 port for the Creator CI20. It turns out that
> MIPS32 support was quietly removed last year:
> 
> > 
> > revision 1.20
> > date: 2014/03/11 07:50:49;  author: jasper;  state: Exp;  lines: +1 -15;
> > remove #if(n)def __LP64__ from the mips64 codebase, as mips32 never really 
> > went anywhere.
> > 
> > ok miod@
> > 
> 
> I was pretty forcibly told that there was no interest, which is
> understandable.
> 
> [snip]

Miod gave me permission to share the emails, which I thought were
informative and interesting:

http://www.sccs.swarthmore.edu/users/16/mmcconv1/others/miod-mips32.txt

Re: Ubiquiti EdgeRouter Lite

[Michael McConville]

Juan Francisco Cantero Hurtado wrote:
> Slightly off-topic:
> 
> Ubiquiti released recently a new router named EdgeRouter X. 49 USD, 5
> gigabit ports, 5W, dual-core 800Mhz, 256MB.
> 
> It's a MIPS32, so if some developer is looking for a new platform for
> OpenBSD... :P . The processor is licensed from Imagination, which I
> guess that is more open than Cavium. I have not found a dmesg yet.
> 
> http://dl.ubnt.com/datasheets/edgemax/EdgeRouter_X_DS.pdf
> 
> http://www.embeddeddeveloper.com/cores/documents/MIPS32_1004K_rev1.pdf

This spring, I asked a few OpenBSD MIPS devs about the project's
interest in a MIPS32 port for the Creator CI20. It turns out that MIPS32
support was quietly removed last year:

> 
> revision 1.20
> date: 2014/03/11 07:50:49;  author: jasper;  state: Exp;  lines: +1 -15;
> remove #if(n)def __LP64__ from the mips64 codebase, as mips32 never really 
> went anywhere.
> 
> ok miod@
> 

I was pretty forcibly told that there was no interest, which is
understandable. Without TLB magic or the below-mentioned EVA, a MIPS32
chip can only directly map 512 MB of memory, which is becoming
unacceptable for everything but embedded devices. For more details,
check out its wacky memory model:

http://www.johnloomis.org/microchip/pic32/memory/memory.html

ImgTec, the new owners of the ISA, added a workaround called Enhanced
Virtual Addressing (EVA) in MIPS32 revision 3.5 (MIPS32r3.5). It
increases the directly mapped memory limit to 3.5 GB. I don't know
whether any OSs actually support it, though, and I remember hearing that
it's not elegant (but that's just a vague memory).

My description of the memory limit issue may have been misleading. If
anyone notices mistakes, please correct me.  :)

So, if you want BSD on MIPS32, NetBSD is your best (only?) bet.

Re: Openbsd 5.7: IPv6 autoconf not working

[Michael McConville]

Alexandre Westfahl wrote:
> I have a problem with IPv6, I'm not getting "public" IP but router
> advertisement/solicitations are being exchanged.

Are you sure pf isn't interfering? What does your pf.conf look like?
I've had that problem in the past with IPv6.

Re: Maintaining CAs not in cert.pem

[Michael McConville]

Ted Unangst wrote:
> Michael McConville wrote:
> > > Another meat could be, why you're using self-signed certificates?
> > > Given the plethora of options for getting free (valid) certificates.
> > 
> > He mentioned in his original email that it's a requirement where he
> > works. That's common, from what I hear, although probably not the
> > safest.
> 
> I would consider a cert signed by somebody I actually trust (me) safer
> than delegating that trust to 300 strangers.

I was thinking of offices that make employees install their root
certificate so that their encrypted traffic can be filtered/monitored.

Re: Maintaining CAs not in cert.pem

[Michael McConville]

Giancarlo Razzolini wrote:
> Em 30-07-2015 09:15, trondd escreveu:
> > I guess the meat of the question is "is certs.pem the only location
> > for CAs used by the system?" (ignoring application certificate
> > stores, ie. Firefox or java).
> 
> Another meat could be, why you're using self-signed certificates?
> Given the plethora of options for getting free (valid) certificates.

He mentioned in his original email that it's a requirement where he
works. That's common, from what I hear, although probably not the
safest.

Re: lidsuspend does not work anymore on 5.8 snapshot, garbles screen, zzz suspend works

[Michael McConville]

Gerald Hanuer wrote:
> > When I opened it the screen stayed black and there were no signs of
> > life other than the battery indicator. Pressing keys did nothing.
> > I had to power cycle.
> 
>  I am seeing similar behavior with current built 7-28-15 and T450s.

Seems that it's tentatively fixed:

https://marc.info/?l=openbsd-cvs&m=143819481225921&w=2

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/dev/acpi/acpi.c

Re: lidsuspend does not work anymore on 5.8 snapshot, garbles screen, zzz suspend works fine (longer)

[Michael McConville]

I'm having a similar issue on today's AMD64 snapshot on a ThinkPad X210.

When I opened it the screen stayed black and there were no signs of life
other than the battery indicator. Pressing keys did nothing. I had to
power cycle.

The only relevant syslog entry was:

> Jul 29 13:29:22 thinkpad apmd: system suspending

dmesg:

OpenBSD 5.8 (GENERIC.MP) #1206: Wed Jul 29 01:00:00 MDT 2015
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 4062691328 (3874MB)
avail mem = 3935670272 (3753MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xe0010 (78 entries)
bios0: vendor LENOVO version "6QET61WW (1.31 )" date 10/26/2010
bios0: LENOVO 3626FAU
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT ECDT APIC MCFG HPET ASF! SLIC BOOT SSDT TCPA SSDT 
SSDT SSDT
acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP1(S4) EXP2(S4) EXP3(S4) 
EXP4(S4) EXP5(S4) EHC1(S3) EHC2(S3) HDEF(S4)
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpiec0 at acpi0
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, 2793.40 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,LONG,LAHF,PERF,ITSC,SENSOR,ARAT
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges
cpu0: apic clock running at 132MHz
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, 2793.00 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,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, 2793.00 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,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, 2793.00 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,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 1 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 2, remapped to apid 1
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus -1 (PEG_)
acpiprt2 at acpi0: bus 13 (EXP1)
acpiprt3 at acpi0: bus -1 (EXP2)
acpiprt4 at acpi0: bus -1 (EXP3)
acpiprt5 at acpi0: bus 5 (EXP4)
acpiprt6 at acpi0: bus 2 (EXP5)
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
acpipwrres0 at acpi0: PUBS, resource for EHC1, EHC2
acpitz0 at acpi0: critical temperature is 100 degC
acpibtn0 at acpi0: LID_
acpibtn1 at acpi0: SLPB
acpibat0 at acpi0: BAT0 model "42T4694" serial  1408 type LION oem "SANYO"
acpibat1 at acpi0: BAT1 not present
acpiac0 at acpi0: AC unit online
acpithinkpad0 at acpi0
acpidock0 at acpi0: GDCK not docked (0)
cpu0: Enhanced SpeedStep 2793 MHz: speeds: 2534, 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
vga1 at pci0 dev 2 function 0 "Intel HD Graphics" rev 0x02
intagp0 at vga1
agp0 at intagp0: aperture at 0xd000, size 0x1000
inteldrm0 at vga1
drm0 at inteldrm0
inteldrm0: 1280x800
wsdisplay0 at vga1 mux 1: console (std, vt100 emulation)
wsdisplay0: screen 1-5 added (std, vt100 emulation)
"Intel 3400 MEI" rev 0x06 at pci0 dev 22 function 0 not configured
puc0 at pci0 dev 22 function 3 "Intel 3400 KT" rev 0x06: ports: 1 com
com4 at puc0 port 0 apic 1 int 17: ns16550a, 16 byte fifo
com4: probed fifo depth: 0 bytes
em0 at pci0 dev 25 function 0 "Intel 82577LM" rev 0x06: msi, address 
f0:de:f1:31:ca:8d
ehci0 at pci0 dev 26 func

Re: Intel Atom?

[Michael McConville]

Michael McConville wrote:
> (especially when the proxied traffic is TLS-encrypted)

Disregard that clause. It's obviously the end-points that handle TLS
sessions, not the exit relay.

Re: Intel Atom?

[Michael McConville]

Quartz wrote:
> > Here's the dmesg for my Tor exit relay, which runs on a D2700. It
> > moves about 2.0-4.5 MB/s in each direction.
> 
> Hmmm that's nowhere near as fast as what we do, and not even as
> fast as a P3.

Do you have 4,500-7,000 open connections? That slows my machine's
networking down quite a bit, but I think it's pretty rare for a small
router to have that many.

Another complication that doesn't apply to you is Tor's crypto. I don't
know how many AES and ed25519 operations Tor demands per network packet,
but (especially when the proxied traffic is TLS-encrypted) it's quite a
few. No AES-NI, either.

> > It seems to be running at full capacity doing so,
> 
> I don't know much about tor. When you say "full capacity", do you mean
> the hardware was maxed out, or that you were doing the most that the
> tor network would allow you?

The machine seems maxed out. If I recall correctly, netperf lets me move
~100 Mbps in each direction, as the dedicated server provider
advertised.

Regardless, my current setup uses all of my allotted monthly bandwidth,
so I'm not looking to change anything.

Re: Intel Atom?

[Michael McConville]

Here's the dmesg for my Tor exit relay, which runs on a D2700. It moves
about 2.0-4.5 MB/s in each direction. It seems to be running at full
capacity doing so, but that's with 3,000-5,000 open files and
4,500-7,000 open connections. So, I think you'll be able to get a lot
out of one of these CPUs.



OpenBSD 5.7-stable (GENERIC.MP) #0: Fri Jun 19 13:20:46 EDT 2015
root@exit:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2112454656 (2014MB)
avail mem = 2052362240 (1957MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7ee98000 (27 entries)
bios0: vendor Intel Corp. version "MUCDT10N.86A.0069.2012.0323.1358" date 
03/23/2012
bios0: Intel Corporation D2700MUD
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP SSDT APIC MCFG HPET
acpi0: wakeup devices SLT1(S4) PS2M(S4) PS2K(S4) UAR1(S3) UAR2(S3) USB0(S3) 
USB1(S3) USB2(S3) USB3(S3) USB7(S3) PXSX(S4) RP01(S4) PXSX(S4) RP02(S4) 
PXSX(S4) RP03(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) Atom(TM) CPU D2700 @ 2.13GHz, 2133.73 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,ITSC
cpu0: 512KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 7 var ranges, 88 fixed ranges
cpu0: apic clock running at 133MHz
cpu0: mwait min=64, max=64, C-substates=0.1.0.0.0, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: Intel(R) Atom(TM) CPU D2700 @ 2.13GHz, 2133.41 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,ITSC
cpu1: 512KB 64b/line 8-way L2 cache
cpu1: smt 1, core 0, package 0
cpu2 at mainbus0: apid 2 (application processor)
cpu2: Intel(R) Atom(TM) CPU D2700 @ 2.13GHz, 2133.41 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,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,ITSC
cpu2: 512KB 64b/line 8-way L2 cache
cpu2: smt 0, core 1, package 0
cpu3 at mainbus0: apid 3 (application processor)
cpu3: Intel(R) Atom(TM) CPU D2700 @ 2.13GHz, 2133.41 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,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,ITSC
cpu3: 512KB 64b/line 8-way L2 cache
cpu3: smt 1, core 1, package 0
ioapic0 at mainbus0: apid 8 pa 0xfec0, version 20, 24 pins
ioapic0: misconfigured as apic 0, remapped to apid 8
acpimcfg0 at acpi0 addr 0xe000, bus 0-63
acpihpet0 at acpi0: 14318179 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 2 (P0P1)
acpiprt2 at acpi0: bus 1 (RP01)
acpiprt3 at acpi0: bus -1 (RP02)
acpiprt4 at acpi0: bus -1 (RP03)
acpiprt5 at acpi0: bus -1 (RP04)
acpicpu0 at acpi0
acpicpu1 at acpi0
acpicpu2 at acpi0
acpicpu3 at acpi0
acpibtn0 at acpi0: PWRB
acpibtn1 at acpi0: SLPB
acpivideo0 at acpi0: GFX0
acpivout0 at acpivideo0: DD02
pci0 at mainbus0 bus 0
pchb0 at pci0 dev 0 function 0 vendor "Intel", unknown product 0x0bf3 rev 0x03
vga1 at pci0 dev 2 function 0 "Intel GMA 3600" rev 0x09
intagp at vga1 not configured
wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation)
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
azalia0 at pci0 dev 27 function 0 "Intel 82801GB HD Audio" rev 0x02: msi
azalia0: codecs: Realtek ALC662
audio0 at azalia0
ppb0 at pci0 dev 28 function 0 "Intel 82801GB PCIE" rev 0x02: msi
pci1 at ppb0 bus 1
em0 at pci1 dev 0 function 0 "Intel 82574L" rev 0x00: msi, address 
00:22:4d:9d:93:e8
uhci0 at pci0 dev 29 function 0 "Intel 82801GB USB" rev 0x02: apic 8 int 23
uhci1 at pci0 dev 29 function 1 "Intel 82801GB USB" rev 0x02: apic 8 int 19
uhci2 at pci0 dev 29 function 2 "Intel 82801GB USB" rev 0x02: apic 8 int 18
uhci3 at pci0 dev 29 function 3 "Intel 82801GB USB" rev 0x02: apic 8 int 16
ehci0 at pci0 dev 29 function 7 "Intel 82801GB USB" rev 0x02: apic 8 int 23
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 "Intel EHCI root hub" rev 2.00/1.00 addr 1
ppb1 at pci0 dev 30 function 0 "Intel 82801BAM Hub-to-PCI" rev 0xe2
pci2 at ppb1 bus 2
pcib0 at pci0 dev 31 function 0 "Intel NM10 LPC" rev 0x02
ahci0 at pci0 dev 31 function 2 "Intel 82801GR AHCI" rev 0x02: msi, AHCI 1.1
scsibus1 at ahci0: 32 targets
sd0 at scsibus1 targ 0 lun 0:  SCSI3 0/direct 
fixed naa.50014ee0ad49cde9
sd0: 476940MB, 512 bytes/sector, 976773168 sectors
ichiic0 at pci0 dev 31 function 3 "Intel 82801GB SMBus" rev 0x02: apic 8 int 19
iic0 at ichiic0
lm1 at iic0 addr 0x2d: W83627DHG
spdmem0 at iic0 addr 0x51: 2GB DDR3 SDRAM PC3-8500 SO-DIMM
usb1 at uhci0: USB revision 1.0
uhub1 at usb1 "Inte

Re: Patching OpenBSD 5.7

[Michael McConville]

Likely related:

https://marc.info/?t=14319191082&r=1&w=2

We never figured it out. Building the entire system from source and
reinstalling fixed it for me.

Re: Building Tor with libevent 2.x (from ports)

[Michael McConville]

On Thu, Jul 23, 2015 at 05:40:54PM +0200, nusenu wrote:
> as we have learned from Nicholas, OpenBSD will stay with libevent
> 1.4.x for the time being.
> 
> Do you have any plans to make the Tor port use libevent 2.x from
> ports?
> 
> Background: Tor on OpenBSD using libevent 1.4.15 is significantly
> "slower" (less throughput) compared to other OSes with libevent 2.x on
> the same machine. I don't know whether libevent is related to this
> issue in any way but I simply wanted to see whether Tor with libevent
> 2.x on OpenBSD is any different in this regard compared to Tor with
> libevent 1.4.x on OpenBSD.

I suspect it'll be a noticeable difference, maybe a big one. Most of the
Libevent performance improvements I've heard of involve systems with
many connections, and exit nodes have thousands.

> If you managed to build Tor on -stable with libevent 2.x from ports
> I'm also happy to try any custom patches you might have applied.

It may be easier to get upstream to use pkg-config first. I'm planning
to look at their autoconf script and open a ticket today.

That said, I think they're phasing out Libevent 1.x support, so we can't
wait too long.

Re: OpenBSD release with libevent 2.x?

[Michael McConville]

> On Wed, Jul 22, 2015 at 11:07:46PM +0200, nusenu wrote:
> > there seem to be a few people that would like to run tor with libevent
> > 2.x (currently available via ports) but failed to build tor with
> > libevent from ports.
> > 
> > So I'm wondering whether there are any plans to ship any of the next
> > two upcoming releases with libevent 2.x (instead of 1.4.x)?
> 
On Wed, Jul 22, 2015 at 11:18:22PM +0100, Nicholas Marriott wrote:
> No we have pretty much settled on a (mildly forked) 1.4 now and there
> are no plans to update the base system.
> 
> I don't see why libevent 1.4 in base blocks anything that requires 2.x,
> the port should coexist happily with base.

For what it's worth, the Libevent 2 port's organization is a little
strange. It's split into a bunch of subarchives/subobjects. This makes
building Tor with it a major headache (I haven't managed yet). However,
that may be mostly due to Tor's brittle config logic.

Re: tor not working in 5.8 #1024

[Michael McConville]

On Wed, Jul 15, 2015 at 05:36:30AM +0200, Peter Hessler wrote:
> On 2015 Jul 15 (Wed) at 05:27:37 +0200 (+0200), L.R. D.S. wrote:
> > Not that "nice". This hardware have many fancy things like UEFI and
> > intel ME.
> 
> > I run i386 mostly because the /amd64.html say that "it is thus safer
> > to run those machines in i386 mode"
> 
> That is an incredibly ancient comment, and is eseentially no longer
> relevant.

Agreed.

The full paragraph is:

> OpenBSD/amd64 runs on AMD's Athlon-64 family of processors in 64-bit
> mode. It also runs on processors made by other manufacturers which have
> cloned the AMD64 extensions. (Some Intel processors lack support for
> important PAE NX bit, which means those machines will run without any
> W^X support -- it is thus safer to run those machines in i386 mode).

And your CPU supports PAE NX:


http://ark.intel.com/products/68316/Intel-Core-i5-3470-Processor-6M-Cache-up-to-3_60-GHz

If I'm reading your dmesg correctly, it's listed there as well.

Someone correct me if I'm wrong, but it seems that the days of i386
images being reasonable to run on amd64 hardware are coming to an end.
i386 support appears to be a fading priority for most projects and the
subset of amd64 features used is growing quickly.

Re: tor not working in 5.8 #1024

[Michael McConville]

On Wed, Jul 15, 2015 at 02:28:38AM +0200, L.R. D.S. wrote:
> The package is from 
> http://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/i386/
> 
> [...]
> 
> OpenBSD 5.8-beta (GENERIC.MP) #1024: Tue Jul 14 00:44:38 MDT 2015
> dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP
> cpu0: Intel(R) Core(TM) i5-3470 CPU @ 3.20GHz ("GenuineIntel" 686-class) 3.21 
> GHz
> cpu0: 
> FPU,V86,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,NXE,LONG,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,LAHF,PERF,ITSC,FSGSBASE,SMEP,ERMS,SENSOR,ARAT

Also, especially with a reasonably nice CPU like that, you should be on
amd64 unless you have a good reason not to be. It's more secure and
better maintained. I'd suggest installing an amd64 snapshot as your next
step. Note that you can't upgrade with a different architecture - it has
to be a reinstall.

Re: tor not working in 5.8 #1024

[Michael McConville]

On Wed, Jul 15, 2015 at 02:28:38AM +0200, L.R. D.S. wrote:
> I did the update of a box today, from 5.7 to 5.8 snapshot. Everything
> is working fine, except the tor package. On 5.7 it work normally,
> without any additional configurations, but in 5.8 it cannot complete
> connections. I watched my interface (re0) with tcpdump when trying a
> connection and the connection go to the exit nodes, but can't download
> the content.
> 
> The package is from 
> http://ftp.openbsd.org/pub/OpenBSD/snapshots/packages/i386/

You changed your PKG_PATH or pkg.conf to that URL and ran 'sudo pkg_add
-u', right?

> Default /etc/tor/torrc
> 
> What I tried:
> - Purge packages/cache/configurations and reinstall;
> - tor-resolve (in different domains);
> - torsocks (cURL and Firefox);
> - SOCKS5 in localhost:9050 (firefox);
> 
> Maybe:
> - It's just a bad configuration (higher probability, since I'm not a 
> sysadmin);
> - Tor network instability;
> - Tor incompatibility with -current 5.8;
> - Bad compiled package;
> - My ISP is blocking Tor connections (I don't think so).

Can you give examples of what's going wrong from the logs? They should
show up in /var/log/messages.

Also, there's a pretty well-populated mailing list for Tor on the BSDs:

http://lists.nycbug.org/mailman/listinfo/tor-bsd

You may have better luck there. I suspect that this problem has a pretty
simple fix, though. I've been running snapshots for about five months
and have never had an issue with Tor (which I use daily), so I think
it's specific to your machine.

Re: SOHO IPv6 router problems

[Michael McConville]

On Mon, Jul 13, 2015 at 03:12:50PM -0300, Giancarlo Razzolini wrote:
> The client doesn't need inbound UDP ports to be open. The OpenBSD
> firewall do, if you're using DHCPv6 to configure it. If using SLAAC,
> only RS and RA icmp messages are needed. Since stateless configuration
> is done using multicast (ff02) and link-local (fe80) addresses, no
> need to worry. You can even make a rule allowing only your CPE
> link-local, if you want.

I stand corrected.

I just disabled all of my IPv6-related pf exceptions and it still works.
I must have inadvertantly fixed something else when I added them.

> You don't need DHCPv6. I use stateless both for my firewall getting
> it's IPv6 address from the CPE and for it advertising the prefix on
> the internal network. Most modern systems can configure the dns using
> stateless configuration. So only a subset of ICMPv6 messages need to
> be allowed both on the router and clients.

Also correct. I just checked, and Comcast home routers let you choose
between stateless and stateful IPv6 config in their control panel.

Sorry for the noise,
Michael

Re: SOHO IPv6 router problems

[Michael McConville]

On Mon, Jul 13, 2015 at 04:39:39PM +, Christian Weisgerber wrote:
> On 2015-07-02, Patrik Lundin  wrote:
> 
> > In summary, using the following commands (together with ip6
> > forwarding enabled) allows us to have a working setup without any
> > other manual intervention:
> >===
> > # ifconfig em0 inet6 autoconf
> > # ifconfig em1 inet6 autoconf
> > # dhcp6c -Df -c /etc/dhcp6c.conf em0 
> > # rtadvd em1 
> >===
> >
> > But like stated initially, we do not really like the idea of
> > enabling autoconf on em1.
> 
> Once you get that far, you might notice that dynamic addresses for
> your network are rather inconvenient.  You'll need to update all
> references to your internal hosts in
> * pf.conf
> * DNS zones
> * ... any other daemons that might refer to them ...
> 
> You'll also need to distribute the addresses to your hosts.  If you
> don't like SLAAC-style addresses, you'll need DHCPv6.  Which you might
> also need for the nameserver, NTP server, etc.
> 
> Out of the box, OpenBSD is poorly equipped for all of this.

I found setting up IPv6 on a Comcast home network to be very painful.

Part of it was that you need inbound IPv6 ICMP and UDP ports open. This
seems like a fundamentally bad idea because it prevents client machines
from just blocking all incoming connections (something I've done since
starting with OpenBSD). Also, DHCPv4 seems to do fine without incoming
connections. Maybe there's a good reason for them, though.

Here's the guide that solved my pf woes:

http://pivotallabs.com/configuring-freebsd-9-1-as-an-ipv6-dhcp-client/

I was considering trying to develop a tool to make it a smoother
process. However, it increasingly seems like a consequence of DHCPv6
being unnecessarily complex.

Re: mail server on rental server , cannot send gmail.com

[Michael McConville]

On Sat, Jul 11, 2015 at 05:53:42AM +0900, Tuyosi Takesima wrote:
> i can send and recieve mail by using mail server on rental server .
> 
> namely send  to tuy...@openbsd.link
>  recieve  from tuy...@openbsd.link
> 
> but now state , i cannot send mail to x...@gmail.com becase of relay
> host

You didn't share the relevant /var/log/maillog entries, right? That's
probably the most important diagnostic.

Re: dhclient.conf does not appear to support resolv.conf formatting for nameservers on non-standard port

[Michael McConville]

On Thu, Jul 09, 2015 at 10:01:01PM -0600, Theo de Raadt wrote:
> The 4.4BSD chflags model of "security" on inodes is unmaintained, and
> the utilitization of this is not realized OpenBSD.
> 
> To be honest, I doubt any of us see much benefit in it, relative to
> other features of the system.  When you are holed, a few file changes
> + a reboot can undo it, voila, noone would ever notice.
> 
> I don't think it is more than a gimmick.
> 
> If you use it, you really are on your own.  To my knowledge, noone in
> the development group has seriously trialed/used it in years.

Could they ever be removed?

>From what I just read, it doesn't seem like they're standardized. Would
the silent changes to people's file access controls be unacceptable?

If it's possible, I'm interesting in trying.

Re: out of memory and login.conf logging

[Michael McConville]

On Thu, Jun 25, 2015 at 05:06:32PM +0200, nusenu wrote:
> would I see any log entries in /var/log/messages if the system runs
> out of memory and kills a process or if a limit in /etc/login.conf has
> been overstepped by a process?

It should be easy to test this yourself. See login.conf(5) and the
ulimit section of ksh(1).

Re: Any books about OpenBSD ARM programming?

[Michael McConville]

On Wed, Jun 24, 2015 at 05:26:10PM +0200, Piotr Kubaj wrote:
> Hi all,
> 
> I'm mainly a FreeBSD user but want to learn OpenBSD. I'm also interested
> in basic electronics, like programming own thermometer. That's why I
> want to install OpenBSD on my BeagleBone Black and write some simple
> programs using I/O pins. Are there any tutorials on this? I have found
> some books about FreeBSD kernel programming, but none for OpenBSD.
> Thanks for your help.

http://www.tedunangst.com/flak/post/OpenBSD-on-BeagleBone-Black

I doubt there's much of what you're looking for. "The Design and
Implementation of the OpenBSD Operating System" doesn't exist, and there
isn't (to my knowledge) much long-form writing about the OpenBSD kernel.

That said, the code is engineered to be easy to understand and modify if
you understand the core concepts, so much of your FreeBSD and general
kernel experience will probably translate.

I'm pretty new to this, so I might have missed something.

Re: OpenBSD 58-beta

[Michael McConville]

On Thu, Jun 18, 2015 at 09:18:31PM +0500, dmitry.sensei wrote:
> First feature :) I can't load latest OpenBSD.iso.
> Unending stream "Process (pid 1) got signal 4"

This has been happening. There was a thread about it yesterday. Theo
advised everyone on tech@ to just wait a few days.

Re: AMD64 Snapshot Issues

[Michael McConville]

> This is how it goes with snaps. You should not complain. If team
> managed to build it, it does not mean that it IS stable. I'v been in
> this situation several times. There are no one to blame. You should
> ever stay away from snaps or be prepared to fix problems by yourself.

No one is complaining, and no one needs a lecture.

These emails are simply to point out the issue in case devs aren't
aware, and to warn people who were considering updating to wait a day or
two.

Fixing snapshot problems yourself isn't necessary as long as you are
willing to briefly have an inoperable machine a few times a year.

Anecdotally, consider wrapping your future emails to 72 characters. It
makes them easier to read for many email clients and archivers:

http://www.openbsd.org/mail.html

AMD64 Snapshot Issues

[Michael McConville]

About twelve hours ago, I downloaded and installed the latest AMD64
snapshot (#1063 in /etc/motd). When booting it hits an infinite loop,
repeatedly printing "Process (pid 1) got signal 4" to the console.

When I boot to a snapshot ramdisk or bsd.rd now, it hangs at "root on
rd0a swap on rd0b dump on rd0b". This happens on two different USBs, and
whether or not my primary drive is even connected to the machine.

A half hour ago, I downloaded a newer snapshot ramdisk from
ftp.openbsd.org. When booted to, this one immediately hits an infinite
loop, printing "Using drive 0, partition 3." to the console.

I'm pretty confident that this is an issue with the snapshots and not my
machine because the 5.7 release images boot fine.

I suspect that the devs are already aware of this, but I thought I'd
mention it.

Error when compiling libcrypto after 003_openssl.patch

[Michael McConville]

Three weeks ago, I manually upgraded a dedicated server from 5.6 to 5.7.
I couldn't use the ramdisk because I have a budget provider that
effectively doesn't offer KVM access. I followed the published
instructions carefully and everything seems to be working.

Patch 002 applied and built cleanly, and patch 003 applied without
issue. However, I get the error shown below when I attempt to build
libcrypto for patch 003.

I have libcrypto.so versions 30 and 32. In case libcrypto.so.30 was a
vestige of 5.6 and was interfering, I built and reinstalled libssl after
disabling libcrypto.so.30 with chmod. I then tried building libcrypto
again, but got the same error.

b_sock.so is mentioned in the error output, but I only have one instance
of it, and it would have been updated when I built and reinstalled
libssl. I don't have much experience with shared libraries, so I thought
I should stop tinkering before I break something.

At least one other user on Freenode had the same issue but hadn't yet
looked into it.

Has anyone else experienced this? Any ideas about what might be causing
it?

$ sudo sh -c 'cd /usr/src/lib/libcrypto/crypto && make obj && make && make 
install'
/usr/src/lib/libcrypto/crypto/obj -> /usr/obj/lib/libcrypto/crypto
building shared crypto library (version 32.0)
cc -shared -fpic  -o libcrypto.so.32.0  `lorder cryptlib.so
malloc-wrapper.so mem_dbg.so cversion.so ex_data.so cpt_err.so uid.so
o_time.so o_str.so o_init.s o mem_clr.so aes_misc.so aes_ecb.so
aes_cfb.so aes_ofb.so aes_ctr.so aes_ige.so aes_wrap.so a_object.so
a_bitstr.so a_utctm.so a_gentm.so a_time.so a_int.so a_octet.so
a_print.so a_type.so a_dup.so a_d2i_fp.so a_i2d_fp.so a_enum.so
a_utf8.so a_sign.so a_digest.so a_verify.so a_mbstr.so a_strex.so
x_algor.so x_val .so x_pubkey.so x_sig.so x_req.so x_attrib.so
x_bignum.so x_long.so x_name.so x_x509.so x_x509a.so x_crl.so x_info.so
x_spki.so nsseq.so x_nx509.so d2i_pu.so d2i_pr.so i2d_pu.so i2d_pr.so
t_req.so t_x509.so t_x509a.so t_crl.so t_pkey.so t_spki.so t_bitst.so
tasn_new.so tasn_fre.so tasn_enc.so tasn_dec.so tasn_utl .so tasn_typ.so
tasn_prn.so ameth_lib.so f_int.so f_string.so n_pkey.so f_enum.so
x_pkey.so a_bool.so x_exten.so bio_asn1.so bio_ndef.so asn_mime.so
asn1_gen .so asn1_par.so asn1_lib.so asn1_err.so a_bytes.so a_strnid.so
evp_asn1.so asn_pack.so p5_pbe.so p5_pbev2.so p8_pkey.so asn_moid.so
a_set.so bf_skey.so bf_ec b.so bf_cfb64.so bf_ofb64.so bio_lib.so
bio_cb.so bio_err.so bss_mem.so bss_null.so bss_fd.so bss_file.so
bss_sock.so bss_conn.so bf_null.so bf_buff.so b_pri nt.so b_dump.so
b_posix.so b_sock.so bss_acpt.so bf_nbio.so bss_log.so bss_bio.so
bss_dgram.so bn_add.so bn_div.so bn_exp.so bn_lib.so bn_ctx.so bn_mul.so
bn _mod.so bn_print.so bn_rand.so bn_shift.so bn_word.so bn_blind.so
bn_kron.so bn_sqrt.so bn_gcd.so bn_prime.so bn_err.so bn_sqr.so
bn_recp.so bn_mont.so bn_mp i.so bn_exp2.so bn_gf2m.so bn_nist.so
bn_depr.so bn_const.so bn_x931p.so buffer.so buf_err.so buf_str.so
cmll_cfb.so cmll_ctr.so cmll_ecb.so cmll_ofb.so c_sk ey.so c_ecb.so
c_enc.so c_cfb64.so c_ofb64.so chacha.so cmac.so cm_ameth.so cm_pmeth.so
comp_lib.so comp_err.so c_rle.so c_zlib.so conf_err.so conf_lib.so co
nf_api.so conf_def.so conf_mod.so conf_mall.so conf_sap.so cbc_cksm.so
cbc_enc.so cfb64enc.so cfb_enc.so ecb3_enc.so ecb_enc.so enc_read.so
enc_writ.so fcryp t.so ofb64enc.so ofb_enc.so pcbc_enc.so qud_cksm.so
rand_key.so set_key.so xcbc_enc.so str2key.so cfb64ede.so ofb64ede.so
ede_cbcm_enc.so dh_asn1.so dh_gen.s o dh_key.so dh_lib.so dh_check.so
dh_err.so dh_depr.so dh_ameth.so dh_pmeth.so dh_prn.so dsa_gen.so
dsa_key.so dsa_lib.so dsa_asn1.so dsa_vrf.so dsa_sign.so dsa_err.so
dsa_ossl.so dsa_depr.so dsa_ameth.so dsa_pmeth.so dsa_prn.so
dso_dlfcn.so dso_err.so dso_lib.so dso_null.so dso_openssl.so ec_lib.so
ecp_smpl.so e cp_mont.so ecp_nist.so ec_cvt.so ec_mult.so ec_err.so
ec_curve.so ec_check.so ec_print.so ec_asn1.so ec_key.so ec2_smpl.so
ec2_mult.so ec_ameth.so ec_pmeth.s o eck_prn.so ecp_nistp224.so
ecp_nistp256.so ecp_nistp521.so ecp_nistputil.so ecp_oct.so ec2_oct.so
ec_oct.so ech_lib.so ech_ossl.so ech_key.so ech_err.so ec s_lib.so
ecs_asn1.so ecs_ossl.so ecs_sign.so ecs_vrf.so ecs_err.so eng_err.so
eng_lib.so eng_list.so eng_init.so eng_ctrl.so eng_table.so eng_pkey.so
eng_fat .so eng_all.so tb_rsa.so tb_dsa.so tb_ecdsa.so tb_dh.so
tb_ecdh.so tb_rand.so tb_store.so tb_cipher.so tb_digest.so tb_pkmeth.so
tb_asnmth.so eng_openssl.so eng_cnf.so eng_dyn.so eng_rsax.so err.so
err_all.so err_prn.so encode.so digest.so evp_enc.so evp_key.so e_des.so
e_bf.so e_idea.so e_des3.so e_camellia.so e _rc4.so e_aes.so names.so
e_xcbc_d.so e_rc2.so e_cast.so m_null.so m_md4.so m_md5.so m_sha.so
m_sha1.so m_wp.so m_dss.so m_dss1.so m_mdc2.so m_ripemd.so m_ec dsa.so
p_open.so p_seal.so p_sign.so p_verify.so p_lib.so p_enc.so p_dec.so
bio_md.so bio_b64.so bio_enc.so evp_err.so e_null.so c_all.so evp_lib.so
evp_pkey .so evp_pbe.so p5_crpt.so p5_crpt2.so e_old.so pmeth_lib.so
pmeth_fn.so pmet