Researchers reveal Meltdown and Spectre CPU exploits

After building speculation fueled by media reports (including our own) ahead of a planned coordinated release, researchers at Google, academic institutions, and other companies have revealed a pair of attack classes this afternoon that exploit fundamental operating principles of modern CPUs to allow attackers to arbitrarily read data from the memory of vulnerable systems.

The first, called "Meltdown," breaks down CPU-level protections that prevent unprivileged applications from reading arbitrary system memory, including privileged memory locations corresponding to the operating system's kernel, using what the researchers describe as side effects of out-of-order execution on modern processors.

According to the Meltdown paper, the researchers were able to successfully perform the Meltdown attack using unprivileged code on Intel microarchitectures because of a privilege escalation vulnerability specific to that company's CPUs, but could not successfully execute the full version of the attack on AMD and ARM CPUs.

The researchers warn that every Intel CPU employing out-of-order execution could be vulnerable to the Meltdown attack, which is to say all Intel chips dating back to the Pentium Pro are vulnerable outside of some in-order Atom cores. The principle of kernel page table isolation (KPTI) described in our earlier news post on this topic was not specifically designed to mitigate this attack, according to the researchers, but it does effectively stop an attacker from exploiting this vulnerability.

The researchers urge the adoption of KPTI-style mitigations for Meltdown as soon as possible—something that macOS, Windows, and Linux have done or are in the process of doing.

The second class of attack, called Spectre, apparently allows similar leaking of memory contents through misdirection of certain speculative execution features present in all modern CPUs. The researchers say they have verified the attack on processors from Intel, AMD, and ARM. The researchers further note that Spectre attacks are harder to carry out but also defy easy mitigation.

Intel has not provided information regarding its response to these attacks beyond its initial statement this afternoon, but AMD claims that at worst its CPUs have a "near zero risk of exploitation" in a dedicated page on its site. ARM has provided a detailed list of affected products and potential workarounds on its site.

At the software level, Google has detailed steps that it's taking to limit the scope of these vulnerabilities in its own products. Microsoft has also pushed an out-of-band security update for Windows and plans to aggressively begin rebooting affected Azure virtual machines this afternoon. As always when discussing this type of vulnerability, we suggest keeping all software as up-to-date as possible as soon as possible.

