Intel Processors Hit with LVI Security Vulnerabilities, Mitigation Hits Performance Hard

[KarymidoN]

The hell is this supposed to be ?

probab just having fun, he realeased a full video demo later explaining in very technical and acurate data his findings

 

[lexluthermiester]

probab just having fun, he realeased a full video demo later explaining in very technical and acurate data his findings

Yup, freaky.

 

[timta2]

At this point I think the only way Intel can fight these vulnerability discoveries is by killing the bug bounty program, or significantly reducing the bounty. The program has clearly sprung up a cottage industry of security researchers (uni professors and their college grad minions) bruteforcing Intel processors for vulnerabilities that they can write papers on (earn citations), report back to Intel, and claim the cash bounties. The BBP has become a fountainhead of headache for CTOs and CIOs.

AMD is safer only because its market footprint is too small in the datacenter space, most of these side-channel attacks affect datacenters, and you can't hack AMD processors for rich bounties (it's similar to the "Macs don't get viruses" fallacy of the 1990s and 2000s).

Shouldn't you be backing up statements like this with a reputable source you can cite, to prove this was a "fallacy"? The truth is that there's always been very little Mac malware in the wild, and all of current Mac malware, that I'm aware of, requires physical access and/or for the user to enter their password and install it themselves. As a Mac enthusiast since 1985, the only Mac "malware" I've ever seen in the real world was a Microsoft Word Macro virus.

This also seems like an unrelated and inappropriate dig.

 

[lexluthermiester]

As a Mac enthusiast since 1985, the only Mac "malware" I've ever seen in the real world was a Microsoft Word Macro virus.

List of Mac malware, viruses and security flaws known today

macOS has long been heralded as the most secure operating system on the market. But it’s not bulletproof. Here are some Mac threats to avoid.

macpaw.com

And that's a short list. Here's another;

Vaughns-1-pagers.com

www.vaughns-1-pagers.com

MacOS is solid for sure, however it is anything but bullet-proof.

 

[R-T-B]

At this point I think the only way Intel can fight these vulnerability discoveries is by killing the bug bounty program, or significantly reducing the bounty. The program has clearly sprung up a cottage industry of security researchers (uni professors and their college grad minions) bruteforcing Intel processors for vulnerabilities that they can write papers on (earn citations), report back to Intel, and claim the cash bounties. The BBP has become a fountainhead of headache for CTOs and CIOs.

Ha, no.

 

[hat]

Geez, guys. I'm all for a healthy debate, don't get me wrong... but do realize BTA is allowed to have an opinion, the same as anyone else.

 

[mtcn77]

The playing field isn't even is all we are saying. It is the complete marvel universe vs. thanos, oh wait, what did I just say, snap! Melodramatic much...
It isn't btarunr's fault, even. We are grimy over puns such as these:

AMD CPUs are vulnerable to a severe new side-channel attack"Finally, an issue with AMD CPUs!" - someone at Intel probably

I like this sort of thing, just my sort of zero risk bias. However, just look at what the focus is on:
AMD CPUs are vulnerable to a severe new side-channel attack
The gaslight is just too intense here. Either sarcastic for noninvolved, or overly dramatic for involved parties, there is just no redeeming quality of such shitty captioning.
That is what we should assemble against, imo.

 

[R-T-B]

Geez, guys. I'm all for a healthy debate, don't get me wrong... but do realize BTA is allowed to have an opinion, the same as anyone else.

I know, he is. I just disagree completely with it's foundations on the level I would a flat-earther.

But yes, he is.

There is something bewildering about the way these things are made public

Sensationalism sells, applies here as well as the media. Is it profesional? No. Does that stop anyone? No.

That kernel.org documentation conflicts with Microsoft published info. Who's telling the truth then?

Both? One applies to linux, and the other windows? You do realize kernel.org parameters are for the linux kernel and not the MS one, right?

Name a ransomware that leverages a CPU-level vulnerability. Bonus points for one that leverages a side-channel attack vector.

Survivership bias. It only takes one.

 

[Ferrum Master]

Both? One applies to linux, and the other windows? You do realize kernel.org parameters are for the linux kernel and not the MS one, right?

