##Headlines
###How to mitigate Spectre and Meltdown on an HP Proliant server with FreeBSD

As recently announced in a previous article I wanted to write a couple of guides on how to mitigate Spectre and Meltdown vulnerabilities in GNU/Linux and UNIX environments. It is always a good and I hope a standard practice to have your systems patched and if they aren’t for whatever the reason (that legacy thing you’re carrying on for ages) you may take the necessary extra steps to protect your environment. I never planned to do any article on patching anything. Nowadays it’s a no brainer and operating systems have provided the necessary tools for this to be easy and as smooth as possible. So why this article?
Spectre and Meltdown are both hardware vulnerabilities. Major ones. They are meaningful for several reasons among them the world wide impact since they affect Intel and AMD systems which are ubiquitous. And second because patching hardware is not as easy, for the manufacturer and for the users or administrators in charge of the systems. There is still no known exploit around left out in the open hitting servers or desktops anywhere. The question is not if it will ever happen. The question is when will it happen. And it may be sooner than later. This is why big companies, governments and people in charge of big deployments are patching or have already patched their systems. But have you done it to your system? I know you have a firewall. Have you thought about CVE-2018-3639? This particular one could make your browser being a vector to get into your system. So, no, there is no reason to skip this.
Patching these set of vulnerabilities implies some more steps and concerns than updating the operating system. If you are a regular Windows user I find rare you to be here and many of the things you will read may be foreign to you. I am not planning to do a guide on Windows systems since I believe someone else has or will do it and will do it better than me since I am not a pro Windows user. However there is one basic and common thing for all OS’s when dealing with Spectre and Meltdown and that is a microcode update is necessary for the OS patches to effectively work.
What is microcode? You can read the Wikipedia article but in short it is basically a layer of code that allows chip manufacturers to deal with modifications on the hardware they’ve produced and the operating systems that will manage that hardware. Since there’s been some issues (namely Spectre and Meltdown) Intel and AMD respectively have released a series of microcode updates to address those problems. First series did come with serious problems and some regressions, to the point GNU/Linux producers stopped releasing the microcode updates through their release channels for updates and placed the ball on Intel’s roof. Patching fast does always include risks, specially when dealing with hardware. OS vendors have resumed their microcode update releases so all seems to be fine now.
In order to update the microcode we’re faced with two options. Download the most recent BIOS release from our vendor, provided it patches the Spectre and Meltdown vulnerabilities, or patch it from the OS. If your hardware vendor has decided not to provide support on your hardware you are forced to use the latter solution. Yes, you can still keep your hardware. They usually come accompanied with a “release notes” file where there are some explanatory notes on what is fixed, what is new, etc. To make the search easy for you a news site collected the vendors list and linked the right support pages for anyone to look. In some scenarios it would be desirable not to replace the whole BIOS but just update the microcode from the OS side. In my case I should update an HP Proliant ML110 G7 box and the download link for that would be this.
Instead of using the full blown BIOS update path we’ll use the inner utilities to patch Spectre and Meltdown on FreeBSD. So let’s put our hands on it

• See the article for the technical breakdown

###A look beyond the BSD teacup: OmniOS installation

Five years ago I wrote a post about taking a look beyond the Linux teacup. I was an Arch Linux user back then and since there were projects like ArchBSD (called PacBSD today) and Arch Hurd, I decided to take a look at and write about them. Things have changed. Today I’m a happy FreeBSD user, but it’s time again to take a look beyond the teacup of operating systems that I’m familiar with.

• Why Illumos / OmniOS?

