Quick Facts about Meltdown and Spectre

pcgeekesq said:
So much for you saying you'd come back in two weeks. You couldn't stay away five minutes, could you?
Click to expand...

Reading IS fundamental! I said "I will in 2 weeks come back to this post" Now read carefully...It said in 2 weeks ill back to this post. Which post you may ask? Well its your post! which said "I have complete confidence that within the next two week, events will demonstrate that you and 'noOther' are totally wrong."
 
Brackle said:
Reading IS fundamental! I said "I will in 2 weeks come back to this post"
Click to expand...
So is hair-splitting, for you apparently.
NoOther said:
Because you can't even form an explanation. You keep saying you have all this experience and you know the researchers are wrong, but you can't even link to a proper source or articulate what it is you think the researchers are wrong about. All you have are continued personal attacks. I am simply asking for your point and insight. I don't understand why you are so unwilling to share if you know for a fact this is a non-issue. Many others would also be heartened to understand why this is a non-issue, if that is truly what you are trying to say.
Click to expand...
Do you or do you not understand anything about advanced micro-processor architecture?
Tell me everything you know on the subject, and I'll see if I can fill in the gaps.

You can start with the basics: OoO issue, OoO execution, reservation stations, reorder buffers, register renaming, cache consistency and coherency, etc. -- the basic stuff they developed back in the Biin days that made its way first into the iAPX432, then into the Intel i960MX, and then into the x86 processor lines.

If you don't understand what I'm talking about, you do not and cannot understand these bugs.
 
Considering you supposedly worked at Intel doing processor design work about the time piss poor decisions on design were being made, I think we all know why you are so defensive and have no response other than to insult people.
 
I'd vote for a 2 week vacation for these 2 so we can focus on the actual discussion instead of who thinks they know what.

I've been concerned about patching our 100+ VM's and their servers next week, but MS has specifically stated with their patches that some anti-virus software may make some bad kernel calls which can BSOD. So rushing to patch the OSes will require us to ensure our other software doesn't screw us over. We are doing an all hands on deck to study how and when we go about patching things server side as to minimize potential downtime. The performance hit is not well documented yet so I know my bosses will be wary of implementing something which may bring our infratstructure to a slow grind.
 
FearTheCow said:
Considering you supposedly worked at Intel doing processor design work about the time piss poor decisions on design were being made, I think we all know why you are so defensive and have no response other than to insult people.
Click to expand...
Another made-up fake-news post from an Intel basher.
I didn't work on any of the affected processors. I left Intel over a decade ago, and I transitioned into cryptographic systems long before that.
 
Perhaps relevant to some (treat it like a grain of salt: --the messenger):

Why Intel's 2015 CPU bugs should make us expect worse bugs in the future

An excerpt from that link follows:

Meltdown / spectre update

This is an interesting class of attack that takes advantage of speculative execution plus side channel attacks to leak privileged information into user processes. It seems that at least some of these attacks be done from javascript in the browser.

Regarding the comments in the first couple updates on Intel’s attitude towards validation recently, another person claiming to be ex-Intel backs up the statements above:

As a former Intel employee this aligns closely with my experience. I didn’t work in validation (actually joined as part of Altera) but velocity is an absolute buzzword and the senior management’s approach to complex challenges is sheer panic. Slips in schedules are not tolerated at all - so problems in validation are an existential threat, your project can easily just be canned. Also, because of the size of the company the ways in which quality and completeness are ‘achieved’ is hugely bureaucratic and rarely reflect true engineering fundamentals.​
 
...so in effect, CPU's are designed to guess what the next instruction would be. The exploit is able to use a 'miss' as a way to get data. The patch forces CPU's to run at the speed they would run at if they did not have speculative prediction. It takes away the guessing game....for most applications.

Who would have thought that taking away a guess could affect 30% of a servers processing speed. Gotta see where this winds up, seems that it cant be as wide an issue as media is making it look - I could be wrong. I wonder if - however - hackers are now being made aware of something that they otherwise would have never thought of :cool::unsure:
 
Brackle said:
Considering Juanrga is liking his post. I would ignore the troll. Only Intel fanboi's are working overtime to make this a non-issue.

This is a non-issue if you do game, you probably wont see any performance hit. But I don't think anyone thought gaming would be affected. From what I have been reading is that mostly Enterprise is what is going to be affected.

