5 ms·

> I wonder if this will at all dissuade either Intel or AMD into continuing to make these super privileged processors whose functions are completely hidden. I

> I wonder if this will at all dissuade either Intel or AMD into continuing to make these super privileged processors whose functions are completely hidden. I think many discussions miss the nuance here. The problem is that the functionality is hidden, not necessarily that the function is there. In corporate use, these tools can be incredibly useful. If they were more transparent, then they could be used by normal users for remote administration as well. But it needs to be secure, and it needs to exist without secrecy. If this portion were free for the user to configure, or if they allowed complete disabling via motherboard jumper, or simply open sourced it, that would be a better step. However, the NSA's activities have destroyed all trust in these sorts of features coming from an American company, so even if it were completely open sourced, there's no guarantee that there isn't other hardcoded ROM also executing in tandem with the open source components.

blacksmith_tb 9y ago
I agree with your overall conclusions, but I am having a hard time imagining the 'normal users' who would use remote administration... though perhaps if that were normal-for-HN users...
- rwmj 9y ago
  I guess I'm "Normal-for-HN". IPMI is so useful that I wouldn't buy a server without it, even one I'm going to use in the same building.
  - subway 9y ago
    IPMI is fantastic, so long that the understanding is in place that access to your IPMI vlan may as well be considered root access to the node. BMCs tend to be pretty miserable when it comes to security. It's generally a good idea to have ACLs in place to ensure BMCs can only communicate with a secured management node, and importantly that BMCs cannot communicate with each other.
    - nullc 9y ago
      Back when boards kept the IPMI on a separate interface it was easy to isolate them, including shutting down all port to port traffic on a switch. Now, on many motherboards the BMC stuff will aggressively talk in-band even if you think you've disabled that.
      - angry_octet 9y ago
        And even if all the dedicated IPMI ports are on a separate switch, if you have root on one box, you can attack another via the IPMI network. You have to put ACLs on the switch to prevent traffic except to the admin node.
