7 ms·

The main problem with intel is direction and process. Dan Luu pointed out in 2015 [1] that intel chips had serious bugs and, given how intel acted, it was only

The main problem with intel is direction and process. Dan Luu pointed out in 2015 [1] that intel chips had serious bugs and, given how intel acted, it was only a manner of time before something like this popped up. What I see happened to Intel is that once they consolidated their monopoly in the late 2000s, they lost the healthy management practices that tend to come from being in a competitive industry. All this talk from upper management about velocity was about trying to find a way to make more money when you've mined out your current niche completely. It ended up instead opening the door for AMD to make a comeback on x86 [1] https://danluu.com/cpu-bugs/ https://danluu.com/cpu-bugs/

harryh 9y ago
I think that comparing the types of bugs in Luu's post (which is excellent) and Spectre/Meltdown is a mistake. The former are mistakes caused by insufficient testing. The latter are conceptual problems that are nearly fundamental to modern processor design. No amount of simple testing would have uncovered them.
- nickpsecurity 9y ago
  Exactly. It's why you need multiple, assurance activities on projects to spot what a single one can't handle. I summarized here [1] those that produced results at various points in CompSci and INFOSEC history. Far as this, the first applications of covert-channel analysis to hardware found cache-based, timing channels in both VAX [2] and Intel CPU's [3]. That the caches leaked secrets meant any number of constructions built on top would leak secrets. So, proper response would be either one cache/core/cpu per security domain or designing a new cache that didn't leak secrets. The former was high-security's fall-back with the latter attempted by many in CompSci using partitioning or masking caches. The first was done in 2005 after Percival's work showing secret leaks. That first attempt on partitioned caches also cited prior work in real-time sector thinking similarly to boost determinism: proving determinism and covert channel prevention were always closely related. There were many designs after that for both partitioning and masking before the Intel hit. So, the root causes of shared, on-chip resources were identified by mid-1990's, demonstrated again by later work like Percivals, being mitigated from that year onward, and ignored by CPU vendors. When I asked in the past, hardware people told me they didn't care about cache security because their sales were strictly tied to customers' benchmarks of performance per dollar and watt. Customers didn't care. Suppliers didn't care. That simple. There were in fact (tiny) segments where customers were buying processors with more robustness or predictability. Those that come to mind were some PowerPC designs from Freescale that aerospace liked, Leon3-FT SPARC that was GPL, some smartcard components, and especially Rockwell-Collins' AAMP7G [5]. Designed with EAL7 methods from 1992, it had mathematical proof of separation at level, triplicated registers for fault-tolerance, ECC memory, and MILSPEC heat tolerance. It's used in guards to separate Top Secret/SCI info from other stuff. So, these are old attacks with mitigations of various costs that were ignored for profit maximization by the big companies and performance maximization by most consumers/businesses who didn't buy security in general. Both old and new techniques were effective at assessing leaks and mitigations, though. They could've been used at any time, were by CompSci, were by security-critical suppliers (esp Rockwell), and even more techniques exist now for analysis [6]. Intel et al will just patch up until next attack since they and the market haven't changed. ;) [1] https://pastebin.com/uyNfvqcp https://pastebin.com/uyNfvqcp [2] https://www.google.ch/patents/US5574912 https://www.google.ch/patents/US5574912 (Note: Using the patent filing since the 1992 work is paywalled. It's the same person filing what they discovered on VAX VMM project.) [3] https://pdfs.semanticscholar.org/2209/42809262c17b6631c0f6536c91aaf7756857.pdf https://pdfs.semanticscholar.org/2209/42809262c17b6631c0f653... [4] https://eprint.iacr.org/2005/280.pdf https://eprint.iacr.org/2005/280.pdf [5] http://www.ccs.neu.edu/home/pete/acl206/slides/hardin.pdf http://www.ccs.neu.edu/home/pete/acl206/slides/hardin.pdf [6] https://pastebin.com/ajqxDJ3J https://pastebin.com/ajqxDJ3J
