Meltdown / Spectre Discussion

[jgreco]

I'd suggest changing the thread title to be more relevant to the issue. Something like "Meltdown / Spectre Discussion"

Fiiiine. And why the frak am I not getting notifications for this thread. Grr.

 

[nightshade00013]

Fiiiine. And why the frak am I not getting notifications for this thread. Grr.

Did you forget to click "watch thread" again?

I know how we can all fix it for you. We can all just make sure to add an @jgreco to keep you informed, LOL.

What I am wondering realistically is what this will all end up doing later on down the road. Obviously affected manufacturer's probably either have to keep releasing flawed products for at least a couple years or scrap a lot of current designs and go back to the drawing board.

How exactly will they be able to harden the cpu architecture against the flaws and how likely is it that the losses will continue.

One interesting thing I saw on the FreeBSD response is this:

The code will be selectable via a tunable which will automatically turn
on for modern Intel processors and off for AMD processors (since they
are reportedly not vulnerable). Since the fix for Meltdown does incur a
performance hit for any transition between user space and kernel space,
this could be rather impactful depending on the workload. As such, the
tunable can also be overridden by the end-user if they are willing to
accept the risk.

So basically once it is released for people who do not have untrusted code being ran on their FreeNAS they should be able to continue as usual by just removing a tunable or will iXsystems force it to be loaded no matter what?

 

[jgreco]

Did you forget to click "watch thread" again?

No. I never do, I follow all threads I participate in, on the theory it's rude to do otherwise. It says it's following it, but it clearly wasn't.

I know how we can all fix it for you. We can all just make sure to add an @jgreco to keep you informed, LOL.

Well thank you.

What I am wondering realistically is what this will all end up doing later on down the road. Obviously affected manufacturer's probably either have to keep releasing flawed products for at least a couple years or scrap a lot of current designs and go back to the drawing board.

How exactly will they be able to harden the cpu architecture against the flaws and how likely is it that the losses will continue.

Many years ago, I remember a depressing discussion about the inevitability of data exfiltration issues and the sheer number of risks in computing systems. Are you aware of spread spectrum clocking, as an example? It's billed as EMI control, which says something...

One interesting thing I saw on the FreeBSD response is this:

So basically once it is released for people who do not have untrusted code being ran on their FreeNAS they should be able to continue as usual by just removing a tunable or will iXsystems force it to be loaded no matter what?

This is an interesting issue. Do you put into a place a security fix on a system where the issue isn't expected to be exploitable? This is kind of a terrible decision to have to make. In theory, this is only exploitable if you already have a toehold in the system. Problem is, it can be an unprivileged toehold. That's kinda bad.

 

[nightshade00013]

I agree there are tons of risks, the only truly safe system is the one that is never turned on. Sadly having a server as a doorstop ins't truly very useful.

Yes spread spectrum I am aware of. Actually had to be put on a spread spectrum setup when I had DSL many years ago. There was some sort of issue in the lines and while it would work the connection would drop at random times when transferring data. The bad thing is that it was slower but some times stability is better than speed. Wouldn't do much good to have a car that would randomly crash and need to be rebooted on a 1000 mile trip even if that car can safely do 200 MPH.

I do agree that it is interesting on deciding over system speed vs security. It's probably better to opt for security in most situations but it is nice to know that if it causes stability issues you could theoretically disable the fix and reboot to make sure that is the actual problem inducing the instability. I know that some of the systems that were issued patches by Microsoft were having BSOD errors. Once things are in the wild with all the different configs we will probably find that a few of them just don't play nice with the fix.

 

[WorBlux]

What I am wondering realistically is what this will all end up doing later on down the road. Obviously affected manufacturer's probably either have to keep releasing flawed products for at least a couple years or scrap a lot of current designs and go back to the drawing board.

How exactly will they be able to harden the cpu architecture against the flaws and how likely is it that the losses will continue.

