9 ms·

The IME gets a lot of hate around here, but let's not get distracted by it: higher-privilege co-processors running code outside the main OS' control is becoming

• dizhn 4y ago
  Thank you thank you thank you. I've been trying to find this talk forever after watching it once. I immediately knew this was it when I saw it under this particular thread. Super Illuminating stuff.
• Xelbair 4y ago
  Sure, but does the separate co-processor needs access to network stack? for a typical end user? definitely not.
  • bragr 4y ago
    It does if you want remote management, which almost every IT department does.
    • boppo1 4y ago
      Can we not have separate enterprise and individual classes of processor?
      • ranger207 4y ago
        Heck, ECC is already market-segregated
        • bubblethink 4y ago
          This is also segmented. The remote management stuff is marketed as vpro which is not available in all SKUs. However, all Intel processors need the ME.
      • vetinari 4y ago
        We do, sort of. In order to have network access, Intel Management Engine is not enough, it does not have full network access at all. You need Intel AMT (also marketed as "vPro"), and that one is paid extra. With CPUs featuring such support being separate SKUs, so you would definitely know -- and you can check in ark. You also need to pair it with Intel ethernet or wifi, any other network interface is not good enough. So here you have it, your separate class of processor.
      • wmf 4y ago
        Consumer PCs already don't have vPro/AMT, although Intel can't afford to make separate hardware so there's a concern that the out-of-band hardware path could be activated later by malware.
      • Spooky23 4y ago
        We do. Every time this topic comes up, everyone gets angry about something that doesn’t affect them, at all.
    • salawat 4y ago
      ...And which almost every pther computer decidedly does not, and more problematically, every other computer user has no visibility into the configuration, implementation details, or actual specs of said highly privileged component. It's one thing to have it, but if it sits out of my reach, sorry hoss, I just don't trust you that much, and the fact you and your buddies all do it and are the only shops in town doesn't make me feel any better.
    • chasil 4y ago
      No IT department wants their remote management at BlackHat. https://www.runzero.com/blog/ilo-vulnerabilities/ https://www.runzero.com/blog/ilo-vulnerabilities/ I'm not sure that iDRAC is much better; haven't checked lately.
      • snuxoll 4y ago
        At least with IPMI interfaces on servers they have a dedicated NIC port you can put on a restricted network.
    • deleted 4y ago
      [deleted]
    • goodpoint 4y ago
      This is plain false.
  • deleted 4y ago
    [deleted]
  • nullc 4y ago
    Is any remote management system available to the public using the ME stuff on consumer systems? I haven't seen it. And when you look at server hardware the have completely different backdoor facilities. It really looks like pure pretext, especially since there isn't just a simple bios option to comprehensively and completely disable it.
    • wmf 4y ago
      https://www.meshcommander.com/ https://www.meshcommander.com/
• clhodapp 4y ago
  Architecturally, that is fine... but if it's not open and well-specified it will continually face (well-deserved) distrust.
• akira2501 4y ago
  > higher-privilege co-processors running code outside the main OS' control is becoming (or already is) the norm everywhere. I don't think this fact is what you should focus on. That fact the blobs are binary, closed, proprietary, signed but not easily verifiable by the user, and not easy to disable is the problem. The promise is they're going to "improve security for PCs." Yet, they're using techniques that we know to be invalid. There's no reason to tolerate this.
  • freedude 4y ago
    When you consider both at the same time it is cause to pause and speculate on how malware might take advantage of this built-in tool.
    • armchairhacker 4y ago
      They can have a physical switch or tool to disable it, or sell separate chips with/without IME. Unfortunately there isn’t really incentive for Intel to do this, unless larger companies / governments refuse to run IME-enabled chips due to security concerns.
      • XorNot 4y ago
        Ironically government probably mostly doesn't care. The assumption of networked systems is that they're compromised if they have any internet connectivity. If it's really important then you air-gap it, and if it needs networking then you still isolate that network. Governments do you use public internet VPN sometimes...via accredited boxes which handle the tunneling for them and are the one point of ingress (and have a commensurate price tag).
        • coryrc 4y ago
          Government != NSA
          • XorNot 4y ago