- inetknght 9y ago
  If you have a hard time imagining normal users who would use this, then I suggest you grow your imagination and teach users what possibilities there are.
  - blacksmith_tb 9y ago
    Normal users can be sold on the idea of devices talking to each other (though in the case of Bluetooth I'd say it may have soured them on the whole thing). But I'd still say that even convincing a non-dev that wake-on-lan would be handy for them is a stretch, let alone more... Also I'm not sure how much evangelism is really appropriate - I may think that shelling into my headless server at home is great, but if you are happy with just cat videos, who am I to say you need to do more?
- derefr 9y ago
  Whenever my HTPC gets borked (it's a Hackintosh, it gets borked a lot), I regret not buying a "Q" motherboard. As it is, to fix the box, I have to temporarily switch the HDMI cable to the internal graphics, plug in a USB keyboard and mouse, and then sit down in front of it on the floor, craning my head to look at my TV beside it. With AMT access, I just could remote into the BIOS from my laptop on my couch.
derefr 9y ago
> or if they allowed complete disabling via motherboard jumper That wouldn't really work; the ME is essentially "the CPU" of the Platform Controller Hub. Disabling it would be disabling your computer (e.g. your IOMMU, your DRAM refresh, your ACPI command routing, etc.) All the stuff that used to be done "manually" by the CPU itself back in the 8086 days—using configured IRQs and PITs and whatever else—is done autonomously by the PCH these days, with the CPU just asking the PCH to "get it done." And the logic that runs in the PCH to interpret those requests and decides when and how to apply them, is executed by the ME. The ME only managed to not exist previously, because mainboards were previously both "simpler" (every bus spoke exactly one protocol and the controller chip for that bus did the protocol signalling) and more complex (tons of single-purpose controller chips.) The PCH boils all that down to one chip, and it needs a CPU to do it, and that CPU is the ME. Getting rid of it would mean going back ~15 years in computer capabilities. (Another way to think of the PCH is that it's basically an SoC chip, with the "heavy lifting" of application execution moved out to a separate, upgradable CPU socket. But, like any SoC, it still does need some sort of internal CPU. The ME is that CPU.)
- javajosh 9y ago
  It's sad to me that manually setting an IRQ is so horrible a prospect that it's better to compromise the entire system. Honestly, I don't understand why there needs to be another CPU in the system. Do systems really need arbitrary bus protocol translation in real time? If people could agree to reasonable standards (a real possibility in the technological asymptote we have entered) we can eliminate this complexity entirely. Then we can worry about something else, which is secretly embedding mini-CPUs into the CPU itself.
  - akvadrako 9y ago
    > Honestly, I don't understand why there needs to be another CPU in the system. There are tons of processors in modern systems. Most separate chips for controlling sub-systems have them, like DRAM, NICs, USB, keyboards, monitors, storage devices, video cards, etc... The reasons are performance and flexibility - when separate components act like remote hosts, the device manufacturer can divide up work between the OS driver (main CPU) and target system as desired.
zkms 9y ago
> I think many discussions miss the nuance here. The problem is that the functionality is hidden, not necessarily that the function is there. > If they were more transparent, then they could be used by normal users for remote administration as well. The fundamental objection with ME isn't that it's "proprietary" or "non-libre" or whatever other ideological objections, it's that it's an opaque embuggerance that makes any analysis or reasoning about the system's security/trustworthiness/reliability completely impossible and specious. There aren't even any robust specifications for it (like those for ISAs); it's literally a black box -- and one granted terrifying access to both the system's internals and external network interfaces. It's 10PM. Do you know if your ME has been provisioned by evil malware? I don't care much about whether its source code is public or not, I care about the fact that I have no verifiable and irreversible way to disable that little implant's function. It's not an innocent housekeeping microcontroller, it's one hell of a remote-access-tool, plain and simple. That intelligence agencies have demanded that Intel provide a bit to neuter the ME after its bringup is testament to that. My personal computer isn't part of an enterprise/corporate network, and I don't want any RAT (nor an auxiliary CPU with network access that is waiting to be provisioned to act like a RAT) installed on it, the same way my house-lock isn't keyed with a master key that the police holds. I (and most other end-users) do not need any sort of remote-management capability. We need trustworthy and robust computers that are capable of not leaking secrets and losing control to adversaries -- and "remote management" hardware is a severe step backwards from that.
- jordigh 9y ago
  > The fundamental objection with ME isn't that it's "proprietary" or "non-libre" or whatever other ideological objections, it's that it's an opaque embuggerance that makes any analysis or reasoning about the system's security/trustworthiness/reliability completely impossible and specious. Erm, your fundamental objection is exactly the same objection as it being non-libre. You presented the same argument while trying to distance yourself from it. Maybe you don't like the words "non-libre" or "proprietary" but you certainly seem to be arguing for the same thing that they are arguing for. > I don't care much about whether its source code is public or not, I care about the fact that I have no verifiable and irreversible way to disable that little implant's function. Having source code is but a tool towards having the freedom to do what you want with your hardware. I can't see another tool that would also work and give the verifiability that you want. Again, maybe you don't like the way people argue for it, but you're arguing for the same freedom that others want.

blacksmith_tb 9y ago

I agree with your overall conclusions, but I am having a hard time imagining the 'normal users' who would use remote administration... though perhaps if that were normal-for-HN users...

rwmj 9y ago
I guess I'm "Normal-for-HN". IPMI is so useful that I wouldn't buy a server without it, even one I'm going to use in the same building.
- subway 9y ago
  IPMI is fantastic, so long that the understanding is in place that access to your IPMI vlan may as well be considered root access to the node. BMCs tend to be pretty miserable when it comes to security. It's generally a good idea to have ACLs in place to ensure BMCs can only communicate with a secured management node, and importantly that BMCs cannot communicate with each other.
  - nullc 9y ago
    Back when boards kept the IPMI on a separate interface it was easy to isolate them, including shutting down all port to port traffic on a switch. Now, on many motherboards the BMC stuff will aggressively talk in-band even if you think you've disabled that.
    - angry_octet 9y ago
      And even if all the dedicated IPMI ports are on a separate switch, if you have root on one box, you can attack another via the IPMI network. You have to put ACLs on the switch to prevent traffic except to the admin node.
inetknght 9y ago
If you have a hard time imagining normal users who would use this, then I suggest you grow your imagination and teach users what possibilities there are.
- blacksmith_tb 9y ago
  Normal users can be sold on the idea of devices talking to each other (though in the case of Bluetooth I'd say it may have soured them on the whole thing). But I'd still say that even convincing a non-dev that wake-on-lan would be handy for them is a stretch, let alone more... Also I'm not sure how much evangelism is really appropriate - I may think that shelling into my headless server at home is great, but if you are happy with just cat videos, who am I to say you need to do more?
derefr 9y ago
Whenever my HTPC gets borked (it's a Hackintosh, it gets borked a lot), I regret not buying a "Q" motherboard. As it is, to fix the box, I have to temporarily switch the HDMI cable to the internal graphics, plug in a USB keyboard and mouse, and then sit down in front of it on the floor, craning my head to look at my TV beside it. With AMT access, I just could remote into the BIOS from my laptop on my couch.

derefr 9y ago

> or if they allowed complete disabling via motherboard jumper That wouldn't really work; the ME is essentially "the CPU" of the Platform Controller Hub. Disabling it would be disabling your computer (e.g. your IOMMU, your DRAM refresh, your ACPI command routing, etc.) All the stuff that used to be done "manually" by the CPU itself back in the 8086 days—using configured IRQs and PITs and whatever else—is done autonomously by the PCH these days, with the CPU just asking the PCH to "get it done." And the logic that runs in the PCH to interpret those requests and decides when and how to apply them, is executed by the ME. The ME only managed to not exist previously, because mainboards were previously both "simpler" (every bus spoke exactly one protocol and the controller chip for that bus did the protocol signalling) and more complex (tons of single-purpose controller chips.) The PCH boils all that down to one chip, and it needs a CPU to do it, and that CPU is the ME. Getting rid of it would mean going back ~15 years in computer capabilities. (Another way to think of the PCH is that it's basically an SoC chip, with the "heavy lifting" of application execution moved out to a separate, upgradable CPU socket. But, like any SoC, it still does need some sort of internal CPU. The ME is that CPU.)

javajosh 9y ago
It's sad to me that manually setting an IRQ is so horrible a prospect that it's better to compromise the entire system. Honestly, I don't understand why there needs to be another CPU in the system. Do systems really need arbitrary bus protocol translation in real time? If people could agree to reasonable standards (a real possibility in the technological asymptote we have entered) we can eliminate this complexity entirely. Then we can worry about something else, which is secretly embedding mini-CPUs into the CPU itself.
- akvadrako 9y ago
  > Honestly, I don't understand why there needs to be another CPU in the system. There are tons of processors in modern systems. Most separate chips for controlling sub-systems have them, like DRAM, NICs, USB, keyboards, monitors, storage devices, video cards, etc... The reasons are performance and flexibility - when separate components act like remote hosts, the device manufacturer can divide up work between the OS driver (main CPU) and target system as desired.

zkms 9y ago

> I think many discussions miss the nuance here. The problem is that the functionality is hidden, not necessarily that the function is there. > If they were more transparent, then they could be used by normal users for remote administration as well. The fundamental objection with ME isn't that it's "proprietary" or "non-libre" or whatever other ideological objections, it's that it's an opaque embuggerance that makes any analysis or reasoning about the system's security/trustworthiness/reliability completely impossible and specious. There aren't even any robust specifications for it (like those for ISAs); it's literally a black box -- and one granted terrifying access to both the system's internals and external network interfaces. It's 10PM. Do you know if your ME has been provisioned by evil malware? I don't care much about whether its source code is public or not, I care about the fact that I have no verifiable and irreversible way to disable that little implant's function. It's not an innocent housekeeping microcontroller, it's one hell of a remote-access-tool, plain and simple. That intelligence agencies have demanded that Intel provide a bit to neuter the ME after its bringup is testament to that. My personal computer isn't part of an enterprise/corporate network, and I don't want any RAT (nor an auxiliary CPU with network access that is waiting to be provisioned to act like a RAT) installed on it, the same way my house-lock isn't keyed with a master key that the police holds. I (and most other end-users) do not need any sort of remote-management capability. We need trustworthy and robust computers that are capable of not leaking secrets and losing control to adversaries -- and "remote management" hardware is a severe step backwards from that.

jordigh 9y ago
> The fundamental objection with ME isn't that it's "proprietary" or "non-libre" or whatever other ideological objections, it's that it's an opaque embuggerance that makes any analysis or reasoning about the system's security/trustworthiness/reliability completely impossible and specious. Erm, your fundamental objection is exactly the same objection as it being non-libre. You presented the same argument while trying to distance yourself from it. Maybe you don't like the words "non-libre" or "proprietary" but you certainly seem to be arguing for the same thing that they are arguing for. > I don't care much about whether its source code is public or not, I care about the fact that I have no verifiable and irreversible way to disable that little implant's function. Having source code is but a tool towards having the freedom to do what you want with your hardware. I can't see another tool that would also work and give the verifiability that you want. Again, maybe you don't like the way people argue for it, but you're arguing for the same freedom that others want.