- throwaway2048 9y ago
  packaging meltdown/spectre together was a brilliant PR coup from intel, dispite the fact that meltdown is much more severe and really only effects Intel processors. This way they can pretend its an industry wide problem and they are not to blame, great.
  - tristanj 9y ago
    How was "packaging meltdown/spectre together was a brilliant PR coup from intel"? It was Google who found the exploits, and Google who published the exploits in the same document & their press release. Google is the one who packaged these exploits together. How does Intel PR take credit for this?
    - terminalcommand 9y ago
      I also think it was a PR coup from the Intel side. I think of myself as pretty much tech savvy. But even I hesitated for a moment and asked myself whether AMD was affected by meltdown although I knew that it didn't. All the google searches lead to sites mentioning "Meltdown/Spectre attacks" as if they were the same thing. You can hardly find sites that explicitly state: look here is meltdown, it only affects intel CPUs and it can only really be patched on the software level and that will result in HUGE perormance losses. Basically every time your CPU accesses the Kernel Space, some kind of cache cleansing needs to be done, it has to context switch. Instead no one seems to grasp what meltdown is, intel is feeding the media with benchmarks and says there is no real impact, users believe intel. I read somewhere that all big companies Google, Intel etc. knew about these security vulnerabilities, especially meltdown months before. Intel made a deal with Microsoft to disclose the vulnerability on a Microsoft Update date and tell everyone that there was an issue and it was fixed. Microsoft was also supposed to make all processors including AMD to get affected by the slowdown. However Google reported 1 week earlier said it couldn't keep this a secret with good conscience. But even if that plan failed there is still a lot of misinformation caused partly by intel. Even if you visit sites such as meltdownattack.com (first result on google with some deeper info), it says we do not know in which aspect Meltdown affects processors. I'm on the verge of buying a new desktop, I will go with intel because I have no other cheap choice. Intel still delivers the cheapest option for me (i3-8100). But I would appreciate if Intel played fairly. All this manipulation behind the scenes is corrupting the market and intel is responsible for it. I don't know what we got ourselves into. The RAM folks built a cartel and are keeping the prices high. Microsoft is deliberately crippling third party antivirus software. Intel is shipping us CPUs with backdoors (Intel ME), there are serious vulnerabilities that get swept under the rug, yet we have to buy intel because we are locked into the x86 platform. At least microsoft is teaming up with Qualcomm and Apple is rolling out its own ARM processors. We need to have an alternative. IMHO Intel has been playing an unfair and an unethical game.
