
OpenBSD 5.9 released early - hobarrera
http://undeadly.org/cgi?action=article&sid=20160329181346
======
throwaway2048
It is likely they released early because they want additional testing time for
the SMP diffs they are about to merge. With 6.0 we may be seeing both fully
SMP routing and PF support. As of now, routing and PF are fully giantlocked in
the kernel, and can only run on one core. This should greatly speed up routing
and filtering performance.

------
robinhoodexe
"The less(1) we're all familiar with has been completely rewritten. After
importing a fork from illumos' Garrett D'Amore, OpenBSD continued to make
improvements to the code. A safer and more modern tool was the end result,
even if it's just for viewing text. Hopefully there will be less bugs now."

Impressive work.

~~~
cajetanus
And _less_ bugs. Beautiful pun there.

~~~
duaneb
...until you realize that the proper word would be "fewer" because bugs are
countable.

~~~
phaemon
...or until you realise that the personal preferences of Robert Baker do not
constitute what is "proper". It was a daft preference when expressed and it's
no less a daft "rule" now.

~~~
chipaca
I think you meant ”fewer daft”.

------
walterbell
_> If running OpenBSD under Xen (such as on Amazon's cloud platform) sounds
interesting to you, you'll be happy to know that 5.9 includes some pretty
solid support for this._

Exciting! Does the default build include Xen PV drivers for networking and
storage, or is a custom build needed? How about SMP support? OpenBSD would
make an excellent firewall VM for Qubes, XenServer, etc.

~~~
maxaf
Yesterday I discovered that OpenBSD runs well in EC2, but EBS attachments are
silently ignored. :(

------
nickpsecurity
Good work to OpenBSD team. Especially on pledge. Widespread changes are risky
and often fail. Just speaks even more about the quality of work they do.

~~~
viraptor
Yeah, that caught my attention. I envy OpenBSD's ability to do "apply this to
everything" projects like this one. Linux had seccomp for ages now, but
there's still barely any application using it. I even wrote patches to add
supports in some projects and they were just ignored. :(

~~~
absorber
You might want to check out firejail -
[https://firejail.wordpress.com/](https://firejail.wordpress.com/) \- it
supports seccomp as well.

~~~
viraptor
It's a step in the right direction, but it misses one great feature of seccomp
- you don't have to activate seccomp at startup.

What it means in practice is (for example) a daemon running under firejail
must be able to open log for writing and open sockets. An application which
uses seccomp natively can first do those things and then block all further
open/socket syscalls.

~~~
netytan
Are you talking about pledge? Pledge works as you describe

------
obsdfnd
Don't forget to donate to the OpenBSD Foundation!

PayPal/Check/Bank Transfer:
[http://www.openbsdfoundation.org/donations.html](http://www.openbsdfoundation.org/donations.html)

~~~
mc808
Is there a way to verify that OpenBSD controls that Bitcoin address?

~~~
obsdfnd
They also have BitPay.

------
hackuser
_802.11n

Another big one for laptop users: initial support for N wireless has landed in
both the iwm(4) and iwn(4) drivers._

Does that mean that 802.11n wasn't supported by OpenBSD until now? 802.11n was
first available in (2010?) and is no longer the current version (802.11ac is).

~~~
nayden
Reversing firmware without documentation takes time. Especially when a single
developer does it on their spare time as a hobby.

~~~
ashitlerferad
Does OpenBSD actually write open WiFi firmware?

~~~
antoinealb
No. But they still have to write drivers that will interact with those
firmwares.

------
soccerdave
The release notes mention good support for running on AWS. I would love to see
more distributions embrace building AMIs, or at the least provide good
documentation to get it running. Ubuntu probably has the best support by
building AMIs for all the regions, it would be awesome to see some others do
the same thing. I think this is probably an overlooked area that could provide
more growth for the BSDs.

~~~
maxaf
When 5.9 was still -current, [https://github.com/ajacoutot/aws-
openbsd](https://github.com/ajacoutot/aws-openbsd) was a viable if clunky way
of producing one's own AMIs. As you can see from the script, there's quite a
bit of work that happens before a -current snapshot could be turned into a
valid AMI.

I think this will become really useful when attached EBS volumes are properly
detected by an OpenBSD system running in EC2. Right now EBS attachments are
silently ignored. (Someone please correct me!)

~~~
devslashnull
As far as I'm aware there isnt any blkfront support in the recent changes,
which would be needed for EBS.

Support for blkfront is not needed to get up and running with Xen though, so
it makes sense to defer it until later and get the bootstrap going and then
the devs can focus on the remaining pieces.

------
krylon
After saving an old laptop at work from landing on the garbage pile, I took it
home and, on a whim, decided to install OpenBSD on it.

I expected problems of some kind or another and was mentally prepared to
install Debian instead, but I was pleasantly surprised that all of the
hardware worked out of the box. Since it is old an fragile, and the battery
lasts about five minutes, I don't do much with it but keep it around for good
luck.

Guess I'll be upgrading this weekend. As luck will have it, I am also binge-
watching Doctor Who currently, which fits in nicely with the cover art. ;-)

~~~
eeks
I am using OpenBSD as my primary workstation on a 2015 Carbon X1, and it works
like a charm.

------
technofiend
OpenBSD has been my go to firewall since my firewall was a Sparcstation IPC.
There have been some major changes along the way, but most of the time
rebuilding the system takes less than an hour and is a matter of porting a few
config files to a fresh copy of the OS. Even the major changes are usually
trivial since the documentation is kept up-to-date and there are plenty of
examples in the docs and on the mailing lists.

The last time I saw anyone test packet passing speeds against OpenBSD it was
around the time of the pf/ipf split and rewrite and OpenBSD was the slowest of
the lot. Although modern hardware can saturate a cable modem, the
multithreading of their network stack is still a positive, as is the work to
support modern wifi cards (N); hopefully AC will be next.

Also definitely looking forward to pledge since it further reduces attack
surfaces on an already hardened OS.

~~~
stsp
There's a lot more work to do for 802.11n in future releases (e.g. MIMO
support). So putting 802.11ac on the roadmap doesn't make much sense at this
stage.

~~~
technofiend
Fair enough - just wishful thinking, and as my friends in OpenBSD-land say "If
you want it so bad, submit a patch."

------
brynet
The 5.9 release includes many pledge(2)'d programs in base, but some notable
ports include decompressors like bzip2/unzip/p7zip/xz.. oh, and Chromium.

------
teamhappy
I'm hoping for a portable version of OpenBSD's less(1) fork (now rewrite) ever
since Theo mentioned it in his pledge(2) talk at Hackfest.

------
deepfriedtech
Another great release from the OpenBSD team. Always looking forward to the
great things Theo and team put out. Pleasantly surprised to see this release a
month early.

OpenBSD has been my favorite OS since 2000. Such an easy-to-use OS for any
number of things. I've used it for firewalls, Web servers, and a nice simple
desktop with a custom FVWM config. Fast and simple.

------
chris_wot
Can anyone explain pledge?

~~~
cypher543
It tells the kernel which system calls and file paths your process intends to
use. If it uses any others, because of malicious code injection or whatever,
your process is killed immediately.

[http://man.openbsd.org/OpenBSD-
current/man2/pledge.2](http://man.openbsd.org/OpenBSD-current/man2/pledge.2)

------
tezza
So it's now possible to have a -1 day exploit ?

~~~
protomyth
In that vein, do note the errata page[1] has patches that need to be applied.

1)
[http://www.openbsd.org/errata59.html](http://www.openbsd.org/errata59.html)

------
cpeterso
Considering how much the OpenBSD team cares about secure programming and the
time they invest rewriting unsafe kernel and userland code, why do they still
use C when they could use a safe language like Rust?

~~~
deepfriedtech
C is a systems language from the ground up with decades of successful use and
knowledge behind it. Rust is the new kid on the block with everything to
prove. C is the best tool for the job. I think Theo de Raadt and his devs know
exactly what they are doing. With only two holes in the default install in
over a decade, why fix what isn't broken?

I'm one of these guys that still clings to old tech because it works. If C
works, use it. Rust is too new, too unproven. C has proven its worth with
billions of lines of code, something Rust will likely never achieve as a niche
language.

~~~
nickpsecurity
"C is a systems language from the ground up"

It was actually an extension of BCPL, which wasn't designed: just what parts
of a good language compiled on 1960's hardware. Proof below.

[http://pastebin.com/UAQaWuWG](http://pastebin.com/UAQaWuWG)

"with decades of successful use"

It actually had decades of failures with all sorts of bugs and hacks that
safer, system languages dodged by design. Only the best coders got successful
and secure use out of it. We praise OpenBSD quality for a reason: it's not
easy.

"Rust is the new kid on the block with everything to prove. "

This is true. I have a rule against using anything new for security-critical
coding if its in the TCB. Takes time to discover all the issues in things.

"With only two holes in the default install in over a decade"

Propaganda I've called out plenty. On the other systems, people finding bugs
often weaponize them, declare a vulnerbaility, and add that to the count.
OpenBSD treats bugs as just bugs then fixes them while assuming their
mitigations stopped any attack attempts. It's easy to say you only had 2
vulnerabilities when you're not counting vulnerabilities. ;)

"C has proven its worth with billions of lines of code, something Rust will
likely never achieve as a niche language."

It does have proven worth. After billions of lines, you can be sure you'll be
fixing all sorts of things and doing breach notifications if you rely on it.
Unless you pay extra money for top coders. Rust already beat it on app-level
safety w/ effects of low-level interactions and compiler risk being next to
assess or address. Ada and SPARK beat both for systematic safety with many
empirical results from case studies and field use. Safe versions of C like
Cyclone and Popcorn outdid C, too, in security but nobody invested more in
them. TAL and CoqASM are even doing safety/security at assembler level.

And so we have a language proven worthless for quality or security the
mainstay of quality or security focused UNIXen even with decades of
alternatives empirically shown to be better. Sounds like a cultural thing to
me. Drawback too.

Only advantages: lots of people know it and lots of existing code/tooling.
Valid reasons to choose it for existing BSD code but allows it was inferior on
other angles. And that rewrites to safer languages for it or new projects
should be ongoing.

~~~
fredmorcos
I am genuinely wondering, what is (or could you point me to) the alternative
with the following properties:

\- Compiled, type-safe and available for armv6.

\- Simple semantics: Rust and Ada are complex (C++-ish) and it gets hard to
limit the number of memory allocations/accesses as well as data copies going
on.

\- Tooling and discoverability: Man pages and Emacs with a few modes that are
easy to setup beats anything I've tried so far.

I understand that C has shortcomings when it comes to safety/security and even
lacks features that would make programming certain things easier, but what do
you suggest I use when I want to write a UNIX daemon that needs to transfer a
boatload of data from disk over the network and vice-versa?

I personally like it, I find it to be clear and concise, a little tedious but
at the price of giving me fine grained control over the data in memory: I just
have to be careful with that.

~~~
steveklabnik

      > it gets hard to limit the number of memory allocations/accesses
      > as well as data copies going on.
    

I would be interested in hearing more about this, if you have the time.

~~~
fredmorcos
In this video[0] on Rust, in this example I was unable to directly tell
whether the Vec structure is being copied to the take() function. If ownership
is being handed over, why is a copy being made? And if a copy really isn't
being made, then why aren't the function signature and the calling site
reflecting that?

I hope I am making any sense... Please tell me if I should try to rephrase, or
if I am in need of clarification on the subject.

(BTW, this is also something I really dislike about C++, two function calls
that look exactly the same, foo(x) and bar(x), could either be pass by value
or pass by reference: you have to go dig up the function signatures to figure
that out).

[0] [https://youtu.be/O5vzLKg7y-k?t=1110](https://youtu.be/O5vzLKg7y-k?t=1110)

~~~
steveklabnik
Gotcha. I thought the video would have explained this, but since it didn't get
through, let me try :)

    
    
      fn take(vec: Vec<i32>)
    
    

In Rust, the default way that things operate is to _move_. So when you call
take(), we'd say that the vector moves into the function.

Moving is always a memcpy. There's no way to change this behavior, so you can
always know that it's true. But with a Vec, there's a subtlety: the Vec itself
is three words: a pointer to the heap, a length, and a capacity. So when I say
that the Vec is memcpy'd, I mean literally those three things. It doesn't try
to follow the pointer and copy the data that it points to.

Incidentally, that pointer is why we say that it moves: because two copies of
the Vec structure itself would mean an aliased pointer to the heap, the
compiler doesn't allow the use of the older binding after take() is called.

For simpler types, like integers:

    
    
        fn take(i: i32)
    

they implement a trait called Copy. This means that when you call take, the
i32 is copied, in the same fashion that the Vec was copied. The only
difference is that there's no problem with having these two copies, as an i32
is, well, just an i32. So the compiler won't prevent the use of the binding
outside the function like it would with a non-Copy type.

References are like pointers, but with the extra static checking that Rust
does.

    
    
        fn take(vec: &Vec<i32>)
    

References also implement Copy, and so when you pass a reference to a Vec to
this function, the same thing happens as in the i32 case. The reference itself
gets copied.

This is sort of a long-winded way of saying that Rust is "pass by value", not
"pass by reference." Some people like to call this "pass reference by value",
since while it's always pass by value, references are themselves values.

What if we _did_ want to make a full copy of the Vec, including its elements?
For that, we have to use the .clone() method.

    
    
        let v = ... // some Vec<i32>
        let v1 = v.clone();
    

Now, v and v1 will be full, independent copies of the same thing. In other
words, if you don't see .clone(), it will never be a deep copy.

    
    
        let v = ... // some Vec<i32>
        let v1 = v; // a move, always a shallow memcpy
        let v2 = v1.clone(); // a deep copy
    

You can always see, syntactically, when you're making a possibly expensive
copy of something.

Does that help? I'm happy to elaborate further.

~~~
nickpsecurity
It was a great detailed explanation that also illustrates why I've held off on
Round 2 of reviewing the docs. I mean, I read this...

"This is sort of a long-winded way of saying that Rust is "pass by value", not
"pass by reference." Some people like to call this "pass reference by value",
since while it's always pass by value, references are themselves values."

...and instantly have to focus hard to make sure I'm not slipping on the basic
concepts. The wording of many Rust descriptions seems unnecessarily confusing
to the point that I just googled value vs reference semantics to make sure my
memory wasn't screwed up [more]. In a normal 3GL, pass by reference basically
stores a pointer in a variable and passes that value somewhere. That
value/reference can be used to modify original data outside its original
function. Is that what Rust does? If so, it's just pass by reference "with
(caveats/rules here)." End of story. Otherwise, I'll see if I can guess a
wording that doesn't merge opposite concepts.

~~~
steveklabnik
This concept isn't Rust specific, it's a general PLT thing. Rust is the same
as C in this regard. Almost every language is pass by value these days. IIRC
Fortran is pass by reference, an exception.

~~~
nickpsecurity
Then just say it's pass by reference instead of stuff I quoted. Counter anyone
else doing the same in your usual, gentle style reminding how unnecessary
confusion hurts adoption. Ill get back on helping find more of this stuff in
the docs once im done moving.

Btw, I tried to get on your draft but link didnt work by time I got back to
it. Was it merged into official docs or where so I read/review the right
thing?

~~~
steveklabnik
I still failed, it's pass by value :( just like C.

[http://github.com/rust-lang/book](http://github.com/rust-lang/book) is the
repo, and has a link to the rendered version.

~~~
nickpsecurity
It's all good. You still take the feedback and try to improve things. That's
what counts. :)

Thanks for the link. Ill look at it again in coming weeks.

