20 ms·

They are still sticking to this line: "This is not a bug or a flaw in Intel products. These new exploits leverage data about the proper operation of processing

• swsieber 9y ago
  Well, that's true (at least for the spectre attack). It's not a bug in Intel products. It's a bug in any CPU that uses branch prediction (please correct me if I'm wrong, this is my current understanding)
  • bad_alloc 9y ago
    IF the bug is present in all processors that use speculative execution AND Intel products use speculative execution THEN it is a bug in Intel products. It would only be correct to say "This is not a bug or a flaw exclusive to Intel products"
  • betterunix2 9y ago
    The effect on Intel is far more severe than on other architectures. There were three vulnerabilities, two grouped together as "spectre" and one called "meltdown." Intel products are uniquely vulnerable to the meltdown attack, while many CPUs are vulnerable to spectre. The summary AFAIUI is that for most CPUs you can attack userspace processes with these techniques (think Javascript running in a browser), while for Intel CPUs you can also attack the kernel. Intel CPUs also seem to be somewhat easier to attack than others because of a higher-bandwidth side channel.
    • Symmetry 9y ago
      A minor correction, ARM's upcoming A75 core looks like it will be vulnerable to Meltdown too. But since it isn't intended for use on server workloads the performance impact of the fix shouldn't be very significant.
    • bzbarsky 9y ago
      > Intel products are uniquely vulnerable to the meltdown attack More precisely, there is only a PoC for Intel at this time. AMD processors are believed to not be vulnerable. Some ARM processors _are_ believed to be vulnerable. > for most CPUs you can attack userspace processes with these techniques Spectre can attack the kernel as well, at least according to http://www.tomshardware.com/news/meltdown-spectre-exploits-intel-amd-arm-nvidia,36219.html http://www.tomshardware.com/news/meltdown-spectre-exploits-i... . It's just harder to use than meltdown.
      • arohner 9y ago
        That link no longer loads for me. AIUI, Spectre can be used to attack the kernel, only if you can get code running in kernel-space, via, e.g. eBPF.
        • contrarian_ 9y ago
          No, you could also find a gadget with ROP techniques. The eBPF thing in the paper was purely due to convenience of exploitation.
        • bzbarsky 9y ago
          > That link no longer loads for me. Oh, right, ycombinator's URL parser is broken. I fixed the link to work around the buggy parser....
        • elihu 9y ago
          I think that's almost but not quite exactly right. Spectre variant 2 attacks vulnerable indirect jump code patterns that exist in the kernel (or some other process), but doesn't require running the attacker's code. Spectre variant 1 allows you to infer the contents of memory in the same address space, so that's the one where you'd use eBPF to attack the kernel. Meltdown (variant 3) if I understand correctly can infer memory contents of other address spaces without relying on any assumptions about the code running in the other address space. https://security.googleblog.com/2018/01/more-details-about-mitigations-for-cpu_4.html https://security.googleblog.com/2018/01/more-details-about-m...
      • 9y ago
    • cma 9y ago
      "(at least for the spectre attack)"
    • swsieber 9y ago
      I did not realize that Intel CPU's also open up the kernel to the Spectre attack, while others don't. That's noteworthy.
  • martinald 9y ago
    Any CPU that uses branch prediction that doesn't invalidate the cache after failure I think.
    • betterunix2 9y ago
      How is that supposed to work? You would have to flush the entire cache on every branch, which would mostly defeat the point of the cache in the first place. (The exploit involves reading an off-limits location in the speculative branch, then reading a legal location based on the off-limits value; so unless the entire cache was flushed the attack would still be possible.)
      • zelos 9y ago
        Could you somehow mark cache lines that are filled by speculatively executed instructions so they only become visible to normally executed instructions when the speculative instructions are committed? I guess that would require a lot more logic and more cache tag bits.
        • contrarian_ 9y ago
          You can then detect which addresses were loaded because they caused other cache lines to be evicted. Even if speculative loads do not modify the cache, you could still have a side channel by analyzing the memory bus contention. IMO there is no way to get rid of these timing attacks entirely without getting rid of SMT and speculation.
          • fyi1183 9y ago
            The solution may lie in a new "non-speculative load“ instruction that delays execution until preceding branches are confirmed. This would allow keeping the performance of speculative execution in the vast majority of cases, while also fixing the kind of potentially leaking double-indirections that Spectre variant 1 can exploit. Spectre variant 2 needs to be fixed by isolation of the branch prediction structures, i.e. tagging the BTB and others with the PCID and privilege level.
  • dekhn 9y ago
    My interpretation is that they not calling this a bug or a flaw, but a logical consequence of the design, and does not represent a flaw because the original specification didn't specify the implementation be resistant to this kind of attack.
    • dmannorreys 9y ago
      A bug is a bug regardless of what the original specification mentioned.
      • dekhn 9y ago
        I don't agree. If a spec leaves out details, the impelmentors are free to make reasonable decisions on how to implement it. It's more likely the spec didn't really have much to say about promises on the visible effects of speculative execution (the specs are often highly detailed about what side effects can be visible, this is a consequence of modern complex processors, which have very subtle designs). A bug would occur in the case where the specification specified that there were no visible side effects from these mispredicted speculative executions, and the processor implementor failed to implement that part of the specification. This is a big deal because if it's a bug, Intel is liable. It's likely all processors with these kinds of features, the specs will get updated to be more specific about these kinds of side effects.
        • dmannorreys 9y ago
          Are you saying a bug cannot exist unless some functionality is specifically mentioned in the specification, and broken in reality?
          • dekhn 9y ago
            From the perspective of Intel, as well as most of the microprocessor industry, yeah. Even "broken in reality" is arguable: while this is indeed an exploit, choosing performance over security (when the resources to implement a chip are finite) is a legitimate design tradeoff.
  • jonknee 9y ago
    That's like if Takata claimed it wasn't a production issue in Takata airbags, it was an issue that affected any airbag that was designed like Takata airbags. It's a bunch of bullshit trying to dance around the fact that Intel shipped faulty products for years. The fact that other similar products may also be faulty isn't a valid excuse.
    • chairmanwow 9y ago
      I'm not sure that calling it faulty is exactly fair. I feel like the attack is actually pretty brilliant, and has been non-obviously "vulnerable" for years.
      • betterunix2 9y ago
        It would be like Takata claiming their airbags are not a problem because all airbags can kill infants. There is a problem that uniquely affects one manufacturer's product line, and another problem that affects many manufacturers. Intel has been shipping chips that are uniquely and more severely affected by these attacks for many years now. They were ignorant, sure, but they did have a uniquely vulnerable design.
      • jonknee 9y ago
        The same can be said for many security vulnerabilities, but that doesn't make them any less faulty. Shellshock exploited a bug that had been in Bash for 25 years (!), but being non-obvious isn't a free pass. I am not angry at Intel and in general think they do a good job, but trying to dodge blame here comes off sounding pathetic.
      • emn13 9y ago
        The attack is pretty brilliant; but it's also not quite novel. Cache-timing attacks aren't new; certainly CPU suppliers should have known the general issues at hand for... at least a decade? See e.g. Colin Percival's somewhat related attack on hyperthreading way back in 2005: http://www.daemonology.net/papers/htt.pdf http://www.daemonology.net/papers/htt.pdf Actually exploiting the information leakage isn't easy; and its compounded by the secrecy surrounding cpu internals. So I think they definitely deserve some blame here. Yes, the PoC is new. But the attack surface was widely known more than a decade ago, and they chose to punt the issue onto software; a solution that was unlikely to really hold water.
  • lurker456 9y ago
    But it is a bug in Intel products. Whether similarly designed products are also affected is orthogonal.
  • revelation 9y ago
    It feels like you should be able to make a version of branch prediction with speculative execution that behaves the same as the non-speculative-fo-real execution. As in accessing memory you can't actually access doesn't cause a load and does not speculatively execute further instructions with data you weren't supposed to be able to load in the first place. This is after all what the real execution does; when you try to load from a memory address that you are not allowed to, it does not cause a memory load, it does not affect the cache and it does not continue executing instruction but instead generates a page fault. We skip the page fault thing in speculative execution, obviously, but we shouldn't continue normal control flow. I'm sure that is a lot more difficult to implement in silicon and may end up negating the performance benefits of speculative execution, but right now it feels like not having the memory protection in place in speculative execution is a performance hack that exploded in all our faces.
    • Gracana 9y ago
      In spectre, the victim process is coerced (via branch misprediction, in their first example) to speculatively access its own memory, resulting in side-effects that you can measure to determine the memory contents. No violation of memory protection needed.
