Chip architecture vulnerability in pretty much everthing

Questions on how we spend our money and our time - consumer goods and services, home and vehicle, leisure and recreational activities
Mudpuppy
Posts: 5889
Joined: Sat Aug 27, 2011 2:26 am
Location: Sunny California

Re: Chip architecture vulnerability in pretty much everthing

Post by Mudpuppy » Fri Jan 05, 2018 10:56 pm

azurekep wrote:
Fri Jan 05, 2018 12:40 pm
Mudpuppy wrote:
Fri Jan 05, 2018 3:29 am
As for the performance hit after applying patches, that has to do with the caches. The primary software fix to keep information from leaking between instructions running with different permissions is to flush the caches before running instructions with a different set of permissions. But you are figuratively throwing the baby out with the bath water. This gets rid of anything in the cache that might be part of an exploit attempt, but it also gets rid of all the cached data that wasn't part of the exploit. Now your memory loads will take longer as the cache is repopulated for the new set of instructions. If you don't switch often between instructions with different permissions, you won't see much of a slow down. But the more you switch, the slower the memory operations will be as the cache gets reloaded over and over again.
Nice explanation. The above excerpt gets to a question I raised earlier. Intel is apparently disputing the degree of slowdown that will come from the patches and says it is dependent on the type of program. From what I understand of your explanation, it would seem to be programs that heavily use the cache. What programs would heavily use the cache? Browsers? Text editors? Tax programs? MP3 tag editing? Photoshop?

We will all be forced to apply patches to internet-facing computers, whether we want to or not, but it would be useful to have some idea of the degree of performance hit we may experience, especially from workhorse tasks like web browsing. It may force people on slow broadband connections, for instance, to upgrade to faster connections to compensate for the slowed processor/cache-related performance.
The patch will have a bigger impact on memory-intensive programs that switch frequently between different privilege levels. Unfortunately, switching between privilege levels is very common, particularly through something called a "system call" or "syscall" for short. Many common tasks like reading and writing a disk, accessing the network, reading key presses from the keyboard, and so on are done through syscalls.

It will not be remedied by getting a faster Internet connection, as the bottleneck is the computer itself, not the Internet connection. And "faster" is actually a misnomer for Internet connections. You get more throughput (more bits per second) with a higher connection, but each bit still transmits at the same speed. An analogy would be to compare a 6-lane road with a 55mph speed limit to a 2-lane road with a 55mph speed limit. Both have the same speed limit, but the bigger road can handle more cars simultaneously. Putting more proverbial cars on the proverbial road won't compensate for this particular patch.

Mudpuppy
Posts: 5889
Joined: Sat Aug 27, 2011 2:26 am
Location: Sunny California

Re: Chip architecture vulnerability in pretty much everthing

Post by Mudpuppy » Fri Jan 05, 2018 11:43 pm

azurekep wrote:
Fri Jan 05, 2018 12:44 pm
If javascript is disabled, what next could the attackers use to access the cache? This is primarily a rhetorical question because those of use who routinely turn off javascript, must turn it back on to access most financial sites. But it's good to understand how this all works.
FactualFran wrote:
Fri Jan 05, 2018 6:36 pm
From what has been posted here, it appears that the hardware is allowing a process to access an address outside the address space of the process if the data at that address is in cache as a result of speculative execution. If the data were not in cache or were in cache due to non-speculative execution, then the hardware would detect the access violation. That leaves the question of how the address outside of the address space of the process is being mapped to data that is in cache as a result of speculative execution.
I'll answer both of these at once as the answer is the same. The basic attack works on any code that has access to a large array of data. Here's the dirty little secret of programming: array boundaries mean nothing to the pipeline and many common languages leave it entirely up to the programmer to make sure their code only accesses the data inside their arrays.

Let's say you have an array of 10 numbers. You can write a program in several programming languages to access the non-existent 1000th number and the compiler will happily go "okay!" and generate the instructions to do that. And those instructions will try to access whatever is 1000 numbers away from the start of the array in main memory, whether that belongs to your program or not.

Now let's say you're a good programmer who always checks your boundaries before accessing the array. Then you'll have something like "if requested data item is a valid index, access that item in the array". That's a branch and calculating if the index for the requested item is a valid index is one of those instructions that might still be calculating in the pipeline when you reach the if-statement. So if the branch predictor guesses "index is valid, go ahead and fetch that data item" when it turns out the index is actually not valid, then that piece of data can be fetched into the cache.

Here's the other dirty little secret: the hardware doesn't really have the concept of users. It only has the concept of privilege levels (called the "rings"). So the hardware doesn't care if the memory belongs to Mary, Bob, or Tom. If they're all at the same ring, the read will go through without a hardware error. One of the Intel bugs is more severe because it allows the exploit to access other rings, which means a normal user can access privileged memory that is supposed to only be accessed by the operating system.

Mudpuppy
Posts: 5889
Joined: Sat Aug 27, 2011 2:26 am
Location: Sunny California

Re: Chip architecture vulnerability in pretty much everthing

Post by Mudpuppy » Fri Jan 05, 2018 11:52 pm

wrongfunds wrote:
Fri Jan 05, 2018 1:35 pm
One of the principle behind "good" guys finding this type of issues and reporting this privately to the "powers to be" is that the vulnerability is publicly disclosed only after the patch has been in place for a while. From reading the current news, it seems as if the patches have not been yet widely available.

I expect scramble when bad guys find something like this exploit it first but I would have expected Intel/MS/LinuxKernel on top of this. May be I am wearing rose colored glasses.
It was kept under wraps for at least half a year while fixes were made. Google security researchers knew about this at least as far back as summer and alerted the processor manufacturers to it. The powers that be were on top of this and the claim is that the original timeline for the public announcement of these vulnerabilities was mid-January, so this was very close to being disclosed through the normal coordinated disclosure mechanism.

However, from what I've read, someone at AMD "done-goofed" and put too much information into the comments for a patch to the Linux kernel in late December. Security researchers had seen the patch activity in the Linux kernel, as it is open-source. So they knew something big was brewing just by the nature of the patches coming into the code repository. But the article I read said that this particular comment gave just enough information for outsiders to figure out what was going on.

azurekep
Posts: 1179
Joined: Tue Jun 16, 2015 7:16 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by azurekep » Fri Jan 05, 2018 11:53 pm

Mudpuppy wrote:
Fri Jan 05, 2018 10:56 pm
The patch will have a bigger impact on memory-intensive programs that switch frequently between different privilege levels. Unfortunately, switching between privilege levels is very common, particularly through something called a "system call" or "syscall" for short. Many common tasks like reading and writing a disk, accessing the network, reading key presses from the keyboard, and so on are done through syscalls.
Browsers do offer the ability to configure the browser disk and/or memory cache. I have always disabled the disk cache, but for Firefox-based browsers, the memory cache seems to be enabled by default. Would playing with these settings minimize the need for the browser itself to access the processor caches?
It will not be remedied by getting a faster Internet connection, as the bottleneck is the computer itself, not the Internet connection.
I agree in principle except when there are two bottlenecks...the internet connection and the processor. At some point, the combination of low broadband speeds and slow processor speeds, perhaps combined with limited RAM, and performance hits a wall. I'd think there would be at least a perception of increased speed if the broadband component could be increased enough. This assumes the primary use of the computer is for web-related activities.
And "faster" is actually a misnomer for Internet connections. You get more throughput (more bits per second) with a higher connection, but each bit still transmits at the same speed. An analogy would be to compare a 6-lane road with a 55mph speed limit to a 2-lane road with a 55mph speed limit. Both have the same speed limit, but the bigger road can handle more cars simultaneously. Putting more proverbial cars on the proverbial road won't compensate for this particular patch.
I see what you're saying, but I still have to think there's more to it than that. For example, when I changed from a 3 Gbps d/l speed to 1.5 Gbps, I noticed a big difference. I don't think it was psychological, though I realize the mind can play tricks.