From what I understand, only allow one level of speculative load. Flush, invalidate, or isolate branch prediction tables whenever context or privilege levels changes, SMT architectures will require at least logical separation of branch table states between threads. Don't keep a map or privileged memory anywhere an unprivileged process might see it.

Future designs might decrease the performance penalty, but there will always be some sort of hit, especially on workloads with a lot of context switches.

https://github.com/marcan/speculation-bugs/blob/master/README.md#bti-linuxqemu-ibrs-patches

 

[molotov-ed]

Long time haunter and user of FreeNAS (and longer of ZFS). Just wanted to say thanks to @jgreco for the nice summary that helped me explain it to some of my employees.

FWIW, I found this the other day: http://www.jonkensy.com/intel-microcode-for-spectre-cve-2017-5715-real-performance-loss-in-zfs/ while this is ZoL, I think it's a good indication of what we're going to see on FreeNAS performance hits.

 

[rs225]

Maybe I'm a conspiracy theorist

Did you hear the one about the CPU which faked its permission checks? Turns out some guys looked at all the angles and figured out how they did it. The whole thing fell apart.

, but I'm having thoughts that Intel built a (near) monopoly using cpus which traded security for performance

I think I read that one reason AMD didn't have the Meltdown issue is that they had to avoid an Intel patent on deferring the security checks until later in execution.

My watching also broke on this thread.

 

[jgreco]

My watching also broke on this thread.

The NSA wants to cover up any discussion of unrepairable CPU flaws. ;-)

 

[Bidule0hm]

Mine works; they must be afraid of me somehow... :D

 

[Ericloewe]

I get the standard notifications, but no emails (haven't signed up for email notifications - I tried that for a week in 2014 and quickly gave up). Is that what you guys were expecting, or are you getting forum notifications but no emails?

 

[Bidule0hm]

I've both.

 

[jgreco]

I get the standard notifications, but no emails (haven't signed up for email notifications - I tried that for a week in 2014 and quickly gave up). Is that what you guys were expecting, or are you getting forum notifications but no emails?

I wasn't getting notifications for this one thread until I did The IT Crowd solution. It did show that the thread was being watched but it was lying.

I pretty much rely on the forum to do the right things and it is unlikely that, aside from debugging forumware idiocy, that I've toggled notifications for threads more than a handful of times over the years.

@rs225 notes it broke for him. I'm going to say I believe it likely that it had something to do with some certain administrator tinkering with my thread, and I'm just going to say that there's too much editing going on these days.

 

[danb35]

there's too much editing going on these days

+1

 

[jgreco]

+1

% echo "We ought to do something to drive the spelling and punctuation police crazy by running all the posts through jive or valspeak before
posting." | jive

We ought t'do sump'n t'roll de spellin' and punctuashun honky pigs crazy by runnin' all de posts drough JIBE o' valspeak befo'e postin'.

 

[danb35]

https://techcrunch.com/2018/01/22/l...-meltdown-spectre-complete-and-utter-garbage/

 

[Ericloewe]

Add to that the broken microcode they pushed/probably will push again in a similar state.

 

[nightshade00013]

Yep and from what I gather the microcode will be turned off by default and the software will have to manually request if it is one that has it available and if it is then activate it or some crap like that. Was reading one article where basically they are trying to PR it as a feature rather than a flaw.

And the really crappy news is they expect to release cpu's with the same flaws for the next two to three years. So get a new CPU next year and BOHICA the "feature" is still there ready to be abused.

 

[jgreco]

Yep and from what I gather the microcode will be turned off by default and the software will have to manually request if it is one that has it available and if it is then activate it or some crap like that. Was reading one article where basically they are trying to PR it as a feature rather than a flaw.

I'm probably dating myself, but does this remind anyone of the whole Coke->New Coke->Classic Coke thing?

 

[nightshade00013]

LOL, I remember that fiasco. They were losing business to Pepsi and decided to rejigger the formula, their die hard fans complained so they eventually went back. It was all a PR stunt and did it ever get a TON of PR.