I read through that later, I didn't get why he replied it that way, I was thinking about the powershell tool also switching mitigations, with the same idea in mind. Win10 doesn't allow to disable Spectre V1, it's baked in. Easy to test... 4K reads writes for my Optane. They crumble a bit with each mitigation. On win7 those are 300MB/s on Win10 those are 170MB/s. Google's retpoline helped a bit for, but still... if this one is promised to be much harder penalty... no good at all.

The other thing is... if a piece of software gets recompiled with worse feature set, having workarounds... it will be slower by definition... Basically... there ain't no good scenario, good ending here.

The idea the bounty program should be accelerated as much they can, to ensure future products don't suffer from it anymore. This generation is tossable for sure.

 

[hat]

I know, he is. I just disagree completely with it's foundations on the level I would a flat-earther.

But yes, he is.

And that's fine. I'm just calling out the disproportionally large number of people in the comments doing the same, I suspected just because it's BTA. You don't usually see this amount of people arguing with a single normal forum member... unless they say something really, really dumb.

 

[HTC]

Phoronix tested with Linux and ... it's not good ...

 

[lexluthermiester]

Phoronix tested with Linux and ... it's not good ...

No one is expecting it to be good. The question is how bad is it going to get/be.

 

[HwGeek]

Bad...Very bad...

AMD FX 9590 to Intel 9900K: "I am no longer afraid from you!".

 

[mtcn77]

Bad...Very bad...

AMD FX 9590 to Intel 9900K: "I am no longer afraid from you!".

We are back in business!

 

[John Naylor]

Much Ado Bout Nothing -
Security Disclosures on Theoretical Intel CPU Flaws Are Becoming Ridiculous

Security Disclosures on Theoretical Intel CPU Flaws Are Becoming Ridiculous

The new attacks discovered against Intel CPUs (and AMD, for that matter) seem to be getting increasingly theoretical and ridiculous, given the language being used to describe them to the public.

www.extremetech.com

"Unfortunately, it’s starting to look like the PR departments working with security researchers the world over have taken a very real problem with problematic leakage of data in side-channel attacks and are now spinning theoretical scenarios that aren’t backed up by the data in the documents themselves. "

In other words, security researchers (or security research firms’ PR divisions) are now putting out reports claiming Intel CPU’s are catastrophically at-risk from theoretical attacks that haven’t even been created yet, even though these attacks are incredibly difficult or downright theoretical. This is an absurdity.
Asking a company to design hardware intelligently to mitigate existing or well-known risks is one thing. Asking it to design hardware that secures against esoteric attacks that haven’t even been demonstrated in real-world testing yet is ridiculous. Even Bitdefender’s Director of Threat Research agrees that this attack isn’t one Intel should realistically bother securing against because it’s so hard to deploy.

We’re starting to hear about ‘theoretical’ risks to both Intel and AMD and threats that could emerge someday, but, you know, don’t actually exist right now. There’s nothing wrong with planning ahead, but given the long development cycles that CPUs go through, there’s no practical way for Intel to build a 2020 CPU to handle every possible security flaw that might be found in software, hardware, or both by 2025. The nature of security flaws is that after you patch one, people go out and find another. I'm increasingly convinced that Intel isn’t being treated fairly by these reports, and it’s not just Intel. Earlier this week we covered another instance where the PR verbiage around an AMD flaw didn’t match what the actual security researchers said in public.

These "security warnings" are akin to "Well we all could fly of the planet .... if we lived in a world w/o gravity."

 

[lexluthermiester]

Much Ado Bout Nothing -
Security Disclosures on Theoretical Intel CPU Flaws Are Becoming Ridiculous

Security Disclosures on Theoretical Intel CPU Flaws Are Becoming Ridiculous

The new attacks discovered against Intel CPUs (and AMD, for that matter) seem to be getting increasingly theoretical and ridiculous, given the language being used to describe them to the public.

www.extremetech.com

"Unfortunately, it’s starting to look like the PR departments working with security researchers the world over have taken a very real problem with problematic leakage of data in side-channel attacks and are now spinning theoretical scenarios that aren’t backed up by the data in the documents themselves. "