Edit: Sorry, that should read: "For example, when I changed from a 3 Mbps d/l speed to 1.5 Mbps, I noticed a big difference."
Last edited by azurekep on Sat Jan 06, 2018 12:32 am, edited 1 time in total.

Mudpuppy
Posts: 5889
Joined: Sat Aug 27, 2011 2:26 am
Location: Sunny California

Re: Chip architecture vulnerability in pretty much everthing

Post by Mudpuppy » Fri Jan 05, 2018 11:57 pm

FactualFran wrote:
Fri Jan 05, 2018 3:57 pm
Epsilon Delta wrote:
Fri Jan 05, 2018 3:23 pm
No it's not a software issue. The problem is that software (malware) can read data that is not in the processes memory map.
Is there a URL that describes that in detail? If the hardware is allowing a process to access memory outside of the address space of the process, then the problem does not depend on speculative instruction execution.
Here is the Google Project Zero page on the topic: https://googleprojectzero.blogspot.co.u ... e.html?m=1. Warning: It is highly technical.

Mudpuppy
Posts: 5889
Joined: Sat Aug 27, 2011 2:26 am
Location: Sunny California

Re: Chip architecture vulnerability in pretty much everthing

Post by Mudpuppy » Sat Jan 06, 2018 12:05 am

azurekep wrote:
Fri Jan 05, 2018 11:53 pm
Mudpuppy wrote:
Fri Jan 05, 2018 10:56 pm
The patch will have a bigger impact on memory-intensive programs that switch frequently between different privilege levels. Unfortunately, switching between privilege levels is very common, particularly through something called a "system call" or "syscall" for short. Many common tasks like reading and writing a disk, accessing the network, reading key presses from the keyboard, and so on are done through syscalls.
Browsers do offer the ability to configure the browser disk and/or memory cache. I have always disabled the disk cache, but for Firefox-based browsers, the memory cache seems to be enabled by default. Would playing with these settings minimize the need for the browser itself to access the processor caches?
It's the same term, but the browser memory cache has to do with storing a copy of the web page you fetched off the Internet so you don't have to wait to fetch it over the Internet again if you access it while it is still cached. It might help a little bit, but not a ton. You wouldn't need to make a syscall to fetch the page over the Internet again which means you won't switch between user-mode and kernel-mode, so you won't flush the processor caches, but you'd still be using the processor caches.

User avatar
Epsilon Delta
Posts: 7430
Joined: Thu Apr 28, 2011 7:00 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by Epsilon Delta » Sat Jan 06, 2018 12:06 am

MindBogler wrote:
Fri Jan 05, 2018 7:35 pm
Mudpuppy wrote:
Fri Jan 05, 2018 11:43 am
Without a fundamental redesign from the bottom-up with security as the primary motivation, it's just going to keep happening.
The problem is that many of these exploits only seem obvious in hindsight. You could have a whole team of engineers building something with security in mind and they'd still miss potential attack vectors.
Misquoting Hoare: That depends on whether the engineers aim for a system that is so simple it obviously has no attack vectors or so complex that it has no obvious attack vectors.

Sure they'll make mistakes either way, but the difference in the number and severity of the mistakes will be enormous.

User avatar
MP123
Posts: 772
Joined: Thu Feb 16, 2017 3:32 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by MP123 » Sat Jan 06, 2018 12:09 am

Mudpuppy wrote:
Fri Jan 05, 2018 11:43 pm
azurekep wrote:
Fri Jan 05, 2018 12:44 pm
If javascript is disabled, what next could the attackers use to access the cache? This is primarily a rhetorical question because those of use who routinely turn off javascript, must turn it back on to access most financial sites. But it's good to understand how this all works.
FactualFran wrote:
Fri Jan 05, 2018 6:36 pm
From what has been posted here, it appears that the hardware is allowing a process to access an address outside the address space of the process if the data at that address is in cache as a result of speculative execution. If the data were not in cache or were in cache due to non-speculative execution, then the hardware would detect the access violation. That leaves the question of how the address outside of the address space of the process is being mapped to data that is in cache as a result of speculative execution.
I'll answer both of these at once as the answer is the same. The basic attack works on any code that has access to a large array of data. Here's the dirty little secret of programming: array boundaries mean nothing to the pipeline and many common languages leave it entirely up to the programmer to make sure their code only accesses the data inside their arrays.

Let's say you have an array of 10 numbers. You can write a program in several programming languages to access the non-existent 1000th number and the compiler will happily go "okay!" and generate the instructions to do that. And those instructions will try to access whatever is 1000 numbers away from the start of the array in main memory, whether that belongs to your program or not.

Now let's say you're a good programmer who always checks your boundaries before accessing the array. Then you'll have something like "if requested data item is a valid index, access that item in the array". That's a branch and calculating if the index for the requested item is a valid index is one of those instructions that might still be calculating in the pipeline when you reach the if-statement. So if the branch predictor guesses "index is valid, go ahead and fetch that data item" when it turns out the index is actually not valid, then that piece of data can be fetched into the cache.

Here's the other dirty little secret: the hardware doesn't really have the concept of users. It only has the concept of privilege levels (called the "rings"). So the hardware doesn't care if the memory belongs to Mary, Bob, or Tom. If they're all at the same ring, the read will go through without a hardware error. One of the Intel bugs is more severe because it allows the exploit to access other rings, which means a normal user can access privileged memory that is supposed to only be accessed by the operating system.
That's one of the clearest explanations of meltdown I've read (as an old programmer) thanks!

MindBogler
Posts: 667
Joined: Wed Apr 17, 2013 12:05 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by MindBogler » Sat Jan 06, 2018 12:35 am

Epsilon Delta wrote:
Sat Jan 06, 2018 12:06 am
Misquoting Hoare: That depends on whether the engineers aim for a system that is so simple it obviously has no attack vectors or so complex that it has no obvious attack vectors.

Sure they'll make mistakes either way, but the difference in the number and severity of the mistakes will be enormous.
Few systems designed today are so simple that they could be classified as the former and the reason so many attack vectors exist is due to the latter.

Mudpuppy
Posts: 5889
Joined: Sat Aug 27, 2011 2:26 am
Location: Sunny California

Re: Chip architecture vulnerability in pretty much everthing

Post by Mudpuppy » Sat Jan 06, 2018 1:37 am