• Deimorz 9y ago
  To me this feels like saying, "My program doesn't have a bug, it's executing the code that I wrote correctly." The actual bug is that the code isn't correct. In Intel's case, even though the operation is correct, it's the actual design that's flawed.
  • netsharc 9y ago
    Yeah... "Hey Mr. CPU-supplier, if I do these things then I can see with 100% certainty the contents of memory areas which I'm not allowed to read!" "Well, that's an interesting hack, I guess you can! But everything works as designed, so there's no flaw!"
    • jrs235 9y ago
      "Works as coded"
      • deleted 9y ago
        [deleted]
    • sandov 9y ago
      This reads like the Patrick Star's "Not my Wallet" meme.
  • hackbinary 9y ago
    I think what Intel is trying to say that this feature makes the chips insecure by design. It’s kind of like in Python where can get around the week protection for classes, methods, and variable to make them pseudo private by putting underscores in front of them.
    • coliveira 9y ago
      Except that these CPUs were not designed to be insecure. CPU makers spent decades marketing their architectures as able to support the implementation of secure operating systems. All of a sudden it is clear that this is not possible without heavy dose of software stopgaps. It is a fundamental flaw on CPU architecture that was not disclosed by these companies.
• debt 9y ago
  " even though a system is operating exactly as it is designed to." So people can leverage the poopy design of your chip to steal compromising information? And it's okay because the chip is functioning as it should? It shows how deeply embedded the idea of maintaining proper design and processes is over, going back to the drawing board and designing a secure chip.
  • ch4ck 9y ago
    So people can leverage the shitty design of your lock to steal goods? And it's okay because the lock is functioning as it should? It shows how deeply embedded the idea of maintaining proper design and processes is over, going back to the drawing board and designing a secure lock.
    • debt 9y ago
      It's an interesting debate. But it's clear in the statement they provided, that they are laser focused on design above all else. Literally, prioritize proper design over security and maybe even performance in some cases. Which is interesting because you'd figure at some point, the customer would be considered in the design. Like are Intel chips designed by robots or something?
    • stcredzero 9y ago
      So people can leverage the shitty design of your lock to steal goods? And it's okay because the lock is functioning as it should? That's how Master Lock stays in business.
