CVE-2018-8897 fix in, more Spectre fixes for DragonFly

A recent and new CPU bug, CVE-2018-8897, is fixed in DragonFly.  THis applies to both Intel and AMD processors.  I’m happy to see that the CERT page lists equal notification timing for a whole lot of operating systems, rather than the few that heard about Spectre/Meltdown early.

Following that topic, Matthew Dillon has “fleshed out” Spectre mitigations, and his commit message details the current state.  The sysctl ‘machdep.spectre_mitigation’ will tell you what’s set at any given point.

Update: update.

In Other BSDs for 2018/04/21

Opinion time: The Reddit / Hacker News forums have reached the anything/everything point where there’s no longer a focus.  Lobste.rs is worth visiting, though, for BSD content and in general.

Lazy Reading for 2018/04/08

Accidental theme this week: Social media is a dead end.

Your unrelated food link for the week: King Arthur test kitchen disasters.  Summarized annually on April Fools Day, every year.

 

Microcode updates on DragonFly

One side effect of Meltdown/Spectre are CPU microcode (firmware) updates.  For future needs: sysutils/devcpu-data is the port that has the updates for Intel, and cpucontrol(8) is the program you run on DragonFly to add them.

I haven’t used this myself, yet, so I can’t tell you how necessary an immediate update could be – but you will probably want to use it soon.

Update: Newer CPUs might require this sizing change.

Update update: a better explanation of applying microcode updates.  There’s new ones out, too.  (via)

More Meltdown fixes

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.

Update: step-by-step microcode fixes from Intel if you really want to trash your performance.

In Other BSDs for 2018/01/06

Note the non-profit link; that may be useful to you.

Remember: don’t kldload i915 too soon

I just wasted an hour trying to figure out why xorg had strange output but no errors on this laptop, and it’s because I had i915_load=”YES” in /boot/loader.conf instead of i915_load=”YES” in /etc/rc.conf.  I’m almost nearly sure I’ve mentioned that before, but if not: here you go.

(though if you never plan to run X, you can put it in loader.conf and everything will just work.)

(Title updated for a more correct sentence)