18.1.1 addresses a few issues in the previous release, while also updating the packages and plugins. Most notably, a Python library change made intrusion detection rules fetch fail previously and we fixed GUI and backend behaviour for two special NAT cases.
We cover an interview about Unix Architecture Evolution, another vBSDcon trip report, how to teach an old Unix about backspace, new NUMA support coming to FreeBSD & stack pointer checking in OpenBSD.
Details of the 2018 campaign have been added to the Foundation's website. The goal for the year is for $300,000. The total for "smaller" donations has already taken the OpenBSD community to bronze level sponsorship! Please show your support by contributing.
We provide you with updates to Spectre & Meltdown from various BSD projects, a review of TrueOS from Linux, how to set up FreeBSD on ThinkPad x240 & a whole bunch of beastie bits.
As 18.1 is drawing near this stable update for the 17.7 series could be the last one. So whether there will be a hotfix to enable the update path or a full 17.7.13 remains to be seen, but we will keep you informed either way. The targeted release date for 18.1 is January 29.
For now we refrain from letting users upgrade directly to the release candidates, but suffice to say that with the development version accompanying this update it is possible from the console. And again thank you to all early adopters which have made the release candidates a thoroughly enjoyable experience.
We review Meltdown & Spectre responses from various BSD projects, show you how to run CentOS with bhyve, GhostBSD 11.1 is out & we look at the case against the fork syscall.
The commands rcp(1), rlogin(1), rlogind(1), rsh(1) and rshd(1) have been removed from DragonFly. There’s a net/bsdrcmds port if you still need them… though I imagine/hope ssh is filling the void for everyone.
For more than 3 years now, OPNsense is driving innovation through modularising and hardening the open source firewall, with simple and reliable firmware upgrades, multi-language support, HardenedBSD security, fast adoption of upstream software updates as well as clear and stable 2-Clause BSD licensing. Over the second half of 2017 well over 500 changes have made it into this first release candidate. Most notably, the firewall NAT rules have been reworked to be more flexible and usable via plugins, which is going to pave the way for subsequent API works on the core firewall functionality. Meltdown and Spectre patches are currently being worked on in FreeBSD, but there is no reliable timeline.
We have previously issued a short statement with preliminary analysis of Meltdown and Spectre vulnerabilities. This post is an update now that we have an official statement from the FreeBSD project.
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. Matthew Dillon wrote a summary of the current status, noting there’s not much you can do for Spectre beyond new hardware. There is an update to the “defensive browser setup” plan for DragonFly (using –site-per-process) that can help at least with Javascript versions of Spectre.
They go to hopefully sensible defaults, but Matthew Dillon has done some testing to show the effects of each in various combinations. (Update: more changes and tests.) Note that this is not the final mitigation work; compilers (i.e. gcc) are being updated to include workarounds for this, so new gcc -> new compiler in DragonFly -> new defenses. No silver bullet there, though.
If you run a mail service, you probably like to have greylisting in place, via spamd(8) or similar means. However, there are some sites that simply do not play well with greylisting, and for those it's useful to extract SPF information to identify their valid outgoing SMTP hosts.
Now OpenBSD offers a straightforward mechanism to do that and fill your nospamd table, right from the smtpctl utility via the subcommand spf walk. Gilles Chehade (gilles@) describes how in a recent blog post titled spfwalk.
This feature is still in need of testing, so please grab a snapshot and test!
We review the information about Spectre & Meltdown thus far, we look at NetBSD memory sanitizer progress, Postgres on ZFS & show you a bit about NomadBSD.
A message to tech@ from Philip Guenther (guenther@) provides the first public information from developers regarding the OpenBSD response to the recently announced CPU vulnerabilities:
So, yes, we the OpenBSD developers are not totally asleep and a handful of
us are working out how to deal with Intel's fuck-up aka the Meltdown
attack. While we have the advantage of less complexity in this area (e.g.,
no 32bit-on-64bit compat), there's still a pile of details to work through
about what has to be *always* in the page tables vs what can/should/must be
hidden. Read it.
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@.
The unveiling of the three new CPU bug classes, collected in the two brandbugs “Meltdown” and “Spectre”, has mostly shocked the BSDs; I’ve got it on some authority that even FreeBSD was not informed ahead of time, left alone the others. Thanks to laffer1 from MidnightBSD for a couple of heads-up warnings into our direction!
Here’s what I could gather until now (please do correct me if I’m wrong):
Meltdown is specific to Intel® CPUs with out-of-order execution, that is, all P6-class (Pentium Pro/MMX, Pentium Ⅱ, but not Pentium Ⅰ/MMX) or newer (except old Atom) CPUs. It appears to allow user processes to read kernel memory, but not across VMs, nor to attack a hypervisor. A variant for ARM exists but AMD’s x86 CPUs are supposedly safe. The KAISER/FUCKWIT/UASS/KPTI patches for Linux fix this, at huge performance cost on x86, not so much on ARM, and no cost for unaffected CPU models (runtime detected).
Spectre affects x86, ARM, POWER CPUs and possibly others. I’ve not yet found information on whether it is also limited to CPUs with out-of-order executions, but it seems likely. SPARC CPUs might be safe; Solaris/SPARC64 is safe due to the way its memory addressing works. If the OOO execution assumption is true, 80486 and P5 class x86 CPUs are also safe. This one does allow cross-VM and hypervisor attacks, so if the bare metal CPU is vulnerable, SOL. There does not yet seem to be a generic fix; some hint at having to patch the compiler and recompile everything with a workaround that has a performance cost, even if the CPU is not affected, or was fixed with a microcode update. AMD’s x86 CPUs are partially hit, one of the variants does not work on them.
“CERT recommends throwing away your CPU and buying an non-vulnerable one” (thanks to El Reg), but nobody states which CPUs are not vulnerable.
At the present time, we suggest any MirBSD/i386 instances that run on any CPU other than an 80486 or P5-class (Pentium Ⅰ or a non-PPro MMX) to be restricted to single user or trusted user access only, and no untrusted software including ECMAscript to be run on them.
Watch this space for updates. Oh, and, if you know what you’re (and I’m) talking about, please, again, do provide me with information necessary to provide those updates, both to MirBSD and to this space.
FreeBSD was made aware of the problems in late December 2017. We're working with CPU vendors and the published papers on these attacks to mitigate them on FreeBSD. Due to the fundamental nature of the attacks, no estimate is yet available for the publication date of patches.
We've just published our goals for 2018. We've got a number of new goals planned, some that require new infrastructure. In 2018, we plan to migrate at least 90% of our infrastructure to a single data center in addition to expanding out existing infrastructure.
More user group news: Helsinki, Finland, has a new BSD User Group: HelBUG. First meeting is February 7th. There’s no mailing list/site that I know of, yet.
We walk through dumping a PS4 kernel in only 6 days, tell you the news that NetBSD 7.1.1 has been released, details on how to run FreeBSD on a Thinkpad T470 & there’s progress in OpenBSD’s pledge.