In other words, security researchers (or security research firms’ PR divisions) are now putting out reports claiming Intel CPU’s are catastrophically at-risk from theoretical attacks that haven’t even been created yet, even though these attacks are incredibly difficult or downright theoretical. This is an absurdity.
Asking a company to design hardware intelligently to mitigate existing or well-known risks is one thing. Asking it to design hardware that secures against esoteric attacks that haven’t even been demonstrated in real-world testing yet is ridiculous. Even Bitdefender’s Director of Threat Research agrees that this attack isn’t one Intel should realistically bother securing against because it’s so hard to deploy.

We’re starting to hear about ‘theoretical’ risks to both Intel and AMD and threats that could emerge someday, but, you know, don’t actually exist right now. There’s nothing wrong with planning ahead, but given the long development cycles that CPUs go through, there’s no practical way for Intel to build a 2020 CPU to handle every possible security flaw that might be found in software, hardware, or both by 2025. The nature of security flaws is that after you patch one, people go out and find another. I'm increasingly convinced that Intel isn’t being treated fairly by these reports, and it’s not just Intel. Earlier this week we covered another instance where the PR verbiage around an AMD flaw didn’t match what the actual security researchers said in public.

These "security warnings" are akin to "Well we all could fly of the planet .... if we lived in a world w/o gravity."

While that is a good article with many good and valid points, the LVI problem is important to bring to the public eye as mitigations need to be developed for business and enterprise. End users are very unlikely to be affected by this as they have nothing of value to warrant the effort of an attack, but large companies and entities need active protection.

 

[R-T-B]

Phoronix tested with Linux and ... it's not good ...

Not as bad as I expected actually. The more practical graph you should be referencing for all but the most secure workloads is the "LFENCE before Ret" one. It's the mitigation that will most likely be used rather than the more extreme ones like "LFENCE + Indirect Branch + RET" which strikes me as overkill and will most likely be made a kernel option.

No one is going to lose 90% of their performance unless they are running a state nuclear program.

 

[KarymidoN]

your xeon can now be a Celerom Yay

 

[R-T-B]

View attachment 148091
your xeon can now be a Celerom Yay

If you opt for it sure. There is no way that is going to be the default set of Mitigations. You should be looking at LFENCE Before RET as the worst case, LFENCE Before indirect branch as the best.

 

[mtcn77]

All this probing around accounts for ai generated attacks right? It is only difficult because it isn't native for us. Targetting around for memory imprints is detective work and I don't think gerrymandering around the issue would be too difficult for ai once it connects the dots. Literal TAS on the fly. It's hard? -Say no more fam...

 

[R-T-B]

All this probing around accounts for ai generated attacks right? It is only difficult because it isn't native for us. Targetting around for memory imprints is detective work and I don't think gerrymandering around the issue would be too difficult for ai once it connects the dots. Literal TAS on the fly. It's hard? -Say no more fam...

I really don't even know what you are trying to say to formulate a reply.

 

[biffzinker]

I really don't even know what you are trying to say to formulate a reply.

Something about it being easier for a AI trained at carrying out these theoretical, and hypothetical exploits in a CPU?

 

[R-T-B]

Something about it being easier for a AI trained at carrying out these theoretical, and hypothetical exploits in a CPU?

I don't think an AI could figure out these exploits. Too situational, requiring human interaction and response.

 

[mtcn77]

I'm not the go to guy, but this local member explained it with a text wall and by the look of this I'm only 'half-wrong' which is accurate enough to sum up this exhibit.
This collide+probe load+reload script kinda serves to break ASLR encryption from 28 to 15 bits on most accounts. It might not seem much, but 65K is a lot sooner than 268M through brute forcing. Coupled with that, presuming the way predictor gets decyphered even more, the suspect attack vector as described to me goes as such,

• We identify targets beforehand(this vulnerability is only the tool, not the means),
• We spoof memory,
• We disable cpu caching,
• We flush caches,
• We access memory first(this is very important to pull it off without concurrent programs reaching for their turn of memory),
• We pull spoofed memory which goes to L3,
• Our accessed memory is in the next sector, however collide+probe somehow makes the sectors enter "probe from access-violate next sector" which is in the next L3 page/word/tag(I haven't figured that part),
• Through magic voila we now have data that is 2^-15 the data we need.

 

[R-T-B]

ASLR encryption

What the heck is ASLR encryption? You do know ASLR is a randomization technique for addresss space layouts and doesn't have anything to do with encryption really, right?