Intel is in full on PR mode right now trying to blame everyone else, and not even admit it is a design flaw when it is.
Click to expand...

FACT 1: I liked a post from pcgeekesq that contains an informative quote from the RISC-V guys about those vulnerabilities.

FACT 2: You and NoOther are posting plain false information such as "You quoted from a report on RISC-V in relation to a bug found in x86 architecture". pcgeekesq is right: this is not a bug in the x86 architecture.

Meldown and Spectre are microarchitectural exploits and so affect to CPUs from different architectures. Many CPUs from x86, ARM, POWER, and Z-series architectures are confirmed to be vulnerable. Here you have a table of vendors affected by Meltdown and Spectre.

On the other hand, CPUs without the microarchitectural elements exploited by Meltdown and Spectre attacks aren't vulnerable. Examples? Older Intel Atoms and ARM Cortex-A53 CPUs aren't affected.
 
bongee said:
Strait from AMD this isn't an accurate description, it does not disable branch prediction. https://www.phoronix.com/forums/for...-wake-of-spectre-meltdown?p=999484#post999484
Click to expand...

And to add more confusion to this issue yesterday SUSE published this, where now they give the same description for non-AMD and AMD systems

CVE-2017-5715 / "SpectreAttack": Local attackers on systems with modern
CPUs featuring branch prediction could use mispredicted branches to
speculatively execute code patterns that in turn could be made to leak
other non-readable content in the same address space, an attack similar
to CVE-2017-5753.

This problem is mitigated by disabling predictive branches, depending
on CPU architecture either by firmware updates and/or fixes in the
user-kernel privilege boundaries.

Please also check with your CPU / Hardware vendor on updated firmware
or BIOS images regarding this issue.

As this feature can have a performance impact, it can be disabled using
the "nospec" kernel commandline option.
Click to expand...
 
And all my personal info and private stuff is stored in cold storage. I never trusted the cloud in the first place.
 
