SPECTRE and MELTDOWN: Bug rocks Intel / ARM CPUs

[segfaulted]

Kinda glad I bought AMD this round. For those who don't know there is a new bug affecting just about every SKU from Intel made in the last .. ohh.. _DECADE_ or so. It's actually worse then F00F or FDIV. Only mitigation appears to castrate the CPU upward of 30%! (depending on processes).

Can Asus confirm AMD and more importantly for me, this or any AMD motherboard are not affected? If so, will there be RMAs?

Fun fact, Intel's CEO dumped stock back in November before they started issuing gags on people from even talking about it.

*****ASUS advisory page(may get updated): https://www.asus.com/News/V5urzYAT6myCC1o2 ******

[raximus21]

Also, I've seen this twice now in this thread. This logic that people want to see a SECURITY update for their mb because they are doing something wrong on their machine is complete nonsense.

Some of us just don't want our credit card, password, or personal info stolen or our OS destroyed. I don't have time to recover my OS all the time because of a virus obtained from a security flaw in my hardware because the manufacturer I bought it from doesn't want to apply a SECURITY update for a mb I bought just a few years back.

:rolleyes::rolleyes::rolleyes:

[segfaulted]

Axle Grease wrote:
Ah, so the MS patch is only installed, but until mobo manufactures release updated BIOSes containing the new intel microcode, there is no hardware support to enable the patch. Do I have that right? It does explain why there's stuff all difference in pre and post patch CPU benchmarks so far.

Depends what benchmarks you're referring to and more importantly which mediation was used. The original proposed solution at least in Linux, from Intel, has or had quite a bite more overhead then the one Google claims to have gone with. There's also the issue of what was really being tested since not all games for example would be affected as they are more GPU constrained.

Part of the fud being thrown around still involves what the exploits actually are.
Your computer is like a school bus. In the morning it picks up kids for school but during the day and afternoon it's chartered. What's supposed to happen is the bus gets cleaned between uses. Meltdown exploits the garbage people leave behind. SPECTRE is less exploit and more observation since it's like looking at the gas gage to judge how far the bus went between users. It doesn't know who they are but can eventually piece together enough data to guess.

All Intel's done at this point is replace the cleaning staff. They're slower, cost more and demanded concessions.

Both are well understood design problems. Meltdown should never have happened if Intel actually followed ring isolation.

What they are now calling SPECTRE for this, has been around for a long, long time and can affect anything with a cache since it's a timing attack. In HTTP it would be like a CDN sitting between you and a server. Probe the CDN enough and you can tell what is in cache. Find a way to uniquely identify a user - with say a session id in the url or sites without any kind of random seed - and you can passively determine where they have gone based on what is in the CDN. If it's there the response will be faster. That is what bugs like SPECTRE, are.

It's quite different from Meltdown and a smokescreen attempt by Intel.

* I've deliberately left out the mitigation methods in HTTP to better illustrate the point.

[Axle_Grease]

segfaulted wrote:
Depends what benchmarks you're referring to and more importantly which mediation was used. The original proposed solution at least in Linux, from Intel, has or had quite a bite more overhead then the one Google claims to have gone with. There's also the issue of what was really being tested since not all games for example would be affected as they are more GPU constrained.

Part of the fud being thrown around still involves what the exploits actually are.
Your computer is like a school bus. In the morning it picks up kids for school but during the day and afternoon it's chartered. What's supposed to happen is the bus gets cleaned between uses. Meltdown exploits the garbage people leave behind. SPECTRE is less exploit and more observation since it's like looking at the gas gage to judge how far the bus went between users. It doesn't know who they are but can eventually piece together enough data to guess.

All Intel's done at this point is replace the cleaning staff. They're slower, cost more and demanded concessions.

Both are well understood design problems. Meltdown should never have happened if Intel actually followed ring isolation.

What they are now calling SPECTRE for this, has been around for a long, long time and can affect anything with a cache since it's a timing attack. In HTTP it would be like a CDN sitting between you and a server. Probe the CDN enough and you can tell what is in cache. Find a way to uniquely identify a user - with say a session id in the url or sites without any kind of random seed - and you can passively determine where they have gone based on what is in the CDN. If it's there the response will be faster. That is what bugs like SPECTRE, are.

It's quite different from Meltdown and a smokescreen attempt by Intel.

* I've deliberately left out the mitigation methods in HTTP to better illustrate the point.

There's a new BIOS out for the Maximus X Formula dated Jan 2. Guru3D does some benchmarks. http://www.guru3d.com/articles-pages/windows-vulnerability-cpu-meltdown-patch-benchmarked,1.html Substantial 4K I/O performance degradation is noticeable in CrystalDiskMark, but it's so workload specific that I am finding it hard to elicit an emotion over it. Well, so long the new cleaning staff do their job...

