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 ld.so, 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)
By brynet (Brynet) on https://brynet.biz.tm/
Really excited about the 6.2 release, nice work everyone! :-)
By Ross (173.27.144.33) 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.
Comments
By Anonymous Coward (71.94.168.156) 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.
By Noryungi (noryungi) noryungi@yahoo.com on
Hello,
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...
By Anonymous Coward (71.94.168.156) 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?
Comments
By Jeff Rollin-Jones (82.45.237.163) jeffrey.rollin@gmail.com on
It's IW emm and IW enn :-)
By Marc (2001:920:1846:1dc0:527b:9dff:fe2b:2aa8) on
Updated and donated the usual 45€ of the former CD-Set.
By Leon Shaw (eshaw) leon.edward.shaw@gmail.com on
OpenBSD 6.2 is amazing. Thank you so much developers. Your hard work and dedication is greatly appreciated.
By Nathan Houghton (2601:646:8080:c2f0:817f:6e41:72ff:64c) nathan@brainwerk.org 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?
Comments
By Nathan Houghton (2601:646:8080:c2f0:817f:6e41:72ff:64c) nathan@brainwerk.org on
Also, thanks a bunch for the hard work! This release is great. I think I need to go make my donation now...
By Theo de Raadt (199.185.136.55) 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..
By jasa instagram (180.244.42.171) netsum1@live.com on https://www.thesocmed.com/
btw anyone knows if base dhclient going to handle ipv4 and ipv6 at some point?
Comments
By Nathan Houghton (n1000) nathan@brainwerk.org 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...
By Chris (32.218.5.162) on
Mac POWERPC packages?
http://ftp.openbsd.org/pub/OpenBSD/6.2/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?
Thanks!
Comments
By Chris (32.218.5.162) 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.