Researchers Claim to Find New Solution to Spectre, Meltdown

[Guest]

MIT's Computer Science and Artificial Intelligence Laboratory revealed DAWG, a new system that can defend against side-channel attacks like Spectre.

Researchers Claim to Find New Solution to Spectre, Meltdown : Read more

 

[Peter Martin]

oh, praying this is implemented and works.... get rid of all the stuttering in games and stuff

 

[hannibal]

This would be good news. But if this is implemented via os update. You need guite new os like win10, ios12 and so on and of course the os can be compromised to bypass the DWAG and then the hardware, firmware and so on solutions are the last line of the defense.

 

[derekullo]

Yo Dawg we heard you had some trouble with your code.

So we added some code to yo code so yo code no longer in a state of trippin'

 

[truerock]

When I was a student majoring in computer science I took a required course called "Operating Systems".
In writing my operating system for the semester I got around to zeroing out memory before starting and ending each task. It was to help me to more quickly track down bugs in my code.
My professor asked me why I was doing this and I explained that it was just something to help debug my code during the writing of my OS and I planned to eliminate the memory-zero-out routines near the completion of the semester course.
We got into a discussion about security issues related to leaving memory un-zeroed after a task was completed and later allocating that un-zeroed memory to a new task.
I don't think this issue is something that has not been thought about for decades.
CPUs are now powerful enough that security can take precedence over efficiency.

 

[bit_user]

I don't think this issue is something that has not been thought about for decades.
CPUs are now powerful enough that security can take precedence over efficiency.

