The OpenBSD Foundation is excited to announce that it has received a second 2018 Iridium level (>$100K) donation from Handshake.
The release of OpenBSD 6.4 has been announced:
We are pleased to announce the official release of OpenBSD 6.4. This is our 45th release. We remain proud of OpenBSD's record of more than twenty years with only two remote holes in the default install. […]
Rather than reproducing the full list of new features here, we refer readers to the official OpenBSD 6.4 page.
Selected highlights include:
- Support has been added for qcow2 images and external snapshots in vmm(4)/vmd(8).
- "join" has been added for Wi-Fi networks.
- Security enhancements include unveil(2), MAP_STACK, and RETGUARD. Meltdown/Spectre mitigations have been extended further, and SMT is disabled by default.
- rad(8) has replaced rtadvd(8).
- bgpd(8) has undergone numerous improvements, including the addition of support for BGP Origin Validation (RFC 6811).
- smtpd.conf(5) uses a new, more flexible grammar.
- For the first time, there are more than 10,000 (binary) packages (for amd64 and i386).
Those upgrading from version 6.3 should read the upgrade guide.
Readers are encouraged to show their appreciation in the conventional manner.
How to travel from Dresden to Usti nad Labem for free!
No drama flying to Dresen, from which a train would take me to n2k18's home in Usti nad Labem. Other than being puzzled that it costs less to fly YYZ -> FRA -> DRS than it costs to fly YYZ -> FRA.
In a short series of commits, Carlos Cardenas (ccardenas@) added support for qcow2 image support to vmd(8). [This builds on an earlier commit adding support for pluggable disk backends.] The code was written by Ori Bernstein, who posted his diffs (thread 1, thread 2) to the firstname.lastname@example.org mailing list in August.
Ken Westerback (krw@ when wearing his dev hat) wrote in with some great news:
We thank Handshake for its very generous support! This donation will no doubt fund many exciting projects in the coming years.
Congratulations to all concerned.
Of course, this donation does not preclude others from contributing ;-)
In a message to tech@, Theo de Raadt (deraadt@) gives an update on the state-of-play regarding processor vulnerabilities:
Two recently disclosed hardware bugs affected Intel cpus: - TLBleed - T1TF (the name "Foreshadow" refers to 1 of 3 aspects of this bug, more aspects are surely on the way) Solving these bugs requires new cpu microcode, a coding workaround, *AND* the disabling of SMT / Hyperthreading.
Theo de Raadt (deraadt@) has committed a diff to mitigate the "Intel L1TF screwup" for the amd64 platform we reported on earlier:
From: Theo de Raadt (elided) Date: Tue, 21 Aug 2018 13:04:41 -0600 (MDT) To: email@example.com Subject: CVS: cvs.openbsd.org: src CVSROOT: /cvs Module name: src Changes by: firstname.lastname@example.org 2018/08/21 13:04:41 Modified files: sys/arch/amd64/amd64: identcpu.c vmm.c vmm_support.S sys/arch/amd64/include: cpu.h specialreg.h vmmvar.h Log message: Perform mitigations for Intel L1TF screwup. There are three options: (1) Future cpus which don't have the bug, (2) cpu's with microcode containing a L1D flush operation, (3) stuffing the L1D cache with fresh data and expiring old content. This stuffing loop is complicated and interesting, no details on the mitigation have been released by Intel so Mike and I studied other systems for inspiration. Replacement algorithm for the L1D is described in the tlbleed paper. We use a 64K PA-linear region filled with trapsleds (in case there is L1D->L1I data movement). The TLBs covering the region are loaded first, because TLB loading apparently flows through the D cache. Before performing vmlaunch or vmresume, the cachelines covering the guest registers are also flushed. with mlarkin, additional testing by pd, handy comments from the kettenis and guenther peanuts
Now we wait for further discoveries...