• betterunix2 9y ago
  "potentially compromising security even though a system is operating exactly as it is designed to" Sounds like a bug to me. The PR team must have had fun trying to find a way to downplay this one...
  • x14 9y ago
    Or NSA had them do this intentionally, and thus, its not a bug :)
    • seppin 9y ago
      I promise you NSA's machines run on Intel chips too
      • pritambaral 9y ago
        Yes, but then again, they could also be running with mitigations, like the HAP bit for the ME.
    • blattimwind 9y ago
      On an "how impractical is this CPU bug as a backdoor"-scale this one is so far off the charts it already left the building.
      • beamatronic 9y ago
        Does that mean we don't need to rush to patch it?
        • pritambaral 9y ago
          Ignore parent, patch all systems as quickly and orderly as you can.
        • blattimwind 9y ago
          I replied to a comment saying "Or NSA had them do this intentionally"; my comment is not about whether this is a vulnerability, or whether exploitation is viable (it absolutely is), but rather about whether this is a viable backdoor.
• sandworm101 9y ago
  They are saying this to protect future products that are too late to update. A flaw must be fixed. This thing will exist in near-future chips for years until they redesign. So lomg as they can call it a software issue they need not stop production.
• rcthompson 9y ago
  It's like we spent 20 years building houses out of wood, and then suddenly someone discovered fire. "This is not a flaw in Intel lumber supplies. This new 'fire' leverages chemical properties common to all plant products, potentially compromising structural integrity even though the lumber is operating exactly as it was designed to." (Edit: It seems this analogy may be overly kind to Intel. Read all the replies to this comment for more information.)
  • pritambaral 9y ago
    > and then suddenly someone discovered fire This is not really like that. The dangers of speculative execution were known before, and, separately, the processor itself provided memory isolation capabilities. That the processor would ignore its own memory isolation principles when speculating about the next instruction to execute is a critical base of these vulnerabilities.
    • rcthompson 9y ago
      So maybe a better analogy would be that they built fire retardant layers into buildings, but neglected the fact that heat could still pass through the layers and start fires on the other side without burning the layer itself?
      • mtanski 9y ago
        Stop trying to make the analogy fit. It's not a good analogy.
        • amygdyl 9y ago
          Wouldn't a good analogy rather have the effect of rationalising what's already ridiculous?
      • pritambaral 9y ago
        Unlike "neglecting the fact that heat could still pass through the layers", speculative execution doesn't merely allow something that was previously possible. It allows something that was previously impossible, and while doing so undermines another, more critical, feature of the processor.