There are a couple of reasons. The Solaris derivatives are the other big community in the *nix family besides Linux and the BSDs and we hadn’t met so far. Working with ZFS on FreeBSD, I now and then I read messages that contain a reference to Illumos which certainly helps to keep up the awareness. Of course there has also been a bit of curiosity – what might the OS be like that grew ZFS?
Also the Ravenports project that I participate in planned to support Solaris/Illumos right from the beginning. I wanted to at least be somewhat “prepared” when support for that platform would finally land. So I did a little research on the various derivatives available and settled on the one that I had heard a talk about at last year’s conference of the German Unix Users Group: “OmniOS – Solaris for the Rest of Us”. I would have chosen SmartOS as I admire what Bryan Cantrill does but for getting to know Illumos I prefer a traditional installation over a run-from-RAM system.
Of course FreeBSD is not run by corporations, especially when compared to the state of Linux. And when it comes to sponsoring, OpenBSD also takes the money… When it comes to FreeBSD developers, there’s probably some truth to the claim that some of them are using macOS as their desktop systems while OpenBSD devs are more likely to develop on their OS of choice. But then there’s the statement that “every innovation in the past decade comes from Solaris”. Bhyve alone proves this wrong. But let’s be honest: Two of the major technologies that make FreeBSD a great platform today – ZFS and DTrace – actually do come from Solaris. PAM originates there and a more modern way of managing services as well. Also you hear good things about their zones and a lot of small utilities in general.
In the end it was a lack of time that made me cheat and go down the easiest road: Create a Vagrantfile and just pull a VM image of the net that someone else had prepared… This worked to just make sure that the Raven packages work on OmniOS. I was determined to return, though – someday. You know how things go: “someday” is a pretty common alias for “probably never, actually.”
But then I heard about a forum post on the BSDNow! podcast. The title “Initial OmniOS impressions by a BSD user” caught my attention. I read that it was written by somebody who had used FreeBSD for years but loathed the new Code of Conduct enough to leave. I also oppose the Conduct and have made that pretty clear in my February post [ ! -z ${COC} ] && exit 1. As stated there, I have stayed with my favorite OS and continue to advocate it. I decided to stop reading the post and try things out on my own instead. Now I’ve finally found the time to do so.

• What’s next?

That’s it for part one. In part two I’ll try to make the system useful. So far I have run into a problem that I haven’t been able to solve. But I have some time now to figure things out for the next post. Let’s see if I manage to get it working or if I have to report failure!

###What are all these types of memory in top(1)?

• Earlier this week I convinced Mark Johnston, one of the FreeBSD VM experts to update a page on the FreeBSD wiki that I saw was being referenced on stackoverflow and similar sites
• Mark updated the explanations to be more correct, and to include more technical detail for inquiring minds
• He also added the new type that appeared in FreeBSD somewhat recently

Active - Contains memory “actively” (recently) being used by applications
Inactive - Contains memory that has not been touched recently, or was released from the Buffer Cache
Laundry - Contains memory that Inactive but still potentially contains useful data that needs to be stored before this memory can be used again
Wired - Memory that cannot be swapped out, including the kernel, network stack, and the ZFS ARC
Buf - Buffer Cache, used my UFS and most filesystems except ZFS (which uses the ARC)
Free - Memory that is immediately available for use by the rest of the system

##News Roundup
###OpenBSD saves me again! — Debug a memory corruption issue

Yesterday, I came across a third-part library issue, which crashes at allocating memory:

Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f594a5a9b6b in _int_malloc () from /usr/lib/libc.so.6
(gdb) bt
#0 0x00007f594a5a9b6b in _int_malloc () from /usr/lib/libc.so.6
#1 0x00007f594a5ab503 in malloc () from /usr/lib/libc.so.6
#2 0x00007f594b13f159 in operator new (sz=5767168) at /build/gcc/src/gcc/libstdc++-v3/libsupc++/new_op.cc:50

It is obvious that the memory tags are corrupted, but who is the murder? Since the library involves a lot of maths computation, it is not an easy task to grasp the code quickly. So I need to find another way:
(1) Open all warnings during compilation: -Wall. Nothing found.
(2) Use valgrind, but unfortunately, valgrind crashes itself:

valgrind: the 'impossible' happened:
Killed by fatal signal

host stacktrace:
==43326== at 0x58053139: get_bszB_as_is (m_mallocfree.c:303)
==43326== by 0x58053139: get_bszB (m_mallocfree.c:315)
==43326== by 0x58053139: vgPlain_arena_malloc (m_mallocfree.c:1799)
==43326== by 0x5800BA84: vgMemCheck_new_block (mc_malloc_wrappers.c:372)
==43326== by 0x5800BD39: vgMemCheck___builtin_vec_new (mc_malloc_wrappers.c:427)
==43326== by 0x5809F785: do_client_request (scheduler.c:1866)
==43326== by 0x5809F785: vgPlain_scheduler (scheduler.c:1433)
==43326== by 0x580AED50: thread_wrapper (syswrap-linux.c:103)
==43326== by 0x580AED50: run_a_thread_NORETURN (syswrap-linux.c:156)