• uncletammy 4y ago
  > higher-privilege co-processors running code outside the main OS' control is becoming (or already is) the norm everywhere There may be good arguments for allowing these types of "features" but this is not one of them. I'm so tired of seeing "it's fine because everyone else is doing it too"
  • marcosdumay 4y ago
    The GP is not saying anything is fine.
    • nicce 4y ago
      Well, he kinda makes it sound like that the fight is over and it is time to move on.
      • CrLf 4y ago
        Quite the opposite. While IME is discussed to death, the same loss of control is happening everywhere and becoming more and more entrenched. Like mentioned elsewhere in this thread, the problem isn't the presence of these types of components, but how opaque to the user (read: highly technical user) they are. Also they exist because there is demand for their features. The talk I linked makes the case that OS development is failing by pretending these co-processors are outside its scope, and hardware vendors just go and do their own thing on the side. I add that this incentivizes proprietary firmware instead of open one. I mean, if there were pressure (from paying customers) for Intel to support open-source IME firmware, they'd do it. After all, they just want to sell more chips.
        • smaudet 4y ago
          We need more exploits of these co-processors running in the wild. This stuff is done in the name of security but is incredibly insecure by nature. We know e.g. the NSA requests builds with this stuff turned off, but if more govts are affected then fewer will put up with this, the markets can follow.
• Kukumber 4y ago
  They banned Huawei equipments for less than that How come Intel get away with it? I went ahead and i disabled it
  • alex_duf 4y ago
    It's about who's your threat. The us government probably like having an American company (Intel) that distributes an attack vector. But they probably don't like being distributed one.
    • smaudet 4y ago
      Except the irony is it's baked into their systems as well, so you distribute your own national security threat... It's like phone lines, Intel agencies loved being able to arbitrarily tap lines, at least until they started having their own lines tapped as well. If I were China or Russia I'd have stockpiled a couple bugs in these backdoors and I'd be waiting to cause major economic disruption to the US govt with their own systems... so then it's just a game of who can knock out the other's comms first (which is as I understand it doctrine generally speaking in conflict, but)
      • alex_duf 4y ago
        > Except the irony is it's baked into their systems as well, so you distribute your own national security threat... From the article posted by OP >sets the 'High Assurance Program' bit, an ME 'kill switch' that the US government reportedly[11] had incorporated for PCs used in sensitive applications[12][13]; [11] links to a dead website, but it makes you understand the US called dibs on disabling it
• blueflow 4y ago
  Yes, and its a movement into the wrong direction. I do not trust the vendors to run code on co-processors that i have no control over. I somewhat expect it to be spyware and ads/data collection soon.
  • ethbr0 4y ago
    And support DRM to protect media companies' IP. Because $$$ talks, and there's a lot of money in media.
    • nicce 4y ago
      Well, luckily we have TPM chip just for that...
      • pedro2 4y ago
        Nope. kernel module mei_hdcp exists on modern systems.
        • d110af5ccf 4y ago
          nope, that's blacklisted on all my machines
    • wmf 4y ago
      Tech is actually much bigger than media. The tail keeps wagging the dog for some reason.
• StillBored 4y ago
  I sorta disagree with the premise of that talk, although the problem is real. Its just that even that talk vastly underestimated just how many microcontrollers exist on a modern machine. In the past those controllers were isolated to a few areas (disk controllers, higher end network cards), but the drive over the past decade+ for more efficient devices and "universal" packetized buses (ex PCIe, USB), has sprinkled them in places simply to monitor utilization and adjust bus clocks, as well as packet scheduling and error/retry logic, etc, etc, etc. I was reading about some of the latest m.2 NVMe controllers a while back and IIRC there were something like a half dozen independent Arm's just inside the controller. The last fully open disk stack on a PC was probably an MFM/RLL controller in the mid 1980's. So, while I would love if the manufacture of every little USB device or whatever published the full register documentation, firmware listings, whatever, that ship has long sailed. The worst part isn't looking for the piles of scattered SPI flash eeproms on random boards, its the integrated "Secure" sides of these devices which happen to be all but invisible. None of that is going to be documented anytime in the near future. Every single one of these companies hides their "secret sauce" in the firmware of these devices, be that how to minimize latency on a NVMe device, to how to get maximum throughput on a wifi chip, to how to increase a DRAM controllers power efficiency. In some of these cases, the firmware probably isn't even that special, they are doing basically the same thing as every one of their competitors, but you will never get them to admit it. So, imagining that an "OS" can control this mess like a 1960's mainframe is nonsense. Modern mainframes don't even control stuff at that level anymore. So like software abstractions, we have hardware abstractions which provide higher level constructs for low level software to talk to. Be that something like XHCI where the system talks to generic endpoint queues and a processor does all the low level packet building/scheduling or its something like the tiny integrated cores making decisions about which parts of a CPUs clock and power domains need to be dynamically enabled/disabled for a given perf/power profile and the OS talks to generic firmware interfaces to set policies. To even LBA disk layouts which abstract away all the details of flash channels, COW, wear leveling, NAND error correction, bit pattern sensing, page/block erase sizes, etc. In the end, if someone wanted to actually work on this problem, the first step towards open hardware isn't really building a RISC-V system, its building competitive NIC's, keyboards, USB controllers, etc, etc, etc with open hardware designs. What we have today is like linux, everyone wants to work on the kernel, no one wants to maintain old crufty code in Make. So, in the end swapping an x86 for a RISC-V doesn't give you more open hardware if its still got its own management processors tied to the same closed hardware IP for literally everything else in the machine.
