Meltdown, Spectre, *BSD


#1

Latest BSDNow has some good info:

http://www.jupiterbroadcasting.com/121362/the-spectre-of-meltdown-bsd-now-228/

Matt Dillon of DragonflyBSD has some performance measurements:
http://lists.dragonflybsd.org/pipermail/users/2018-January/335643.html


#2

https://lists.freebsd.org/pipermail/freebsd-security/2018-January/009719.html


#3

Looks like some meltdown/spectre work may be starting to hit 12Current.
Fun read if you’re a software geek ; the solution shows the complexity of the problem and this is a very good example of how a commit message should be written.

https://docs.freebsd.org/cgi/getmsg.cgi?fetch=1311178+0+current/svn-src-head


#4

OK, but how will the new kernel work with the new processor chips? In the next years machines will be with new processors and will be with the “old” wrong processors. Will the new kernel “support” the new and old processor chips also?


#5

back to the 8080 era :wink:

just guessing here

unless we all move to arm64(?), intel/amd will keep some of their current architecture. and that could take some time to be delivered


#6

@Zoltan that is a good question. The kernel developers can only work with the published information, they write the code to conform. Newer CPUs typically add newer features or new ways of doing something, but they will support the old ways. If you do dmesg and look for “features” that tells you what your cpu can do.

So today’s kernel will run on tomorrow’s CPU, but won’t enable the features it doesn’t know about. As the developers find out and figure out how to use them, detection code gets added to enable them.


#7

Thank’s your answer Mer!


#8

No problem. Some of it is just guessing on my part, but over the years I’ve seen how new hardware (CPUs) get integrated, so there is a little bit of logic behind it.


#9

There is a package available, but was told use at your own risk.

https://www.freshports.org/search.php?query=Devcpu-data&search=go&num=10&stype=name&method=match&deleted=excludedeleted&start=1&casesensitivity=caseinsensitive


#10

% sudo /usr/local/etc/rc.d/microcode_update onestart
Updating cpucodes…
/usr/local/share/cpucontrol/m12306a9_0000001c.fw: updating cpu /dev/cpuctl0 from rev 0x13 to rev 0x1c… done.
/usr/local/share/cpucontrol/m12306a9_0000001c.fw: updating cpu /dev/cpuctl2 from rev 0x13 to rev 0x1c… done.
Done.


#11

My opinion only:
Look I know Meltdown and Spectre are scary, but you’re really better off letting upstream (FreeBSD) finish getting all changes into the code, tested as much as possible and then giving TrueOS time to pull those changes in. Trying to jump the gun sounds good, but at this point you don’t know what problems you are going to cause. They will be hard to reproduce, you may introduce performance and timing issues that lead to system instability. That makes it even harder for folks like me to try and help you solve problems.

Poke around for Windows patches for the issues: they wound up BSOD and hard crashing systems on folks that needed system restore media to correct (where’s that windbag nija saying how great windows is).

As pointed out by @RodMyers use at your own risk and in my opinion, the risk is not worth it at the moment.


#12

:crossed_fingers: This is a system running unstable - a cut of 12-current we should be loading microcode updates - but mostly known good ones. I’m going to see what this does to my stability. I know Intel pushed out early dev grade microcode & the last tested one is November’s afair. I had instability on a recent Unstable update & the broken i915. So I expect breakages.


#13

Yep cross them all. Some of the reports I’ve seen (over at DragonflyBSD Matt Dillon did a good performance assessment) show a big performance hit. There may be new sysctls added that give you control over what fixes are enabled.

If this is an unstable system that is effectively a test platform for you have fun :slight_smile:


#14

So, after some research, my CPU is now running:
sig 0x000306a9, pf mask 0x12, 2015-02-26, rev 0x001c, size 12288
from: https://launchpad.net/ubuntu/+source/intel-microcode/+changelog

So:
1.) This should be stable :slight_smile:
2.) This establishes a baseline for me & anyone who has this Id=0x306a9 Family=0x6 Model=0x3a Stepping=9
3.) It shows my BIOS/UEFI blob doesn’t contain the latest Intel ucode for my CPU.
4.) Since we know that an Intel ucode update will be required to enable modifications to the branch prediction/speculation for Spectre varients & for general good practice it would be good to consider having TrueOS ucode updates as a user option?
5.) As with so-many things - BEs enable roll-back :wink:

Thoughts?


#15

Nice to hear that so far, your risk has been low :slight_smile:
microcode updates: I’d have to check upstream FreeBSD base, but a lot of times ucode updates will get distributed with a new version of kernel. Basically, it’s support for a new CPU feature. Now if upstream doesn’t do this, then at the very least I’d expect to see a port for “latest ucode” that a user could install.


#16

Awesome writeup, from a name familiar in *BSD circles.

http://www.daemonology.net/blog/2018-01-17-some-thoughts-on-spectre-and-meltdown.html


#17

I just read the write up. I’ve always been a fan of Colin’s work and now even more so.


#18

Something went wrong at the Intel :slight_smile:


#19

“Never patch security bugs: Support the NSA. Society must be protected.” IRONY OFF.


#20

Ahh, Intel doing the MS patching methodology: Here’s a patch it may or may not work, it may or may not brick your system. Worst case buy a new system with Windows 10.