• ZeroGravitas 9y ago
  If they designed it like this, and it works as they designed it, is their PR spin opening them up to legal challenge? Presumbly they've just been misrepresenting what their system was capable of if they claim this wasn't news to them. Is it a valid legal defence to say, that was just marketing lies so don't take it seriously?
  • scott00 9y ago
    > Is it a valid legal defence to say, that was just marketing lies so don't take it seriously? There actually is a recognized defense to fraud claims along those lines. The concept is called "puffery": https://definitions.uslegal.com/p/puffery/ https://definitions.uslegal.com/p/puffery/
• MegaDeKay 9y ago
  The Register does a pretty fine job of shredding Intel's doublespeak: "We translated Intel's crap attempt to spin its way out of CPU security bug PR nightmare" http://www.theregister.co.uk/2018/01/04/intel_meltdown_spectre_bugs_the_registers_annotations/ http://www.theregister.co.uk/2018/01/04/intel_meltdown_spect...
• sambe 9y ago
  I would imagine trying to preempt class actions.
• tzahola 9y ago
  Actually, it’s a feature.
• frik 9y ago
  Well, there's something positive about it - DRM is dead, and backdoors easier to find Once there is an Expoit in the wild, the DRM solutions will fall like foliage in the fall. And since even basic functions of the OS are now naked and no code snippet can detect a kernel debugger, clever people will find out what, for example, Microsoft is doing.
• mrandish 9y ago
  This ridiculous double-speak is just their lawyers attempting to minimize exposure to claims for replacement processors due to not performing to specifications.
• jcoffland 9y ago
  > This is not a bug or a flaw in Intel products. . .[the] system is operating exactly as it is designed to. So Intel has learned nothing and will be prone to similar mistakes in the future.
  • mtgx 9y ago
    Fingers crossed for new CEO?
• rdslw 9y ago
  Dear Intel, dont worry, this will be court tested. And btw, did you notice that huge amount of people disagrees already with you, simply putting your stock 8% down in two days?
  • bluGill 9y ago
    The majority of the people putting the stock value down have no clue how bad this is: they are just making a bet (and many of them will make a lot of money even if this turns out to be an elaborate hoax). Sure a lot of people disagree, but if you read all the threads here you can quickly get a sense that among people who have a clue what this means on a technical level (those who real hacker news) don't agree how bad it is.
  • ionforce 9y ago
    What if the court is in the same pocket as Intel?
• igorhrcek 9y ago
  So what they're saying is that it was designed with a fault from the beginning. Or maybe we are just using it wrong?
• osteele 9y ago
  I read this as saying "our lawyers do not want us to preemptively strengthen the case for legal liability for damages", and as being completely independent of plans for mitigation or future product changes.
• std_throwaway 9y ago
  Does this mean it was deliberately designed to be insecure to gain some performance? With each day passing this looks more and more like the Diesel scandal. Is it OK if all big players do it?
• olfactory 9y ago
  I suppose the question would be whether the chip could be as fast at a similar price and also not suffer from the vulnerability...
• b3lvedere 9y ago
  And now people have found (made?) two workarounds for those hardware design specifications: Spectre and Meltdown. So people made workarounds for those two workarounds: software patches. Maybe even more other people will find (or make?) workarounds for those software patches? Will we witness an semi-endless cycle of workarounds until the current design specifications are slowly becoming worthless? Or will we suddenly witness new updated (patched?) design specifications (with some extra free features we never knew we wanted) and all buy new hardware?
• yndoendo 9y ago
  Movie Theatre is good one. Our service works just ask expected without any flaws. Our ushers check for proper tickets after the presentation has finished, that way we know who should and should not have access to the theatre. But shouldn't you check before hand? Again our service works ...
• djmips 9y ago
  I read this in HAL's voice
• hex12648430 9y ago
  I find it very interesting that most of their official communication on this matter seems to be for their shareholders rather than the people who are directly impacted by using their products, as if they already completely gave up on the latter. Or maybe they think we wouldn't see through this bullshit PR speak, in which case I feel quite insulted.