- pcwalton 9y ago
  Spectre is fundamental to processor design, but Meltdown is pretty much a bug.
  - wklauss 9y ago
    It is only a bug once you have discovered that branch prediction can be used as a vector of attack. Until then, it was a perfectly valid design implementation.
    - pritambaral 9y ago
      It was a bug right from the original design, because it sidestepped the privilege level separation guarantees of the CPU. That the bug could not be exploited for other reasons does not make it not-a-bug.
    - jotm 9y ago
      What actual data can be extracted by a Meltdown/Spectre attack? Still need to find an answer to that, nothing online says anything specific. Datacenters should probably be worried, but what about the hundreds of millions of users out there? Doesn't seem like a big deal, tbh - until an actual exploit is out there, why should they worry?
      - scott_s 9y ago
        The page from the researchers is your best source: https://meltdownattack.com/ https://meltdownattack.com/. I also recommend reading the actual papers (https://meltdownattack.com/meltdown.pdf https://meltdownattack.com/meltdown.pdf and https://spectreattack.com/spectre.pdf https://spectreattack.com/spectre.pdf). I haven't gotten to the Spectre paper yet, but the Meltdown paper is excellent, readable, and clear.
      - tptacek 9y ago
        Meltdown allows userland native code (the Javascript your browser loads from random websites is JIT'd down to native code) to dump kernel memory.
- dboreham 9y ago
  Speculatively executing code without performing memory access checks seems like a big design/architecture mistake. Not really the kind of thing that testing or verification is aimed at.
  - tptacek 9y ago
    That's one of the bugs, Meltdown. The other, more insidious bug doesn't involve memory checks not being done, but rather the more basic fact that results written to cache can't easily be backed out.
krn1p4n1c 9y ago
This isn't just Intel. Every chip company is like this. Pre/Post silicon verification is given a narrow window in which to catch everything and if it's a non-trivial bug that requires a layer change it's probably shelved till the next revision.
cookiecaper 9y ago
I think this is less of a thing that is specifically endemic to Intel as much as it's just a "big, old company" thing. Companies become massive, they eventually lose their visionary leadership, and then they spend the proceeding few decades lumbering along just based on inertia. These companies continue to employ a lot of smart people and have exciting things going on in some components, but the corporate culture makes it hard to get a consistent positive execution. Intel has been sitting pretty for the last 20 years because chip design is not something that lends itself to modern patterns of disruption. I'm sure it will happen some day, but for now, Intel has kept its position mostly due to the difficulty of the niche than any intrinsic competitive edge. The point being that Intel itself is not uniquely terrible; they're routinely terrible. They're just positioned in a space that's much more hostile to less-terrible entrants, so capable people do something that is less hard.

harryh 9y ago

I think that comparing the types of bugs in Luu's post (which is excellent) and Spectre/Meltdown is a mistake. The former are mistakes caused by insufficient testing. The latter are conceptual problems that are nearly fundamental to modern processor design. No amount of simple testing would have uncovered them.

nickpsecurity 9y ago
Exactly. It's why you need multiple, assurance activities on projects to spot what a single one can't handle. I summarized here [1] those that produced results at various points in CompSci and INFOSEC history. Far as this, the first applications of covert-channel analysis to hardware found cache-based, timing channels in both VAX [2] and Intel CPU's [3]. That the caches leaked secrets meant any number of constructions built on top would leak secrets. So, proper response would be either one cache/core/cpu per security domain or designing a new cache that didn't leak secrets. The former was high-security's fall-back with the latter attempted by many in CompSci using partitioning or masking caches. The first was done in 2005 after Percival's work showing secret leaks. That first attempt on partitioned caches also cited prior work in real-time sector thinking similarly to boost determinism: proving determinism and covert channel prevention were always closely related. There were many designs after that for both partitioning and masking before the Intel hit. So, the root causes of shared, on-chip resources were identified by mid-1990's, demonstrated again by later work like Percivals, being mitigated from that year onward, and ignored by CPU vendors. When I asked in the past, hardware people told me they didn't care about cache security because their sales were strictly tied to customers' benchmarks of performance per dollar and watt. Customers didn't care. Suppliers didn't care. That simple. There were in fact (tiny) segments where customers were buying processors with more robustness or predictability. Those that come to mind were some PowerPC designs from Freescale that aerospace liked, Leon3-FT SPARC that was GPL, some smartcard components, and especially Rockwell-Collins' AAMP7G [5]. Designed with EAL7 methods from 1992, it had mathematical proof of separation at level, triplicated registers for fault-tolerance, ECC memory, and MILSPEC heat tolerance. It's used in guards to separate Top Secret/SCI info from other stuff. So, these are old attacks with mitigations of various costs that were ignored for profit maximization by the big companies and performance maximization by most consumers/businesses who didn't buy security in general. Both old and new techniques were effective at assessing leaks and mitigations, though. They could've been used at any time, were by CompSci, were by security-critical suppliers (esp Rockwell), and even more techniques exist now for analysis [6]. Intel et al will just patch up until next attack since they and the market haven't changed. ;) [1] https://pastebin.com/uyNfvqcp https://pastebin.com/uyNfvqcp [2] https://www.google.ch/patents/US5574912 https://www.google.ch/patents/US5574912 (Note: Using the patent filing since the 1992 work is paywalled. It's the same person filing what they discovered on VAX VMM project.) [3] https://pdfs.semanticscholar.org/2209/42809262c17b6631c0f6536c91aaf7756857.pdf https://pdfs.semanticscholar.org/2209/42809262c17b6631c0f653... [4] https://eprint.iacr.org/2005/280.pdf https://eprint.iacr.org/2005/280.pdf [5] http://www.ccs.neu.edu/home/pete/acl206/slides/hardin.pdf http://www.ccs.neu.edu/home/pete/acl206/slides/hardin.pdf [6] https://pastebin.com/ajqxDJ3J https://pastebin.com/ajqxDJ3J
throwaway2048 9y ago
packaging meltdown/spectre together was a brilliant PR coup from intel, dispite the fact that meltdown is much more severe and really only effects Intel processors. This way they can pretend its an industry wide problem and they are not to blame, great.
- tristanj 9y ago
  How was "packaging meltdown/spectre together was a brilliant PR coup from intel"? It was Google who found the exploits, and Google who published the exploits in the same document & their press release. Google is the one who packaged these exploits together. How does Intel PR take credit for this?
  - terminalcommand 9y ago
    I also think it was a PR coup from the Intel side. I think of myself as pretty much tech savvy. But even I hesitated for a moment and asked myself whether AMD was affected by meltdown although I knew that it didn't. All the google searches lead to sites mentioning "Meltdown/Spectre attacks" as if they were the same thing. You can hardly find sites that explicitly state: look here is meltdown, it only affects intel CPUs and it can only really be patched on the software level and that will result in HUGE perormance losses. Basically every time your CPU accesses the Kernel Space, some kind of cache cleansing needs to be done, it has to context switch. Instead no one seems to grasp what meltdown is, intel is feeding the media with benchmarks and says there is no real impact, users believe intel. I read somewhere that all big companies Google, Intel etc. knew about these security vulnerabilities, especially meltdown months before. Intel made a deal with Microsoft to disclose the vulnerability on a Microsoft Update date and tell everyone that there was an issue and it was fixed. Microsoft was also supposed to make all processors including AMD to get affected by the slowdown. However Google reported 1 week earlier said it couldn't keep this a secret with good conscience. But even if that plan failed there is still a lot of misinformation caused partly by intel. Even if you visit sites such as meltdownattack.com (first result on google with some deeper info), it says we do not know in which aspect Meltdown affects processors. I'm on the verge of buying a new desktop, I will go with intel because I have no other cheap choice. Intel still delivers the cheapest option for me (i3-8100). But I would appreciate if Intel played fairly. All this manipulation behind the scenes is corrupting the market and intel is responsible for it. I don't know what we got ourselves into. The RAM folks built a cartel and are keeping the prices high. Microsoft is deliberately crippling third party antivirus software. Intel is shipping us CPUs with backdoors (Intel ME), there are serious vulnerabilities that get swept under the rug, yet we have to buy intel because we are locked into the x86 platform. At least microsoft is teaming up with Qualcomm and Apple is rolling out its own ARM processors. We need to have an alternative. IMHO Intel has been playing an unfair and an unethical game.