Comments closed
    • johnsmith26
    • 2 years ago
    • HERETIC
    • 2 years ago

    Can’t wipe the smile off apple’s face’s-INHell (massive understatement) has pushed Batterygate
    to the back pages-You know the one where they’re offering to replace a $5 battery(which they
    should have done for free)with another $5 battery,and conned you into believing they’re
    doing you a favor only charging you $29.
    Back to the story-For all who find a lot of this going WOOSH (pick me) Charlie over at SA has
    a dumbed down version,as long as you can handle the blinkered approach-
    [url<]https://www.semiaccurate.com/2018/01/04/kaiser-security-holes-will-devastate-intels-marketshare/[/url<]

      • NTMBK
      • 2 years ago

      Apple’s CPUs are also vulnerable to Meltdown, so I don’t think they’ll be too happy.

        • smilingcrow
        • 2 years ago

        Heretic was simply pointing out that this is such a serious situation that Apple’s battery woes have lost the focus of the tech reports.

    • just brew it!
    • 2 years ago

    Spectre puts a whole new spin on Chrome’s recently announced [url=https://techreport.com/news/32937/chrome-63-puts-bad-sites-in-solitary-confinement<]site isolation[/url<] feature. I bet the Chrome team had advance knowledge of the exploit, and this is one of the potential mitigations. If you haven't enabled site isolation (it is still considered experimental, and disabled by default) go to [url<]chrome://flags/#enable-site-per-process[/url<]

      • Kevsteele
      • 2 years ago

      I believe it was a Google research team that discovered Meltdown, so yeah – they had advanced knowledge of it. πŸ˜‰

      • the
      • 2 years ago

      The time lines don’t match up well. Site isolation appears to have been in development prior to the initial discovery of Spectre. A quick Google search shows some work for it being [url=https://groups.google.com/a/chromium.org/forum/#!topic/site-isolation-dev/Nttn3WiY9DA<]added 15 months ago to Chrome v54[/url<]. Full site isolation just hit mainstream release as an experimental feature but It would make sense that internally Google fast tracked the work on that feature.

        • just brew it!
        • 2 years ago

        Yeah, you’re probably right (unless there’s been a suspicion of something like Spectre being exploitable for a very long time). But I bet they did fast-track it once things started to heat up.

    • ronch
    • 2 years ago

    Given how these exploits affect CPUs with speculative execution, could someone test the AMD K5, K6, Cyrix M1, M2, NexGen Nx586, IDT Winchip 1 & 2 and VIA C3?

      • derFunkenstein
      • 2 years ago

      [s<]Nuke the site from orbit[/s<] Throw them out. It's the only way to be sure.

      • MOSFET
      • 2 years ago

      No one has a pair of SIMMs anymore.

    • just brew it!
    • 2 years ago

    Spectre is really quite brilliant. It looks like they’ve figured out a way to get malicious JIT-compiled JavaScript to “read” arbitrary locations in the web browser’s memory, which could potentially leak passwords, encryption keys, etc.

    Cliff Notes version:

    In effect, they evaluate an expression of the form B[A[x]], where A and B are both arrays, and x is a carefully chosen out-of-bounds array index. They also “prime” the branch predictor first (by executing in-bounds accesses), so that the branch predictor guesses wrong, and the CPU starts speculatively evaluating the expression [i<]before it has figured out that x is out-of-bounds[/i<]. The key to the exploit is that -- even though all of the CPU register state gets rewound once the branch mispredict is detected -- an existing value gets evicted from the CPU's data cache, in order to hold the (no longer needed) value fetched from array B. Furthermore, [i<]which[/i<] cache line gets evicted depends on the address of B[A[x]], which in turn depends on the value stored at A[x]. The exploit then deduces which cache line got evicted, by carefully timing how long it takes to access a range of memory addresses which were known to be in cache previously. The "slow" address is the one corresponding to the cache line which got evicted, and this indirectly tells the attacker the value of A[x] -- the memory location you are trying to "read". Hats off to the people who figured this out, it's amazing stuff. I'm also not sure how you defend against this, other than being less aggressive with speculative execution (hurts overall CPU performance), or going back to straight interpretation for JavaScript instead of JIT compilation (huge hit to web browser performance).

      • Anonymous Coward
      • 2 years ago

      That is pretty amazing. This must get more difficult on a busy computer with many cores and threads.

      • the
      • 2 years ago

      Since the exploit is uses Java Script in an example, the JIT compiler could potentially be altered to avoid these scenarios. Hypothetical solution would replacing regular A[x] array loads (x + $A[0]) with compiled code similar to x*%array_size+$A[0] which would redirect the speculative access back to memory containing the array. This of course is a bit of a bandaid as it only prevents the very specific instance of this attack cited in the paper and not the real principle behind it. However, my general point here is that with a JIT compiler there is the [i<]potential[/i<] for them to be altered to prevent this attack from this particular vector. The problem is that code doesn't necessarily [i<]have[/i<] to use JavaScript for the principles of this attack to still be in play and the Spectre paper includes basic examples using C. Also interesting in the paper is that this exploit works well with SMT. Chances to OS schedulers here can mitigate the risk of cross process exploitation but again at a potential performance hit.

        • just brew it!
        • 2 years ago

        [quote<]Since the exploit is uses Java Script in an example, the JIT compiler could potentially be altered to avoid these scenarios. Hypothetical solution would replacing regular A[x] array loads (x + $A[0]) with compiled code similar to x*%array_size+$A[0] which would redirect the speculative access back to memory containing the array. This of course is a bit of a bandaid as it only prevents the very specific instance of this attack cited in the paper and not the real principle behind it. However, my general point here is that with a JIT compiler there is the potential for them to be altered to prevent this attack from this particular vector.[/quote<] Yes, it can be patched in the JIT compiler, but there will be a performance hit since the compiler will need to generate additional code which somehow guarantees that the second speculative memory access does not proceed until the result of the check is known. So more code, plus you lose some of the benefit of speculative execution in the normal (non-malicious) case. Your modulo example also breaks JavaScript semantics, where an out-of-bounds access is supposed to return the special value 'undefined'. [quote<]The problem is that code doesn't necessarily have to use JavaScript for the principles of this attack to still be in play and the Spectre paper includes basic examples using C.[/quote<] Yes, but web browsers don't execute random C code embedded in potentially malicious web pages. The C example is a mostly* local exploit, whereas the JavaScript one is trivially remotely exploitable. *I say "mostly" because you could theoretically exploit existing C runtime library code on the system, but that would be more difficult since there are additional layers in between which are also going to tend to muck with the caches and obfuscate the results.

          • the
          • 2 years ago

          [quote<]Yes, it can be patched in the JIT compiler, but there will be a performance hit since the compiler will need to generate additional code which somehow guarantees that the second speculative memory access does not proceed until the result of the check is known. So more code, plus you lose some of the benefit of speculative execution in the normal (non-malicious) case.[/quote<] Correct but even with the performance hit, it should still be superior interpretation. That's all it needs to be. [quote<]Your modulo example also breaks JavaScript semantics, where an out-of-bounds access is supposed to return the special value 'undefined'.[/quote<] True but it was never meant to be JavaScript, just pseudo code for what the JIT could produce afterward. The source JavaScript would still be the B[A[x]] example. [quote<]Yes, but web browsers don't execute random C code embedded in potentially malicious web pages. The C example is a mostly* local exploit, whereas the JavaScript one is trivially remotely exploitable.[/quote<] True and my statement was more in a general context than specific to web browsers. JIT compiler changes are far from a universal fix for this issue. Using Spectre is still possible for an attacker if they were able to gain the ability for code execution by other means.

            • just brew it!
            • 2 years ago

            [quote<][quote<]Your modulo example also breaks JavaScript semantics, where an out-of-bounds access is supposed to return the special value 'undefined'.[/quote<] True but it was never meant to be JavaScript, just pseudo code for what the JIT could produce afterward. The source JavaScript would still be the B[A[x]] example.[/quote<] If the JIT compiler produced code equivalent to that, then the code would not conform to proper JavaScript semantics. It would break working programs which expect to get the special value 'undefined' when indexing past the end of an array. [quote<]True and my statement was more in a general context than specific to web browsers. JIT compiler changes are far from a universal fix for this issue. Using Spectre is still possible for an attacker if they were able to gain the ability for code execution by other means.[/quote<] Right. But since Spectre only gives access to data in the local process context, if the attacker has gained arbitrary code execution capability then Spectre is irrelevant because they can just read the data directly (without resorting to Spectre). It's already "game over".

            • the
            • 2 years ago

            [quote<]If the JIT compiler produced code equivalent to that, then the code would not conform to proper JavaScript semantics. It would break working programs which expect to get the special value 'undefined' when indexing past the end of an array.[/quote<] You're right. The out of bounds exception is kinda import for debugging and sane logic. For standard loops bounds checking could be thrown by checking x>array_size at each iteration. The downside would be that the exception would not occur with the actual line of code responsible (loop iteration vs. array access) in the compiled code, though the actual error (array out of bounds access) would be correct for the real issue. For direct array access, the bounds check would have to tested upon access but if you have code that attempts A[x] and x > array_size outside of a loop, something fishy is going on anyway.

            • just brew it!
            • 2 years ago

            I suspect that a fair amount of code doesn’t even check x against the array size, and just loops until it gets the ‘undefined’ value back (effectively using ‘undefined’ as a sentinel value). Can’t speak from direct experience as I’ve not looked at (nor written) a lot of JavaScript… I probably know just enough of it to be dangerous. πŸ˜‰

      • Chrispy_
      • 2 years ago

      +3 for ELI5 edition that I understand.

        • daniel123456
        • 2 years ago

        Yup. JBI you are a legend. Your posts are always superbly well informed and educational! Thanks

          • just brew it!
          • 2 years ago

          Thank you (both of you). I needed to understand it well enough to explain it to my co-workers and management so we could realistically evaluate our exposure, so I went and read the paper. Like 1/4 of the way in, I went “Holy crap… they did THAT?!??”

          And then I figured I could probably distill it down for a tech-savvy (though not necessarily system software developer) audience, hence the above post.

          XKCD’s also got a pretty good analogy: [url<]https://xkcd.com/1938/[/url<]

      • anotherengineer
      • 2 years ago

      would disconnecting from the internet defend against it??

        • Ryu Connor
        • 2 years ago

        Is this a serious question?

        • Wirko
        • 2 years ago

        Yes but it’s also necessary to swallow up the network cable.

        • just brew it!
        • 2 years ago

        Might as well stop receiving postal mail and disconnect your telephone too. Then you aren’t vulnerable to any mail or phone scams. You could still be hit by door-to-door scams though; I guess you need to move to a cabin in the woods at the far end of a 3 mile long dirt footpath, or (if you’re REALLY paranoid) a remote island in the middle of the ocean, if you really want to be sure.

          • anotherengineer
          • 2 years ago

          So I will take that as a yes πŸ™‚

          Still fascinating stuff. But why is it java script that always seems to have these exploits and not other program languages?

          Is it just because it’s so popular?

            • Redocbew
            • 2 years ago

            In this case, probably, but it doesn’t seem like the specific language used makes much difference here. Also, if you pick something obscure for the PoC you run the risk of people reacting with “Cool. That’s really interesting, but so what?”

            • just brew it!
            • 2 years ago

            Not exactly. It’s because it is the de facto language for creating interactive web pages, and is executed by your web browser by default. So you’re running random JavaScript code from pretty much every site you visit.

            Other languages are widely used too, but they typically run on a back-end Cloud server, or as part of an application you’ve explicitly downloaded and installed. They don’t just run on your PC without you giving them permission.

            JavaScript is different because untrusted code is routinely run directly on your PC. The web browser’s sandboxing is supposed to protect you from malicious web code, but in the case of Spectre that protection fails.

      • Meadows
      • 2 years ago

      Came here because it was the top comment.

      Verified that it is, in fact, a top comment.

      • SlappedSilly
      • 2 years ago

      Going my this Cliff Notes version, the data leak is by cache eviction with an address set by an out of bounds read.

      If that’s the case, I would think a suitable mitigation would be to invalidate all of the cache when an out of bounds read has happened. Then all cache lines are invalid and no information is available. I just don’t know if a subsequent fetch timing can happen before the out of bounds is detected and cache flushed.

      This shouldn’t impact performance of well behaved code as it would happen in the exception handler, and does anyone care about performance of code that attempts OOB reads?

      /me sits back down in armchair and picks up cold popcorn.

      • smilingcrow
      • 2 years ago

      One method to disrupt it is to reduce the resolution of the timer and also by adding a random offset to it.

        • just brew it!
        • 2 years ago

        Chrome was already doing this. The people who figured out the Spectre exploit worked around it by creating their own high resolution timer in software, with a thread that just spins and increments a shared variable.

      • Cuhulin
      • 2 years ago

      I agree that Spectre is an amazing piece of work, and you probably are right that it would be difficult to resolve with existing silicon.

      However, it should be eminently possible to fix with new processors – just don’t make these internal processes visible to the system. That won’t be trivial, and it probably will be a little slower than the current approach, but there is no reason for the timing to be known outside the processor, so return all values on a schedule.

      Scheduled responses = no timing variations to read.

      That’s my thought anyway. There probably are others possible. What I do believe is that we are going to be buying new silicon during the next few years.

        • just brew it!
        • 2 years ago

        The problem is that the timing variations are due to whether data is in cache or not. If you make everything take as long as a non-cached access, then you’ve just defeated the whole purpose of having the cache, and likely set us back 10 years in terms of performance.

    • Zizy
    • 2 years ago

    A nice twitter summary of what is/was going on:
    [url<]https://twitter.com/nicoleperlroth/status/948811287508799489[/url<] That image with "solution = Replace CPU hardware" made me laugh.

      • adisor19
      • 2 years ago

      Yet, it’s the only permanent solution. Until the next vulnerability is found. :S

      Adi

      • Flying Fox
      • 2 years ago

      The problem is, replace with what? Pretty much all modern high performance CPUs employ some form of speculative execution to get that high performance, which may be susceptible to Spectre. And this one looks tricky to fix even at the hardware level.

        • adisor19
        • 2 years ago

        Solution will be found. Encrypting RAM with a key that stays in a SecureEnclave chip could be an option. IBM did it on their mainframes. Apple will probably implement it in their iPhone 5S and up barring a performance penalty for current chips.

        The solution is out there. Just takes time and $ to implement it. Mainly the $ part.

        Adi

          • Flying Fox
          • 2 years ago

          There is currently no obvious software fix for Spectre. This may require new hardware which may not come soon enough. And even chips with the fix is available within the year, how many of the general mass public would rush out to replace their newly bought iPhone 8/X so soon?

          So yes, it is mainly the $ part, especially from the consumer side.

          As for encrypting RAM, see the other subthread discussions on “what about decryption”.

          • psuedonymous
          • 2 years ago

          Encrypted data in flight will do naff-all to halt the Spectre attack, as it relies on [i<]not[/i<] accessing the information, but on the CPU itself's (required) ability to access the information. It's a timing-based attack.

    • ronch
    • 2 years ago

    These newfangled chips are nuts! We should’ve stuck with the original Pentium!

    / (@_@;)

      • Grigory
      • 2 years ago

      6502 is where it’s at, dude.

        • Wirko
        • 2 years ago

        No, you can do OOO and speculative execution even on an abacus!

      • IGTrading
      • 2 years ago

      Personal opinion :

      This is by far the most biased and misleading title and article I’ve read this year.

      Everybody (and I really mean everybody out there) clearly points out that Intel’s chips are vulnerable and AMD’s are not.

      Intel’s shares are falling, AMD’s are shooting up.

      TechReport talks about “Meltdown and Spectre CPU exploits” without mentioning in the title that these affect 100% of Intel’s CPUs on the laptop, server and PC markets.

      Come the f. on ! Can you be more biased than this ?!

      Documentation (directly from the team that discovered and tested the exploits) : [url<]https://meltdownattack.com/meltdown.pdf[/url<] Quote : "6.4 Limitations on ARM and AMD 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." They do say that with more research and resources, MAYBE an BETTER exploit could be written to hack AMD too, but for now, AMD is NOT vulnerable, AMD IS vulnerable to Spectre and all CPU will be vulnerable unless patched, because speculative execution is a very important performance booster. BUT for AMD, Spectre is patch-able with ZERO performance hit, according to the latest reports. So Intel's Meltdown brings a 30% performance hit, AMD's immune. AMD's Spectre patch has no effect on performance and make AMD's platform immune. It is simple if you really want to tell the truth. I've worked as a journalist in IT for 4 years and trust me, IMHO this is not the right/correct/accurate title for such an article. Sure ... I was doing that 15 years ago, when sources and research didn't mean having a Twitter or FaceBook account ... Who the heck cares about "Meltdown and Spectre" ? Who will remember these names ?! Will you remember this as useful , interesting or even entertaining information ?! What IS useful and interesting is that if you happen to have an Intel based system there is a 95% chance you will need to patch it. If you have an AMD laptop , PC or server, you are safe for now and there will NOT be a performance penalty. I remember one Intel fanboy around here that was saying just a few weeks ago that AMD's chips are just as vulnerable if not more, when talking about Intel's security issues in IME. Funny how each month we head about some NEW Intel flaw, security issue, compatibility issue or performance issue .... but hardware sites don't warn users about there at the end of a review .... When it comes to AMD, I remember them not recommending a R290 which was beating nVIDIA's Titan for half the price, because "the fan was too loud" .... How conveniently some things are comfortably left out, not mentioned, forgotten just at the right moment or at the right place (not mentioned in the title, but in the middle of the article). I hope nobody has a problem with a freely expressed opinion of a boring dude working in IT hardware for more than 2 decades ...

        • Ninjitsu
        • 2 years ago

        Personal opinion: This is by far the most biased and misleading comment I’ve read this year. I mean it’s January 4th, I’m sure there will be worse…

          • derFunkenstein
          • 2 years ago

          Not sure I’d make that bet lol

        • techguy
        • 2 years ago

        Please inform us for which outlet(s) you write so we don’t read them and misinform ourselves. The fact that you want to play up an AMD vs. Intel angle to this piece is precisely the problem with modern sensationalist I “journalism”.

        Report the facts and leave the narrative aside or you are nothing more than a propagandist.

          • IGTrading
          • 2 years ago

          Mate, that IS the news : 100% of Intel recent processors are 100% vulnerable and the patch brings an “up to 53%” performance penalty.

          Saying “but AMD is vulnerable too in a single particular type of Linux setup and easily fixable with no performance hit” is not the news story.

          Sensationalism ?! Call it what you like. It the “country is on fire” , then the country is on fire.

          At least Intel’s “country” .

          That’s your opinion and I welcome it.

            • techguy
            • 2 years ago

            The patch does not bring a 53% performance penalty in any real world scenario. The Phoronix testing you reference was SYNTHETIC.

            I happen to actually work in the industry which you merely report on, and I can tell you that from the errata release notes RedHat issued for these CVEs last night (2017-5715, 5753, 5754), the *measured* performance penalty varies from < 2%, UP TO 12%.

            [url<]https://access.redhat.com/articles/3307751[/url<] - for anyone else that is a RedHat customer But keep up the sensationalism, I'm sure it generates lots of clicks for whichever rumor-mongering site you work for.

            • IGTrading
            • 2 years ago

            You mean you haven’t yet identified the “real world scenarios” where the performance hit is visible. (if you try to play journalist)

            I happen to be working for 21 years in IT Hardware mate πŸ˜‰ The writing I’ve done was just a side step.

            Now I’m not “mongering” anything anywhere. I’m a technical expert.

            That doesn’t make you a “journalist” or able to “advise” on how “journalism” is done.

            I’m not going to say anything about your work skills because I don’t know what you do and how well you do it.

            Relax mate, I’m just stating my opinions about the bias that I perceive and that’s it. πŸ™‚ Not trying to convince you of anything.

            Believe what you want and enjoy your evening.

            • Meadows
            • 2 years ago

            You must have a very patient editor, because the way you write and format your comments is utter rubbish.

        • K-L-Waster
        • 2 years ago

        Yes yes, let’s just ignore the actual exploit description and base our conclusions about articles on how closely they follow the group think of our favoured forums and subreddits.

        • just brew it!
        • 2 years ago

        Actually, Meltdown affects only Intel chips; but Spectre potentially affects AMD (and likely ARM, and POWER) as well. It’s a more general attack.

          • IGTrading
          • 2 years ago

          Yes.

          It seems to only affect Linux on AMD and only in non-standard settings and there is no performance penalty in the patch.

          So why should we emphasize the fact that AMD’s chip has a easily fixable problem which only appears in some particular cases of Linux installs ?

          It is my opinion that we should emphasize that people need to update to be safe and caution Intel users that the update brings an “up to 53%” performance penalty in some situations. (as proven by Phoronix) .

          Everybody seems to have this “but AMD is affected too” reaction which is basically like ignoring 99% of the story and focusing on 1% .

            • just brew it!
            • 2 years ago

            You’re still completely missing the point that there are two different (but somewhat related) vulnerabilities here. One (Meltdown) is mitigated by kernel page table isolation; the other one (Spectre) is not.

            • IGTrading
            • 2 years ago

            No I’m not πŸ™‚ .

            I got that.

            They actually have 3 versions tested, in the attempt to see if AMD’s registers will leak the data, but they weren’t able to. For now.

            • Glorious
            • 2 years ago

            You’re missing even more points now: The registers aren’t leaking the data, the caches are indirectly because of timing.

            You clearly have absolutely no idea what you are talking about. Go away.

            • derFunkenstein
            • 2 years ago

            I admit I wasn’t totally getting this earlier today.

        • thedosbox
        • 2 years ago

        I’m disappointed they didn’t title the piece “AMD vulnerable to SPECTRE. Bond is nowhere to be seen”. That would have made the comments more “interesting” than this pathetic response.

        I particularly like that you’re whining about the first mention of Intel being “buried in the middle” of the article, whereas the first reference to either AMD or Intel states that AMD are *not* affected.

      • jihadjoe
      • 2 years ago

      Itanium bruh!

    • bog.us
    • 2 years ago

    [url<]http://www.change.org/en-CA/petitions/governments-of-the-world-punish-more-severely-hackers-and-computer-vulnerability-revealer?utm_source=guides&utm_medium=email&utm_campaign=kickstart_petition[/url<]

      • Ninjitsu
      • 2 years ago

      In the world of useless change.org petitions…

      • derFunkenstein
      • 2 years ago

      Why would the government punish, more often than not, its own sanctioned actions?

    • chuckula
    • 2 years ago

    Despite the koolaid drinking from some people who can’t understand the underlying technology but have no problem pretending that corporate press releases from the “right” companies tell the whole story, these exploits affect pretty much every modern CPU architecture from every manufacturer.

    Think ARM makes you safe? Nope.

    Think AMD is magic? Wrong.

    Think your POWER9 box can’t be affected… guess what, you got hit too!

    Here’s a good summary from Redhat: [url<]https://access.redhat.com/security/vulnerabilities/speculativeexecution[/url<]

      • freebird
      • 2 years ago

      So are you saying AMD is lying in their released statement? If so, then there are definitely legal repercussions which the SEC should investigate.

        • Redocbew
        • 2 years ago

        What they said may be technically correct for these two specific exploits, but this is a wide open topic that just went from being theoretical to practical. These will almost certainly not be the only two exploits we see focused on speculative execution.

          • freebird
          • 2 years ago

          Is that proof or just “speculation”… sorry couldn’t help that. Just had to have some fun with a pun.

          It is interesting in each companies statements AMD seems fairly confident in the statement, although NEAR ZERO and ZERO leave and infinity of possibilities no matter how “small”.

          I found it interesting that Intel didn’t say AMD chips were affected by any of these attacks, but stated Intel “…is working closely with many other technology companies, including AMD, ARM Holdings and several operating system vendors, to develop an industry-wide approach to resolve this issue promptly and constructively.” Thereby linking the other CPU manufactures into the security fiasco. I’m sure it was carefully parse by their lawyer team which will probably be earning their keep over the next several months. And AMD’s also if found to be untruthful in their responses.

            • Redocbew
            • 2 years ago

            It’s speculative, but my history table tells me I’m probably right. πŸ™‚

            Like Tipoo said below, it’s only Meltdown that AMD said wouldn’t be an issue. They said Spectre was being taken care of within the OS which is corporate speak for “yes, we’re in the same boat as everyone else, and someone else will probably release a fix for this long before we can.”.

            Once it gets patched, it’ll still be a very long time before new silicon is out in the wild that was designed with these things in mind, and even then there will probably have to be legacy code involved for backwards compatibility, so the fact that both AMD and Intel were terse in their statements doesn’t really surprise me. I’m sure the chipmakers would like nothing more than for all this to just go away.

            • nanoflower
            • 2 years ago

            Only problem I have with AMD’s statement is that Google says they already have a proof of concept exploit for the AMD CPUs. So either AMD is lying or Google is lying. Given that Google doesn’t benefit from lying while AMD does then I can guess who I think might be lying (or at least using very lawerly logic to be technically correct while giving an improper impression.)

            • mudcore
            • 2 years ago

            AMD states variant 1 does impact their CPUs, from my knowledge that is all that Google claims they have a PoC on AMD chips. Variant 2 which AMD claims “there is a near zero risk of exploitation” for their architectures the Google post only claims a PoC on for Intel Haswell, no statements of a PoC on an AMD chip. Variant 3 is the one dubbed “Meltdown” and is Intel specific.

            I’m going off what’s stated here: [url<]https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html[/url<] AMD's statements seem to be generally consistent with Google's.

            • freebird
            • 2 years ago

            nanoflower <– Neither is lying (as mudcore states and I’m expand upon here) , but the devil is in the details… after reading through the Google release here…

            [url<]https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html[/url<] My take is: ------------- The only variant that an AMD Processor (Pro A8-9600/Excavator arch) is vulnerable to that I would consider serious is Variant 1: bounds check bypass (CVE-2017-5753) which also requires "the kernel's BPF JIT is enabled (non-default configuration)" this allows "when running with normal user privileges under a modern Linux kernel with a distro-standard config, can perform arbitrary reads in a 4GiB range [3] in kernel virtual memory" The only other vulnerability of both the FX8320 (PileDriver Arch) and the (Pro A8-9600/Excavator arch) allows "...for the ability to read data inside mis-speculated execution within the same process, without crossing any privilege boundaries" Still bad, but does not allow reading/leaking Kernel memory. AMD Processors are mentioned in Variant 2 or 3; not to say they can't be affected, but no PoC yet exists, unlike Intel Has(not so)well Xeon CPU (sorry another pun) -------- Summary: only PileDriver & Excavator Arch have been shown to be vulnerable with Excavator being most vulnerable (Kernel Memory reads) but does require "the kernel's BPF JIT is enabled (non-default configuration)" Also the research mentions the bytes per second read speed for Haswell, but none listed for the AMD Pro which I find mildly interesting.... didn't they test it? If it is a PoC and they could time it for Haswell, I'm sure they could time it for the AMD Pro chip. I don't believe any AMD Server processors ever used anything past the PileDriver arch until EPYC emerged, but I could be wrong, I didn't research that. ***************************************************** ****UPDATED: info from [url<]https://spectreattack.com/spectre.pdf[/url<] ***************************************************** "We have empirically verified the vulnera- bility of several Intel processors to Spectre attacks, in- cluding Ivy Bridge, Haswell and Skylake based proces- sors. We have also verified the attack’s applicability to AMD Ryzen CPUs. " ****** Still, I see quotes about the speed that memory can be read with Intel processors "The unoptimized code in Appendix A reads approximately 10KB/second on an i7 Surface Pro 3." but none for the AMD or ARM processors. excerpt from Project Zero link --------------------------------------- So far, there are three known variants of the issue: Variant 1: bounds check bypass (CVE-2017-5753) Variant 2: branch target injection (CVE-2017-5715) Variant 3: rogue data cache load (CVE-2017-5754) Before the issues described here were publicly disclosed, Daniel Gruss, Moritz Lipp, Yuval Yarom, Paul Kocher, Daniel Genkin, Michael Schwarz, Mike Hamburg, Stefan Mangard, Thomas Prescher and Werner Haas also reported them; their [writeups/blogposts/paper drafts] are at: Spectre (variants 1 and 2) Meltdown (variant 3) During the course of our research, we developed the following proofs of concept (PoCs): A PoC that demonstrates the basic principles behind variant 1 in userspace on the tested Intel Haswell Xeon CPU, the AMD FX CPU, the AMD PRO CPU and an ARM Cortex A57 [2]. This PoC only tests for the ability to read data inside mis-speculated execution within the same process, without crossing any privilege boundaries. A PoC for variant 1 that, when running with normal user privileges under a modern Linux kernel with a distro-standard config, can perform arbitrary reads in a 4GiB range [3] in kernel virtual memory on the Intel Haswell Xeon CPU. If the kernel's BPF JIT is enabled (non-default configuration), it also works on the AMD PRO CPU. On the Intel Haswell Xeon CPU, kernel virtual memory can be read at a rate of around 2000 bytes per second after around 4 seconds of startup time. [4] A PoC for variant 2 that, when running with root privileges inside a KVM guest created using virt-manager on the Intel Haswell Xeon CPU, with a specific (now outdated) version of Debian's distro kernel [5] running on the host, can read host kernel memory at a rate of around 1500 bytes/second, with room for optimization. Before the attack can be performed, some initialization has to be performed that takes roughly between 10 and 30 minutes for a machine with 64GiB of RAM; the needed time should scale roughly linearly with the amount of host RAM. (If 2MB hugepages are available to the guest, the initialization should be much faster, but that hasn't been tested.) A PoC for variant 3 that, when running with normal user privileges, can read kernel memory on the Intel Haswell Xeon CPU under some precondition. We believe that this precondition is that the targeted kernel memory is present in the L1D cache.

        • tipoo
        • 2 years ago

        Looks like they’re saying they’re immune to the first, not the second. Not sure where the performance implications of the two patches fall

        [url<]https://www.amd.com/en/corporate/speculative-execution[/url<]

          • mczak
          • 2 years ago

          AMD is indeed saying they are immune to meltdown.
          spectre, noone is immune, but it’s more difficult to exploit, and those patches don’t help at all actually for this issue, neither on intel nor amd nor anywhere else. The core issue looks very difficult to fix to me in either software or hardware, albeit it may be more difficult to exploit depending on how the cpu exactly works. (Basically this attack works due to the branch predictor using state which isn’t per process, so you can influence branch prediction from another process and gain information that way due to the resulting timing differences.)

            • Srsly_Bro
            • 2 years ago

            I think you are mistaken.

            [url<]https://www.cnbc.com/amp/2018/01/03/amd-rebukes-intel-says-flaw-poses-near-zero-risk-to-its-chips.html[/url<]

            • Redocbew
            • 2 years ago

            CNBC, bro?

            So far the only thing AMD has really said about Spectre is that it’s being patched in the OS for one variant, and there’s no proof of concept on their hardware for the other. I suppose that’s their prerogative if they want to ignore the possibility until there is proof of concept. It doesn’t seem like there’s much they can do about it at the moment anyway.

        • hescominsoon
        • 2 years ago

        Intel is absolutely lying out its ass. AMD, however, is not being totally honest either. The attack known as Spectre DOES affect AMD. AMD is playing corporate pr in not saying their processors are immune to Meltdown..which is the one that hits Intel the hardest.

      • crabjokeman
      • 2 years ago

      You’ve drunk enough Kool-Aid to empty out Kool-Aid Man. Those who live in glass pitchers shouldn’t throw stones.
      “Oh, yeah!”

        • cynan
        • 2 years ago

        On the other hand, a glass pitcher than can bust through a brick wall unscathed can probably withstand a few stones.

      • LocalCitizen
      • 2 years ago

      let’s separate the issues:
      3 problems, and 1 fix

      – Meltdown is easily triggered on Intel, not AMD nor ARM
      – Spectre (2 variations) affects everyone, intel, amd, power, arm and leg, everyone

      – the fix is only for Meldown and it slows the performance in real life scenarios by 0-10% or so, and by up to 65% in pure synthetic tests (see Phoronix for his numerous tests)
      – the fix for Spectre does not exist — “The researchers further note that Spectre attacks are harder to carry out but also defy easy mitigation, as with Meltdown.”
      – since there’s no patch for Spectre, there is no performance penalty to speak of.

        • bhtooefr
        • 2 years ago

        Nitpick: ARM’s released a statement saying Cortex-A75 is vulnerable to Meltdown (Variant 3) as-is: [url<]https://developer.arm.com/support/security-update[/url<] Also worth noting that there's a further variant of Meltdown that allows access to the privileged registers, that Cortex-A15, A57, and A72 are vulnerable to, but they feel that no mitigation is necessary (registers not being as dangerous as arbitrary address space), and if an OS developer is concerned, to clear privileged registers before context-switching into unprivileged code.

      • the
      • 2 years ago

      Whoa, ye olde mainframe System Z in that Red Hat list. That is actually kind of surprising as the Z architecture intentionally avoided OoOE in part due to security. The first IBM mainframe to include OoOE was the Z196 introduced in 2010. The other oddity is that the zArch supports hardware memory encryption so conceptually even were able to read higher privileged memory, it’d be kind of worthless. Decryption keys for memory are not stored in memory but rather in a secure enclave.

      AMD’s Epyc also supposed memory encryption so it’d be interesting to see how this affects these exploits.

        • adisor19
        • 2 years ago

        IBM’s engineers/bean counters deserve some praise for actually sniffing this out a long time ago and putting in protections in place for it. I guess at the price that mainframes go for, they could afford it.

        Adi

      • Andrew Lauritzen
      • 2 years ago

      IMO anyone trying to point fingers at specific companies, OSes or chips here is severely missing the point, so let me spell it out: this is a very worrying new class of attack vectors that really blow open the traditional models of CPU and GPU process and memory isolation. Addressing these vectors fundamentally will require some significant rethinking and redesign of the core way that OS kernels and hardware interact, let alone VMs. *That* is the reason why everyone is freaking out and people are willing to issue patches on super short notice with non-trivial performance impact.

      Whether or not there are known exploits for a given CPU or OS today is not really the point. This is bad news for everyone in the long run.

        • windwalker
        • 2 years ago

        The whole blame and apologia game players are the ones actually “severely missing the point”.
        Most people are neither microprocessor nor operating system designers, but users of those products.
        For the users, the finger pointing and deflection tactics only serve to make it more difficult and frustrating to answer the only questions the vast majority of people care about:
        [list=1<] [*<]How does this impact me and my computer systems? [/*<][*<]How can I protect against it? [/*<][*<]What is the cost? [/*<] [/list<] Every else is just petty nonsense.

        • the
        • 2 years ago

        I would argue more toward worrisome in the short and medium term.

        Obviously there will be exploits that are quickly built to take advantage of the time frame between announcement and wide spread patch deployment. Proof of concepts seemingly exist in the wild already for Meltdown and it is only a matter of time before they’re adapted into malware. It is interesting to note that these exploits already had patches developed and is the incorporation of the Linux patch into the mainstream release process that let the cat out of the bag. So the beta testing process got trimmed in the name of security which I think was ultimately appropriate here. Additional patching can be done if the current patches are buggy. This is all short term in my book.

        Medium term is that the Spectre class is still open and it’ll need some hardware redesign to fix. Right now it is hard to envision a real exploit using this in the wild but then again it is difficult to imagine an flaw like Spectre to exist in the first place and be so wide spread. I fathom that it’d be some combination of flaws, say hypothetically Spectre + Rowhammer, to really become dangerous. It’ll take time for malware to incorporate something that complex into he wild… I hope. It takes hardware roughly 3 to 5 years to develop with the cut off of new features/changes roughly 18 months before release. So anything in the labs right now due out in ~2020 could carry the first wave of immune hardware. It’ll be wild ride the next couple of years as developers try to patch around these hardware flaws as they’re more commonly exploited.

        Long term this will all be settled but I do hope it teaches a lesson in validation. By the time the hardware fixes for this are out in the wild, some new idea could easily emerge that has a hidden flaw. In fact, there is still plenty of design concepts only recently introduced that could be further explored for side channel attacks. For example, Cascade Lake is set to introduce new ISA extensions for handling non-volatile memory and memory encryption.

        • IGTrading
        • 2 years ago

        Linus Torvalds is pointing at Intel :

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

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

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

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

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

        Intel never intends to fix anything

        OR

        these workarounds should have a way to disable them.

        Which of the two is it?

        Linus”

        When he says “mitigation patches should be written with “not all CPU’s are crap” in mind” , what CPUs do you think he means ?! Intel ?! πŸ˜‰

        No, re is referring to AMD and ARM.

          • techguy
          • 2 years ago

          Still stirring that pot, huh? Care to tell us which sites publish your writing or do you, by omitting this information, admit that you are in fact a troll?

            • IGTrading
            • 2 years ago

            Mate, I’m quoiting the founder Linux and the technical documentation of the team that found the design flaw.

            Care to put up some documentation of your own to prove some point, or just post random remarks with attempted insults ?

            Relax, I’m not insulted. πŸ™‚

            Have a good day and try posting something useful. I’m always willing to learn useful, smart stuff.

            • techguy
            • 2 years ago

            I guess you don’t read all the comments which are addressed to you. Try reading comment 40, then respond.

            • IGTrading
            • 2 years ago

            No πŸ™‚

            But I made an effort in this case and answered.

            Have a good evening!

          • Andrew Lauritzen
          • 2 years ago

          Yeah but it’s Linus… and you clipped the context that he’s wanting a toggle switch on the kernel mode page table isolation stuff with the hopes that it can be disabled again in the future (understandable as it’s a bit of a mess for software).

          Intel is certainly being a bit disingenuous with their PR, but so is AMD. That attack vector here is a serious one and I pretty much don’t believe anyone claiming they are immune to any possible variant of this. Remember: any time someone says “hasn’t been demonstrated on our silicon yet”, that’s what this whole thing was for everyone until a few days ago (months if you were in the know)…

          It’s possible the end state of this is something as drastic as processors having to have dedicated L1 I$’s (and more) for kernel mode, but that doesn’t even address the issue with VMs or to some extent, web scripting. Again, the real news here is that the way we’ve been doing code/process/kernel isolation likely needs to be rethought to some extent… characterizing this as a “bug” that someone will just “fix” is inaccurate.

            • derFunkenstein
            • 2 years ago

            [quote<]Remember: any time someone says "hasn't been demonstrated on our silicon yet", that's what this whole thing was for everyone until a few days ago (months if you were in the know)...[/quote<] And this is why I think it should be turned on for all CPUs. It's irresponsible to have a fix and not implement it prior to someone exploiting the (as-yet undiscovered) bug.

            • Redocbew
            • 2 years ago

            If it was built with a toggle switch, but defaulted to being switched on, then that’s probably the way it would stay for the vast majority of systems. Having the toggle switch in there just enforces better encapsulation of a feature like this which is kind of a mess, and makes you wish there was a better alternative. Things that are hardcoded tend to grow entrenched over time otherwise.

            • derFunkenstein
            • 2 years ago

            It’s built with a toggle switch but [url=https://lkml.org/lkml/2017/12/27/2<]AMD's contribution to the fix[/url<] is defaulting the toggle to off for its CPUs.

            • Redocbew
            • 2 years ago

            Yeah, that’s probably not the best idea from a purely engineering standpoint, but I suppose that’s up to Linus now.

            • derFunkenstein
            • 2 years ago

            I’m curious what Microsoft is doing. In the datacenter, Linux might be more popular, but Windows will affect more people overall.

            • HERETIC
            • 2 years ago

            KB4056894

            • the
            • 2 years ago

            Immunity should be possible today by simply not using speculative execution. Considering the history of these flaws going back decades, there are a couple of chips released in that time frame which would be immune. Notable from Intel are the Bonnell based Atoms, Itanium and the Larrabee based Xeon Phis. IBM had the console processors in the Xbox 360 and PS3 plus POWER6. ARM still offers various in-order designs. The obvious problem is that all of these designs which should inherently have been immune are currently phased out (with the possible exception of some select ARM IP).

      • blastdoor
      • 2 years ago

      what about Itanium?

        • Ninjitsu
        • 2 years ago

        See! We should have listened to them! πŸ˜›

        • IGTrading
        • 2 years ago

        Haha, yes.

        Good one! πŸ™‚

        • hescominsoon
        • 2 years ago

        not vulnerable to meltdown.

          • blastdoor
          • 2 years ago

          what about spectre? Wasn’t part of the motivation for Itanium to avoid OOE?

            • chuckula
            • 2 years ago

            Itanium was designed to avoid OOE but it had zero to do with avoiding side-channel data leak attacks when it was being drawn up in the early 1990’s.

            Instead it had to do with OOE being a big complex and power-hungry part of a CPU core. All of those assumptions were — and are — correct, but Itanium’s big failure was the belief that compilers could become good enough to schedule instructions at compile time in a way that would give you performance that’s close to OOE without needing the silicon to do it. That was wrong, which is why it’s not just Intel that’s doing OOE in 2018.

            • blastdoor
            • 2 years ago

            Yup, yup, and yup.

            But is Itanian immune to Spectre?

            If so, then even though that wasn’t the motivation for creating Itanium in the first place, might it be a reason to take another whack at the compiler challenges?

            • Redocbew
            • 2 years ago

            I think those are mostly unrelated problems. Patching exploits like Spectre and Meltdown is probably going to be a game of security whackamole until the chipmakers have a chance to work out the underlying vulnerabilities in the hardware.

      • cegras
      • 2 years ago

      [url<]https://lkml.org/lkml/2018/1/3/797[/url<] [quote<]Please talk to management. Because I really see exactly two possibibilities: - Intel never intends to fix anything OR - these workarounds should have a way to disable them. Which of the two is it? Linus[/quote<]

      • Cuhulin
      • 2 years ago

      AMD is not lying. The existing Spectre exploits do not affect AMD processors because the AMD processors implement speculative execution a little differently. However, AMD itself says that their processors are not subject to these exploits only “at this time” (or variations on that phrasing.)

      That is more than enough reason for AMD processors to sell and Intel processor purchases to be questionable right now. However, the basic concepts apparently apply to AMD and all modern processors, so there could be AMD vulnerability in the future.

    • Leader952
    • 2 years ago

    AMD response:

    [url<]https://www.amd.com/en/corporate/speculative-execution[/url<] [quote<]Variant / AMD Response Matrix Variant One: Bounds Check Bypass - Resolved by software / OS updates to be made available by system vendors and manufacturers. Negligible performance impact expected. Variant Two: Branch Target Injection - Differences in AMD architecture mean there is a near zero risk of exploitation of this variant. Vulnerability to Variant 2 has not been demonstrated on AMD processors to date. Variant Three:Rogue Data Cache Load - Zero AMD vulnerability due to AMD architecture differences. [/quote<] Edit: Additional information about Meltdown and AMD [quote<]Most notably, AMD claims that is has zero vulnerability to Variant 3 (Meltdown), stating that the patches that are currently being issued for Meltdown do not apply to its processors due to "architectural differences." This is excellent news for AMD, as it therefore has no exposure to the current round of potentially performance-sapping patches. That bodes very well for the company as it reenters the data center with a competitive line of EPYC processors. The Ryzen desktop processors are also not susceptible to Meltdown. Linus Torvalds has also granted AMD an exemption to the performance penalties incurred by the Linux patch for Meltdown. [url<]http://www.tomshardware.com/news/meltdown-spectre-exploits-intel-amd-arm-nvidia,36219.html[/url<] Linux Will End Up Disabling x86 PTI For AMD Processors - Update: Now Disabled [url<]https://www.phoronix.com/scan.php?page=news_item&px=Linux-Tip-Git-Disable-x86-PTI[/url<] [/quote<]

      • Redocbew
      • 2 years ago

      Thank you for being such a blatant extension of AMDs PR department. I much prefer that over those who try to be all sneaky about it.

        • NTMBK
        • 2 years ago

        Because sharing useful information makes him a shill? 0_o

          • Anovoca
          • 2 years ago

          psch, exactly what a Leader952 shill would say…..

          • derFunkenstein
          • 2 years ago

          In computer security terms, “near zero risk” = at risk

            • NTMBK
            • 2 years ago

            Indeed- AMD is susceptible to Spectre, just like every other OoO CPU out there. But they are not susceptible to Meltdown.

            • derFunkenstein
            • 2 years ago

            Doesn’t matter; that means that AMD needs KPTI just as much as Intel. Either there’s a vulnerability or there’s not.

            The important thing (to me) is the impact to Ryzen’s performance. AMD says the difference is negligible, so why are they irresponsibly submitting Linux kernel patches to opt their CPUs out of the fixes?

            • NTMBK
            • 2 years ago

            I was under the impression that KPTI did not fix Spectre?

            • derFunkenstein
            • 2 years ago

            Maybe not?

            [quote=”https://spectreattack.com/”<]There are patches against Meltdown for Linux ( KPTI (formerly KAISER)), Windows, and OS X. There is also work to harden software against future exploitation of Spectre, respectively to patch software after exploitation through Spectre.[/quote<] But the question, again, is if there's not a performance penalty on Ryzen why would you exclude it? Just because it hasn't been found vulnerable to an attack yet doesn't mean people aren't actively working on it. It seems AMD is saying its CPUs are magically secure and it gives the public a false sense of security. Folks can downvote me all they want, but I'm arguing for sensibility here.

      • blastdoor
      • 2 years ago

      How about this:

      [url<]https://www.extremetech.com/computing/252523-ibms-new-z-mainframe-can-encrypt-data-time[/url<] ?

        • derFunkenstein
        • 2 years ago

        It might be cool and it might be secure, but the article reads like sponsored content. Everything is laid out as fact rather than IBM’s assertions, and none of the figures are questioned (400% more custom silicon than previous IBM servers, but how much was in the past, for example).

          • blastdoor
          • 2 years ago

          well, sure. I wasn’t endorsing the article.

          I’m just wondering if memory encryption helps with Spectre or not. I guess at some point it has to be unencrypted… and the point at which Spectre attacks seems likely to be a point where the memory is not encrypted. But I don’t know, so I thought I’d ask….

          edit: ah, I see others are discussing this in another subthread. Nevermind!

            • derFunkenstein
            • 2 years ago

            Maybe. Guess it depends where this custom silicon is and when the data is finally decrypted. Definitely a good question.

    • chuckula
    • 2 years ago

    Time to call 007 if Spectre is being a nuisance again.

      • the
      • 2 years ago

      I am Commander Shepard and this is my favorite comment on Tech Report.

      • Growler
      • 2 years ago

      Blofeld’s plot to take over the tech industry is better than Zorn’s, for sure.

      • EndlessWaves
      • 2 years ago

      I’ll let you break the news that Q division is out of action on this one.

    • lem18
    • 2 years ago

    Gotta melt(down) the butter on my popcorn for this one.

      • adisor19
      • 2 years ago

      There ain’t enough popcorn in the world to cover this situation..

      Adi

        • NovusBogus
        • 2 years ago

        I tried to buy some, but the popcorn company said they were out of orders.

          • derFunkenstein
          • 2 years ago

          So you’re saying there was merely the Spectre of Popcorn Past?

            • Redocbew
            • 2 years ago

            No doubt the popcorn company was attempting to branch out and diversify.

            • derFunkenstein
            • 2 years ago

            It’s hard to predict where the market will go.

            • Wirko
            • 2 years ago

            Shall we buy popcorn or shall we keep the cache?

      • ronch
      • 2 years ago

      And you can do that using your CPU.

    • Redocbew
    • 2 years ago

    I don’t know who designed the logos, but I love that the Spectre ghost wields a stick.

      • Ryu Connor
      • 2 years ago

      [url=https://vividfox.me/<]Natascha Eibl[/url<] created the logos and they have been released to the public domain. There are links to PNG and SVG versions of the images at the bottom of the meltdownattack.com site.

      • Clint Torres
      • 2 years ago

      It’s not a stick…it’s a branch <rimshot>!

        • Redocbew
        • 2 years ago

        That makes it even better. πŸ™‚

      • ronch
      • 2 years ago

      Did they really have to design logos for these vulnerabilities? Or (Conspiracy Theory = 1) did these chip companies deliberately left a door open for the purposes of the Illuminati?

        • the
        • 2 years ago

        They had six months between now and when the flaws were first discovered. I think they had some time in there to doodle.

      • freebird
      • 2 years ago

      That actually isn’t a stick… it is a +5 Rod of Smiting with 5%-30% chance of CPU disintegration(degradation).

      ;D

Pin It on Pinterest

Share This