MindBogler wrote:
Fri Jan 05, 2018 7:35 pm
Mudpuppy wrote:
Fri Jan 05, 2018 11:43 am
Without a fundamental redesign from the bottom-up with security as the primary motivation, it's just going to keep happening.
The problem is that many of these exploits only seem obvious in hindsight. You could have a whole team of engineers building something with security in mind and they'd still miss potential attack vectors.
Perhaps, but if your entire design mindset is to be fast while still ensuring data integrity, you're going to have blinders on to issues that affect data confidentiality. Just look at the way Intel's press release earlier this week was written (https://newsroom.intel.com/news/intel-r ... -findings/):
Intel and other technology companies have been made aware of new security research describing software analysis methods that, when used for malicious purposes, have the potential to improperly gather sensitive data from computing devices that are operating as designed. Intel believes these exploits do not have the potential to corrupt, modify or delete data.
Note that they emphasize that data integrity (corruption, modification, or deletion) was not affected in the last sentence. They also had many qualifiers on the first sentence describing the data confidentiality issue, but almost no qualifiers on the last sentence describing the data integrity issue.

If one designed from a security mindset, both integrity and confidentiality would be important. Speed would also be important as that affects availability, but one would not sacrifice confidentiality for the sake of speed.

wrongfunds
Posts: 1875
Joined: Tue Dec 21, 2010 3:55 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by wrongfunds » Sat Jan 06, 2018 9:29 am

I suspect browser speed is not critically dependent upon the speed of the processor. In computer terms when I mean fast, the human interaction time is laughably slow in terms of compute speed. Besides, all of the heavy lifting is done NOT at browser but at the cloud. Certainly, the effective data transfer speed (not just the bit rate but the back and forth transaction latency) determines whether you feel if your browser is "fast" or not.

TLDR; Loss of 30% CPU speed is not going to be experienced by you as a browser user.

MindBogler
Posts: 667
Joined: Wed Apr 17, 2013 12:05 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by MindBogler » Sat Jan 06, 2018 11:15 am

Mudpuppy wrote:
Sat Jan 06, 2018 1:37 am
Perhaps, but if your entire design mindset is to be fast while still ensuring data integrity, you're going to have blinders on to issues that affect data confidentiality.
Look, I don't disagree with you completely but I stand on the point that there will always be exploits. No amount of human engineering has yet been capable of making a system that is impossible to exploit. I mean we've seen exploits of air-gapped nuclear centrifuges with stuxnet! Intel is riding a wave of prominent security failures between the vPro, management engines and now this. I think Intel has been careless for years and it is because they have no real competition. Twenty years ago we had AMD, Cyrix and a few other bit players in the x86 processor market. Beyond Intel's incompetence I have more serious questions as to how herds of programmers working on various operating systems from Unix and Linux to Windows managed to overlook and/or fail to publicly exploit this possibility for 20 years.

btenny
Posts: 4554
Joined: Sun Oct 07, 2007 6:47 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by btenny » Sat Jan 06, 2018 11:39 am

How do we know that these vulnerabilities have NOT been exploited already????? If some hacker has used this before I am pretty sure he/she is not telling anyone......

FactualFran
Posts: 741
Joined: Sat Feb 21, 2015 2:29 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by FactualFran » Sat Jan 06, 2018 1:52 pm

Thanks to Mudpuppy and others for trying to providing additional details I wanted. The details that I was interested in were addressed by the following sentence from https://arstechnica.com/gadgets/2018/01 ... s-patches/
Intel processors, specifically—though not AMD ones—allow speculative execution of ring 3 code that writes to ring 0 memory.
Essentially, that answered a question I asked in a previous post: "Is such a mode change is being allowed during speculative execution?" The processor goes through some of the motions of doing a write to kernel [ring 0] memory before detecting that the process doing the write has read-only access to that memory address. The fact that those motions were gone through is detectable by another process.

Mudpuppy
Posts: 5889
Joined: Sat Aug 27, 2011 2:26 am
Location: Sunny California

Re: Chip architecture vulnerability in pretty much everthing

Post by Mudpuppy » Sat Jan 06, 2018 2:04 pm

MindBogler wrote:
Sat Jan 06, 2018 11:15 am
Look, I don't disagree with you completely but I stand on the point that there will always be exploits. No amount of human engineering has yet been capable of making a system that is impossible to exploit.
If you review my post history, you'll see that I quite frequently have said it is impossible to have perfect security because humans are not perfect. So I think we agree on this point, but have different outlooks on the ability to take a more secure default posture in computer architecture design.
MindBogler wrote:
Sat Jan 06, 2018 11:15 am
Beyond Intel's incompetence I have more serious questions as to how herds of programmers working on various operating systems from Unix and Linux to Windows managed to overlook and/or fail to publicly exploit this possibility for 20 years.
The "many eyes" principle only works when (a) those eyes are actually looking and (b) those eyes have the appropriate skills to know what they are looking for. With respects to (a), the bystander effect often comes into play. People assume that because so many others have the ability to look at what is going on, there must be others looking at it, so they don't take the time to personally look into it. With respects to (b), as I already stated up-thread, there are very few programmers who possess the hardware-level knowledge necessary to even begin to understand the consequences of this particular pipeline side effect.

I suspect that there will be a lot of graduate schools adding a hardware-level security track over the next couple of years, so at least (b) will start to reverse over time as more young computer scientists are trained in that area. It's just like how network security was relatively new and popular when I went to graduate school. The bystander effect of (a) really is the more pressing issue, as it's a fundamental human psychology issue. That makes it a much tougher issue to overcome.

Edit: Added a section.

Mudpuppy
Posts: 5889
Joined: Sat Aug 27, 2011 2:26 am
Location: Sunny California

Re: Chip architecture vulnerability in pretty much everthing

Post by Mudpuppy » Sat Jan 06, 2018 2:11 pm

btenny wrote:
Sat Jan 06, 2018 11:39 am
How do we know that these vulnerabilities have NOT been exploited already????? If some hacker has used this before I am pretty sure he/she is not telling anyone......
There has been no malware discovered in the wild that takes advantage of these vulnerabilities, which means if any malware does exist, it is very subtle. The most probable source for a subtle attack would be the government cyberintelligence agencies of various countries, and of course they won't be talking if they were using this. Hackers targeting organizations for criminal purposes (such as advanced persistent threats) tend to be a little less subtle in their approach, which is why their malware is often discovered, even if it takes the victim a year or more to realize they've been attacked and bring in the experts who can find the malware.

azurekep
Posts: 1179
Joined: Tue Jun 16, 2015 7:16 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by azurekep » Sat Jan 06, 2018 2:13 pm

wrongfunds wrote:
Sat Jan 06, 2018 9:29 am
I suspect browser speed is not critically dependent upon the speed of the processor. In computer terms when I mean fast, the human interaction time is laughably slow in terms of compute speed. Besides, all of the heavy lifting is done NOT at browser but at the cloud. Certainly, the effective data transfer speed (not just the bit rate but the back and forth transaction latency) determines whether you feel if your browser is "fast" or not.

TLDR; Loss of 30% CPU speed is not going to be experienced by you as a browser user.
Thanks. Good to know.

MindBogler
Posts: 667
Joined: Wed Apr 17, 2013 12:05 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by MindBogler » Sat Jan 06, 2018 3:35 pm

Mudpuppy wrote:
Sat Jan 06, 2018 2:04 pm
If you review my post history, you'll see that I quite frequently have said it is impossible to have perfect security because humans are not perfect. So I think we agree on this point, but have different outlooks on the ability to take a more secure default posture in computer architecture design.
I think designing for security is a worthy goal and should be pursued. However, I think we have two different perspectives on the capacity or desire of humans to design secure systems. If you've interpreted my comments to mean "pursuing secure design is worthless" then you have not understood my intent. I'm pro-security, I champion it, possibly to my own detriment, in professional settings on a frequent basis. But that is why I am cynical that there are any easy answers to these kind of problems. There will always be barriers to security: time, money and ignorance of chains of consequence that might occur from various design decisions. Often it isn't as simple as if A then B is insecure, it is if A then B -> Q are OK but now Z is secure except when R is null. Sometimes even the best laid plans are vulnerable to attacks that few would consider. In the end security is the harder path and humans tend towards the expedient.

Businesses want to fail fast. Teams develop using agile methodologies. The business forces pushing out minimum viable content and letting the consumer beta test while getting paid for it. Iterate your way to success. The problem is that most of these teams each developer or engineer only understands small components of their system -- the pieces they are working on. They aren't always considering how the components interact or how their decisions might affect the assumptions of other developers or engineers. Forcing secure decisions in large teams will require a groundswell change in how products are currently being developed. This isn't strictly my opinion. I'm just one engineer in a sea (of electrons). Talk to some software or hardware engineers at any major company and you'll hear these same themes repeated.

User avatar
Epsilon Delta
Posts: 7430
Joined: Thu Apr 28, 2011 7:00 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by Epsilon Delta » Sat Jan 06, 2018 3:46 pm

Mudpuppy wrote:
Sat Jan 06, 2018 2:04 pm
MindBogler wrote:
Sat Jan 06, 2018 11:15 am
Beyond Intel's incompetence I have more serious questions as to how herds of programmers working on various operating systems from Unix and Linux to Windows managed to overlook and/or fail to publicly exploit this possibility for 20 years.
The "many eyes" principle only works when (a) those eyes are actually looking and (b) those eyes have the appropriate skills to know what they are looking for. With respects to (a), the bystander effect often comes into play. People assume that because so many others have the ability to look at what is going on, there must be others looking at it, so they don't take the time to personally look into it. With respects to (b), as I already stated up-thread, there are very few programmers who possess the hardware-level knowledge necessary to even begin to understand the consequences of this particular pipeline side effect.
I think the bigger issue is the shear number of security holes. Any particular bug is unlikely to be discovered when the detection rate is much less than the number waiting to be found. When there are more holes than eyes you don't have many eyes. We'd need to increase the number of eyes by quite a few orders of magnitude before we'd have many eyes

Looking for and patching bug has little effect on the number of bugs. Patching known bugs is still important because it makes the bad guys work to find new ones, and there are far more people who can exploit known issues than find new ones.

MindBogler
Posts: 667
Joined: Wed Apr 17, 2013 12:05 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by MindBogler » Sat Jan 06, 2018 3:55 pm

Epsilon Delta wrote:
Sat Jan 06, 2018 3:46 pm
I think the bigger issue is the shear number of security holes. Any particular bug is unlikely to be discovered when the detection rate is much less than the number waiting to be found. When there are more holes than eyes you don't have many eyes. We'd need to increase the number of eyes by quite a few orders of magnitude before we'd have many eyes

Looking for and patching bug has little effect on the number of bugs. Patching known bugs is still important because it makes the bad guys work to find new ones, and there are far more people who can exploit known issues than find new ones.
Absolutely agreed. Anyone who can read and follow directions can download Kali Linux to cause serious damage against systems unpatched for known vulnerabilities. :beer

Finding new vulnerabilities often takes deep knowledge of systems, hardware, software or some combination of the three! Some very talented individuals are on the forefront of finding these things.

Mudpuppy
Posts: 5889
Joined: Sat Aug 27, 2011 2:26 am
Location: Sunny California

Re: Chip architecture vulnerability in pretty much everthing

Post by Mudpuppy » Sat Jan 06, 2018 3:59 pm

MindBogler wrote:
Sat Jan 06, 2018 3:35 pm
Businesses want to fail fast. Teams develop using agile methodologies. The business forces pushing out minimum viable content and letting the consumer beta test while getting paid for it. Iterate your way to success. The problem is that most of these teams each developer or engineer only understands small components of their system -- the pieces they are working on. They aren't always considering how the components interact or how their decisions might affect the assumptions of other developers or engineers. Forcing secure decisions in large teams will require a groundswell change in how products are currently being developed. This isn't strictly my opinion. I'm just one engineer in a sea (of electrons). Talk to some software or hardware engineers at any major company and you'll hear these same themes repeated.
But that was my point: the current business model is insufficient for handling the security needs of technology and it will remain that way until there is either a major flaw with wide-ranging consequences and/or a major cultural shift. We're just putting bandaid solutions on fundamental underlying issues and until the culture changes away from "fast fast fast" to a more security-centric mindset, major security flaws are just going to keep coming. If we're unlucky, one of those flaws will have wide-ranging consequences, the least of which would be wide-ranging economic consequences and the worst of which will be wide-ranging disasters (e.g. attacks on critical SCADA systems). We're like children playing with a loaded gun at the moment in technology and the development culture just accepts it as normal.

While I wouldn't expect all software companies to take the development model NASA used for the space shuttle program (https://www.fastcompany.com/28121/they- ... ight-stuff), it would be feasible for Intel, AMD, and other major hardware providers to adopt some of those practices in their processor and chipset designs. The practice of having an in-house verification team that is looking for security issues and otherwise trying to "break" the design (in order to make it better) would have a large impact. Of course, until there is an economic incentive to invest in new development practices or a large economic consequence to their current practices, they probably will not spend the money to adopt such practices. That is why my pessimistic side says this is all just a disaster waiting to happen.

MindBogler
Posts: 667
Joined: Wed Apr 17, 2013 12:05 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by MindBogler » Sat Jan 06, 2018 4:10 pm

Mudpuppy wrote:
Sat Jan 06, 2018 3:59 pm
That is why my pessimistic side says this is all just a disaster waiting to happen.
This much is certain. Barring some major financial disincentive, e.g. a company folds as a result, things are unlikely to change. Look at the Experian breach for example. This was a catastrophe. And yet, the company is still in business and so I'd be surprised if any fundamental, long term change occurs within the organization. I've seen breaches occur and the reaction of the business is usually to plug the hole and do damage control. Hire some outside auditors and produce a report to provide to the board. Then a few changes are made for appearances of "doing something" while business as usual continues.

User avatar
Epsilon Delta
Posts: 7430
Joined: Thu Apr 28, 2011 7:00 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by Epsilon Delta » Sat Jan 06, 2018 4:51 pm

MindBogler wrote:
Sat Jan 06, 2018 3:55 pm
Finding new vulnerabilities often takes deep knowledge of systems, hardware, software or some combination of the three! Some very talented individuals are on the forefront of finding these things.
In practice it's a complete waste of talent, except to the extent it trains people how to not create bugs. Finding and fixing previously unknown bugs does not significantly reduce the number of unknown bugs and it does not make it harder to discover an unknown bug.
Mudpuppy wrote:
Sat Jan 06, 2018 3:59 pm
While I wouldn't expect all software companies to take the development model NASA used for the space shuttle program (https://www.fastcompany.com/28121/they- ... ight-stuff)
While a lot of that is good and better than a lot of other places I'm not sure NASA is as good as they say. If there is a software bug that blows up a Space shuttle main engine every 10,000 hours of operation we would probably never hear about it. Where as if some of my software failed fatally every 10,000 hours of operation there would be a hecatomb, although with fewer visuals. Certainly the claim of software quality is a claim that the software engineers are better than the o-ring engineers. And at least in principle the mechanical engineers follow much the same procedures.
Mudpuppy wrote:
Sat Jan 06, 2018 3:59 pm
The practice of having an in-house verification team that is looking for security issues and otherwise trying to "break" the design (in order to make it better) would have a large impact.
I don't think this works any better than having external teams break the design. The better way is to make the designer explain why it can't fail, when he can't send him back to add simplicity until he can.

wrongfunds
Posts: 1875
Joined: Tue Dec 21, 2010 3:55 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by wrongfunds » Sat Jan 06, 2018 5:29 pm

Intel says, "Dont worry, be happy!"
"The statistical analysis of these behaviors can in some cases be used to potentially expose sensitive data on computer systems that are operating as designed. These exploits do not have the potential to corrupt, modify or delete data."
Notice the words "operating as designed", "does not corrupt, modify or delete data" etc. What are you guys worried about??? :-)