pcwalton 9y ago
Spectre is fundamental to processor design, but Meltdown is pretty much a bug.
- wklauss 9y ago
  It is only a bug once you have discovered that branch prediction can be used as a vector of attack. Until then, it was a perfectly valid design implementation.
  - pritambaral 9y ago
    It was a bug right from the original design, because it sidestepped the privilege level separation guarantees of the CPU. That the bug could not be exploited for other reasons does not make it not-a-bug.
  - jotm 9y ago
    What actual data can be extracted by a Meltdown/Spectre attack? Still need to find an answer to that, nothing online says anything specific. Datacenters should probably be worried, but what about the hundreds of millions of users out there? Doesn't seem like a big deal, tbh - until an actual exploit is out there, why should they worry?
    - scott_s 9y ago
      The page from the researchers is your best source: https://meltdownattack.com/ https://meltdownattack.com/. I also recommend reading the actual papers (https://meltdownattack.com/meltdown.pdf https://meltdownattack.com/meltdown.pdf and https://spectreattack.com/spectre.pdf https://spectreattack.com/spectre.pdf). I haven't gotten to the Spectre paper yet, but the Meltdown paper is excellent, readable, and clear.
    - tptacek 9y ago
      Meltdown allows userland native code (the Javascript your browser loads from random websites is JIT'd down to native code) to dump kernel memory.
dboreham 9y ago
Speculatively executing code without performing memory access checks seems like a big design/architecture mistake. Not really the kind of thing that testing or verification is aimed at.
- tptacek 9y ago
  That's one of the bugs, Meltdown. The other, more insidious bug doesn't involve memory checks not being done, but rather the more basic fact that results written to cache can't easily be backed out.

krn1p4n1c 9y ago

This isn't just Intel. Every chip company is like this. Pre/Post silicon verification is given a narrow window in which to catch everything and if it's a non-trivial bug that requires a layer change it's probably shelved till the next revision.

cookiecaper 9y ago

I think this is less of a thing that is specifically endemic to Intel as much as it's just a "big, old company" thing. Companies become massive, they eventually lose their visionary leadership, and then they spend the proceeding few decades lumbering along just based on inertia. These companies continue to employ a lot of smart people and have exciting things going on in some components, but the corporate culture makes it hard to get a consistent positive execution. Intel has been sitting pretty for the last 20 years because chip design is not something that lends itself to modern patterns of disruption. I'm sure it will happen some day, but for now, Intel has kept its position mostly due to the difficulty of the niche than any intrinsic competitive edge. The point being that Intel itself is not uniquely terrible; they're routinely terrible. They're just positioned in a space that's much more hostile to less-terrible entrants, so capable people do something that is less hard.