It’s possible to have data corrupted on a HAMMER2 volume during a specific combination of a bulkfree operation and a lot of writing to disk. Matthew Dillon has a potential fix already. As he announced, it’s scheduled to go into 5.4 this weekend. It’s a rare bug, but if you want to check for it, look for CHECK FAIL entries in /var/log/messages.
And because every cloud has a silver lining: some not-yet-quantified performance improvements.
DragonFly 5.2.0 has been released. Spectre/Meltdown mitigations are in there, along with improvements for HAMMER2, accelerated video, and ipfw. My users@ post has the details on upgrading, as does the release notes.
If you’re on the bleeding edge of DragonFly and already updated for Meltdown fixes, there’s a few more commits you’ll want to get.
Update: step-by-step microcode fixes from Intel if you really want to trash your performance.
By now you’ve probably heard of the Meltdown/Spectre attacks. (background rumors, technical note) Matthew Dillon’s put together a Meltdown mitigation in DragonFly, done in four commits.
It’s turned off and on by the sysctl machdep.isolated_user_pmap – and defaults to on for Intel CPUs. Buildworld tests show about a 4-5% performance hit, but that’s only one form of activity, measured, so there will surely be other effects.
Note that Spectre is not mitigated by this commit series, and as I understand it, cannot be realistically fixed in software.
Update: Matthew Dillon posted a summary to users@.
Update 2: He told us so.
SSH in DragonFly 5, by default, does not make a password authentication request on outgoing ssh sessions. You can manually add the option or change the config. Or use public keys, which is really the best idea if at all possible.
DragonFly 4.8 has been updated to 4.8.1, bringing in a lot of small fixes. Improved Intel video support and the virtio_scsi driver will be of most interest, I think. The 4.8.1 tag commit has all the details. You can update the normal way, and if you need an install image, I’ve uploaded them and they should appear at your local mirror.
There’s a bug with shared libraries in pkg(), which may bite you when upgrading. It’s present in version 1.10.1 at least, so you may want to wait for this fix to be applied before your next upgrade.
DragonFly 4.8 is officially released! Download from your nearest mirror, where it should appear in the next 24 hours. If you’re upgrading your existing install, you can use the generic instructions in the release notes or in my users@ email; whichever you click first. Don’t forget to ‘pkg upgrade’!
There was some issues with the DPorts repo, so you may need to reset your local copy. This only applies if you pulled down a copy in the last 48 hours or so. (update: or less, based on John’s comment) Otherwise, you are fine.
I should have posted this sooner: SemiBUG is having a meeting in about half an hour at Altair Engineering. Mike Wayne is presenting about monitoring. Run now if you are near.
Recent changes for virtual machine support and the new powerd utility have been rolled into the release branch for DragonFly. They’ll probably be in the next point release, or you can rebuild a release machine now for immediate access.
Also mentioned in the update from Matthew Dillon, DragonFly-master users should upgrade carefully as DragonFly migrates to using LibreSSL in base, and dports-based LibreSSL in dports.
Because this always happens just after I create a DragonFly release, there’s a new version of OpenSSL. However, this is for version 1.0.2. 1.0.1 is what’s in the release, and it’s supported through the end of the year.
OpenSSH has a major version bump in DragonFly, to 7.3p1. This means some features – specifically patches for High Performance Networking – are no longer there, and you’ll get an error if your config file requires them. Either remove the options from your config, or install OpenSSH from dports.
DragonFly 4.6 is officially released! Download from your nearest mirror, or update your source files and build – my users@ email describes the steps.
I’m a bit late on this, but: If you are using DragonFly-current, you will need to rebuild world. If you are on 4.4, this won’t matter until you go to 4.6, and you’d be rebuilding world and kernel for that anyway.
(4.6 will probably be tagged this weekend.)
If you are running DragonFly 4.5 (i.e. bleeding edge), Sepherosa Ziehau made an ifnet change that will require a full buildkernel/world if you want things like netstat to keep working.
If you are running bleeding-edge DragonFly, Sepherosa Ziehau has made some networking changes that both reduce CPU usage in high-traffic situations and change some underlying network structures. This means a full buildworld is needed on your next update.
If you’re using DragonFly 4.4.x or older, you are unaffected.
That’s a pretty cryptic headline, isn’t it? John Marino has ‘privatized’ several libraries in DragonFly, so that they can’t get included involuntarily as part of a port build. That may mean you will need to perform a full rebuild of your system if you are tracking DragonFly-current.
(This is the way to fix ‘system’ languages like Perl was in FreeBSD 4.x – keep them clearly separate from the port version. It’s about a decade too late for that idea to work out, though.)
There’s two important security updates for SSH. DragonFly release and development have been updated for it, and you can correct for it on your running system using the one-liner at Undeadly.
Note: keep in mind this is a client bug – it’s an information leak when you as a client connect out to somewhere else. A server, as an endpoint, is not affected.
If you are running DragonFly-master (i.e. 4.5), and you have a system between these two updates (roughly between November 27th and now), please rebuild your kernel to avoid a TCP bug.
If you are on bleeding-edge DragonFly (4.3), you will need to rebuild both kernel and world to keep them in sync, after Sepherosa Ziehau’s commit. This won’t affect you at all if you are on 4.2.x.