• dottedmag 4y ago
  Apple M* CPUs do not have anything like that. Their coprocessors are not higher-privileged. On the contrary, they are all isolated from AP, each other and main memory (by IOMMU).
  • smaudet 4y ago
    Hmm. If Apple were easier to develop on I'd consider buying their M chip laptops for that reason alone. My issue last I worked with one was that userspace was ridiculously restricted - they have made it antagonistically difficult to do anything on a Mac. Normal PC, despite the nonsense in the hardware, remains fairly easy to work with, as long as you aren't doing security critical stuff.
    • dottedmag 4y ago
      You might be interested in following https://asahilinux.org/ https://asahilinux.org/ then
• Sirened 4y ago
  Yep, the practical difference between a hidden higher privldihe level and another random coprocessor on the system bus which can send memory writes to your core's internal MMIO region (common on ARM based SoCs, anyways) is quite literally zero. If you can write arbitrary physical memory, the entire system is cooked (well, mostly, but RIP SGX). IME is no worse than random DSP, ISP, ML, etc. cores on your average SoC in terms of its privilege in the system. Don't miss the forest for the trees.
• hsbauauvhabzb 4y ago
  ‘Everyone else is doing it’ is a bad excuse. Arbitrarily focusing on intel has made it so others know if they perform shady actions then it’s possible they’ll also become an arbitrary target. The disproportionate hate is a good thing, if you ask me.
• captainmuon 4y ago
  I think this model is completely wrong and should be inverted. The main CPU should be on top and run completely transparently. If you want secure coprocessors for DRM and cryptography, they should be subordinate black boxes.
  • uni_rule 4y ago
    Like a tpm module?
    • coldacid 4y ago
      I for one would be fine with a TPM that is on its own silicon and carrier rather than on the processor die or otherwise inside the CPU package. Then I could disable it when I don't want it working, without possibly killing my processor by doing so.
    • captainmuon 4y ago
      Yeah, or like a HSM for example.
• _nalply 4y ago
  I have taken the time to watch the talk. What I have learnt (to my dismay): Complex hardware has their own software, like IME, but they do important things you can't turn off. The danger in this: hardware-based exploits. In other words, the security of an OS is irrelevant if there is some shoddy closed-source software on your system running hardware components. Linux already has lost the control of hardware. It's like virtualization, but on the hardware level. People talk about switching off the IME, but that's barking up the wrong tree. What's proposed: redesign hardware and write an OS encompassing all hardware functions. Don't accept opaque SOCs where your OS is just an API consumer. This is controversial because of course DRM components want to be a black box, for example.
  • _nalply 4y ago
    Follow-up: Now I am afraid the victory of Asahi running Linux on Apple Silicon systems is only superficial. Apple still has a tight grip on how hardware is ran on a level lower than Linux. If I am wrong, please point out. I would be happy.
    • EricE 4y ago
      People have been worrying about Apple locking stuff out for decades - and they haven't. And why would they? What do they gain by restricting access to the hardware? It just doesn't make sense. People love to ascribe all sorts of motives to them that are, quite frankly, utterly ridiculous. They aren't perfect - no one company is - but they certainly are one of the better choices given where things are going in general.
      • _nalply 4y ago
        No need to be negative ("utterly ridiculous"). And you seem to have misunderstood me. It's not about Apple locking something, its about Apple software on the hardware of your Asahi Linux system.