sched status:
running_tid=1

(3) Change compiler, use clang instead of gcc, and hope it can give me some clues. Still no effect.
(4) Switch Operating System from Linux to OpenBSD, the program crashes again. But this time, it tells me where the memory corruption occurs:

Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000014b07f01e52d in addMod (r=<error reading variable>, a=4693443247995522, b=28622907746665631,

I figure out the issue quickly, and not bother to understand the whole code. OpenBSD saves me again, thanks!

###Native Encryption for ZFS on FreeBSD (Call for Testing)

To anyone with an interest in native encryption in ZFS please test the projects/zfs-crypto-merge-0820 branch in my freebsd repo: https://github.com/mattmacy/networking.git

git clone https://github.com/mattmacy/networking.git -b projects/zfs-crypto-merge-0820

The UI is quite close to the Oracle Solaris ZFS crypto with minor differences for specifying key location.
Please note that once a feature is enabled on a pool it can’t be disabled. This means that if you enable encryption support on a pool you will never be able to import it in to a ZFS without encryption support. For this reason I would strongly advise against using this on any pool that can’t be easily replaced until this change has made its way in to HEAD after the freeze has been lifted.
By way of background the original ZoL commit can be found at:

• https://github.com/zfsonlinux/zfs/pull/5769/commits/5aef9bedc801830264428c64cd2242d1b786fd49

###VMworld 2018: Showcasing Hybrid Cloud, Persistent Memory and the Asigra TrueNAS Backup Appliance

During its last year in Las Vegas before moving back to San Francisco, VMworld was abuzz with all the popular buzzwords, but the key focus was on supporting a more agile approach to hybrid cloud.
Surveys of IT stakeholders and analysts agree that most businesses have multiple clouds spanning both public cloud providers and private data centers. While the exact numbers vary, well over half of businesses have a hybrid cloud strategy consisting of at least three different clouds.
This focus on hybrid cloud provided the perfect timing for our announcement that iXsystems and Asigra are partnering to deliver the Asigra TrueNAS Backup Appliance, which combines Asigra Cloud Backup software backed by TrueNAS storage. Asigra TrueNAS Backup Appliances provide a self-healing and ransomware-resistent OpenZFS backup repository in your private cloud. The appliance can simultaneously be used as general-purpose file, block, and object storage. How does this tie in with the hybrid cloud? The Asigra Cloud Backup software can backup data from public cloud repositories – G Suite, Office 365, Salesforce, etc. – as well as intelligently move backed-up data to the public cloud for long-term retention.
Another major theme at the technical sessions was persistent memory, as vSphere 6.7 added support for persistent memory – either as a storage tier or virtualized and presented to a guest OS. As detailed in our blog post from SNIA’s Persistent Memory Summit 2018, persistent memory is rapidly becoming mainstream. Persistent memory bridges the gap between memory and flash storage – providing near-memory latency storage that persists across reboots or power loss. vSphere allows both legacy and persistent memory-aware applications to leverage this ultra-fast storage tier. We were excited to show off our newly-introduced TrueNAS M-Series at VMworld, as all TrueNAS M40 and M50 models leverage NVDIMM persistent memory technology to provide a super-fast write cache, or SLOG, without any of the limitations of Flash technology.
The iXsystems booth’s theme was “Enterprise Storage, Open Source Economics”. iXsystems leverages the power of Open Source software, combined with our enterprise-class hardware and support, to provide incredibly low TCO storage for virtualization environments. Our TrueNAS unified storage and server offerings are an ideal solution for your organization’s private cloud infrastructure. Combined with VMware NSX Hybrid Connect – formerly known as VMware Hybrid Cloud Extension – you can seamlessly shift running systems into a public cloud environment for a true hybrid cloud solution.
Another special treat at this year’s booth was iXsystems Vice President of Engineering Kris Moore giving demos of an early version of “Project TrueView”, a single-pane of glass management solution for administration of multiple FreeNAS and TrueNAS systems. In addition to simplified administration and enhanced monitoring, Project TrueView will also provide Role-Based Access Control for finer-grained permissions management. A beta version of Project TrueView is expected to be available at the end of this year.
Overall, we had a great week at VMworld 2018 with lots of good conversations with customers, press, analysts, and future customers about TrueNAS, the Asigra TrueNAS Backup Appliance, iXsystems servers, Project TrueView, and more – our booth was more popular than ever!

###End of life for NetBSD 6.x

In keeping with NetBSD’s policy of supporting only the latest (8.x) and next most recent (7.x) major branches, the recent release of NetBSD 8.0 marks the end of life for NetBSD 6.x. As in the past, a month of overlapping support has been provided in order to ease the migration to newer releases.

• As of now, the following branches are no longer maintained:

• netbsd-6-1

• netbsd-6-0

• netbsd-6

• This means:

• There will be no more pullups to those branches (even for security issues)

• There will be no security advisories made for any those branches

• The existing 6.x releases on ftp.NetBSD.org will be moved into /pub/NetBSD-archive/

• May NetBSD 8.0 serve you well! (And if it doesn’t, please submit a PR!)

##Beastie Bits

• Blast from the past: OpenBSD 3.7 CD artwork
• People are asking about scale of BSD projects. Let’s figure it out…
• Tuesday, 21 August 18: me, on ed(1), at SemiBUG
• arm64 gains RETGUARD
• Call for participation
• FreeBSD-UPB/bhyvearm64-utils

##Feedback/Questions

• Eric - FreeNAS for Vacation
• Patrick - Long Live Unix
• Jason - Jason - Full MP3 Recordings
• Bostjan - Question about jails and kernel

• Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv

##Headlines
###FreeBSD Foundation Update, July 2018

• MESSAGE FROM THE EXECUTIVE DIRECTOR

We’re in the middle of summer here, in Boulder, CO. While the days are typically hot, they can also be quite unpredictable. Thanks to the Rocky Mountains, waking up to 50-degree (~10 C) foggy weather is not surprising. In spite of the unpredictable weather, many of us took some vacation this month. Whether it was extending the Fourth of July celebration, spending time with family, or relaxing and enjoying the summer weather, we appreciated our time off, while still managing to accomplish a lot!
In this newsletter, Glen Barber enlightens us about the upcoming 12.0 release. I gave a recap of OSCON, that Ed Maste and I attended, and Mark Johnston explains the work on his improved microcode loading project, that we are funding. Finally, Anne Dickison gives us a rundown on upcoming events and information on submitting a talk for MeetBSD.
Your support helps us continue this work. Please consider making a donation today. We can’t do it without you. Happy reading!!

• June 2018 Development Projects Update
• Fundraising Update: Supporting the Project
• July 2018 Release Engineering Update
• OSCON 2018 Recap
• Submit Your Work: MeetBSD 2018
• FreeBSD Discount for 2018 SNIA Developer Conference
• EuroBSDcon 2018 Travel Grant Application Deadline: August 2

iXsystems

###BSDCan Trip Reports

• BSDCan 2018 Trip Report: Constantin Stan
• BSDCan 2018 Trip Report: Danilo G. Baio
• BSDCan 2018 Trip Report: Rodrigo Osorio
• BSDCan 2018 Trip Report: Dhananjay Balan
• BSDCan 2018 Trip Report: Kyle Evans

##News Roundup
###FreeBSD and OSPFd

With FreeBSD jails deployed around the world, static routing was getting a bit out of hand. Plus, when I needed to move a jail from one data center to another, I would have to update routing tables across multiple sites. Not ideal. Enter dynamic routing…

OSPF (open shortest path first) is an internal dynamic routing protocol that provides the autonomy that I needed and it’s fairly easy to setup. This article does not cover configuration of VPN links, ZFS, or Freebsd jails, however it’s recommended that you use seperate ZFS datasets per jail so that migration between hosts can be done with zfs send & receive.

In this scenario, we have five FreeBSD servers in two different data centers. Each physical server runs anywhere between three to ten jails. When jails are deployed, they are assigned a /32 IP on lo2. From here, pf handles inbound port forwarding and outbound NAT. Links between each server are provided by OpenVPN TAP interfaces. (I used TAP to pass layer 2 traffic. I seem to remember that I needed TAP interfaces due to needing GRE tunnels on top of TUN interfaces to get OSPF to communicate. I’ve heard TAP is slower than TUN so I may revisit this.)

In this example, we will use 172.16.2.0/24 as the range for OpenVPN P2P links and 172.16.3.0/24 as the range of IPs available for assignment to each jail. Previously, when deploying a jail, I assigned IPs based on the following groups:

Server 1: 172.16.3.0/28
Server 2: 172.16.3.16/28
Server 3: 172.16.3.32/28
Server 4: 172.16.3.48/28
Server 5: 172.16.3.64/28

When statically routing, this made routing tables a bit smaller and easier to manage. However, when I needed to migrate a jail to a new host, I had to add a new /32 to all routing tables. Now, with OSPF, this is no longer an issue, nor is it required.

• To get started, first we install the Quagga package.

• The two configuration files needed to get OSPFv2 running are /usr/local/etc/quagga/zebra.conf and /usr/local/etc/quagga/ospfd.conf.

• Starting with zebra.conf, we’ll define the hostname and a management password.

• Second, we will populate the ospfd.conf file.

• To break this down:

• service advanced-vty allows you to skip the en or enable command. Since I’m the only one who uses this service, it’s one less command to type.

• ip ospf authentication message-digest and ip ospf message-diget-key… ignores non-authenticated OSPF communication. This is useful when communicating over the WAN and to prevent a replay attack. Since I’m using a VPN to communicate, I could exclude these.

• passive-interface default turns off the active communication of OSPF messages on all interfaces except for the interfaces listed as no passive-interface [interface name]. Since my ospf communication needs to leverage the VPNs, this prevents the servers from trying to send ospf data out the WAN interface (a firewall would work too).

• network 172.16.2.0/23 area 0.0.0.0 lists a supernet of both 172.16.2.0/24 and 172.16.3.0/24. This ensures routes for the jails are advertised along with the P2P links used by OpenVPN. The OpenVPN links are not required but can provide another IP to access your server if one of the links goes down. (See the suggested tasks below).

• At this point, we can enable the services in rc.conf.local and start them.

• We bind the management interface to 127.0.0.1 so that it’s only accessable to local telnet sessions. If you want to access this service remotely, you can bind to a remotely accessable IP. Remember telnet is not secure. If you need remote access, use a VPN.

• To manage the services, you can telnet to your host’s localhost address.

• Use 2604 for the ospf service.

• Remember, this is accessible by non-root users so set a good password.

###A broad overview of how ZFS is structured on disk

When I wrote yesterday’s entry, it became clear that I didn’t understand as much about how ZFS is structured on disk (and that this matters, since I thought that ZFS copy on write updates updated a lot more than they do). So today I want to write down my new broad understanding of how this works. (All of this can be dug out of the old, draft ZFS on-disk format specification, but that spec is written in a very detailed way and things aren’t always immediately clear from it.)

Almost everything in ZFS is in DMU object. All objects are defined by a dnode, and object dnodes are almost always grouped together in an object set. Object sets are themselves DMU objects; they store dnodes as basically a giant array in a ‘file’, which uses data blocks and indirect blocks and so on, just like anything else. Within a single object set, dnodes have an object number, which is the index of their position in the object set’s array of dnodes. (Because an object number is just the index of the object’s dnode in its object set’s array of dnodes, object numbers are basically always going to be duplicated between object sets (and they’re always relative to an object set). For instance, pretty much every object set is going to have an object number ten, although not all object sets may have enough objects that they have an object number ten thousand. One corollary of this is that if you ask zdb to tell you about a given object number, you have to tell zdb what object set you’re talking about. Usually you do this by telling zdb which ZFS filesystem or dataset you mean.)

Each ZFS filesystem has its own object set for objects (and thus dnodes) used in the filesystem. As I discovered yesterday, every ZFS filesystem has a directory hierarchy and it may go many levels deep, but all of this directory hierarchy refers to directories and files using their object number.

ZFS organizes and keeps track of filesystems, clones, and snapshots through the DSL (Dataset and Snapshot Layer). The DSL has all sorts of things; DSL directories, DSL datasets, and so on, all of which are objects and many of which refer to object sets (for example, every ZFS filesystem must refer to its current object set somehow). All of these DSL objects are themselves stored as dnodes in another object set, the Meta Object Set, which the uberblock points to. To my surprise, object sets are not stored in the MOS (and as a result do not have ‘object numbers’). Object sets are always referred to directly, without indirection, using a block pointer to the object set’s dnode. (I think object sets are referred to directly so that snapshots can freeze their object set very simply.)

The DSL directories and datasets for your pool’s set of filesystems form a tree themselves (each filesystem has a DSL directory and at least one DSL dataset). However, just like in ZFS filesystems, all of the objects in this second tree refer to each other indirectly, by their MOS object number. Just as with files in ZFS filesystems, this level of indirection limits the amount of copy on write updates that ZFS had to do when something changes.

PS: If you want to examine MOS objects with zdb, I think you do it with something like ‘zdb -vvv -d ssddata 1’, which will get you object number 1 of the MOS, which is the MOS object directory. If you want to ask zdb about an object in the pool’s root filesystem, use ‘zdb -vvv -d ssddata/ 1’. You can tell which one you’re getting depending on what zdb prints out. If it says ‘Dataset mos [META]’ you’re looking at objects from the MOS; if it says ‘Dataset ssddata [ZPL]’, you’re looking at the pool’s root filesystem (where object number 1 is the ZFS master node).

PPS: I was going to write up what changed on a filesystem write, but then I realized that I didn’t know how blocks being allocated and freed are reflected in pool structures. So I’ll just say that I think that ignoring free space management, only four DMU objects get updated; the file itself, the filesystem’s object set, the filesystem’s DSL dataset object, and the MOS.

• (As usual, doing the research to write this up taught me things that I didn’t know about ZFS.)

Digital Ocean

###HardenedBSD Foundation Status

On 09 July 2018, the HardenedBSD Foundation Board of Directors held the kick-off meeting to start organizing the Foundation. The following people attended the kick-off meeting:

• 1. Shawn Webb (in person)
• 2. George Saylor (in person)
• 3. Ben Welch (in person)
• 4. Virginia Suydan (in person)
• 5. Ben La Monica (phone)
• 6. Dean Freeman (phone)
• 7. Christian Severt (phone)

We discussed the very first steps that need to be taken to organize the HardenedBSD Foundation as a 501©(3) not-for-profit organization in the US. We determined we could file a 1023EZ instead of the full-blown 1023. This will help speed the process up drastically.

• The steps are laid out as follows:
• Register a Post Office Box (PO Box) (completed on 10 Jul 2018).
• Register The HardenedBSD Foundation as a tax-exempt nonstock corporation in the state of Maryland (started on 10 Jul 2018, submitted on 18 Jul 2018, granted 20 Jul 2018).
• Obtain a federal tax ID (obtained 20 Jul 2018).
• Close the current bank account and create a new one using the federal tax ID (completed on 20 Jul 2018).
• File the 1023EZ paperwork with the federal government (started on 20 Jul 2018).
• Hire an attorney to help draft the organization bylaws.
• Each of the steps must be done serially and in order.

We added Christian Severt, who is on Emerald Onion’s Board of Directors, to the HardenedBSD Foundation Board of Directors as an advisor. He was foundational in getting Emerald Onion their 501©(3) tax-exempt, not-for-profit status and has really good insight. Additionally, he’s going to help HardenedBSD coordinate hosting services, figuring out the best deals for us.

We promoted George Saylor to Vice President and changed Shawn Webb’s title to President and Director. This is to help resolve potential concerns both the state and federal agencies might have with an organization having only a single President role.

We hope to be granted our 501©(3) status before the end of the year, though that may be subject to change. We are excited for the formation of the HardenedBSD Foundation, which will open up new opportunities not otherwise available to HardenedBSD.

###More mitigations against speculative execution vulnerabilities

Philip Guenther (guenther@) and Bryan Steele (brynet@) have added more mitigations against speculative execution CPU vulnerabilities on the amd64 platform.

CVSROOT:    /cvs
Module name:    src
Changes by: guenther@cvs.openbsd.org    2018/07/23 11:54:04

Modified files:
    sys/arch/amd64/amd64: locore.S 
    sys/arch/amd64/include: asm.h cpufunc.h frameasm.h 

Log message:
Do "Return stack refilling", based on the "Return stack underflow" discussion
and its associated appendix at https://support.google.com/faqs/answer/7625886
This should address at least some cases of "SpectreRSB" and earlier
Spectre variants; more commits to follow.

The refilling is done in the enter-kernel-from-userspace and
return-to-userspace-from-kernel paths, making sure to do it before
unblocking interrupts so that a successive interrupt can't get the
CPU to C code without doing this refill.  Per the link above, it
also does it immediately after mwait, apparently in case the low-power
CPU states of idle-via-mwait flush the RSB.

ok mlarkin@ deraadt@```

+ and:

```CVSROOT: /cvs
Module name:    src
Changes by: guenther@cvs.openbsd.org    2018/07/23 20:42:25

Modified files:
    sys/arch/amd64/amd64: locore.S vector.S vmm_support.S 
    sys/arch/amd64/include: asm.h cpufunc.h 

Log message:
Also do RSB refilling when context switching, after vmexits, and
when vmlaunch or vmresume fails.

Follow the lead of clang and the intel recommendation and do an lfence
after the pause in the speculation-stop path for retpoline, RSB refill,
and meltover ASM bits.

ok kettenis@ deraadt@```

+ "Mitigation G-2" for AMD processors:

```CVSROOT: /cvs
Module name:    src
Changes by: brynet@cvs.openbsd.org  2018/07/23 17:25:03

Modified files:
    sys/arch/amd64/amd64: identcpu.c 
    sys/arch/amd64/include: specialreg.h 

Log message:
Add "Mitigation G-2" per AMD's Whitepaper "Software Techniques for
Managing Speculation on AMD Processors"

By setting MSR C001_1029[1]=1, LFENCE becomes a dispatch serializing
instruction.

Tested on AMD FX-4100 "Bulldozer", and Linux guest in SVM vmd(8)

ok deraadt@ mlarkin@```
***


##Beastie Bits
+ [HardenedBSD will stop supporting 10-STABLE on 10 August 2018](https://groups.google.com/a/hardenedbsd.org/forum/#!topic/users/xvU0g-g1l5U)
+ [GSoC 2018 Reports: Integrate libFuzzer with the Basesystem, Part 2](https://blog.netbsd.org/tnf/entry/gsoc_2018_reports_integrate_libfuzzer1)
+ [ZFS Boot Environments at PBUG](https://vermaden.wordpress.com/2018/07/30/zfs-boot-environments-at-pbug/)
+ [Second Editions versus the Publishing Business](https://blather.michaelwlucas.com/archives/3229)
+ [Theo de Raadt on "unveil(2) usage in base"](https://undeadly.org/cgi?action=article;sid=20180728063716)
+ [rtadvd(8) has been replaced by rad(8)](https://undeadly.org/cgi?action=article;sid=20180724072205)
+ [BSD Users Stockholm Meetup #3](https://www.meetup.com/BSD-Users-Stockholm/events/253447019/)
+ [Changes to NetBSD release support policy](https://blog.netbsd.org/tnf/entry/changes_to_netbsd_release_support)
+ [The future of HAMMER1](http://lists.dragonflybsd.org/pipermail/users/2018-July/357832.html)
***

**Tarsnap**

##Feedback/Questions
+ Rodriguez - [A Question](http://dpaste.com/0Y1B75Q#wrap)
+ Shane - [About ZFS Mostly](http://dpaste.com/32YGNBY#wrap)
+ Leif - [ZFS less than 8gb](http://dpaste.com/2GY6HHC#wrap)
+ Wayne - [ZFS vs EMC](http://dpaste.com/17PSCXC#wrap)
***

- Send questions, comments, show ideas/topics, or stories you want mentioned on the show to [feedback@bsdnow.tv](mailto:feedback@bsdnow.tv)