Yes, they have been thought about. And yes, people are (and have been) burning CPU cycles on security features, such as ASLR (https://en.wikipedia.org/wiki/Address_space_layout_randomization).

Wikipedia has better explanations than I could manage:

https://en.wikipedia.org/wiki/Spectre_(security_vulnerability)
https://en.wikipedia.org/wiki/Meltdown_(security_vulnerability)

 

[jpe1701]

I really hope this pans out. When I built my nephew's computer with a Pentium g4560 the performance hit was pretty big. Iirc the cpu-z multi score was a little over 100 points different. I just left him an app that could switch off the protection when he didn't need it.

 

[s1mon7]

Wassup DAWG? Heard you need some new code in your code so you can process better while you process.

 

[stdragon]

As far as I'm aware, when it comes to OS security, Theo de Raadt (with OpenBSD) is the person to listen too. He even recommends disabling HT in BIOS.

What I'm more interested will be his thoughts on this whole DAWG mitigation method.

 

[DookieDraws]

GO DAWGS!

 

[secretxax]

If I were a higher-up in AMD or Intel, I'd hire them to help in processor design. All CPU companies should have people that can implement abstract and advanced techniques, ideas, and methods in every way of the technology.

 

[bit_user]

If I were a higher-up in AMD or Intel, I'd hire them to help in processor design. All CPU companies should have people that can implement abstract and advanced techniques, ideas, and methods in every way of the technology.

Most grad students go on to take jobs in the industry. Only a few will stay in academia.

One important question is who owns the IP described in this paper. MIT likes to patent inventions of their students, although the work might've been done under an industry grant or fellowship. At least if MIT owns the patent, it should be available for a practical amount of money - though perhaps not available for use in open source projects like Linux and the BSDs.

Looking at it now... I don't see any reference to patents or use rights. And the work was carried out partly under NSF and DARPA grants:

Funding for this research was partially provided by NSF grant CNS-1413920; DARPA contracts HR001118C0018, HR00111830007, and FA87501720126; Delta Electronics, DARPA & SPAWAR contract N66001-15-C-4066; DoE award DE-FOA0001059, and Toyota grant LP-C000765-SR.

...so, that's your tax dollars at work.

 

[audiospecaccts]

Well, lets go back to January, and remember what Linus says:


From Linus Torvalds <>
Date Wed, 3 Jan 2018 15:51:35 -0800
Subject Re: Avoid speculative indirect calls in kernel


Why is this all done without any configuration options?

A *competent* CPU engineer would fix this by making sure speculation
doesn't happen across protection domains. Maybe even a L1 I$ that is
keyed by CPL.

I think somebody inside of Intel needs to really take a long hard look
at their CPU's, and actually admit that they have issues instead of
writing PR blurbs that say that everything works as designed.

.. and that really means that all these mitigation patches should be
written with "not all CPU's are crap" in mind.

Or is Intel basically saying "we are committed to selling you shit
forever and ever, and never fixing anything"?

Because if that's the case, maybe we should start looking towards the
ARM64 people more.

Please talk to management. Because I really see exactly two possibibilities:

- Intel never intends to fix anything

OR

- these workarounds should have a way to disable them.

Which of the two is it?

Linus




I don't know Linus, but there is more to this than just an x86 flubb up. I'm still thinking its code in parts with firmware, and when a certain combination of hardware is assembled and connected to the internet the rest of it invades the machine. More offline installation experiments need to confirm this.

 

[stdragon]

It's not just Intel x86. Spectre effects some ARM and Apple A series CPUs. The flaw isn't a bug, rather a fundamental philosophical ideology in how to execute instruction that leave the CPU to exploitation. Everything else after the fact is a scramble to patch

 

[homeybaloney]

there is a logic that ties this cpu spectre and meltdown to search engines. there is the search engine adding in engineered results to searches that put the companies ideology first to then let the real search results below, sometimes way below at the bottom of the search page. the search engine then weeds out the real search results, to craft you clicking on an approved link.

the cpu errors called meltdown and spectre are an idea that the real search results arent being tuned to let only approved links in. then the user can click unapproved links and use the computer in an un-managed state as they please, for things like bit torrent or tor, or vpn, things that are hard to snoop on. so they need to fix the cpu so eventually all things the user does online is approved for them.

 

[audiospecaccts]

It's not just Intel x86. Spectre effects some ARM and Apple A series CPUs. The flaw isn't a bug, rather a fundamental philosophical ideology in how to execute instruction that leave the CPU to exploitation. Everything else after the fact is a scramble to patch

Is this during, or after the program is over.
If its after, then I guess the compilers need to check for the equivalent of the memory reset that's done on 8bit cpu/eprom systems. In that example, when an eprom, say in a amusement game, ends the game, the game over signal pin (on the eprom) triggers a reset logic that is sent to a watchdog and clears memory and resets the program for the next player.

 

[audiospecaccts]

there is a logic that ties this cpu spectre and meltdown to search engines. there is the search engine adding in engineered results to searches that put the companies ideology first to then let the real search results below, sometimes way below at the bottom of the search page. the search engine then weeds out the real search results, to craft you clicking on an approved link.

the cpu errors called meltdown and spectre are an idea that the real search results arent being tuned to let only approved links in. then the user can click unapproved links and use the computer in an un-managed state as they please, for things like bit torrent or tor, or vpn, things that are hard to snoop on. so they need to fix the cpu so eventually all things the user does online is approved for them.

Strange analogy, But is it internet related?

Sometimes I step back and think of all the "features" that are added to processor's core, and how a person could exploit them. Say that for instance, a Hard drive controller driver that was always loaded was altered to perform iSCSI connection so that a logic bus is tied to a remote server and other compromised computers to form a type of parallel processing network. Since every machine has its own encryption, each computer would not respond to the data that is looped through in the round robin sync but there own. Of course, the hacker would program such driver to send them the key for each machine so that they can review the encrypted data from the victim's machine. This, I'm afraid is quite doable, even to the point of making a second encrypted layer on the HDD and hosting a site or a service illegally. Reason why I say illegal, is that they would be stealing the internet service from the victim (theft of utility). There is something about mac addresses that ties into this somehow in the above example.
Edit:
Stepping back a little to what you were saying about search engines. Let's say this hacker(s) spread pieces of its code across several pages where the victim goes to. Say shopping results on a search engine. when the victim clicks on any link it triggers a side code (that the browser escapes it in the gui, but executes in the background ) to execute. Sites that perform updates would be a highly suspicious victim, as an unaddressed XML security flaw allows unknowns web storage access.

Of course this is "hypothetical" , but possible.

 

[stdragon]

It's not just Intel x86. Spectre effects some ARM and Apple A series CPUs. The flaw isn't a bug, rather a fundamental philosophical ideology in how to execute instruction that leave the CPU to exploitation. Everything else after the fact is a scramble to patch

Is this during, or after the program is over.
If its after, then I guess the compilers need to check for the equivalent of the memory reset that's done on 8bit cpu/eprom systems. In that example, when an eprom, say in a amusement game, ends the game, the game over signal pin (on the eprom) triggers a reset logic that is sent to a watchdog and clears memory and resets the program for the next player.

The common denominator among all three different CPUs is that they employs some variant of speculative execution; which is used to enhance the efficiency of fetching new instructions and sharing them between threads (HT) or cores. That information in CPU cache can be snooped via the exploits to ostensibly gain access to the RAM (if you know where to look). This is why the big freakout. Because, prior to the patches, you could be running this exploit on a VM to snoop in on what's in RAM being address by a completely different VM on the same host!

At least with Meltdown (which was Intel specific), the fix was to dump what was in cache whenever there was a call between a user application and the kernel. So long as operations remained in user-land, no performance hit would occur. Ditto for the kernel. But once the boundary is crossed, the cache would be dumped. Where this specifically would occur in file system and database access. To access the disk means the user-land application must make a call to the kernel to get to the file system. As such over a 20% performance hit in IOPS would occur as the cache must be dumped at each transaction through the boundary / membrane.

 

[audiospecaccts]

It goes back to the idea that they should get rid of those "virtualization features" for the common consumer as well as the Mac address inside they deployed.
It could cause direct injection via a XML request from the internet possible especially if they get something like webRTC in the mix.

 

[stdragon]

It goes back to the idea that they should get rid of those "virtualization features" for the common consumer

Oh, no, you have to go much farther such as disabling Hyper-Threading all together (in BIOS). That's what's being suggested by Theo de Raadt for OpenBSD; and that man is the go-to person to reference computer security.

As for the Mac address (NIC?), that has nothing to do with Spectre and Meltdown.

As for web exploitation, Spectre has been mitigated on all the major browsers against JavaScript. Specifically in regards to Firefox since 52

"Since this new class of attacks involves measuring precise time intervals, as a partial, short-term, mitigation we are disabling or reducing the precision of several time sources in Firefox. The precision of performance.now() has been reduced from 5μs to 20μs, and the SharedArrayBuffer feature has been disabled because it can be used to construct a high-resolution timer"

 

[audiospecaccts]

It goes back to the idea that they should get rid of those "virtualization features" for the common consumer

Oh, no, you have to go much farther such as disabling Hyper-Threading all together (in BIOS). That's what's being suggested by Theo de Raadt for OpenBSD; and that man is the go-to person to reference computer security.

As for the Mac address (NIC?), that has nothing to do with Spectre and Meltdown.

As for web exploitation, Spectre has been mitigated on all the major browsers against JavaScript. Specifically in regards to Firefox since 52

"Since this new class of attacks involves measuring precise time intervals, as a partial, short-term, mitigation we are disabling or reducing the precision of several time sources in Firefox. The precision of performance.now() has been reduced from 5μs to 20μs, and the SharedArrayBuffer feature has been disabled because it can be used to construct a high-resolution timer"

The only machine I have hyper threading turned on is a music computer that never gets connected to the internet.
The mac address would be a new possible attack vector because its 1/2 of the info needed to sent direct TCP packets.
I heard that phones are a lot easier to send xml scripts to without knowing the Mac address. Of course, some might alert the consumer of a text message, but when they check their phone, they didn't get any message. Or maybe the screen lights up for a second. It depends I hear.

 

[stdragon]

The mac address would be a new possible attack vector because its 1/2 of the info needed to sent direct TCP packets.
I heard that phones are a lot easier to send xml scripts to without knowing the Mac address. Of course, some might alert the consumer of a text message, but when they check their phone, they didn't get any message. Or maybe the screen lights up for a second. It depends I hear.

FYI - Mac addresses don't cross over different networks; specifically through NAT. The only Mac address that's visible outside your network is between the WAN port Mac address of your router and your ISP. The rest of the world on the internet can't track it. Only your public IP address would be visible, not the client or number of clients behind your private network.

 

[bit_user]

there is a logic that ties this cpu spectre and meltdown to search engines. there is the search engine adding in engineered results to searches that put the companies ideology first to then let the real search results below, sometimes way below at the bottom of the search page. the search engine then weeds out the real search results, to craft you clicking on an approved link.

the cpu errors called meltdown and spectre are an idea that the real search results arent being tuned to let only approved links in. then the user can click unapproved links and use the computer in an un-managed state as they please, for things like bit torrent or tor, or vpn, things that are hard to snoop on. so they need to fix the cpu so eventually all things the user does online is approved for them.

This seems like an obvious troll (especially considering your username), but I hope you don't honestly believe any of that. If so, you need to find a good source of information about technology and start reading.

 

[bit_user]

It's not just Intel x86. Spectre effects some ARM and Apple A series CPUs. The flaw isn't a bug, rather a fundamental philosophical ideology in how to execute instruction that leave the CPU to exploitation. Everything else after the fact is a scramble to patch

Is this during, or after the program is over.

During.

You should really read the wikipedia links I posted above. If it's still not clear, then try to find more explanations about how CPUs work and maybe check the references at the bottom of the wikipedia articles. The exploits are a little difficult to understand, which is how they existing for so long before being uncovered.

 

[bit_user]

It goes back to the idea that they should get rid of those "virtualization features" for the common consumer as well as the Mac address inside they deployed.

Virtualization features in the CPU are not the problem.

The issue with virtualization is that it's supposed to protect one VM from hostile code in another, but these security vulnerabilities prevent that from happening. So, the virtualization features of your CPU do no harm, but they also don't offer quite the level of protection that was advertised.