More than six years ago, LibreSSL was forked from OpenSSL, and almost two years ago, i explained the status of LibreSSL documentation during EuroBSDCon 2018 in Bucuresti. So it seems providing an update might be in order.
With this commit and several more, Patrick Wildt (patrick@) upgraded -current to version 10.0.0 of LLVM:
CVSROOT: /cvs Module name: src Changes by: patrick@cvs.openbsd.org 2020/08/03 08:30:27 Log message: Import LLVM 10.0.0 release including clang, lld and lldb. ok hackroom tested by plenty Status: Vendor Tag: LLVM Release Tags: LLVM_10_0_0 […]In this commit, Paul Irofti (pirofti@) added support for reading timecounters in userland without making a syscall.
Since we reported the first bits of powerpc64 support going into the tree on 16 May, work has progressed at a steady pace, resulting in snapshots now being available for this platform.
So, if you have a POWER9 system idling around, go to your nearest mirror and fetch this snapshot. Keep in mind that as this is still very early days, very little handholding is available - you are basically on your own.
Wesley Mouedine Assaby who runs the OpenBSD Jumpstart webpage with hints and tips for beginners about OpenBSD in general has produced a visualization of how PCs boot into OpenBSD.
I presented a talk on how I used OpenBGPd as a control plane for my ISP. I cover areas such as Routing fundamentals, a lightning introduction to BGP. An interesting aspect of the design is how the OpenBSD / OpenBGPd is used to control the routing information in my ISP yet the forwarding of packets is offloaded to hardware Layer 3 switches. I also outline my favourite new feature of OpenBGPd max prefix out which I'm sure will save my blushes if/when I fat finger my Prefix filters (although if my hair cut is anything to go by it is clear I have no shame anyway!). You can check out the talk here! Tom would welcome comments and feedback on the talk. I hope the talk will help others in deploying OpenBGPd and OpenBSD in their networks.
I would also suggest that those interested in learning more about OpenBGPd check out Peter Hessler's Tutorial on OpenBGPd which served as an essential aid in getting comfortable in configuring BGP on OpenBSD / OpenBGPd. Peter usually runs the Tutorial in advance of BSD Conferences.
I would like to give a big shout out to the people who write the code in OpenBSD and OpenBGPd, and that your effort makes my life running my network and ISP easier.
A huge word of thanks is due to Dan Langielle and the BSDCAN2020 Volunteers who organised the virtual BSDCAN 2020 conference this year in quite difficult circumstances.
Jonathan Gray (jsg@) has just committed an update to the DRM code to the tree. This update brings support for newer AMD and Intel graphics parts.
Date: Sun, 7 Jun 2020 22:48:16 -0600 (MDT) From: Jonathan Gray <jsg@openbsd.org> To: source-changes@openbsd.org Subject: CVS: cvs.openbsd.org: src CVSROOT: /cvs Module name: src Changes by: jsg@cvs.openbsd.org 2020/06/07 22:48:16 Modified files: sys/arch/amd64/conf: Makefile.amd64 sys/arch/arm64/conf: Makefile.arm64 sys/arch/i386/conf: Makefile.i386 ... Log message: update drm to linux 5.7 adds kernel support for amdgpu: vega20, raven2, renoir, navi10, navi14 inteldrm: icelake, tigerlake Thanks to the OpenBSD Foundation for sponsoring this work, kettenis@ for helping, patrick@ for helping adapt rockchip drm and many developers for testing.As is clear from Jonathan's commit message, this work was sponsored by the OpenBSD Foundation - it shows how your financial support of the foundation can directly improve (in this case) hardware support. Many thanks to Jonathan for working on this.
Otto Moerbeek (otto@) posted to misc@ a useful summary of the state of play of FFS2 in the 6.7 release (and, to some extent, -current).
In his mail, Otto clarifies some things about the latest release:
In a commit touching quite a few files, Theo recently renamed the installation images from installXX.fs to installXX.img:
Date: Sun, 17 May 2020 11:04:29 -0600 (MDT) From: Theo de Raadt <deraadt@openbsd.org> To: source-changes@openbsd.org Subject: CVS: cvs.openbsd.org: src CVSROOT: /cvs Module name: src Changes by: deraadt@cvs.openbsd.org 2020/05/17 11:04:29 Modified files: distrib/alpha/miniroot: Makefile distrib/amd64/iso: Makefile ... bin/dd : dd.1 usr.sbin/ldomctl: ldomctl.8 Log message: Change install images called *.fs to *.img. These are UFS filesystem images, but additionally have a bootblock in the first 8K (since UFS does not use that space). There are some UEFI direct-from-internet bootloaders that require the name *.img. So this makes things more convenient for those, while keeping it consistant in all architectures. ok kettenis beck knThis means that with recent snapshots, you should use the .img file to prepare your installation medium, where you were previously using the .fs file. It also means that you can install 'direct-from-internet' on these fancy UEFI machines! Note that if you want to install the OpenBSD 6.7 release, you still need to use install67.fs.
These are some highlights of the improvements in the present release:
See the release page and the daily changelog for a full list of changes since the previous release. Those upgrading from version 6.6 should read the Upgrade Guide.
Thanks to the developers for all the good work that goes into each release! To support further work on OpenBSD, please see the donations page for ways to contribute even if you can not offer up code yourself.
In a set of commits to the tree on Saturday, Mark Kettenis (kettenis@) added the early beginnings of support for the 64-bit PowerPC platform:
Date: Sat, 16 May 2020 11:11:14 -0600 (MDT) From: Mark Kettenis <kettenis@openbsd.org> To: source-changes@openbsd.org Subject: CVS: cvs.openbsd.org: src CVSROOT: /cvs Module name: src Changes by: kettenis@cvs.openbsd.org 2020/05/16 11:11:14 Added files: sys/arch/powerpc64/compile: Makefile Makefile.inc sys/arch/powerpc64/compile/GENERIC: Makefile sys/arch/powerpc64/conf: GENERIC Makefile.powerpc64 files.powerpc64 ld.script sys/arch/powerpc64/include: _types.h atomic.h bus.h cdefs.h conf.h cpu.h db_machdep.h disklabel.h endian.h exec.h fpu.h frame.h intr.h limits.h mutex.h param.h pcb.h pmap.h proc.h psl.h ptrace.h reg.h signal.h softintr.h spinlock.h tcb.h vmparam.h sys/arch/powerpc64/powerpc64: autoconf.c conf.c cpu.c disksubr.c genassym.cf locore.S locore0.S machdep.c pmap.c process_machdep.c softintr.c sys_machdep.c syscall.c vm_machdep.c Log message: Planting the first seed for OpenBSD/powerpc64.As support for additional hardware platforms brings opportunities to find (and fix) bugs on other, more established environments, this is definitely an interesting development. Of course it is still currently very much in its infancy, so don't drag out your POWER9 systems just yet, unless you're ready to roll up your sleeves and get some diffs submitted. Thanks to Mark for working on this port!
After our article on TLS 1.3 server support in LibreSSL, we have decided to upgrade the machine running the undeadly website to newer LibreSSL.
Since earlier today the site supports TLS 1.3. Undeadly still gets an A+ on Qualys' SSL Labs.
In a post to the ports@ mailing list, Landry Breuil (landry@) shared some of his notes on using qemu guest agent on OpenBSD kvm/qemu guests. He made a few enhancements for Undeadly:
In a post to tech@, Matt Dunwoodie announced the availability of a WireGuard [VPN] patchset for OpenBSD:
[…] A while ago I wanted to learn more about OpenBSD development. So I picked a project, in this case WireGuard, to develop a native client for. Over the last two years, with many different iterations, and working closely with the WireGuard's creator (Jason [Jason A. Donenfeld - Ed.], CC'd), it started to become a serious project eventually reaching parity with other official implementations. Finally, we are here and I think it is time for any further development to happen inside the src tree. […]From the WireGuard point-of-view, this is an official patchset.
See the full thread on tech@ for more detail.
With the following commit, Joel Sing (jsing@) enabled the TLSv1.3 server code (in LibreSSL) in -current:
CVSROOT: /cvs Module name: src Changes by: jsing@cvs.openbsd.org 2020/05/11 12:19:19 Modified files: lib/libssl : ssl_locl.h Log message: Enable the TLSv1.3 server. ok beck@ tb@The client code was already enabled in -current (and will be in the 6.7 release).
Thanks to Joel, Bob Beck (beck@), Theo Buehler (tb@), and others for the hard work!
While many of us have been busy social distancing, OpenBSD development work has continued. Noteworthy things not previously reported here include:
Developer Otto Moerbeek (otto@) has been working on support to boot from FFS2. He writes in with the below article, to give us a little insight into the challenges he faced while working on this.
FFS2 filesystem support has been in OpenBSD for quite a while. FFS2 has a few advantages above FFS1: large partition support, 64-bit timestamps, faster newfs(8) and faster fsck(8), but it is only used for large (> 1TB) filesystems at the moment. The only drawback is that its meta-data overhead is a bit larger than FFS1 because of 64-bit instead of 32-bit blocknumbers and timestamps.
I decided that it was time to start using FFS2 in as many places as possible, and that includes booting from it. Booting is an area where there are quite large differences between the various platforms OpenBSD supports. The boot code interacts with the platform-specific firmware and the bootstrap process uses different vendor-specific mechanisms.
I had the pleasure of sitting with Bob Beck at EuroBSDCon 2018 in Bucharest and asking him some questions about the OpenBSD Project, its approaches and some of his favourite aspects of the Operating System and its projects. Bob patiently outlines the hows and whys of his involvement in the BSD project.
Tom and Bob conduct a post-mortem on a training course on LibTLS Bob Delivered (excellently) in EuroBSDCon & BSDCAN. Bob discusses what online services he used in class for training students on LibTLS and why it can be a very effective teaching aid.
Bob modestly plays down his ability to churn out LibTLS Developers. Bob also gives guidance on the approaches to contributing to the project.
Bob reveals the code he least likes working on and why.
Bob lets us know what he really thinks about documentation and its value to the community.
Bob outlines an example of applying lessons learned from one bug to inform audits looking for similar bugs elsewhere in the OS and the software ecosystem that it supports.
I enjoyed making the interview with Bob who answered the questions with a remarkable combination of purpose and humour.
Bob thanks again for your time, and putting up with my interruptions and jokes :)