Cleaning the bus between uses would also make it more difficult for any lowlife to exploit spectre as new rubbish replaces old more frequently, right? ...or wrong?

[segfaulted]

Axle Grease wrote:
There's a new BIOS out for the Maximus X Formula dated Jan 2. Guru3D does some benchmarks. http://www.guru3d.com/articles-pages/windows-vulnerability-cpu-meltdown-patch-benchmarked,1.html Substantial 4K I/O performance degradation is noticeable in CrystalDiskMark, but it's so workload specific that I am finding it hard to elicit an emotion over it. Well, so long the new cleaning staff do their job...

4k blocks are the default in just about every OS so the implications could be severe. I'm a bit confused looking at their results though. He's trying to do an AB comparison but not keeping the sort order?? Proper way to do that would have been either next to each other or even better on the same chart.

Those tests aren't really fair comparisons for this anyway. For one he's using SSD's and NVME which by design avoid CPU involvement more then a regular hard drive.

Axle Grease wrote:
Cleaning the bus between uses would also make it more difficult for any lowlife to exploit spectre as new rubbish replaces old more frequently, right? ...or wrong?

The analogy was meant to be more high level then technical so a bit of clarity. The act of cleaning the bus, is a cache flush. What intel does is like what a kid would do to clean their room - shove some stuff under the bed and hope no one sees it. Well, people did.

It's still very different then cache observation attacks (the gas gauge), some of which are actually useful byproducts. Think if you had a block in cache and a block on disk, getting it from cache would be quicker. But unless you have complete cache coherency, you cannot know for certain where the block is. Thus things like cache snooping (in a good way), are used. Effectively asking the hardware "do you have this?". The cost of doing that obviously has to be a net gain - both performance and security - the hardware telling you is in of itself an attack for the same reason a CDN can be leveraged against a site. In multi user environments that utilize things like dedupe you can attack the other hosts around you simply by asking the hardware what is in memory. This is all very well understood.. at least it should have been.


Enough analogies though, hope this makes more sense as to the smoke coming from Intel.

[Vlada011]

Now look this...

Real Bench 2.54 Image Edition 5820K 4.2GHz

September 17

197.304
28.2745

October 14

199.103
26.7559

December 7

197.903
26.9221

December 10

198.633
26.8232

After Windows Update
Januar 6

138.704
38.4125

Intel just destroyed enthusiasm of thousands people worldwide.
I think this is more than Intel could fix in near future.
People would not satisfied until Intel completely recover them to the last percent of performance.
How they think to do that and how much will cost them to do that, enthusiasts shouldn't care at all.
If not Intel customers should promise Intel that his stock will be less than AMDs' now very soon.

Guys who live on Image Editing....I have no word. I;m still under shock and think that maybe is something else.
Are you aware that guys with Haswell-E in some cases have performance of Ivy Bridge E. Even after OC you can't compensate default results before new fix.
Intel just crippled IT industry and himself, they explode. I don't remember this something like this happen in IT industry even close.
Brain of 99% computers, is crippled completely. Not 99%, 100% of people who deal with Intel.

hard core motherboards, deliding, watercooling, benchmarking, nothing worth any more at all.
Nothing. I think impression of enthusiasts will never recover from this completely and many people think,
People will start to scare from benchmark tests and scores because they show tragic reality next 5 years.
But if you invest in i9-7980X after OC you will still beat 1950X... Hahahaaa.

[Caudwell]

Hi all
I have ( Asus x99 Rampage V Extreme )
Bios i am useing is ( 3504 )
CPU i have is ( Intel Core i7-5930K )
I update my windows 10 to Version 1709 ( OS Build 16299.192 )
I Done Test this what Testing come back dose not look good hoping it be fix.

[Nixon2992]

Caudwell wrote:
Hi all
I have ( Asus x99 Rampage V Extreme )
Bios i am useing is ( 3504 )
CPU i have is ( Intel Core i7-5930K )
I update my windows 10 to Version 1709 ( OS Build 16299.192 )
I Done Test this what Testing come back dose not look good hoping it be fix.

Dear.
You can update microcode with tool in atachments(with last uCode for HSW-E:0x3B)
Best Regards.

[A_Catalin]

https://www.asus.com/News/V5urzYAT6myCC1o2

[Caudwell]

A.Catalin wrote:
https://www.asus.com/News/V5urzYAT6myCC1o2

Thanks for post but what why is my Motherboard not on the list ( Asus Rog x99 Rampage V Extreme ) ?

[xeromist]

Caudwell wrote:
Thanks for post but what why is my Motherboard not on the list ( Asus Rog x99 Rampage V Extreme ) ?

These lists are subject to change and more models may get added. Regardless I would check and see if your board has an update released at the same time as other x99 boards. It's possible there is an update but you're not listed.