Straight from horse's mouth
Is this a bug in Intel hardware or processor design?

No. This is not a bug or a flaw in Intel products. These new exploits leverage data about the proper operation of processing techniques common to modern computing platforms, potentially compromising security even though a system is operating exactly as it is designed to. Based on the analysis to date, many types of computing devices — with many different vendors’ processors and operating systems — are susceptible to these exploits.

wrongfunds
Posts: 1875
Joined: Tue Dec 21, 2010 3:55 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by wrongfunds » Sat Jan 06, 2018 5:54 pm

Question to MudPuppy:-

Given that the exploit uses repeated exceptions to infer the protected data, why not have a patch which clamps down and kills the offending thread when it does "too many" exceptions "too quickly"? Come to think of it, generally one strike and out rule is applied to the exception unless specific exception handling code is written but that part can easily be tweaked in the kernel to prevent using the exceptions for the exploits now that we know the scheme used by bad guys.

This would be exactly like limiting the number of wrong password attempts before locking up an account.

Unless there is a way to exploit this flaw without causing the exception?

patrick
Posts: 1624
Joined: Fri Sep 04, 2009 3:39 am
Location: Mega-City One

Re: Chip architecture vulnerability in pretty much everthing

Post by patrick » Sat Jan 06, 2018 7:09 pm

