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)
Subject: CVS: cvs.openbsd.org: src
Module name: src
Changes by: email@example.com 2018/08/21 13:04:41
sys/arch/amd64/amd64: identcpu.c vmm.c vmm_support.S
sys/arch/amd64/include: cpu.h specialreg.h vmmvar.h
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...
Theo de Raadt (deraadt@)
posted to the tech@ mailing list with some background on how the latest discovered Intel CPU
issues relate to OpenBSD.
Date: Wed, 15 Aug 2018 00:31:16 -0600
From: Theo de Raadt [elided]
Subject: CVE-2018-3615, CVE-2018-3620, CVE-2018-3646
These 3 issues all relate to a bug in Intel cpus
The cpu will speculatively honour invalid PTE against data in the
on-core L1 cache. Memory disclosure occurs into the wrong context.
These 3 issues (CVE-2018-3615, CVE-2018-3620, CVE-2018-3646) together
are the currently public artifacts of this one bug.
[Dr.] Brian Callahan (bcallah@) recently live-streamed
an interactive OpenBSD Porting Workshop.
A recording of the workshop is
Todd Mortimer (mortimer@) has added RETGUARD
for the arm64 platform.
We previously reported the
addition of RETGUARD for amd64.
Bob Beck (beck@ when wearing OpenBSD-only hat)
on using libtls:
This tutorial is designed for people with some C experience on a POSIX, BSD like machine with the latest libtls installed. It focuses on changes that are necessary to make an existing program written in C that uses the POSIX sockets api to use TLS over those same connections.
Ingo Schwarze (schwarze@ when wearing OpenBSD-only hat)
wrote in to let us know about the new release:
From: Ingo Schwarze [elided]
Date: Wed, 8 Aug 2018 22:21:13 +0200
Subject: mandoc-1.14.4 released
after a full year of tranquil development, i just released mandoc-1.14.4.
This is a regular maintenance release. As there are no major structural
changes, i expect it to be very stable, so all downstream systems are
encouraged to upgrade from any earlier version.
Patrick Wildt (patrick@) has been experimenting with small I2C and SPI-connected displays, and with
this commit, it was enabled for armv7 and arm64 platforms as ssdfb(4) in -current.
For the g2k18 Ljubljana hackathon, i decided to try and get rid
of as many small userland tasks as possible.
Lots of them have been piling up over time.
to tech@, Theo de Raadt (deraadt@) discusses the state of development of
support in userland (and for a certain port):
A new g2k18 hackathon report has arrived, this time from Kenneth Westerback (krw@), who writes:
Other than missing a connection due to "seat maintenance" in YYZ,
travel was uneventful. I arrived MUC (twelve hours late) and spent a
week hacking with bluhm@ and mpi@ at Genua's Geekweek, to which bluhm@
had kindly arranged an invitation. I managed to start committing some
disklabel(8) code refactoring otto@ and I have been discussing for a
while. Mostly cleaning up partition offset and size rounding code. I
also tightened up some dhcpd(8) man page ambiguity as requested by
sthen@ and started by jmc@. I ok'ed a mpi@ fix for a dhclient(8) issue
and reviewed and ok'ed various diffs from bluhm@.