Meltdown affects INTEL processors.
Click to expand...
MELTDOWN also affects some ARM cores (including Apple's custom variants), and Redhat's listing for CVE-2017-5754 also covers POWER variants so that may be vulnerable too (still looking into this, IBM's statement doe snot specify which vulnerabilities they are affected by, just that they are affected). The researchers also do not rule out MELTDOWN affecting other architectures too, just that they only produced a PoC for Intel:
Currently, we have only verified Meltdown on Intel processors. At the moment, it is unclear whether ARM and AMD processors are also affected by Meltdown.
Click to expand...
 
NoOther said:
The evidence I quoted right from their papers? I did not pull up random stuff, I pulled right from the whitepapers. You do realize those white papers is what the GPZ report was made from right? I went directly to the source.

Your experience level is not indicated by your posts. You quoted from a report on RISC-V in relation to a bug found in x86 architecture, what sense does that make?
Click to expand...

The issues exploited by both Meltdown and Spectre are not architectural. Architecturally, all processors from all affected vendors are doing the correct thing. Both rely on non-architectural state as an effective side channel in order to get data.

In essence, the code looks like the following:

Z=0
Y=0
If X < [SOME_LOAD]
Y = LSB([LOAD_IN_PROTECTED_SPACE])
If Y != 0
Z = [LOAD_FROM_FLUSHED_ARRAY]
ENDIF
ENDIF

Now at the end of that code sequence, Z and Y are still 0 because a fault occurs and everything is rolled back. But, critically, the processor can during the sequence speculatively do both the loads for Y and Z and hence bring them into the cache. The load for Y can't be read by the processes and no information is available from it because it is in a protected space. But the existence of the load from Z in the cache can be tested for via timing of a subsequent load which lets you know if the LSB of the protected memory is 1.

Architecturally, everything is working correctly. This is a micro-architectural attack that merely uses the cacheline presence as a side channel. There are other possible ways to side channel the data but using cacheline presence is the easiest.

And because it relies on micro-architectural state and not architectural state, this really isn't an x86 or even Intel issue but a general issue affecting pretty much all micro-architectures that do speculative execution from ARM, Power, Alpha, MIPS, X86, etc. The only processors that aren't affected are those that don't do speculative execution: basically simple in-order designs.

Now side channel attacks aren't new, they've been a major issue in cryptography for a long long time, but this is a new application of side channel attacks that will have repercussions across all architectures from this point forward regardless of vendor or ISA.
 
aaronspink said:
Now side channel attacks aren't new, they've been a major issue in cryptography for a long long time, but this is a new application of side channel attacks that will have repercussions across all architectures from this point forward regardless of vendor or ISA.
Click to expand...

One of the best I ever heard of was the detecting of RF signals from an computers CRT screen, duplicating what was on the targets screen from a hundred meters away. Some NSA type businesses bought tempest class faraday cages to protect against it. I still find that amazing, but today I wonder if the threat has gone away or just not thought about.
 
pcgeekesq said:
You wouldn't understand the explanation, and I don't have time or inclination to teach you the 12 graduate-level credit-hours worth of processor hardware design knowledge you'd need.
Click to expand...
I was really enjoying what you were saying up until this post.
If you do truly know what you are talking about on here, and I'm not saying you do or don't, then you should at least be able to write out a somewhat understandable variant of what you are talking about, or at least an analogy to make it clearer for those who may or may not be educated in the subject matter.

I am legitimately interesting in seeing what you have to say on the explanation on this, especially with the credentials you have listed.
At a minimum, at least try to give an explanation so we, and others, can have a better understanding of where you are coming from. :)

Also, I'm not an "Intel hater" or anything like that, and just looking to understand more about the subject matter at hand.
Even if we don't understand your explanations, it may be enough to spark our interest to investigate and learn further, which hopefully will help us, and others, in the long run. :)
 
I still have some uncertainties about this vulnerability. If an attacker gets to run code on your system, they just as well can run keylogger to get your passwords, no need to sift trough memory to get it. So it seems to me that for the home user this doesn't present any new threats. It's the same old don't run malicious software and use nosrcript remedy.

As I understand it is a problem for cloud services because by running the exploit on a virtual machine the attacker can get access to the data of all other vms running on the same node.

So is that right, or am I still getting it wrong?
 
M76 said:
I still have some uncertainties about this vulnerability. If an attacker gets to run code on your system, they just as well can run keylogger to get your passwords, no need to sift trough memory to get it. So it seems to me that for the home user this doesn't present any new threats. It's the same old don't run malicious software and use nosrcript remedy.

As I understand it is a problem for cloud services because by running the exploit on a virtual machine the attacker can get access to the data of all other vms running on the same node.

So is that right, or am I still getting it wrong?
Click to expand...

Installing a keylogger requires privileged access, which usually notifies the user (even if they ignore it). These attacks do not.

Think of something like the recent attack that used SMB to spread itself through the internal networks of corporations around the globe. Imagine if instead of encrypting the contents of the systems drives and becoming blatantly obvious that something had gotten in, it just quietly ran a background process phoning home the data it found in those systems' memories. Eventually someone would notice that there's been some unusual network traffic, but that could be months afterward.
 
ryan_975 said:
Installing a keylogger requires privileged access, which usually notifies the user (even if they ignore it). These attacks do not.

Think of something like the recent attack that used SMB to spread itself through the internal networks of corporations around the globe. Imagine if instead of encrypting the contents of the systems drives and becoming blatantly obvious that something had gotten in, it just quietly ran a background process phoning home the data it found in those systems' memories. Eventually someone would notice that there's been some unusual network traffic, but that could be months afterward.
Click to expand...

But given the size of memory and without the attacker knowing what they're looking for it would be a huge amount of data. Or if they want to sift trough it on the target computer that's a huge amount of processing. Both could be easily noticeable. As long as the malicious code runs on the target computer it can be detected by AV software. But of course AV software has to be changed and upgraded to detect this kind of activity. I don't think that's impossible. It only needs to analyze each process once, so it shouldn't even have a significant performance impact. Most enterprise AV software already automatically sandboxes suspicious tasks for analysis.
 
These are the kind of bugs malicious hackers use to spy would be interested in. I would imagine governement hackers would love a way to get this into some form which finds a way to dump all memory contents (ie whole vm). Sorting through what the data entails later is moot once they have taken all the information out of the systems they are attacking.

On a more simplified consumer level, targeting specific banking information, email access etc is just about standard fare for their goals.
 
Khahhblaab said:
One of the best I ever heard of was the detecting of RF signals from an computers CRT screen, duplicating what was on the targets screen from a hundred meters away. Some NSA type businesses bought tempest class faraday cages to protect against it. I still find that amazing, but today I wonder if the threat has gone away or just not thought about.
Click to expand...
Generally known as "Van-Eck Phreaking". It;s one of the easier emission attacks, as VGA is nicely analog squirted over a long antenna (the cable) and already helpfully encoded onto carrier signals. The came attack, with more sensitive detectors and more decoding workload, and be performed against DVI, HDMI, DisplayPort, your keyboard PS/2 or USB cable, etc.
 
This is one of those intentionally engineered bugs so the Feds can backdoor anyone anytime.
 
Thanks for the no nonsense quick and easy breakdown guys. you guys are always on your game. Thank you.
 
EdZ said:
Generally known as "Van-Eck Phreaking". It;s one of the easier emission attacks, as VGA is nicely analog squirted over a long antenna (the cable) and already helpfully encoded onto carrier signals. The came attack, with more sensitive detectors and more decoding workload, and be performed against DVI, HDMI, DisplayPort, your keyboard PS/2 or USB cable, etc.
Click to expand...

..so while everyone is worried about meltdown and spectre, there are guys with homemade equipment directly watching the data on the screens of the computers we are worried about. Huh? :confused:

I kinda thought that the potential went away since crt's are less in use. But if everything connected to a computer can be "Van-Eck'd", there are more considerations than the bug of recent notice.
 
I'm hoping they will find a strong solution for this outside of crippling CPU performance.

Hopefully they can find a way to filter/trap malicious code in the OS, NIC driver, or even a new security processor built-in to the chipset.
It would be nice to have a watchdog processor that monitors the CPU and can halt it if need be.

They should use this situation as an opportunity to beef up security for this and any future threats.

.
 
Khahhblaab said:
..so while everyone is worried about meltdown and spectre, there are guys with homemade equipment directly watching the data on the screens of the computers we are worried about. Huh? :confused:

I kinda thought that the potential went away since crt's are less in use. But if everything connected to a computer can be "Van-Eck'd", there are more considerations than the bug of recent notice.
Click to expand...

Van-Eck is much more complicated and costly and target limited as such. Basically you are looking at millions these days for a single setup that can monitor a single computer. If you are doing work that could potentially merit the cost of Van-Eck, you are already inside a fully shielded building in most cases and therefore immune.
 
aaronspink said:
If you are doing work that could potentially merit the cost of Van-Eck, you are already inside a fully shielded building in most cases and therefore immune.
Click to expand...
Immune, he says! TEMPEST may prevent RF leakage (unless you duct it through the building;s plumbing as a waveguide) but everyone needs power. I picked that link because it's a passive technique requiring no modification of the target, but if you can infiltrate code you can exfiltrate data via power from unmodified devices, and if you can infiltrate hardware (e.g. doctored PSU in a coffee maker) then exfiltration via power is pretty much trivial. Then you have extra fun stuff like audio and optical side-channel attacks.

Van-Eck is also much cheaper than you make out, Software Defined Radio receivers are a commodity part nowadays.
 
Spartacus said:
I'm hoping they will find a strong solution for this outside of crippling CPU performance.
Click to expand...

Those are emergency patch. The patches would be optimized in a future and reduce the performance impact. But wait some impact however.
 
juanrga said:
Those are emergency patch. The patches would be optimized in a future and reduce the performance impact. But wait some impact however.
Click to expand...


Optimism is good, but I think a fix is going to require a performance hit due to the nature of the problem.


.
 
i wonder if they can pass that job from the processor to the software to gain back performance , sort of like they do with software raid
 
the_real_7 said:
i wonder if they can pass that job from the processor to the software to gain back performance , sort of like they do with software raid
Click to expand...

I don't think so.

The problem exists at a very low level inside the CPU where it is shuffling instructions and data around.
Software fixes just become more data to shuffle around in a sense.

The software fixes are like trying to lock the front door of the bank even though the vault door is still stuck
open inside the bank.

It's going to take microcode, BIOS, and probably hardware changes to absolutely fix the problem.
I think the best they can do without CPU hardware changes is make it more difficult for the hackers.

Maybe speculation (pun intended) on my part, but that's how it looks to me at this point.


.
 
Folks this isn't a patch it and forget it security flaw.

1. This is not just a patch. (just got done telling a VP and directors that.) This is a patch and a microcode/bios update.

2. This does not make you immune to this processor flaw. It only corrects the first iteration of exploits for this flaw. Like a flue vaccine it is not 100% effective... and efficacy is only going to become less as time passes.

3. The only real solution is a processor that does not have this flaw in it.

Does this mean AMD is the end all be all? No.. it means AMD does this in a method of their own design and not reverse engineered like it seems everyone else did. (Or licensed.)

AMD is the safer bet right now for a hardware platform for externally facing and accessing systems. Potentially for DB systems depending on the impact and need of the fix internally.

This patch is only being applied in windows based on the vendor of your AV or Anti Malware solution being up to date and ready for a bit to be flipped in your registry to allow this patch to come down. Otherwise it can cause severe system instability.

I don't want to sound excessively ominous folks but this is only the beginning of what we see with this vulnerability.
 
Agree with all of the above.

>>AMD is the safer bet right now for a hardware platform for externally facing and accessing systems.

True, but I'm sure you would agree that it's a bit premature to toss the Intel gear in the wood chipper and replace it all with AMD.
This is all going to bring more scrutiny on both major platforms (a good thing).

You could scrap all of your Intel gear and go with AMD only to have a new flaw found next month that only affects AMD. Then what?

I'm also an IT guy and I'm telling my customers that we need to apply all updates as they become available, but that there is no need
to panic at this point and start investing in new systems.

This is bad, but it's not THAT bad.

It's actually pretty impossible to take off the shelf computer hardware, run an off the shelf OS, connect it to the whole world, and then
promise that the system will have perfect security. I don't know if that will ever be possible.

.
 
For Chrome users, go enable Strict Site Isolation here: chrome://flags/#enable-site-per-process

This, plus the os patches, plus firmware updates should keep most end users safe for now.

Probably be more ways in which these side channels can be exploited, found in the future. I suspect this train-wreck will drag on for sometime...
 
J3RK said:
:D

I could pretty happily go back to 68000 and 6510 based machines for a while, while they work this all out. Then come back to modern architecture when it's all resolved. :D
Click to expand...

I knew there was a good reason I still have my Pentium MMX 233MHz PC other than playing early Glide games on a Voodoo Graphics board... :pompous:
 
  • Like
Reactions: DocNo
like this
Spartacus said:
Agree with all of the above.

>>AMD is the safer bet right now for a hardware platform for externally facing and accessing systems.

True, but I'm sure you would agree that it's a bit premature to toss the Intel gear in the wood chipper and replace it all with AMD.
This is all going to bring more scrutiny on both major platforms (a good thing).

You could scrap all of your Intel gear and go with AMD only to have a new flaw found next month that only affects AMD. Then what?

I'm also an IT guy and I'm telling my customers that we need to apply all updates as they become available, but that there is no need
to panic at this point and start investing in new systems.

This is bad, but it's not THAT bad.

It's actually pretty impossible to take off the shelf computer hardware, run an off the shelf OS, connect it to the whole world, and then
promise that the system will have perfect security. I don't know if that will ever be possible.

.
Click to expand...


Oh no yea I agree replacing everything all at once right now would be over reaction. BUT <-- Note that is a big but.. If we end up having to schedule firmware updates and off cycle critical patches every month or other month it's quickly going to be cheaper to abandon the Intel hardware for the most vulnerable systems and replace with AMD in this case.

Not to mention if you have huge DB servers running 128+ core systems where you either need to add another 64 cores and the INSANE DB licensing costs.. of close to 200k for that. OR replace with AMD hardware to get your performance back. (30k in hardware. + more secure for now. + save on licensing costs.)
 
Spartacus said:
Optimism is good, but I think a fix is going to require a performance hit due to the nature of the problem.


.
Click to expand...

juanrga said:
Agree. I expect the performance hit to reduce when patches will be optimized.
Click to expand...

Spartacus said:
It's going to take microcode, BIOS, and probably hardware changes to absolutely fix the problem.
I think the best they can do without CPU hardware changes is make it more difficult for the hackers.

Maybe speculation (pun intended) on my part, but that's how it looks to me at this point.
Click to expand...

So it seems that the newer the processor, the more data may be open for extraction by meltdown and spectre, if more out of order data means more data can be hacked.

Skylake and ooo instructions.jpg


Remember when this used to be a point made about better processing power?
 
You must log in or register to reply here.
Back
Top