Slashdot Mirror


Intel Plans To Release Chips That Have Built-in Meltdown and Spectre Protections Later This Year (businessinsider.com)

Intel plans to release chips that have built-in protections against the Spectre and Meltdown attacks later this year, company CEO Brian Krzanich said during company's quarterly earnings call this week. From a report: The company has "assigned some of our very best minds" to work on addressing the vulnerability that's exploited by those attacks, Krzanich said on a conference call following Intel's quarterly earnings announcement. That will result in "silicon-based" changes to the company's future chips, he said. "We've been working around clock" to address the vulnerability and attacks, Krzanich said. But, he added, "we're acutely aware we have more to do."

154 comments

  1. Fool me thrice by Anonymous Coward · · Score: 2, Insightful

    From the people who brought you F00F, FDIV, and now Meltdown? No thanks.

    1. Re:Fool me thrice by Anonymous Coward · · Score: 1

      They have assigned some of their very best minds. Top men.

    2. Re:Fool me thrice by Anonymous Coward · · Score: 0

      Top. Men.

    3. Re:Fool me thrice by Anonymous Coward · · Score: 0

      The problem is that their designs are poisoned, and everybody uses it or at least seem to use the same poisoned design model, AMD suffers the same problems and some ARM too.

    4. Re:Fool me thrice by Anonymous Coward · · Score: 0

      Hmm no, AMD and ARM don't suffer from F00F, FDIV, or Meltdown

    5. Re:Fool me thrice by Anonymous Coward · · Score: 0

      TOP. MEN!

  2. So in the end by fisted · · Score: 4, Insightful

    So in the end, Intel is going to make a shitton of money on Meltdown and Spectre because everybody is supposed to buy their new, fixed CPUs

    1. Re:So in the end by alvinrod · · Score: 5, Interesting

      Personally I'm probably going to buy AMD for my next build. I've got an Ivy Bridge that's still serviceable enough, but now that 8-core chips have come down to mainstream prices and AMD doesn't have anemic performance compared to Intel for most workloads, I'm more than willing to give them my business. They should have their CPU lineup refreshed around April and I expect NVidia to start launching their newest line of Volta GPUs around that time as well so it's a good time to put together a new PC.

    2. Re:So in the end by TheDarkMaster · · Score: 2, Interesting

      I second that. Also waiting for Zen+ to see it they will deliver enough performance to justify a change from my current CPU. I could buy an i9 but honestly, pay dearly for a processor that uses mayonnaise between die and lid? I did not buy a Threadriper just because of the problems to run games/memory compatibility, otherwise I would have already switched.

      --
      Religion: The greatest weapon of mass destruction of all time
    3. Re:So in the end by Anonymous Coward · · Score: 0

      I did not buy a Threadriper just because of the problems to run games/memory compatibility, otherwise I would have already switched.

      Your daily dose of regular inteltard bullshit.

        hurr durr, memry dont vork.

        0.002 shekels have been deposited to your account.

    4. Re:So in the end by TheDarkMaster · · Score: 2

      Oh look, a little snowflake here with some serious cognitive problems. A normal person would ask first why I think Threadripper is not good for games and I would respond, but seens the methamphetamine abuse has melted the cognitive part of your brain, right? I'm sorry, then I will pass to you the version "for birds" from my comment when I have time.

      --
      Religion: The greatest weapon of mass destruction of all time
    5. Re:So in the end by Anonymous Coward · · Score: 0

      This is exactly *why* Meltdown and Spectre arose to the surface now. The PC market has been slumping for a while, and it was time to invoke one of the planned obsolescence mechanisms that they had previously baked-in.

      Yes, I know the story we have been told about how it was discovered, etc. The dog was wagged.

       

    6. Re: So in the end by Anonymous Coward · · Score: 0

      This was pretty much an industry accepted architecture design choice blunder. Your average consumer won't be updating their processors for the sake of security, especially something as complicated as this to explain.

      Most enterprise environments will be pushing new processors out on fairly regular schedule as well, applying software patches as fixes in the meantime until hardware design changes are more standard or upgrades are already deemed necessary.

      I don't think Intel made much money off this at all, maybe a small blip which may be countered by the negative publicity. Also, so many of your average consumers now rely on ARM as their one and only architecture anywho.

    7. Re:So in the end by chispito · · Score: 2

      So in the end, Intel is going to make a shitton of money on Meltdown and Spectre because everybody is supposed to buy their new, fixed CPUs

      That was most of Slashdot's initial reading on the situation:

      Their stock is going nowhere but up. The time it takes them to correct their architecture is far lower than the time it will take all their customers to migrate to a different architecture.

      --
      The Daddy casts sleep on the Baby. The Baby resists!
    8. Re:So in the end by malikto · · Score: 2

      AMD has some interesting CPU level protections in place. The RAM encryption (SME/SEV) is a nice thing, because it protects against leaks from VM to VM, as well as if the hypervisor has bugs. For a VM farm, this looks very interesting. I just hope AMD keeps playing in the enterprise sector, as competition here is always a plus.

    9. Re:So in the end by Anonymous Coward · · Score: 0, Interesting

      I'll never buy AMD because you can't get a laptop with an AMD CPU with an Nvidia GPU. There is no way I'm going to put up with buggy, incompatible AMD GPUs and drivers.

    10. Re:So in the end by Solandri · · Score: 1

      Pretty much every CPU maker was affected by Spectre. It was an oversight in how speculative execution could be abused and thus affected all CPU designs, it wasn't an accidental implementation bug like the FDIV bug. So now that "we know better" yes future CPUs are going to be superior in this regard. Just like once we realized making car bodies stronger was actually causing more occupants to be killed, newer cars designed with crumple zones were safer. No specific company was at fault here - human knowledge was.

      Meltdown was more specific to Intel, and fixing it eliminates a good chunk of Intel's performance advantage over AMD. So it will cost them in lost CPU sales to AMD.

    11. Re:So in the end by Anonymous Coward · · Score: 0

      Hopefully they remembered to add a new vulnerability for the next upgrade cycle.

      - signed
      Intel shareholders.

    12. Re: So in the end by aliquis · · Score: 1

      My i7 8700K crashes like crazy with 3466 mhz cl16 ram from motherboard qvl so don't worry about ryzen just doing 3200 mhz.
      Also new models in April. Threadripper seem to have better support than ryzen.

    13. Re:So in the end by Anonymous Coward · · Score: 0

      Intel had already lost its performance advantage with the introduction of AMD's Zen architecture. Patching Meltdown will put them at a disadvantage.

    14. Re:So in the end by Anonymous Coward · · Score: 0

      0.002 shekels have been deposited to your account.

      Nice backhanded racist comment, you simpleton toolbag..

    15. Re:So in the end by Anonymous Coward · · Score: 0

      I pointed this out on day one, and got down voted to hell for it.

    16. Re:So in the end by Anonymous Coward · · Score: 0

      Nice backhanded racist comment, you simpleton toolbag..

      currency is racist

    17. Re:So in the end by TheRealMindChild · · Score: 3, Informative

      If you have something to say, then say it. Don't make other people ask you what you are talking about.

      --

      "When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
    18. Re:So in the end by Anonymous Coward · · Score: 0

      some serious cognitive problems

        let's see some serious problems

      problems to run games

        apparently when you click dota2.exe, TR4 doesn't run it

      memory compatibility

        in other words, you want to pick some random ram kit off the shelves and your RGB leds won't light up.

        But hey, you'd gladly buy an i9, but you don't want the IHS intel is using.

      Let me think, you don't care that it is an already dead platform that is not going to be supported any more by new products,
      you don't care that it stresses the VRM and the motherboard and we've seen cases of frying sockets, you don't care that you will need a kilowatt PSU, you don't care about the IME security wholes, you don't care about the MELTDOWN and SPECTRE problems that surfaces a few weeks ago and their rushed patches brick or slows down systems, you don't care that those cpus suffer when they run their newest shinniest AVX version and throttle down to keep the thermals at a sufferable levels.

      One talks about serious cognitive problems, but doesn't even have a reality perception.

      another 0.02 shekels have been deposited to your account.

    19. Re:So in the end by TheDarkMaster · · Score: 1

      It's that I actually did not find it necessary in the original comment, but since you asked politely I'll tell you

      Let's say that my current desktop has "X" performance, I've defined to myself that I should only change when new hardware is at least 50% better than the current one (a i7 4930K@4GHz). When the Threadripper appeared I thought I had found the ideal candidate, and in fact in multitasking applications it is several times better than my current desktop.

      However, the TR performance on games (especially old games) is at most comparable to my current hardware (the games I enjoy playing can not make effective use of multithreading), so in terms of games I would not be really upgrading. The Threadripper also have that problem with the way it accesses the memory (high latency depending on which core is accessing which bank), which is not exactly a problem for normal desktop applications but hinders games where you are trying to extract every possible frame.

      So I have a situation where it pays to upgrade on one activity but it does not pay off on the other, so I decided to wait. But now with the Zen+ AMD might get the extra performance per core I need to old games (and better memory controller maybe), then there will be time to upgrade.

      --
      Religion: The greatest weapon of mass destruction of all time
    20. Re:So in the end by TheDarkMaster · · Score: 1

      it's clear enough that I'm thinking of buying an AMD and I'm just waiting the launch of Zen+ to do it, braindead. You only proved what I said about you ;)

      --
      Religion: The greatest weapon of mass destruction of all time
    21. Re:So in the end by Anonymous Coward · · Score: 0

      high latency depending on which core is accessing which bank

      Um, what? TR literally has a 'game mode' designed explicitly for the scenario you are discussing - it isolates the logical threads to a single die so you don't cross fabric for memory calls. So you get high-end single die performance for your shitty synthetic benchmark games FRAPS jerk-off, and a hilarious amount of threads for anything that can actually utilize it effectively. FWIW, game devs are *STILL* terrible at writing engines to take advantage of parallelization, so 'high end' gaming is kind of a stupid metric to chase on CPUs that are't designed for it. I don't know what your other home-use workflows are, but in my case, video trans-coding and real-time CAD more than justify the upgrade cost to TR, and I'm not 'sacrificing' anything to game other than the cost.

      Either you're choosing not to upgrade for non-gaming workflows because the gaming performance isn't enough for your e-peen, or you're choosing to cripple non-gaming workflows out of some ridiculous expectation that you'll only upgrade when everything is empirically better.

    22. Re:So in the end by Anonymous Coward · · Score: 0

      I've been thinking about this as well. I too have a strong Ivy Bridge machine that has been serving well for years. My plan was to build another beast in early 2019 to replace it. Now I'm starting to think the next big machine may be my last; I certainly expect it to function for 5+ years and by that time I wonder if I'll want another.

      And what to build? AMD is back in the game and have new models in April... Intel has just broadcast their next punch with this news... Guess I'll wait and see. I'm inclined to buy Intel due to virtualization; Intel CPUs are better for that use case if only because they've dominated the market for years and all the virtualization software is wedded tightly to Intel's architecture. Anyhow, I think I'm going to go very big because the next one will be around for a long time.

    23. Re:So in the end by Anonymous Coward · · Score: 0

      Good for you. I have been running a pure AMD system for 4 years now without a single problem, unlike my old laptop with a Quadro card that would bluescreen on boot (only on Windows, it ran perfectly on Linux).

    24. Re:So in the end by MachineShedFred · · Score: 1

      Note: have not read TFA. But the headline is "built-in meltdown and spectre protection"

      That doesn't sound like "fixed" - that sounds like "mitigated" or "avoided"

      This is a hardware hack, not a proper fix.

      --
      Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
    25. Re:So in the end by Anonymous Coward · · Score: 0

      Good for you, fanboy. I have seen nothing but game bugs, graphics corruption, instability and unoptimised drivers from ATI/AMD GPUs.

    26. Re: So in the end by Brockmire · · Score: 2

      "apparently when you click dota2.exe, TR4 doesn't run it" Try double clicking.

    27. Re:So in the end by TeknoHog · · Score: 1

      Pretty much every CPU maker was affected by Spectre. It was an oversight in how speculative execution could be abused and thus affected all CPU designs, it wasn't an accidental implementation bug like the FDIV bug.

      Meltdown was more specific to Intel, and fixing it eliminates a good chunk of Intel's performance advantage over AMD. So it will cost them in lost CPU sales to AMD.

      Apparently, Meltdown is neither "an oversight" nor "an accidental implementation bug". It's more like "fuck security, let's make this fast". Meanwhile, AMD is left looking like the square, nerdy kid who did everything right in a world of loudmouth salespeople, and we can only hope he gets the girl before the end titles.

      --
      Escher was the first MC and Giger invented the HR department.
    28. Re:So in the end by Anonymous Coward · · Score: 0

      Worked for Experian.

    29. Re: So in the end by Targon · · Score: 1

      You may have missed that Ryzen can go up beyond DDR4-3600 memory now. The new AGESA 1.0.0.0a isn't perfect yet, but the platform has been seeing some nice improvements.

    30. Re: So in the end by aliquis · · Score: 1

      My point really is that enabling XMP on the ASUS Z370-F Strix motherboard claiming support for up to 4000 MHz memory OC depending on the processor with an i7 8700K and Corsair Vengeance RGB 3466 MHz CL 16 2x8 GB kit on the QVL list of the Z370-F and with Samsung B-die chips AFAIK doesn't work reliably and generate memory errors in memtest86 within seconds-minutes on test 6 (block move) and crashes on a daily bases at normal use.

      So clearly 3466 MHz with the i7 8700K I happen to have didn't worked either.

      I haven't been following Ryzen lately but I assume Ryzen 2000-series will improve things too.

    31. Re:So in the end by drinkypoo · · Score: 1

      The time it takes them to correct their architecture is far lower than the time it will take all their customers to migrate to a different architecture.

      Is that really true? They're struggling just to get out a patch, in spite of being considered highly competent at programming what with their compiler being so good and all. (And also so good at making code that doesn't run quickly on AMD processors even though it can do so — use gcc or even Microsoft's compiler instead for superior results on amd64! But I digress.) They're considered highly competent at making CPUs, but they don't actually seem to be as competent as their competitors. So will they actually be able to fix this problem in a timely fashion? Will they botch the fix? They botched the design, after all, and have so far botched the patches.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    32. Re:So in the end by Tough+Love · · Score: 1

      Also waiting for Zen+ to see it they will deliver enough performance to justify a change from my current CPU.

      Why wait? Posting from a Ryzen 1700 with 32GB. This is a budget build that arguably out-muscles high end Intel workstations. It's not just the multi-core performance that rocks, but energy sipping power performance. And single threading performance is far from shabby. Intel can't match this for the money, and maybe can't match it even if money isn't a factor.

      Next step up for me will be the Threadripper refresh. Not a budget proposition but the value is there, and currently is the performance king. Budget motherboards are not a thing in this segment, and that is kind of nice. I almost went Threadripper this build, but in the end, cheap won me over.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    33. Re:So in the end by Tough+Love · · Score: 1

      I have seen nothing but game bugs, graphics corruption, instability and unoptimised drivers from ATI/AMD GPUs.

      Hello, wizened story teller. Neolithic age called and wants you back.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
    34. Re:So in the end by TheDarkMaster · · Score: 1

      Why wait? I am waiting because if is to pay a lot then I'll pick up something that has Threadripper performance for multitasking and also has more gaming performance than my current config, and maybe Zen+ or Zen2 will fulfill that goal.

      --
      Religion: The greatest weapon of mass destruction of all time
    35. Re:So in the end by TheDarkMaster · · Score: 1

      Well I have to be careful about the time to upgrade because I live in a shithole country where you have to pay twice as much for decent hardware. So yes, I'm waiting for the moment when the available hardware becomes arguably superior in any scenario because only then will be a good idea to do the upgrade, is too expensive to do that too soon.

      --
      Religion: The greatest weapon of mass destruction of all time
    36. Re:So in the end by Tough+Love · · Score: 1

      Why wait? I am waiting because if is to pay a lot then I'll pick up something that has Threadripper performance for multitasking and also has more gaming performance than my current config, and maybe Zen+ or Zen2 will fulfill that goal.

      You don't pay a lot for Ryzen right now, a 1700 costs $290 and a decent AM4 board runs around $90. That gets you into a highly respectable box that no doubt makes your current one look old and feeble, including in game performance. Your box is five years old, right? Has half the cores and one quarter the threads of Ryzen? You will be moving from DDR3 1333 to DDR4 2400 or better. Seems like a no-brainer.

      To get into Threadripper you triple the cost at least, and you get a best on the block enthusiast machine, if that is what you are into. Threadripper is the only game in town at that level. I will go there when Zen+ comes out, any day now. I am instantly addicted to the dead silent Ryzen power performance with ordinary fans and I want more of that with the 12nm update. Zen2... believe it when you see it. I would not put off any upgrade plans in the hopes that 7nm is going to come online smoothly.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
  3. Wat by Anonymous Coward · · Score: 0

    So instead of removing the vulnerability, they... will... build in more stuff to protect the CPU from its own inherently flawed design? Now I'm definitely moving to AMD for good.

    1. Re:Wat by aliquis · · Score: 1

      I assume they will built in a check for what memory is accessed, just like AMD already have.

      So.. I guess it's .. ARM for you or something.

    2. Re:Wat by thegreatbob · · Score: 1

      They should be happy enough with a Zilog. Just slip them a TI 83 or similar under the basement door and run away quickly.

      --
      There is no XUL, only WebExtensions...
    3. Re: Wat by Anonymous Coward · · Score: 0

      I assume they will built in a check for what memory is accessed, just like AMD already have.

      You are most definitely an ass, but don't drag other people in.

      That's not how it works: neither AMDs native immunity or Intels proposed fixes for those who know under NDA.

    4. Re: Wat by Brockmire · · Score: 1

      It would be poetic justice if Intel had to license AMD'S implementation protection.

  4. Hopefully it will be secure by default... by wierd_w · · Score: 4, Insightful

    I a reminded of Torvald's scathing emails about Intel, their proposed patch sets, and how they pointed toward intel wanting to make future chips "Fast but insecure" by default, and requiring the BIOS or OS to tell the CPU "No bitch, secure mode only please", just so they could continue to claim benchmark scores (naturally, with the anti-spectre and meltdown patches disabled so the chip runs really fast.)

    Hopefully these silicon level fixes are *ACTUAL* fixes to the methodology used by the speculative execution implementation of the chip, so that speculative execution still is active, but the chip no longer leaves bits and pieces in the processor cache that can be exploited, and that it does this by default.

    Hopefully.

    1. Re:Hopefully it will be secure by default... by gweihir · · Score: 1

      Since actual fixes would impact performance, that hope is slim. It will be the least they can get away with calling "a fix".

      --
      Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
    2. Re:Hopefully it will be secure by default... by TimothyHollins · · Score: 1

      Hopefully these silicon level fixes are *ACTUAL* fixes to the methodology used by the speculative execution implementation of the chip, so that speculative execution still is active, but the chip no longer leaves bits and pieces in the processor cache that can be exploited, and that it does this by default.

      Hopefully.

      I can only assume that you are on copious amounts of drugs.

      Intel hasn't gotten where they are by doing what's best for the consumer. In fact, at every given opportunity, they have taken the distinctly customer-butt-violating path instead.

    3. Re:Hopefully it will be secure by default... by Anonymous Coward · · Score: 0

      Intel hasn't even come close to figuring out how to really fix the problem. [Hint: it's the side channels, not the speculative execution.]

      I would suggest turning cache control over to the OS in future chips, so that process can be isolated form impact one another if the OS so desires.

    4. Re:Hopefully it will be secure by default... by infolation · · Score: 4, Funny

      intel wanting to make future chips "Fast but insecure" by default, and requiring the BIOS or OS to tell the CPU "No bitch, secure mode only please", just so they could continue to claim benchmark scores (naturally, with the anti-spectre and meltdown patches disabled so the chip runs really fast.)

      Which is effectively the VW-emissions-scandal school of benchmarking.

  5. never look back, thats for sure. by nimbius · · Score: 4, Funny

    INTEL: we've assigned some of our very best minds to developing new chips with built in protections
    Slashdotters: what about the 8 generations of chips that do not have such protections and in fact require massive performance losses to protect?
    INTEL: very...best...minds.

    --
    Good people go to bed earlier.
    1. Re:never look back, thats for sure. by dyfet · · Score: 1

      Let me correct this for them...

      assigned some of our very best marketing minds minds to sell suckers entirely new chips with built in protections disabled by default

    2. Re:never look back, thats for sure. by Anonymous Coward · · Score: 0

      Did they just hire them?
      Or were they here all along?

    3. Re:never look back, thats for sure. by Anonymous Coward · · Score: 0

      You are both very snarky and very wrong. Since it's a hardware fix, there isn't anything they can do for old chips.

      It's not like you can take it to the CPU mechanic and have him swap out the defective access protection gates. Or, in the case of Meltdown, install protections that don't currently exist.

    4. Re:never look back, thats for sure. by 110010001000 · · Score: 2

      Exactly. There isn't anything they can do. Just take your old $1000 CPU and throw in it in the trash and get a new $1000 CPU when they come out. I don't know what everyone is complaining about?

    5. Re:never look back, thats for sure. by chefren · · Score: 2

      Buy an AMD this time?

    6. Re:never look back, thats for sure. by Anonymous Coward · · Score: 0

      It reminds me of the Indiana Jones movie, "Raiders of the Lost Ark"

      "We have top men working on this"

      Movie ends with a fork lift taking a box and shelving the ark in a huge warehouse.

    7. Re:never look back, thats for sure. by Anonymous Coward · · Score: 0

      TOP... MEN.

    8. Re:never look back, thats for sure. by Anonymous Coward · · Score: 0

      there isn't anything they can do for old chips

      So when these problems were discovered the CPU in my motherboard somehow soldered itself down and now can't be replaced with a CPU that works as Intel claimed at the time I bought it?

  6. did intel know about spectre and meltdown? by Anonymous Coward · · Score: 0

    so roughly 1 year from "discovering" these vulnerabilities to retail cpu's based on fixed silicon, is this doable? or is it more plausible they knew about this before it's disclosure and had these planned and engineering samples already made when these vulnerabilities were made public?

    1. Re:did intel know about spectre and meltdown? by Anonymous Coward · · Score: 0

      AC because of moderation, but:

      I assume they are redesigning products that are currently under development, and possibly even retaping products that are already in the pipeline.

      Retaping will cost a lot of lot of money and implies a schedule slip, but if they haven't announced a launch date for the next gen CPUs yet then no one will really notice the delay.

    2. Re:did intel know about spectre and meltdown? by Megol · · Score: 1

      Fixing silicon is "creap" - a lot of cash and a lot of time (making masks and manufacturing the chips).

      Verifying that the fix is correct will probably be very expensive.

  7. Flush by Anonymous Coward · · Score: 0

    From what I understand about the vulnerability, all they need to do is flush the execution pipelines and cache after a context switch - if a speculative branch has occurred. It can incur a performance hit under certain circumstances, but unless your OS is constantly context switching, it won't be that big of a deal.

    For VMs, you can mostly mitigate this with CPU affinity.

    1. Re:Flush by Gr8Apes · · Score: 2

      From what I understand about the vulnerability, all they need to do is flush the execution pipelines and cache after a context switch

      Which is already the most expensive operation on an Intel CPU, and happens all the time in our current workloads.

      --
      The cesspool just got a check and balance.
    2. Re:Flush by Hal_Porter · · Score: 3, Interesting

      Spectre works by getting speculatively executed code access kernel mode memory. So they'd need to do protection checks before the speculative code did the access.

      https://medium.com/@mattklein1...

      1. In the first line, a âoeprobe arrayâ is allocated. This is memory in our process which is used as a side channel to retrieve data from the kernel. How this is done will become apparent soon.
      2. Following the allocation, the attacker makes sure that none of the memory in the probe array is cached. There are various ways of accomplishing this, the simplest of which includes CPU-specific instructions to clear a memory location from cache.
      3. The attacker then proceeds to read a byte from the kernelâ(TM)s address space. Remember from our previous discussion about virtual memory and page tables that all modern kernels typically map the entire kernel virtual address space into the user process. Operating systems rely on the fact that each page table entry has permission settings, and that user mode programs are not allowed to access kernel memory. Any such access will result in a page fault. That is indeed what will eventually happen at step 3.
      4. However, modern processors also perform speculative execution and will execute ahead of the faulting instruction. Thus, steps 3â"5 may execute in the CPUâ(TM)s pipeline before the fault is raised. In this step, the byte of kernel memory (which ranges from 0â"255) is multiplied by the page size of the system, which is typically 4096.
      5. In this step, the multiplied byte of kernel memory is then used to read from the probe array into a dummy value. The multiplication of the byte by 4096 is to avoid a CPU feature called the âoeprefetcherâ from reading more data than we want into into the cache.
      6. By this step, the CPU has realized its mistake and rolled back to step 3. However, the results of the speculated instructions are still visible in cache. The attacker uses operating system functionality to trap the faulting instruction and continue execution (e.g., handling SIGFAULT).
      7. In step 7, the attacker iterates through and sees how long it takes to read each of the 256 possible bytes in the probe array that could have been indexed by the kernel memory. The CPU will have loaded one of the locations into cache and this location will load substantially faster than all the other locations (which need to be read from main memory). This location is the value of the byte in kernel memory.

      Using the above technique, and the fact that it is standard practice for modern operating systems to map all of physical memory into the kernel virtual address space, an attacker can read the computerâ(TM)s entire physical memory.

      Now, you might be wondering: âoeYou said that page tables have permission bits. How can it be that user mode code was able to speculatively access kernel memory?â The reason is this is a bug in Intel processors. In my opinion, there is no good reason, performance or otherwise, for this to be possible. Recall that all virtual memory access must occur through the TLB. It is easily possible during speculative execution to check that a cached mapping has permissions compatible with the current running privilege level. Intel hardware simply does not do this. Other processor vendors do perform a permission check and block speculative execution. Thus, as far as we know, Meltdown is an Intel only vulnerability.

      Edit: It appears that at least one ARM processor is also susceptible to Meltdown as indicated here and here.

      Seems like there are two options. One is to do privilege checks before speculative code is executed. Another would be roll back the state of the cache on a protection fault.

      The later one appeals actually. In a GP fault handler you could just invalidate the cache line to foil step 7. And you don't need to slow down the common case where speculative

      --
      echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
    3. Re:Flush by amorsen · · Score: 3, Informative

      Seems like there are two options. One is to do privilege checks before speculative code is executed. Another would be roll back the state of the cache on a protection fault.

      The later one appeals actually. In a GP fault handler you could just invalidate the cache line to foil step 7. And you don't need to slow down the common case where speculative execution doesn't execute code which causes a GP fault.

      That should work great on uniprocessor single-threaded. However it should be possible to let another core or hardware thread watch whether the cache line gets locked by carefully timing access, and that probably gives the adversary some of the same information. By the time the cache line is invalidated, the adversary already got what they wanted.

      Even if I'm wrong and this attack is infeasible, you have only prevented Meltdown, not Spectre.

      Spectre hits you when you try to execute untrusted code such as JavaScript in a VM. The VM runs at the same privilege level as the untrusted code, so the CPU does not have any protection boundaries to stop it from speculatively executing into the wrong area. There will be no protection fault, the CPU will just realize that oops the speculation was wrong and do the unwind. You will have to extend your proposal to do cache invalidation on all unwinds, not just protection faults.

      --
      Finally! A year of moderation! Ready for 2019?
    4. Re:Flush by Anonymous Coward · · Score: 0

      Spectre flaw != Meltdown flaw.

    5. Re:Flush by Hal_Porter · · Score: 1

      Uh, yeah. I do.

      --
      echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
    6. Re:Flush by Hal_Porter · · Score: 1

      The process doing the probing gets the GP faults. It's relying on the fact that even though the accesses fault they still affect the cache. So you could clean up that in the GP fault handler before you return to the process, do a context switch or execute any untrusted code.

      Actually you could do this in software. Which makes me wonder why no one has thought of it, because it seems a bit obvious. Maybe it's flawed in someway.

      A bit of Googling turns up this

      https://security.stackexchange...

      Fixing Meltdown is relatively easy (compared to Spectre), although it probably can't be done with a microcode update. As well as setting a fault-if/when-this-reaches-retirement bit on the uop, a TLB lookup could gate the page-address bits (to all ones) with the privilege-check. e.g. a load in user-space from any kernel page could micro-architecturally execute as a load from the very top physical page. (And systems with less than the max amount of RAM wouldn't have any physical RAM at that physical address.)

      Or a failed privilege check could maybe still allow the load to happen microarchitecturally, but mask the result to all-zero in the load port. (Remember, the Meltdown problem isn't that an unprivileged load can bring kernel data into cache, it's that the secret data load result can be used to make another load with a data-dependent address. Continuing speculative execution with a zero result for any under-privileged load that hits in the TLB wouldn't allow any data-dependent microarchitectural effects).

      I.e. you do the virtual to physical translation using the TLB but you make invalid addresses map to an address with all ones. Since you have to do the V to P translation anyway, that seems like a good option.

      I'm guessing Intel will do something in the next generation batch of chips out - basically hack the current generation with the fix. With a bit of luck Meltdown has put the ph3ar of the h@xx0rz into them and they'll do that at top priority.

      It still means it's not a good time to buy a new PC though - anything you buy now will need KPTI or the equivalent enabled. It's claimed that on chips with PCID support KPTI isn't too bad, but that is dependent on what you're doing with the machine.

      --
      echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
    7. Re:Flush by Anonymous Coward · · Score: 0

      "Meltdown" means kernel memory access from user mode. Why "Meltdown" is a problem is pretty obvious. That's the Intel-only problem. They don't check access restrictions until after the memory access. "Spectre" on the other hand means accessing memory that the code could normally access, but through a side channel. It is non-trivial to explain why "Spectre" is a problem despite not technically violating any CPU-level access restrictions. The lack of an access violation makes protecting against Spectre difficult at the CPU level. Fortunately the problem is limited to certain use cases, most notably JIT compilers. (Other problem cases include return-oriented programming attacks.) In the case of JIT compilers (think Javascript in a web page), you can make the JIT compiler avoid generating certain code patterns. This does not need any changes to the CPU. Normal machine code can just read the memory normally, so there's nothing to protect against.

    8. Re:Flush by amorsen · · Score: 1

      The process doing the probing gets the GP faults. It's relying on the fact that even though the accesses fault they still affect the cache. So you could clean up that in the GP fault handler before you return to the process, do a context switch or execute any untrusted code.

      You cannot clean it up in the GP fault handler because the hardware thread running at the same time can detect the cache changes before you clean up.

      Your solution only works in the single-core single-socket non-threaded case, and most single-core single-socket non-threaded CPUs today do not do speculative execution. Besides, AMD has proven that there is very little performance loss from simply doing the access check properly while speculating. Meltdown is simply not a problem if the chip designer is competent.

      You are focusing on fixing the easy case. The hard case, Spectre, is when the speculative execution does not cross a privilege boundary.

      --
      Finally! A year of moderation! Ready for 2019?
    9. Re:Flush by Anonymous Coward · · Score: 0

      Thanks! I'd been wondering why this couldn't just be fixed in software, because I hadn't considered multicore and multithreaded.

    10. Re:Flush by Anonymous Coward · · Score: 0

      Uhm, sorry no. Invalidating the cache does not fix the problem. Just invert step 2 so your probe array is in the cache. Then look for an entry that takes longer to access.

    11. Re:Flush by Megol · · Score: 1

      Ah - that's trivial since the 486: just insert a WBINVD instruction in the context switch code - done!

      Hope you like slow computers though - that instruction flushes all caches and is slow as a glued snail.

    12. Re:Flush by Anonymous Coward · · Score: 0

      Other comments have already pointed out that cleaning up after the access would not be sufficient, but I would like to point out that no protection fault is even triggered in the first place. The code is executed speculatively. A handler would only get control when the instruction is settled (i.e. it turns out that the speculation was right and the code actually needs to be executed for real). This never happens. All violating instructions are discarded. The only thing that remains is the illegally accessed value in cache (not a problem because it can still not be read without triggering a protection fault), and one of two values that the process can access normally. Reading the illegally accessed value is achieved by timing memory accesses to find which of the two values is in the cache, revealing one bit of the illegally accessed value.

      The two "solutions" are bogus: By the time you know that the access is illegal, you can just stop speculative execution: A privilege violation exception doesn't need to be that fast. The CPU simply doesn't know in time. If Intel had not optimized away the possibility of recognizing illegal accesses before further instructions speculatively execute, there wouldn't be a problem.

    13. Re:Flush by gnasher719 · · Score: 1

      Spectre works by getting speculatively executed code access kernel mode memory. So they'd need to do protection checks before the speculative code did the access

      Not at all. Speculative access to data outside your own process is no problem. But the data read is (kind of) poisoned - it must not be used for anything that leaves detectable side affects, like evicting a cache line and loading a different cache line.

    14. Re:Flush by gnasher719 · · Score: 1

      Spectre hits you when you try to execute untrusted code such as JavaScript in a VM.

      The problem with Spectre is that it hits you if you run malware on your computer, whereas before you were in trouble if you ran malware in your user space.

      For cloud servers, this is absolutely fatal, because a different user running code on the same computer could attack you.

      If you have a Mac, PC, or Linux computer running VMs, and there is malware on those VMs, then with Spectre you're in trouble; before Spectre you were not.

      But if you are an ordinary Mac or Windows users, Spectre doesn't make much difference: If you have malware on your computer, then the single user is in trouble. Spectre or no Spectre. Spectre doesn't make things worse.

      The exception is malware in Javascript, which can always happen. Safari protects you from most things through sandboxing, but cannot protect you from Spectre. Their solution is that all access to timers is made artificially inaccurate when running JavaScript. I suppose other browsers do the same.

    15. Re:Flush by Anonymous Coward · · Score: 0

      Sure you do. That's why you copy-pasted a long description of Meltdown and called it Spectre. You must work for Intel.

      "Spectre works by getting speculatively executed code access kernel mode memory." —Hal Porter

      I.e., Spectre = Meltdown

    16. Re:Flush by Agripa · · Score: 1

      The process doing the probing gets the GP faults. It's relying on the fact that even though the accesses fault they still affect the cache.

      Speculated accesses do not fault because they are rolled back by being ignored at instruction retirement.

    17. Re:Flush by Hal_Porter · · Score: 1

      But, at least on Intel's microarchitecture, they still affect the cache, which is the reason Meltdown works.

      It's different on AMD's microarchitecture.

      --
      echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
    18. Re:Flush by Agripa · · Score: 1

      But, at least on Intel's microarchitecture, they still affect the cache, which is the reason Meltdown works.

      It's different on AMD's microarchitecture.

      It is not that Intel's microarchitecture allows speculative loads to affect the cache but that it allows speculative instructions to operate on data which would otherwise generate a protection fault when accessed.

      Did AMD block speculative loads or block speculative instructions which operate on protected data? Either should prevent Meltdown.

    19. Re:Flush by Hal_Porter · · Score: 1

      AMD apparently do a privilege check which either stops the speculated code running or at least makes it side effect free.

      I found this interesting comment on how Intel could fix it

      https://security.stackexchange...

      Fixing Meltdown is relatively easy (compared to Spectre), although it probably can't be done with a microcode update. As well as setting a fault-if/when-this-reaches-retirement bit on the uop, a TLB lookup could gate the page-address bits (to all ones) with the privilege-check. e.g. a load in user-space from any kernel page could micro-architecturally execute as a load from the very top physical page. (And systems with less than the max amount of RAM wouldn't have any physical RAM at that physical address.)

      I.e. you do the virtual to physical translation using the TLB but you make invalid addresses map to an address with all ones. Since you have to do the V to P translation anyway, that seems like a good option.

      So illegal addresses would map to address (all ones). So that address would be loaded into the cache but the operation would later fault. Since all the addresses you don't have access to map to (all ones) you can't later do a side channel attack to find out if they're cached. And you have to do the virtual to physical translation anyway, so it doesn't cost you anything.

      Very elegant.

      --
      echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
  8. Translation by 110010001000 · · Score: 3, Funny

    Our CPUs cannot be fixed with software. You are going to need to buy a new CPU.

    1. Re:Translation by Anonymous Coward · · Score: 0

      Yeah, no shit. Hardware can't be redesigned with a software update.

      Holy fuck, what is it like to be so obtuse?

    2. Re:Translation by M0j0_j0j0 · · Score: 1

      I read somewhere you can get your battery replaced for 29$ for the the hardware fix.

  9. FTFY... by Anonymous Coward · · Score: 0

    Intel Plans To Release Chips That Have Built-in NSA backdoors.

    1. Re: FTFY... by Anonymous Coward · · Score: 0

      Those are already there. This is probably an honest mistake, however, or on made and ignored for the sake of inching out performance.

  10. Fix, not redesign by Anonymous Coward · · Score: 0

    Why doesn't Intel redesign their chips so they don't have this flaw? Why build a chip with a flaw and add extra code to try and stop it? Oh, it's money. It's all about the money. Intel wants to sell insecure chips because they can't design secure ones fast and cheap enough. Every time Intel makes a statement about Spectre or Meltdown they reinforce how little they care about their customers.

  11. That's great by Anonymous Coward · · Score: 0

    But tell us which chips will be fixed. I recently built a Skylake based gaming rig. My motherboard can take a Kaby Lake with a flash. So I flashed my BIOS, with the hope they create a new batch of Kaby Lake with the Meltdown fix. It should be a nice upgrade, and avoid the slowdown of the patch. But if they just fix the new ones (Coffee Lake) I'll be pissed because I'll have to upgrade everything.

  12. Can they be more insulting to their customers? by Anonymous Coward · · Score: 0

    Ah, more news from the Intel Comedy Club. The microcode updates that are supposed to fix the problem don't fix it at all. Intel's CEO says there will be no recall even though the chips are defective. Claims "working as intended." And lets not forget that Intel's CEO did a mass sell-off of his stock in November 2017...BEFORE the security flaw was made public. Can you be even more suspicious? I guess he wanted to become the subject of a federal insider trading investigation.

    Intel's PR department has been putting so much spin on this that there is now a cyclone above their Santa Clara, CA facility. ARM and AMD has published exactly what the problems with their chips are, which chips are affected, etc. Intel just tries to cloud the issue. And then they want us to reward them by buying more chips... And in other news, Intel reports that they had a record quarter of USD $17.7 Billion in revenue for 4th quarter 2017.

  13. wtf article? by pak9rabid · · Score: 4, Informative
    From the article:

    The Meltdown attack also affects chips from AMD and those based on ARM designs and, in turn, nearly every PC, smartphone and tablet made in recent years.

    What. the. FUCK! That couldn't be further from the truth. It's like Intel wrote this garbage piece of shit "article" for them.

    1. Re:wtf article? by drinkypoo · · Score: 2

      What. the. FUCK! That couldn't be further from the truth. It's like Intel wrote this garbage piece of shit "article" for them.

      Troy Wolverton and BI are both on G+, so I went over there and plus-tagged them both in a complaint about it. Incompetence all around. If only BI were qualified to comment upon this issue, they would have had an editor who could catch that error.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    2. Re:wtf article? by Anonymous Coward · · Score: 0

      No, you're wrong, you dumb fucking cunt. Go kill yourself. The gene pool will be better without you.

      The fundamental flaw that affects all chips is called "Spectre".

      "Meltdown" is Intel-only, just like the GP said.

    3. Re:wtf article? by Anonymous Coward · · Score: 0

      Wrong, you're thinking of Spectre. Intel, AMD, & ARM are affected by Spectre. But, Intel is ALSO affected by Meltdown; specifically they're the only one.

    4. Re:wtf article? by amorsen · · Score: 4, Informative

      No. No they have not. Meltdown is an Intel-only thing except possibly for a few exotic ARMs.

      Spectre affects everyone.

      --
      Finally! A year of moderation! Ready for 2019?
    5. Re:wtf article? by thegarbz · · Score: 1

      And IBM Power8 and Power9 are also affected by Meltdown, and Oracle has refused to talk about any SPARC systems which are not currently in support.

    6. Re:wtf article? by Anonymous Coward · · Score: 0

      I sent and email to Mr. Wolverton pointing out this error and he has changed the wording in his article to say AMD is susceptible to Spectre.

    7. Re:wtf article? by Anonymous Coward · · Score: 0

      and spectre is an irrevelant non-problem.

    8. Re:wtf article? by Anonymous Coward · · Score: 0

      Power7 and later, but the meltdown workaround is not as invasive (no complete TLB flush, only invalidation of L1 data cache, which is write-through, and therefore never dirty). The performance hit is much lower, especially in the worst cases.

    9. Re: wtf article? by zilym · · Score: 1

      You're still fooled by Intel's Jedi^H^H^H^Hmarketing mind tricks. Spectre does not affect everyone. Many ARM cores used in tablets and smart phones lack speculative execution features in order to save battery power. Without speculative execution, there is no Spectre. Only the higher performance ARM's implement speculative execution.

    10. Re:wtf article? by drinkypoo · · Score: 1

      Power7 and later,

      IBM has said that there will be further communication on older processors. Some suggest that G3 and G4 are safe, but that still leaves POWER5 and POWER6

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  14. And Intel ME? by Hrrrg · · Score: 4, Interesting

    And of course, because they are serious about security, they won't be including the Intel Management Engine in computers that don't need it, RIGHT????? Fixing Meltdown and Spectre isn't news - everyone knew that they would jump on that one. But how about removing the bug-ridden, back-door infested Intel ME? THAT is what we should insist on every time they try to claim security credibility.

    1. Re:And Intel ME? by Anonymous Coward · · Score: 0

      Actually, it is ALREADY capable of being disabled. Both at the motherboard BIOS level, and at the ME level itself. Disabling it at the ME level is quite the pain in the ass, however.

      The ME is quite useful for large organizations that deploy and manage large numbers of systems.

    2. Re:And Intel ME? by Parker+Lewis · · Score: 1

      Well, according our Slashdot specialists, a open source processor has not a single advantage over the current obscure ones, not even when we mention IME.

    3. Re:And Intel ME? by Neuroelectronic · · Score: 1

      Who needs credibility when you can just purchase the journalist? Why would they mention that the ME exists when they don't have plans to fix it?

    4. Re:And Intel ME? by thegarbz · · Score: 1

      But how about removing the bug-ridden, back-door infested Intel ME?

      They why would businesses buy Intel? If they have to spend extra money on enterprise management they may just as well go to AMD.

    5. Re:And Intel ME? by drinkypoo · · Score: 1

      Actually, it is ALREADY capable of being disabled. Both at the motherboard BIOS level, and at the ME level itself. Disabling it at the ME level is quite the pain in the ass, however.

      They should dedicate a pin to this, so that you can have a physical ME disable jumper. They could lie about whether it works, but at least you wouldn't have to worry about software lying to you, only hardware.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  15. It's part of the plan by TheInternet01 · · Score: 1

    Make insecure chips but fast, use ahh didn't realize security issue marketing, slow down chips, resale chips with the same performance level, profit.

    Much cheaper than actually coming up with faster chipsets to purchase.

    --
    Uplink Hosting - Web/email at an affordable price with high performance - https://uplinkhosting.ca/link.php?id=3
    1. Re:It's part of the plan by Anonymous Coward · · Score: 0

      Or... Oops, our backdoor isn't good enough so we'll expose the flaw so everyone will fud to our new secret backdoor enabled line of products.

  16. firedrill of stupid by Anonymous Coward · · Score: 0

    It should be ready to go since they have known about this issue for 20 years.

  17. Why only now ? by Alain+Williams · · Score: 3, Insightful

    This was know about at least 7 months ago, there have been stories about side channels longer than that. So: why have they only got their 'best minds' working on it now ?

    1. Re:Why only now ? by Anonymous Coward · · Score: 0

      They are going to pull a Reverse Scotty on us so that we can call them the miracle workers.

  18. Later this year? They knew of the flaws months ago by Anonymous Coward · · Score: 0

    In the end it will take a year to ship 'fixed' silicon? BS. Intel doesn't want to be stuck with the existing flawed stock.

    Vendor salesguy: you guys need any new hardware?

    Purchasing: yes, but we'll wait for the models with the fixed CPUs or we'll take your flawed ones for 80% off.

    This means vendors are screwed.

  19. Let me rewrite the headline for you... by Anonymous Coward · · Score: 0

    New headline: Intel promises to fix the bugs in their chips. But not give you a replacement for your old, broken one. Thanks Intel!

  20. Doesn't this by Anonymous Coward · · Score: 0

    "assigned some of our very best minds"

    just want to make you wet yourself laughing?

  21. Alright lads... by Anonymous Coward · · Score: 0

    time to buy AMD.

    1. Re:Alright lads... by Anonymous Coward · · Score: 0

      Well I was just about to start a new build. AMD will definitely get a look this time around.

  22. What Reputation? by Anonymous Coward · · Score: 0

    AMD seems to have done it right with the latest designs, they're available now, and their performance is competitive especially with Intel's patches slowing down CPUs. Intel for a long time got away with tricks that let them claim better performance, but now we find that they were exactly that: tricks, that they knew - at least by 6 months or more ago - were unsafe. I will not buy Intel, at least n the foreseeable future. There will be a huge need to replace older Intel stuff over the next year or 2, and AMD better be lining up more fab capacity...

    1. Re:What Reputation? by Tough+Love · · Score: 1

      AMD seems to have done it right with the latest designs, they're available now, and their performance is competitive...

      Ryzen is a beast, and runs so cool. Bye Intel.

      --
      When all you have is a hammer, every problem starts to look like a thumb.
  23. Stop phrasing this shit like Intel PR by tomxor · · Score: 4, Interesting

    We don't need "built in protection" we need a "design which isn't vulnerable", if the former is truly their strategy then the analogue is anti-virus inside your CPU... You people who write headline need to stop playing into Intel PR's incredulous attitude to their own fucking design flaw. Meltdown and Spectre are not inevitable, they need to be designed out not paved over. Intel: stop treating everyone like morons or suffer the consequences.

  24. Obligatory: Intel CPU Backdoor Report (Jan 1 2018) by Anonymous Coward · · Score: 1

    Change log:
    2018/01/01 - Added 14 Useful Links. Disable Intel ME 11 via undocumented NSA "High Assurance Platform" mode with me_cleaner, Blackhat Dec 2017 Intel ME presentation, Intel ME CVEs (CVSS Scored 7.2-10.0)

    Intel CPU Backdoor Report
    The goal of this report is to make the existence of Intel CPU backdoors a common knowledge and provide information on backdoor removal.

    What we know about Intel CPU backdoors so far:

    TL;DR version

    Your Intel CPU and Chipset is running a backdoor as we speak.

    The backdoor hardware is inside the CPU/Bridge and the backdoor firmware (Intel Management Engine) is in the chipset flash memory.

    30C3 Intel ME live hack:
    [Video] 30C3: Persistent, Stealthy, Remote-controlled Dedicated Hardware Malware
    @21:43, keystrokes leaked from Intel ME above the OS, wireshark failed to detect packets.

    [Quotes] Vortrag:
    "the ME provides a perfect environment for undetectable sensitive data leakage on behalf of the attacker".

    "We can permanently monitor the keyboard buffer on both operating system targets."

    Decoding Intel backdoors:
    The situation is out of control and the Libreboot/Coreboot community is looking for BIOS/Firmware experts to help with the Intel ME decoding effort.

    If you are skilled in these areas, download Intel ME firmwares from this collection and have a go at them, beware Intel is using a lot of counter measures to prevent their backdoors from being decoded (explained below).

    Backdoor removal:
    The backdoor firmware can be removed by following this guide using the me_cleaner script.
    Removal requires a Raspberry Pi (with GPIO pins) and a SOIC clip.

    2017 Dec Update:
    Intel ME on recent CPUs may be disabled by enabling the undocumented NSA HAP mode, use me_cleaner with -S option to set the HAP bit, see me_cleaner: HAP AltMeDisable bit.

    Useful links (Added 2018 Jan 1):
    Disabling Intel ME 11 via undocumented HAP mode (NSA High Assurance Platform mode)
    me_cleaner: Set HAP AltMeDisable bit with -S option
    Blackhat 2017: How To Hack A Turned Off Computer Or Running Unsigned Code In Intel Management Engine
    EFF: Intel's Management Engine is a security hazard, and users need a way to disable it
    Sakaki's EFI Install Guide/Disabling the Intel Management Engine
    Intel ME bug storm: Hardware vendors race to identify and provide updates for dangerous Intel flaws.
    CVE-2017-5689: An unprivileged network attacker could ga

  25. Troy Wolverton is a fucking liar by Anonymous Coward · · Score: 0

    Fucking Intel presstitude.

  26. Fuck off cunt, Meltdown is Intel only by Anonymous Coward · · Score: 2, Insightful

    Intel cheated to get better benchmarks, AMD didn't.

    1. Re:Fuck off cunt, Meltdown is Intel only by Megol · · Score: 1

      I don't actually think they got any measurable performance increase.

  27. Comment removed by account_deleted · · Score: 1

    Comment removed based on user account deletion

  28. Intel CEO sold his shares by Anonymous Coward · · Score: 0

    Then pretend it was planned long time ago, when the plan was created a month after he was notified of the bug.

    Fuck Intel.

  29. Comment removed by account_deleted · · Score: 1

    Comment removed based on user account deletion

  30. Except you can turn it the fuck back on by Anonymous Coward · · Score: 0

    Through Windoze exploits, or fucking Spectre

  31. Intel: Years of insufficient management. by Futurepower(R) · · Score: 3, Insightful

    "From the people who brought you F00F, FDIV, and now Meltdown? No thanks."

    Intel has had many years of insufficient management, in my opinion.

    It is not difficult to find evidence of insufficient management at Intel. Yesterday I got 2 poorly considered, poorly written marketing emails from Intel.

    More evidence of insufficient management: Intel's CEO reportedly sold shares after the company already knew about massive security flaws

    Will Intel be allowed to PROFIT from many years of producing processors with vulnerabilities? Will Intel be treated like U.S. banks in 2008, when many banks profited and many finance system managers got bonuses after the financial crash?

    If vulnerabilities are profitable, would Intel deliberately allow vulnerabilities in its products? Were the previous vulnerabilities deliberate? Maybe the CEO didn't previously know about the vulnerabilities. Did someone else at Intel profit from the vulnerabilities?

  32. amd needs boards with IPMI for the E-3 class of c by Joe_Dragon · · Score: 1

    amd needs boards with IPMI for the E-3 class of cpus (aka desktop) that they have. Not all servers needs an 8 ram channel 128 pci-e high end system.

  33. How delicate! by aglider · · Score: 1

    Are you seriously "planning"?
    I thought it was a mandatory move to be done as priority 1 over everything else!

    You insensitive silicon clod!

    --
    Sent as ripples into the electromagnetic field. No single photon has been harmed in the process.
  34. "protections" by AnotherBlackHat · · Score: 1

    ... built-in protections against the Spectre and Meltdown attacks ...

    Hey Intel! It's not an attack, it's a demonstration of why your design is broken.
    It's fundamentally broken to read protected memory without permission.
    If your chip can read protected memory without permission at any time, for any reason, it's broken.
    Don't try to mitigate the "attack", just fix your damn broken design.

    1. Re:"protections" by gnasher719 · · Score: 1

      It's fundamentally broken to read protected memory without permission. If your chip can read protected memory without permission at any time, for any reason, it's broken.

      You don't understand Spectre. Reading protected memory through speculative execution by itself is no problem. Using the data in a way that leaves a trace (like using it to form an address and reading from that address) is the problem.

    2. Re:"protections" by Anonymous Coward · · Score: 0

      Neither of these flaws allows reading protected memory without permission. You can use one of these side channel attacks to indirectly determine the contents of said memory.

    3. Re:"protections" by AnotherBlackHat · · Score: 1

      Reading protected memory through speculative execution by itself is no problem.

      It's a problem if you have memory mapped I/O, and reading it causes something to happen.
      For example, status registers frequently auto-clear when read.

    4. Re:"protections" by AnotherBlackHat · · Score: 1

      Neither of these flaws allows reading protected memory without permission.

      Sometimes you don't need to read protected memory to cause problems, you just need it to be read.

  35. Newspeak by mwvdlee · · Score: 1

    [quote]Intel Plans To Release Chips That Have Built-in Meltdown and Spectre Protections Later This Year [/quote]
    Translation: Intel Plans To Releas Chips That Have Fixed The Meltdown and Spectre Bugs Later This Year.
    These are not added protection. This is not some feature. This is repairing a mistake in all chips released while continuing to sell broken products up to "Later This Year".

    --
    Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
  36. I think we're missing an opportunity here... by atrex · · Score: 1

    Now security is important. But, otoh, Intel has already manufactured a lot of these flawed chips. Following the news about these vulnerabilities the demand for these chips is going to drop. This should open up a window of opportunity to snap up these chips at some steeply discounted prices and use them for workloads and in environments where the chips' design flaw isn't going to be an issue (just avoid applying the mitigation patches that slow everything down).

  37. FUD by Anonymous Coward · · Score: 0

    This is complete BS. Intel won't have fixed silicon for at least two years. And sites like Slashdot should get a clue and stop propagating Intel's lying PR.

  38. Where is Motorola and Zilog when you need them? by Anonymous Coward · · Score: 0

    Kick X86 to the curb!

    (and put some Sparc back into computing!)

  39. Will cost more; will be slower. by haruchai · · Score: 1

    or as Intel will try to frame it - next-gen performance and security!!

    --
    Pain is merely failure leaving the body
  40. Re:amd needs boards with IPMI for the E-3 class of by Anonymous Coward · · Score: 0

    the die is flexible too. Make it soldered on-board, with the I/O configured for server stuff like 10GbE. Replace the (3rd party) companion chip chip known as X370, B350, A320 with another one.
    Fun fact the Ryzen looks very similar to Xeon D on all grounds. Although, a low end Xeon E5 server is so cheap that I don't think many bother with a Xeon E3 or Xeon D..

  41. Wrong by Anonymous Coward · · Score: 0

    If Intel did the extra check and cleanup like AMD does, it'd be 5% or more slower.

  42. Re:Obligatory: Intel CPU Backdoor Report (Jan 1 20 by Anonymous Coward · · Score: 0

    That's just it. If it's connected to your LAN you should be able to see the mac address and/or any network traffic through your router.

  43. Modern computing by kfsone · · Score: 1

    There are three main types of computing environment:

    - Monolithic single process,
    - Complex single process,
    - Mixed processes

    MSP: written in a low-level language (asm, c, c++), typically a very finely tuned process that may use CPU threads for parallelism in a very carefully managed way, probably implementing its own scheduling etc. Non-deterministic operations like OS/Kernel interactions are generally very, very carefully supervised, custom memory management all over the place, etc, this is the core focus of the system and every effort is made to strip the OS down to preserve cache and determinism,

    CSP: possibly written in a less high-level language or one that uses a VM, or incorporates lots of disparate libraries, less to no focus on determinism, often heavy interaction with the os (file access, etc), non-organized thread organization (typically task-specific threads), cache/memory efficiency may be optimized for algorithms or routines but the overhead multitasking isn't a major factor,

    Mixed: The system is expected to run a large number of processes/services and the process has no expectation of determinism, everything from assembly to python-implemented-in-bash.

    The design of Windows means that it's hard to build an MSP on Windows but it's feasible now with some of the server versions. These are usually extreme cases like High Frequency Trading but also all kinds of realtime systems.

    CSPs are your "performant" industrial server process, from game servers to web servers. They probably take huge amounts of RAM for granted, but you'd probably get fired if you logged in on one and started using CPU.

    Mixed: everything from your mundane intranet server, mail machine, firewall, to desktop computer. There's a ton of stuff running and unless someone logs in and uses 100% cpu for a couple hours people probably wouldn't notice even high amounts of contention.

    For all of these solutions we follow one model: Everything competes for time on the same CPU: Scheduler, Kernel, OS and Processes.

    We've moved some tasks out to co-processors which have been reabsorbed into the CPU: MMU, FPU...

    Now we have complex chips with multiple cores and ... thread assignment is done in code, in competition with the code-threads that should be running?

    In the MSP case: The OS is essentially a forced hit you have to take on your processor availability: you know that every so often it's going to pop in and steal some cycles determining that ... you should carry on doing what you were doing, sorry for messing up your cache line.

    In the other cases, especially when there are a lot of processes, you get a gradual degradation caused by the system taking longer to make decisions about what is fair, while it is, itself, obstructing work from being done.

    We need the ability to have a Kernel-Core or a Scheduler-Core with custom instructions that can do things like tell memory to go zero a page for us rather than writing zeros to memory... That can get special state information about the CPU cores to make smart decisions about what to run, instructions only available on those cores.

    Putting the kernel on its own core gives us a security barrier, and again allows us to dedicate instructions.

    We're over due for this architecture. We're already trying to do this with containers and hypervisors, but CPU vendors are just like "*shrug* we'll sell you more of the same"...

    --
    -- A change is as good as a reboot.
  44. Intel To Release Chips With Built-in Meltdown and by hcs_$reboot · · Score: 1

    Slashdot subject size limitation helps to find out the truth.

    --
    Slashdot, fix the reply notifications... You won't get away with it...
  45. I am... by Excelcia · · Score: 1

    I am Pentium of Borg. Division is futile. You will be approximated.

    Ah. That never gets old.

  46. Exactly what kind of fix? by paradigm82 · · Score: 1
    Exactly what does it mean the fix is in hardware? One option is, it means the microcode updates that Intel have made for current CPU's (and which have performance impact) has been preloaded into the CPU (i.e. part of the built-in microcode). This would be very easy for Intel since the microcode has already been validated (not the same as fully bug-free as the increase-reboot-frequency-saga shows!) so it is just a matter of pre-loading what they already made. This will make it seem built-in from a consumer point-of-view and of course it is beneficial that you are not dependent on a BIOS loading it. Yet, it is not really a huge evolution in addressing the problem and won't improve performance so I won't call it a true hardware fix. Could Intel have made more sophisticated updates? I think there will be at least some true hardware fix. We know Intel knew about this problem in spring 2017 so they have had some, although limited, time to make changes. Also, Meltdown is currently only mitigated in software, not with microcode updates so probably this requires some real silicon update so we know they can't just be building-in the microcode update in order to "mitigate in hardware". It also doesn't seem to be that difficult to fix in silicon - just insert the permission check earlier in the pipeline. It should have no functional consequences because they already have this check later in the pipeline but it avoids the speculative execution. Such a fix will probably also have much less performance impact than the current operating system level mitigations. Intel Icelake taped out in June 2017 http://hexus.net/tech/news/cpu... so there would have been some time for a last-minute tweak like this, even though it would have been very rushed to get through validation. But it is also strategically important for the company, so certainly possible! It could even be it was already easy to switch to the more conservative strategy using just a configuration option when synthesizing the core. Or it could be Intel started on the mitigation even earlier because there were already reports in 2016 that address space randomization could be compromised due this aspect of the architecture. Even though it was not possible to read actual data from user space using that attack, maybe it prompted Intel's engineers started working on disabling the speculative aspect of meltdown.

    I think Spectre is much more difficult to fix (or at least try to mitigate) in hardware so here I think it is more likely the microcode update is simply built in. It could be there are some tweaks here and there that might make the new features exposed to the operating system work better etc. but I doubt it is fully mitigated in hardware, at most it is some evolutionary change on top of the microcode update fix.

    But given Meltdown has the biggest performance impact, it is also the most important to fix. And as mentioned, I think that is very feasible.

  47. After having successfully released by Anonymous Coward · · Score: 0

    Chips with built-in meltdown and spectre features for years

  48. "we're acutely aware we have more to do" by jay+age · · Score: 1

    Yes you do.

    How about offering some compensation to people, who bought your chips with the flaws, for the drops in the performance created by the patches? You did receive semi-monopoly prices for them, so coughing some of that up would be only fair, as we're left up with something that doesn't perform as good as advertised.

    Now if only avoiding Intel on notebooks would be easier. There will be some potentially good stuff coming up this year, such as Ryzen powered Thinkpads, but there just isn't much choice.
    On the desktops or workstations however ... vote with your wallets people!