34 thoughts on “The Intel Bug”

  1. I been considering upgrading. I was going to go with Intel/NVidia system, simply because I prefer NVidia graphics, and I didn’t want to go AMD/NVidia. I will be reconsidering. It has been awhile since I’ve built a desktop. For the past few years, I’ve been happy with Desktop performance, but I just don’t think the mobile graphic chip is sufficient for VR.

      1. I’m thinking this scandal will help Ryzen sales more than a little. It makes the original Pentium integer bug look tame by comparison.

        I’ve stayed with AMD, but that’s because I’m poor, cheap, and not much of a gamer. I have an older 2-core Asus Essentio which is magnificent with music & movies, and is more than “good enough” for normal tasks.

        1. I usually make a conscience choice to buy from the second largest company whenever they can do the job because I feel so strongly about supporting competition.

          Amazon does a better job than Jet, but I will still buy from Jet first even at a higher price and lower service.

          That’s true for AMD except they often surprise with the best product.

          This bug is a hardware problem. Fixing it in software is the definition of kluge, but has to be done as well now.

    3. I used Radeon in the past, but I more often found compatibility to be better with NVidia, especially with initial PhysX models. However, I did see something that VR could run on lower end Rizen models better than NVidia. Whenever I’m ready, I’ll spend a few days at Tom’s Hardware before I purchase.

  2. You know it’s bad because first they denied it was THAT bad, then they claim others have the same problem (as if hardware could catch it like a software virus!)

    1. Strictly speaking, any processor that does out-of-order *and* speculative execution is susceptible to some of these attacks. In particular the higher-end ARM chips in most modern smartphones are vulnerable. (By contrast, the wimpier on in the Raspberry Pi isn’t, because it doesn’t do out-of-order execution.)

  3. The good news is that an attacker needs to get hostile code on your computer in the first place, and even then it looks like a very difficult privilege escalation for anything beyond just trashing the running system. But this is still a very embarrassing bug for Intel.

    1. My understanding is, it is a memory control issue? All attacks involve getting hostile code on the target machine.. What’s different here is that it allows access to privileged memory that hostile code normally can’t get to even after it’s on the target machine.

      Just being able to call that protected code could give them access they could not get otherwise with any code (it would normally generate a fault interrupt.)

      I looked at some ARM code recently. Don’t know if ARM is big or little endian, but it does look sweet. The 6502 was the last time I enjoyed assembler.

      1. It’s not about calling protected kernel code. That’s still shouldn’t be possible. It’s about accessing data that was thought “safe” because it was in kernel memory. Things like cached passwords, crypto keys, the call stack… Basically, about half the time people realized “oh, I have a problem here, I need to secure this data”, the solution was to move it into this area that’s now open to being exploited. It’s bad enough to expose the data there, but the call stack… if I know what method you just called, what you passed it, and where it returned to.. especially if “you” is a virtual machine hypervisor… nasty doesn’t begin to describe it.

      2. Modern processors execute several instructions at the same time, reordering the operations based on implicit dependencies of results, using a very complex mechanism. Apparently a flaw in the Intel implementation, when the processor switches to supervisor mode other instructions in flight at the same time get elevated privilege. So a handful of operations immediately preceding the switch to supervisor mode in the instruction stream may have a chance to access OS memory in the usual arrangement where the OS exists in a reserved address range within the application memory space. This should still be a very difficult exploit as modern operating systems randomize the location of system tables and fault threads trying to access outside allowed address space.

  4. This is mostly a disaster for Cloud companies. There may be a move back to renting bare hardware instead of cloud capacity.

    1. Not sure I understand that. Is it because you can’t control the hardware of a cloud? I thought the point of a cloud was to avoid scaling issues? and hardware management.

      1. I think Cloud companies also advertised that your data was secure on their systems. You don’t have to worry about security on your own home system as much.

      2. The problem is cloud companies do a lot of things that the mitigation for this issue slows down. one example: applications with lots of I/O access typically do it by having many transitions back and forth between kernel and user space. All of those transitions get slowed down. The Phoronix tests of MySQL show something like a 20% slowdown.

    2. I refuse to use the cloud because I figure my files are not only open to hackers but also to people who work for the cloud company.

      So over Christmas I built my own server. Admittedly it’s not open to the outside world so I can’t get to my data from the outside but that’s ok. And I built it with an Intel chip too. I don’t know whether or not I’ll ever allow outside access to the server.

      But I can at least pile up the protections on the data. Doesn’t save me from some of the mischief that this new problem can cause but it helps a little.

      1. Honestly, the cloud is probably safer for anything that isn’t targeted by a government. The main advantage is improved security. It turns out that security scales massively well. It really doesn’t take more effort to apply a patch to 10,000,000 servers compared to 10,000 servers. So if you go with Amazon, you suddenly have a billion dollar security budget. For example, all my servers were patched before most people even knew about the issue, and I didn’t have to do anything.

        And of course, if you are a business type: If servers in our data center are hacked, the headlines will read “Our servers were hacked!”, whereas if the cloud servers at Amazon are hacked the headlines read “Amazon servers hacked!”. Guess which of those headlines cause the company to go out of business?

    1. Yes, because the CPU is where the vulnerability exists. Everything that runs on an Intel CPU is can be affected by this, without the OS safeguards. (AMD and ARM–and, presumably, other classes of CPU–may be vulnerable to some of the three classes of this attack.)

      Apparently some of these attacks simply can’t be mitigated against at a software level.

  6. FWIW, the latest on this from my reading:

    – This is a whole new(ish) class of attacks based on speculative execution. Nearly all modern chips pipeline multiple instructions at once on a sort of assembly line, including some that may have to be reverted when it turns out they weren’t actually supposed to happen. Unfortunately these aborted instructions can leave side effects that allow processed to deduce the contents of memory they’re not supposed to see.

    – Intel has an especially egregious bug in its handling of this; this class of attacks is called ‘Meltdown’. There are OS-level fixes for this but they massively increase the costs of context switch between OS kernel and user programs.

    – There’s a much more general form of this attack called ‘Spectre’; this is a bit harder to execute, and potentially affects all modern CPUs. There are workarounds that make it impractical (but require doing things like recompiling all your code with performance-hitting options), and lots of research is still going on here.

    In general compute-heavy code (including games) will be minimally effected by the mitigations, I/O code could see hits of as much as 30% with the first-pass fixes.

  7. Now that it’s documented it should be a feature, not a bug.

    It seems to me that this fixes a long-term flaw in the Intel chipset whereby it was designed to ensure that trusted white programs had more privileges than poor and minority programs. Now everybody is upset that “other” aps might, in rare cases, also be allowed to have special privileges. The whole thing just reeks of racism and misogyny.

      1. It’s a matter of some code being trusted to manage the system. I’ve been following a new architecture in development that does away with the conventional system mode, instead using turfs with access to different address areas. And no turf, other than the initial boot turf, need have access to everything.

  9. AMD doesn’t make you safe, anyway.

    (Meltdown doesn’t affect AMD.

    Spectre does.

    “The researchers say AMD’s Ryzen family is affected by Spectre. Googlers have confirmed AMD FX and AMD Pro cores can allow arbitrary data to be obtained by a user process; the proof-of-concept worked just within one process, though. An AMD Pro running Linux in a non-default configuration – the BPF JIT is enabled – also lets a normal user process read from 4GB of kernel virtual memory.“)

  10. (On the plus side, it looks like Meltdown doesn’t allow nearly as-arbitrary access, and the biggest most-user-cases issue is that hostile JS might be able to access other-site-cookies, which is more easily mitigated.

    Then again, the early indications suggest that Spectre requires native-binary access to really be able to work well; it doesn’t seem like the timing attack and getting just the right ASM out is something that you could really exploit through JS.

    This looks a lot more like “makes malware even worse” combined with “the cloud hosting VM guys are shitting their pants because they’re the biggest, best, most accessible and highest value target imaginable here”.)

  11. I’m looking forward to seeing the performance hit on the actual updated Windows 10 kernel. I’m hoping to build a new machine capable of driving the upcoming 144 Hz 4k monitors. Such a machine may be processor limited for graphics intensive games. Depending on how much the processors performance are degraded, I might need to wait for the corrected microcode to make it onto new high end processors from Intel to run at something close to a 144 frame rate.

    1. Supposedly the patch went out to Windows 10 Insiders in November. I’ve got the current build (17063) and haven’t noticed any slowdown.

    2. My understanding is that most games – especially the ones that are CPU bound anyway – don’t do so much user/kernel context switching and so the patches should have minimal effect.

Comments are closed.