wrongfunds wrote:
Sat Jan 06, 2018 5:54 pm
Question to MudPuppy:-

Given that the exploit uses repeated exceptions to infer the protected data, why not have a patch which clamps down and kills the offending thread when it does "too many" exceptions "too quickly"? Come to think of it, generally one strike and out rule is applied to the exception unless specific exception handling code is written but that part can easily be tweaked in the kernel to prevent using the exceptions for the exploits now that we know the scheme used by bad guys.

This would be exactly like limiting the number of wrong password attempts before locking up an account.

Unless there is a way to exploit this flaw without causing the exception?
The meltdown paper mentions exploitation by branch misprediction instead of exceptions. In that case the processor would predict that a conditional branch would go one way, speculatively execute in that direction (including reloading a cache line based on the non-readable data), but roll back once it determines that the branch should go the other way.

azurekep
Posts: 1179
Joined: Tue Jun 16, 2015 7:16 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by azurekep » Sat Jan 06, 2018 9:20 pm

The Pale Moon team claims their browser is safe. They're not resting on their laurels, however.

Pale Moon is a fork of Firefox.

What do we know about other browsers?
After confirmation that the "Meltdown" and "Spectre" CPU vulnerabilities could be exploited via the web, we have immediately taken action to investigate impact on Pale Moon and Basilisk. The web-based exploits either need very accurate timing through performance timers or a way to construct their own very accurate timers using shared buffer memory between threads in JavaScript.

Pale Moon isn't vulnerable

Pale Moon already set the granularity for the performance timers sufficiently coarse in Oct 2016 when it became clear that this could be used to perform hardware-timing based attacks and fingerprinting.

Pale Moon also, by design, doesn't allow buffer memory to be shared between threads in JavaScript, so the "SharedArrayBuffer" attack is not possible.

Even so, we will be adding some additional defense-in-depth changes to the upcoming version 27.7 to be absolutely sure there is no further room for any of these sorts of hardware-timing based attacks in the future

https://forum.palemoon.org/viewtopic.php?f=1&t=17928

Mudpuppy
Posts: 5889
Joined: Sat Aug 27, 2011 2:26 am
Location: Sunny California

Re: Chip architecture vulnerability in pretty much everthing

Post by Mudpuppy » Sat Jan 06, 2018 9:31 pm

wrongfunds wrote:
Sat Jan 06, 2018 5:29 pm
Intel says, "Dont worry, be happy!"
"The statistical analysis of these behaviors can in some cases be used to potentially expose sensitive data on computer systems that are operating as designed. These exploits do not have the potential to corrupt, modify or delete data."
Notice the words "operating as designed", "does not corrupt, modify or delete data" etc. What are you guys worried about??? :-)

Straight from horse's mouth
Is this a bug in Intel hardware or processor design?

No. This is not a bug or a flaw in Intel products. These new exploits leverage data about the proper operation of processing techniques common to modern computing platforms, potentially compromising security even though a system is operating exactly as it is designed to. Based on the analysis to date, many types of computing devices — with many different vendors’ processors and operating systems — are susceptible to these exploits.
Don't fall for the Intel PR attempt to sweep this under the rug. Meltdown, which allows the user-mode ring to read data in the kernel-mode ring, has only been successfully run against Intel processors. AMD quite rightly stops those types of speculative execution paths before they affect the cache, since they see that the operations are attempting to access data outside of their current ring. Intel didn't take that precaution because it would cause a slight slowdown in the pipeline during such branches.

PFInterest
Posts: 2554
Joined: Sun Jan 08, 2017 12:25 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by PFInterest » Sat Jan 06, 2018 9:37 pm

Gray wrote:
Thu Jan 04, 2018 2:27 am
The solution (since this type of thing is an ongoing reality) is defense in depth (layered defensive practices). Firewalls, antivirus, intrusion detection/prevention, common sense, active patching, minimal rights for normal computing use, encrypting data, two factor authentication, and buying from trusted vendors that provide robust after-sale support, etc.

You could also use a ARM-based chromebook with an Amazon hosted workspace as your PC. I’ve been thinking about doing that before this arose so I can access my same PC from every computer, phone, or tablet.

https://docs.aws.amazon.com/workspaces/ ... lient.html
You don't understand this vulnerability.

Mudpuppy
Posts: 5889
Joined: Sat Aug 27, 2011 2:26 am
Location: Sunny California

Re: Chip architecture vulnerability in pretty much everthing

Post by Mudpuppy » Sat Jan 06, 2018 9:42 pm

wrongfunds wrote:
Sat Jan 06, 2018 5:54 pm
Question to MudPuppy:-

Given that the exploit uses repeated exceptions to infer the protected data, why not have a patch which clamps down and kills the offending thread when it does "too many" exceptions "too quickly"? Come to think of it, generally one strike and out rule is applied to the exception unless specific exception handling code is written but that part can easily be tweaked in the kernel to prevent using the exceptions for the exploits now that we know the scheme used by bad guys.

This would be exactly like limiting the number of wrong password attempts before locking up an account.

