OpenBSD Journal

OpenBSD 6.2 Released

Contributed by Peter N. M. Hansteen on from the Puffy's 44th release dept.

A few days ahead of the date hinted at by the work-in-progress release page, OpenBSD 6.2 was released today, October 9th 2017.

Notable changes in this release are as always numerous, and include:

  • Improved hardware support on modern platforms including ARM64/ARMv7 and octeon, while amd64 users will appreciate additional support for the Intel Kaby Lake video cards.
  • Network stack improvements include extensive SMPization improvements and a new FQ-CoDel queueing discipline, as well as enhanced WiFi support in general and improvements to iwn(4), iwm(4) and anthn(4) drivers.
  • Improvements in vmm(4)/vmd include VM migration, as well as various compatibility and performance improvements.
  • Security enhancements including a new freezero(3) function, further pledge(2)ing of base system programs and conversion of several daemons to the fork+exec model.
  • Trapsleds, KARL, and random linking for libcrypto and, dramatically increase security by making it harder to find helpful ROP gadgets, and by creating a unique order of objects per-boot.
  • The base system compiler on the amd64 and i386 platforms has switched to clang(1).
  • New versions of OpenSSH, OpenSMTPd, LibreSSL and mandoc are also included.

The full story is, as always, to be found in the release page, an upgrade guide is available, and of course the project Donations page is always open for business.

(Comments are closed)

  1. By brynet (Brynet) on

    Really excited about the 6.2 release, nice work everyone! :-)

  2. By Ross ( on

    Seems more stable than 6.1 for me as far as IntelDRM drivers & graphics go, so that's a big +

    Now if I could just figure out why some models of mice aggressively attach & detach constantly while other models don't.

    1. By Anonymous Coward ( on

      If your platform supprts wsmoused(8), have you tested that as a console-based workaround? Starting that daemon as root, and killing it right before starting X, works for me with non-USB mice which are connected via a PS/2 to USB converter.

  3. By Noryungi (noryungi) on


    I know this is not the ideal place to do this, but OpenBSD 6.2 seems somewhat vulnerable to the issue corrected by "029_tcb" in OpenBSD 6.1.

    That should probably be its first errata... ;-)

    Please note: since the 6.2 kernel is relinked every reboot, some kernels might be vulnerable, while others are not. I estimate the issue is present around 20% of the time...

  4. By Anonymous Coward ( on

    Thanks, looking forward to running 6.2 on some older systems, including several macppc models and an i486 with a special history.

    Wondering if there was a typo above?: Under the "Network stack improvements" bullet point, there were two adjacent iwm(4) links. Might one have been meant to indicate a different driver?

    1. By Jeff Rollin-Jones ( on

      It's IW emm and IW enn :-)

  5. By Marc (2001:920:1846:1dc0:527b:9dff:fe2b:2aa8) on

    Updated and donated the usual 45€ of the former CD-Set.

  6. By Leon Shaw (eshaw) on

    OpenBSD 6.2 is amazing. Thank you so much developers. Your hard work and dedication is greatly appreciated.

  7. By Nathan Houghton (2601:646:8080:c2f0:817f:6e41:72ff:64c) on

    What was the main design consideration for having freezero() require a size argument? Were there a lot of use cases where the sensitive data was at the beginning of a larger allocation?

    1. By Nathan Houghton (2601:646:8080:c2f0:817f:6e41:72ff:64c) on

      Also, thanks a bunch for the hard work! This release is great. I think I need to go make my donation now...

    2. By Theo de Raadt ( on

      Our malloc internally remembers the exact size. That allows us to check it.

      However, we also want freezero() to be a portable interface, so that a systems without deep-hooking into libc malloc code can do it. So the size has to be provided by the caller.

      Same concept with reallocarray, recallocarray.

      Some of the software we write is important enough that we also produce -portable versions. We want them to pick up this stronger development practice, without #ifdef

      Also, along the way we discovered that modifying programs to track the lengths, and then pass to these functions where our malloc can check them, was very good since it exposed some previously unknown problems.

      Hand tracking of sizes was also introduced to the kernel allocators a while back -- there this increasingly rigorous process improved quite a bit of code..

  8. By jasa instagram ( on

    btw anyone knows if base dhclient going to handle ipv4 and ipv6 at some point?

    1. By Nathan Houghton (n1000) on

      I don't have an answer for you... but I just wanted to mention I recently moved to dhcpcd from wide-dhcpv6 (dhcp6c) (saw it mentioned in some mailing list discussion), it's so much better.

      What are folks using for the dhcpv6 server? I'm still using the WIDE one (dhcp6s), but noticed a few others were available, and was thinking about trying a new one...

  9. By Chris ( on

    Mac POWERPC packages?

    I was thinking about upgrading from 6.1 And I noticed the powerpc directory is missing from the 6.2 packages. Is there a delay normally after release for the packages?


    1. By Chris ( on

      Sorry I just re-read the release and missed "Packages for the following architectures will be made available as their builds complete...powerpc" the 1st time around.

      I apologize for the noise.

      Thanks again for your hard work.

Latest Articles


Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]