Unless there is a way to exploit this flaw without causing the exception?
It's not really an exception in the traditional sense of the processor sending an error to the OS. Unwinding an erroneous speculative path is not considered an error that would be reported to the OS. It's just a feature of how branch prediction works (note how Intel's PR wording constantly refers to "operating properly"). Additionally, unwinding speculative paths happens all the time for innocent reasons, so it's also not always a sign of an attack.

It is "easier" for the OS to clear the caches whenever it switches between user-mode and kernel-mode than to deploy the heuristics needed to distinguish between normal pipeline operation and something trying to trigger this bug. The next generation of CPUs will likely clear the caches on their own as part of unwinding the erroneously speculative path. And let's hope Intel takes a page from AMD's book and stops speculation when there's a memory access outside the current instruction's privilege ring.

Mudpuppy
Posts: 5889
Joined: Sat Aug 27, 2011 2:26 am
Location: Sunny California

Re: Chip architecture vulnerability in pretty much everthing

Post by Mudpuppy » Sat Jan 06, 2018 10:04 pm

azurekep wrote:
Sat Jan 06, 2018 9:20 pm
The Pale Moon team claims their browser is safe. They're not resting on their laurels, however.

Pale Moon is a fork of Firefox.

What do we know about other browsers?
It looks like Pale Moon artificially "slows down" timers in JavaScript so that an attacker won't be able to execute a timing-based attack. I'm not sure if they actually slow things down or just apply a large rounding value to the actual results.

Firefox 57.0.4 has been updated to similarly artificially "slow down" JavaScript and to also disable a special shared array between JavaScript threads that is needed to run this particular exploit in JavaScript. This fix has not back-ported to Firefox ESR, as the Mozilla blog says it does not have JavaScript shared array. They do plan to back-port the general timing "slow downs" to Firefox ESR on January 23rd. Here's the Mozilla blog: https://blog.mozilla.org/security/2018/ ... ng-attack/

Chrome will be updated in Chrome 64 in a similar fashion. The update is scheduled for release "on or about" January 23rd. Their page also says it will disable the shared array as of now, before the Chrome 64 update is available. Here is the Chrome page on this attack: https://www.chromium.org/Home/chromium-security/ssca

Microsoft Edge and Internet Explorer 11 also are making similar changes. It looks like only Windows 10 Edge had the shared array, but both Edge and IE will get the timing attack mitigations. Here is Microsoft's page: https://blogs.windows.com/msedgedev/201 ... DKibAxg.97

Opera plans an update at the end of the month. Here is their page: https://blogs.opera.com/security/2018/0 ... abilities/

User avatar
Epsilon Delta
Posts: 7430
Joined: Thu Apr 28, 2011 7:00 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by Epsilon Delta » Sat Jan 06, 2018 10:47 pm

Mudpuppy wrote:
Sat Jan 06, 2018 9:31 pm
Intel didn't take that precaution because it would cause a slight slowdown in the pipeline during such branches.
I don't understand this. The user/supervisor bit is in the TLB and the page tables. Why not just append it to the address and do a 49 bit lookup instead of 48 bits? It needs a custom compare for the permission bit but it should be fully parallelizable with a permission issue giving a fault instead of loading the cache.

User avatar
MP123
Posts: 772
Joined: Thu Feb 16, 2017 3:32 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by MP123 » Sat Jan 06, 2018 11:20 pm

Isn't this vulnerability sort of like Van Eck Phreaking in the sense that it would difficult to exploit outside of a laboratory?

I don't have a complete understanding of it but the timing issues in particular seem like they would present a challenge in real world applications.

wrongfunds
Posts: 1875
Joined: Tue Dec 21, 2010 3:55 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by wrongfunds » Sun Jan 07, 2018 12:00 am

I just read the Meltdown paper completely. Interestingly, the authors of the both papers are the same gang. I am suspecting there were some heavy personality issues which resulted in two papers being printed with two of them taking the 1st slot but I am not in academics; so I don't know if this is how it is supposed to work! I also liked how the novel concept of finding if the processor has "accidentally" filled cache slot filled or not has been dressed up with lots and lots verbiage to have different sections for having a full fledged paper (exactly 16 pages!) worthy of receiving next years Turing Award :-)

Meltdown paper claims to have the accuracy of .02% but do pay close attention to Listing 3 and Listing 4 and notice the number of "XX". There are heck lot more than .02% of them!

Section 6.4 also makes it clear that the toy version successfully leaks the data on ARM and AMD. If the AMD has the ring protection as some of you are claiming, then the toy program would have failed.

User avatar
Epsilon Delta
Posts: 7430
Joined: Thu Apr 28, 2011 7:00 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by Epsilon Delta » Sun Jan 07, 2018 12:14 am

wrongfunds wrote:
Sun Jan 07, 2018 12:00 am
Meltdown paper claims to have the accuracy of .02% but do pay close attention to Listing 3 and Listing 4 and notice the number of "XX". There are heck lot more than .02% of them!
Meltdown cannot positively confirm that a memory location contains zero. Looking at the listings it is entirely plausible that those areas are long strings of zero padding. When they calculate the error rate they know what the values actually are and probably replace all the XX with zero for purposes of looking for errors.

Mudpuppy
Posts: 5889
Joined: Sat Aug 27, 2011 2:26 am
Location: Sunny California

Re: Chip architecture vulnerability in pretty much everthing

Post by Mudpuppy » Sun Jan 07, 2018 3:08 am

MP123 wrote:
Sat Jan 06, 2018 11:20 pm
Isn't this vulnerability sort of like Van Eck Phreaking in the sense that it would difficult to exploit outside of a laboratory?

I don't have a complete understanding of it but the timing issues in particular seem like they would present a challenge in real world applications.
The reason so many browsers are pushing out updates right now is because there is a proof-of-concept using JavaScript. Browsers are disabling a special array that can be shared between threads and obfuscating timers to make an exploit using JavaScript infeasible.

Mudpuppy
Posts: 5889
Joined: Sat Aug 27, 2011 2:26 am
Location: Sunny California

Re: Chip architecture vulnerability in pretty much everthing

Post by Mudpuppy » Sun Jan 07, 2018 3:26 am

wrongfunds wrote:
Sun Jan 07, 2018 12:00 am
Section 6.4 also makes it clear that the toy version successfully leaks the data on ARM and AMD. If the AMD has the ring protection as some of you are claiming, then the toy program would have failed.
The "toy example" they refer to in Section 6.4 of the Meltdown paper is basically a variant of Spectre, which allows one to access other memory locations within one's current ring. That AMD and ARM are susceptible to Spectre is not in dispute. But, as noted quite clearly in Section 6.4, a process running by a user cannot use Meltdown to leak kernel memory on AMD and ARM processors:
We also tried to reproduce the Meltdown bug on several ARM and AMD CPUs. However, we did not manage to successfully leak kernel memory with the attack described in Section 5, neither on ARM nor on AMD.
And as a reminder from my earlier post, processors have no concepts of users. Rings are just privilege levels, primarily used to separate the OS memory ("kernel" memory) from the user memory. All normal users are running in the same ring, so you don't have to leave your ring to access memory that doesn't belong to you, as happens with Spectre.

So AMD does have "ring protection" in that it prevents a user process from using these vulnerabilities to access kernel memory. Kernel memory is in a different ring that the user process, so AMD blocks the access even during speculative execution. Intel on the other hand allows the access.

Mudpuppy
Posts: 5889
Joined: Sat Aug 27, 2011 2:26 am
Location: Sunny California

Re: Chip architecture vulnerability in pretty much everthing

Post by Mudpuppy » Sun Jan 07, 2018 3:41 am

xkcd has a new comic up about Spectre and Meltdown: https://xkcd.com/1938/

wrongfunds
Posts: 1875
Joined: Tue Dec 21, 2010 3:55 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by wrongfunds » Sun Jan 07, 2018 7:46 am

The "toy example" they refer to in Section 6.4 of the Meltdown paper is basically a variant of Spectre, which allows one to access other memory locations within one's current ring. That AMD and ARM are susceptible to Spectre is not in dispute. But, as noted quite clearly in Section 6.4, a process running by a user cannot use Meltdown to leak kernel memory on AMD and ARM processors:
I do not believe that is correct. The listing 1 is using deliberate exception to read the "unauthorized" "data". The "data" used in the listing is the result of the unauthorized access. The toy example does not give exact machine code but the intent is clear to me and it was written specifically to show the meltdown concept itself. If it is not for the fundamental privilege violation, where else would exception come from?

I am willing to concede this if you can show me why I am wrong.

User avatar
Epsilon Delta
Posts: 7430
Joined: Thu Apr 28, 2011 7:00 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by Epsilon Delta » Sun Jan 07, 2018 9:27 am

Mudpuppy wrote:
Sun Jan 07, 2018 3:26 am
But, as noted quite clearly in Section 6.4, a process running by a user cannot use Meltdown to leak kernel memory on AMD and ARM processors:
We also tried to reproduce the Meltdown bug on several ARM and AMD CPUs. However, we did not manage to successfully leak kernel memory with the attack described in Section 5, neither on ARM nor on AMD.
Granted they are smart people but the fact that they could not figure out how to do it doesn't mean it can't be done. Perhaps they just ran out of time or the grad student working on the ARM was less skilled or they just know less about the AMD architecture than Intel so they could not find the right crack to slip through.

wrongfunds
Posts: 1875
Joined: Tue Dec 21, 2010 3:55 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by wrongfunds » Sun Jan 07, 2018 12:46 pm

However, for both ARM and AMD, the toy example as described in Section 3 works reliably, indicating that out-of-order execution generally occurs and instructions past illegal memory accesses are also performed.
Emphasis added; At least this makes it clear that the fundamental problem exist in ARM and AMD but their full fledged program was not able to leverage the flaw.

Mudpuppy
Posts: 5889
Joined: Sat Aug 27, 2011 2:26 am
Location: Sunny California

Re: Chip architecture vulnerability in pretty much everthing

Post by Mudpuppy » Mon Jan 08, 2018 1:24 am

wrongfunds wrote:
Sun Jan 07, 2018 7:46 am
The "toy example" they refer to in Section 6.4 of the Meltdown paper is basically a variant of Spectre, which allows one to access other memory locations within one's current ring. That AMD and ARM are susceptible to Spectre is not in dispute. But, as noted quite clearly in Section 6.4, a process running by a user cannot use Meltdown to leak kernel memory on AMD and ARM processors:
I do not believe that is correct. The listing 1 is using deliberate exception to read the "unauthorized" "data". The "data" used in the listing is the result of the unauthorized access. The toy example does not give exact machine code but the intent is clear to me and it was written specifically to show the meltdown concept itself. If it is not for the fundamental privilege violation, where else would exception come from?

I am willing to concede this if you can show me why I am wrong.
Did you mean Listing 3? Listings 1 and 2 are just code snippets. Also, Listings 3 through 5 are the result of running the code from Section 5 against Intel systems. When section 6.4 referred to the "toy example", it was referring to code from Section 3 (a variant of Spectre). Only code from Section 5 is Meltdown. Getting back to your point about the carefully padded paper length to fit the standard journal page length, the actual meat of the Meltdown paper doesn't start until Section 5.

Mudpuppy
Posts: 5889
Joined: Sat Aug 27, 2011 2:26 am
Location: Sunny California

Re: Chip architecture vulnerability in pretty much everthing

Post by Mudpuppy » Mon Jan 08, 2018 1:29 am

Epsilon Delta wrote:
Sun Jan 07, 2018 9:27 am
Mudpuppy wrote:
Sun Jan 07, 2018 3:26 am
But, as noted quite clearly in Section 6.4, a process running by a user cannot use Meltdown to leak kernel memory on AMD and ARM processors:
We also tried to reproduce the Meltdown bug on several ARM and AMD CPUs. However, we did not manage to successfully leak kernel memory with the attack described in Section 5, neither on ARM nor on AMD.
Granted they are smart people but the fact that they could not figure out how to do it doesn't mean it can't be done. Perhaps they just ran out of time or the grad student working on the ARM was less skilled or they just know less about the AMD architecture than Intel so they could not find the right crack to slip through.
AMD does not allow speculation and out-of-order instruction processing when there is an attempt to access memory in another ring. So I doubt throwing more Ph.D. students at the problem is going to change AMD's risk profile to Meltdown, since Meltdown needs speculation and out-of-order instruction processing that is allowed to access memory in another ring.

Mudpuppy
Posts: 5889
Joined: Sat Aug 27, 2011 2:26 am
Location: Sunny California

Re: Chip architecture vulnerability in pretty much everthing

Post by Mudpuppy » Mon Jan 08, 2018 1:33 am

wrongfunds wrote:
Sun Jan 07, 2018 12:46 pm
However, for both ARM and AMD, the toy example as described in Section 3 works reliably, indicating that out-of-order execution generally occurs and instructions past illegal memory accesses are also performed.
Emphasis added; At least this makes it clear that the fundamental problem exist in ARM and AMD but their full fledged program was not able to leverage the flaw.
I feel like I am repeating myself since I already said this up-thread. But it bears repeating: The "toy example" they refer to in Section 6.4 of the Meltdown paper is basically a variant of Spectre, which allows one to access other memory locations within one's current ring. That AMD and ARM are susceptible to Spectre is not in dispute.

wrongfunds
Posts: 1875
Joined: Tue Dec 21, 2010 3:55 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by wrongfunds » Mon Jan 08, 2018 7:55 am

1 raise_exception();
2 // the line below is never reached
3 access(probe_array[data * 4096]);
Listing 1: A toy example to illustrate side-effects of outof-
order execution.
The above is listing 1

Fowlloing is section 3
3 A Toy Example
In this section, we start with a toy example, a simple
code snippet, to illustrate that out-of-order execution can
change the microarchitectural state in a way that leaks
information. However, despite its simplicity, it is used as
a basis for Section 4 and Section 5, where we show how
this change in state can be exploited for an attack.
Listing 1 shows a simple code snippet first raising an
(unhandled) exception and then accessing an array. The
property of an exception is that the control flow does not
continue with the code after the exception, but jumps to
an exception handler in the operating system.
I will continue if you agree that this is straight from the paper. I am suspecting you think I am making this up.

User avatar
Epsilon Delta
Posts: 7430
Joined: Thu Apr 28, 2011 7:00 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by Epsilon Delta » Mon Jan 08, 2018 2:45 pm

Mudpuppy wrote:
Mon Jan 08, 2018 1:29 am
Epsilon Delta wrote:
Sun Jan 07, 2018 9:27 am
Mudpuppy wrote:
Sun Jan 07, 2018 3:26 am
But, as noted quite clearly in Section 6.4, a process running by a user cannot use Meltdown to leak kernel memory on AMD and ARM processors:
We also tried to reproduce the Meltdown bug on several ARM and AMD CPUs. However, we did not manage to successfully leak kernel memory with the attack described in Section 5, neither on ARM nor on AMD.
Granted they are smart people but the fact that they could not figure out how to do it doesn't mean it can't be done. Perhaps they just ran out of time or the grad student working on the ARM was less skilled or they just know less about the AMD architecture than Intel so they could not find the right crack to slip through.
AMD does not allow speculation and out-of-order instruction processing when there is an attempt to access memory in another ring. So I doubt throwing more Ph.D. students at the problem is going to change AMD's risk profile to Meltdown, since Meltdown needs speculation and out-of-order instruction processing that is allowed to access memory in another ring.
Even if the bold bit is true it would have no bearing on the dubiousness of interpreting the authors statement that "They did not manage ... " into "a process cannot ...". Until recently no-one had managed to do any of this, yet specter and meltdown now exist.

Mudpuppy
Posts: 5889
Joined: Sat Aug 27, 2011 2:26 am
Location: Sunny California

Re: Chip architecture vulnerability in pretty much everthing

Post by Mudpuppy » Tue Jan 09, 2018 3:59 am

wrongfunds wrote:
Mon Jan 08, 2018 7:55 am
I will continue if you agree that this is straight from the paper. I am suspecting you think I am making this up.
I made no such claim that you are making things up. Please do not ascribe motives to me that do not exist. However, I do believe that you are not completely comprehending the paper. The paper quite clearly says Sections 3 and 4 are the foundation upon which Meltdown is built. Meltdown itself is not presented until Section 5. A processor must be vulnerable to the technique in Section 5 to be vulnerable to Meltdown.

Section 3 in particular is a variation on Spectre that uses exception handling to trigger the issue instead of branches. It seems wildly different to those who haven't taken a computer architecture class, but incorrect branch paths and exceptions are actually very similar at the pipeline level. When a processor comes upon a branch, it guesses which branch path to take and starts down that path. If the path is incorrect when the branch is finally calculated, the instructions on the wrong path are flushed from the pipeline, but still have the cache side-effects described in the Spectre paper.

Exception handling, as described in Section 3, is pretty much the same thing. Since the exception is not fully processed until a later stage in the pipeline, there will be other instructions in the pipeline when the exception is finally processed. This means the pipeline has started to process instructions which should not have been processed, exactly the same as when it guessed the wrong branch path in the Spectre paper. The pipeline is flushed when this happens, just like with Spectre. And the cache side-effects remain, just like with Spectre. Section 3 is basically a Spectre variant.

Basically, whether one uses branches or exceptions, the pipeline level actions are the same: the pipeline loads some instructions that shouldn't be run, a memory fetch is located in those "wrong" instructions, the pipeline eventually notices the error and "flushes" the pipeline, and the cache is not flushed so a timing attack can be used to access the memory. You'll also note that both the Spectre paper and Meltdown paper use the Flush+Reload side channel technique to iterate memory. So that's why Section 3 of the Meltdown paper is really just a variant of Spectre. It's not until Section 5 that you get to the meat of the Meltdown problem.

Referring back to the Project Zero blog on Spectre (variants 1 and 2) and Meltdown (variant 3), note that it clearly says Meltdown is based on the previous variants (aka Spectre) (bold added):
Variant 3: Rogue data cache load
Basically, read Anders Fogh's blogpost: https://cyber.wtf/2017/07/28/negative-r ... user-mode/

In summary, an attack using this variant of the issue attempts to read kernel memory from userspace without misdirecting the control flow of kernel code. This works by using the code pattern that was used for the previous variants, but in userspace. A processor must be vulnerable to the technique in Section 5 to be vulnerable to Meltdown.

wrongfunds
Posts: 1875
Joined: Tue Dec 21, 2010 3:55 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by wrongfunds » Tue Jan 09, 2018 10:23 am

Do you agree that the entire explanation is valid for AMD also? Exception happens because the unauthorized data access was tried and as it turns out was the data was actually retrieved but just not returned to the user mode caller when processor completed the exception. The side effect of not cleaning up the cache hit provides the clever user mode code to infer the data. (which begs the question; why allow cache flush from user mode code in the first place? aka why not cache flush instruction be a privileged one but that *probably* will not have solved this problem)

The above vulnerability is shared across Intel, AMD, ARM and probably other processors.

The disagreement between us is around the claim that AMD is immune to this type of attack.

Mudpuppy
Posts: 5889
Joined: Sat Aug 27, 2011 2:26 am
Location: Sunny California

Re: Chip architecture vulnerability in pretty much everthing

Post by Mudpuppy » Tue Jan 09, 2018 1:22 pm

wrongfunds wrote:
Tue Jan 09, 2018 10:23 am
Do you agree that the entire explanation is valid for AMD also? Exception happens because the unauthorized data access was tried and as it turns out was the data was actually retrieved but just not returned to the user mode caller when processor completed the exception. The side effect of not cleaning up the cache hit provides the clever user mode code to infer the data. (which begs the question; why allow cache flush from user mode code in the first place? aka why not cache flush instruction be a privileged one but that *probably* will not have solved this problem)

The above vulnerability is shared across Intel, AMD, ARM and probably other processors.

The disagreement between us is around the claim that AMD is immune to this type of attack.
Again, the attack in Section 3 of the Meltdown paper is NOT Meltdown, it is a variant of Spectre that uses exceptions to trigger the Spectre issue instead of branches. The paper itself doesn't even call Section 3 Meltdown. It calls it the "side channel Meltdown exploits" and that side channel is basically Spectre. I have already said multiple times that AMD is vulnerable to Spectre.

The Meltdown attack itself is not until Section 5 and AMD has so far been immune to the attack in Section 5. Meltdown specifically involves uses the speculative execution triggered by either branches or exceptions to read memory outside of the ring of the current program. In particular, it can be used to read kernel memory from user programs.

Spectre can iterate through memory in one's current ring, including memory for other users. And with Spectre, if you can get the kernel to run code for you (there are legitimate reasons to do this), you can get to kernel memory, but it's actually a kernel process accessing kernel memory, not a user process accessing kernel memory as with Meltdown. The spectacularly bad part of Meltdown is that it lets user-space programs access kernel memory.

In summary, the cache side-effect issue is Spectre. Accessing kernel memory from a user-space program is Meltdown. AMD is vulnerable to Spectre, but so far it has proven immune to Meltdown. AMD's design choices likely mean that it is truly immune, not just waiting for some stable of Ph.D. students to figure it out.

I do not know how many more times I can explain that Section 3 of the Meltdown paper is just a variant of Spectre and Meltdown is not presented until Section 5. The paper itself on page 2 in the Outline section even says the Meltdown attack is not presented until Section 5: "In Section 5, we present the Meltdown attack." The Google Project Zero blog by the authors of the paper also says this. You can either believe all of these sources, including the authors, or not. I've run out of ways to explain this and my personal limit of repeating myself with a slightly different variation in hopes of getting the point across has been met.

wrongfunds
Posts: 1875
Joined: Tue Dec 21, 2010 3:55 pm

Re: Chip architecture vulnerability in pretty much everthing

Post by wrongfunds » Tue Jan 09, 2018 2:14 pm

Let us agree to disagree. You believe AMD does not allow user mode program to access the kernel memory. I believe the Listing 1 clearly implies otherwise. I do not care whether something is called Meltdown or Spectre. All I know is when term "exception" is being used in this context, ring violation has already occurred.

Post Reply