4 ms·

@pgeorgi: >All Intel chips since 2010 or so have the management engine. Do you have sources for this? I wanted to verify it, but after a few Google searches I

@pgeorgi: >All Intel chips since 2010 or so have the management engine. Do you have sources for this? I wanted to verify it, but after a few Google searches I could not find anything that states exactly that. I have a Haswell CPU, but I have no Management Engine settings in my BIOS. How does the vPro feature correlate with the Management Engine? Because not all Intel CPU's come with vPro. Or is that only a firmware difference? Would be nice to see clearer in this issue, but most websites contain only marketing nonsense.

eeZi 12y ago
It is part of the chipset and has other functions too (parts of the power management, for example).
pgeorgi 12y ago
My source is that I work on coreboot, where we have to interact with that stuff all the time. It's actually somewhat hidden in our haswell driver because so much is now binary-only on Intel platforms. But look at http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/northbridge/intel/haswell/finalize.c;hb=HEAD http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=sr... whose comments refer to both "ME" (the management engine) and "PAVP", which is the "Protected A/V Path" referred to in the article. One sure way to figure it out is to get a full image of your firmware flash, and analyze it. coreboot has a tool called ifdtool which can parse the "intel firmware descriptor", which is kind of a partitioning scheme for flash - among other things, to make room for the ME firmware. Sometimes board vendors have full images available for download that you could use for analysis, but these days they're often smaller, shipping only the changed parts. flashrom (www.flashrom.org) might be able to read out the chip on your running system, but on Intel platforms in particular, this is often restricted and you'd need to attach some external flash programmer to read it out and be sure. I think it speaks volumes that you have to work around such things on your own hardware in the first place... As far as I know, vPro only requires the larger firmware and the use of on-chipset hardware, in particular NIC and GPU, since the vPro firmware doesn't support external devices. I don't know if that's just economics (no need to write drivers for tons of devices, no desire to support other vendors' hardware) or if the ME is too limited for that - but my guess is the former. One way we (at coreboot) can test ME involvement is to corrupt the ME firmware with an external flasher (while leaving everything else intact) and see the system either not start at all, or reliably shut down after 30 minutes. The exact behaviour depends on some wiring on the board, I guess.
- userbinator 12y ago
  From that file: pci_or_config32(PCI_DEV_HSW, 0xb0, 1 << 0); /* BDSM */ What is "BDSM"? It almost seems like a strangely appropriate name for another DRM feature. It's actually somewhat hidden in our haswell driver because so much is now binary-only on Intel platforms. One thing that I've noticed browsing around Coreboot sources is that the source code is rather opaque - full of "magic constants" with little to no meaning. It may be "open-source" and GPL, but I don't think it's in the spirit of open-source to have code that can't really be understood. I can get the same depth of information by just disassembling a BIOS and seeing what addresses it writes with what values. If anything, it feels like someone has found a way to "contribute" to open-source without actually disclosing much. (Aside: how do binary-only blobs get let into Coreboot? It sort of defeats the purpose, doesn't it?) and see the system either not start at all, or reliably shut down after 30 minutes That second alternative is just scary. Really scary, like a hidden silent killswitch.
  - pgeorgi 12y ago
    When all you do is to write a single opaque value in a register, and never use those bits again, it's slightly excessive to give each of them a name. This also reflects in chipset documentation, which sometimes comes with pages and pages of "write X to register Y", and not much more. The value is that the higher level structure is more easily visible when you know what is code and what is data (which is the main issue with disassembly), and the ability to quickly see that you haven't missed extra code that is executed in some sneaky place because everything in the output is accounted for somehow. The options we have with coreboot are to have 8MB of unaccounted stuff, or 500KB of unaccounted stuff. The latter can be reverse engineered more easily, since the scope is known, and the complexity is a magnitude smaller (no code decompressing other code, jumping into it, ...). That was actually done for sandybridge. We even built tools to simplify reverse engineering (www.serialice.com) As for the funnily named BDSM register: http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/4th-gen-core-family-mobile-u-y-processor-lines-vol-2-datasheet.pdf http://www.intel.com/content/dam/www/public/us/en/documents/... calls it "Base Data of Stolen Memory". Essentially, both GPU and ME get assigned some system memory to work in, and that register contains the first address that isn't available to the CPU due to this arrangement. That register itself is harmless. In older Intel chipsets, it was possible for the host CPU to get a peek into the ME's memory by messing with that register, which was used for some ME analysis in 2012 or 2013. Unfortunately they plugged that hole, and that register's role is more of the informative kind.

eeZi 12y ago

It is part of the chipset and has other functions too (parts of the power management, for example).

pgeorgi 12y ago

My source is that I work on coreboot, where we have to interact with that stuff all the time. It's actually somewhat hidden in our haswell driver because so much is now binary-only on Intel platforms. But look at http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=src/northbridge/intel/haswell/finalize.c;hb=HEAD http://review.coreboot.org/gitweb?p=coreboot.git;a=blob;f=sr... whose comments refer to both "ME" (the management engine) and "PAVP", which is the "Protected A/V Path" referred to in the article. One sure way to figure it out is to get a full image of your firmware flash, and analyze it. coreboot has a tool called ifdtool which can parse the "intel firmware descriptor", which is kind of a partitioning scheme for flash - among other things, to make room for the ME firmware. Sometimes board vendors have full images available for download that you could use for analysis, but these days they're often smaller, shipping only the changed parts. flashrom (www.flashrom.org) might be able to read out the chip on your running system, but on Intel platforms in particular, this is often restricted and you'd need to attach some external flash programmer to read it out and be sure. I think it speaks volumes that you have to work around such things on your own hardware in the first place... As far as I know, vPro only requires the larger firmware and the use of on-chipset hardware, in particular NIC and GPU, since the vPro firmware doesn't support external devices. I don't know if that's just economics (no need to write drivers for tons of devices, no desire to support other vendors' hardware) or if the ME is too limited for that - but my guess is the former. One way we (at coreboot) can test ME involvement is to corrupt the ME firmware with an external flasher (while leaving everything else intact) and see the system either not start at all, or reliably shut down after 30 minutes. The exact behaviour depends on some wiring on the board, I guess.

userbinator 12y ago
From that file: pci_or_config32(PCI_DEV_HSW, 0xb0, 1 << 0); /* BDSM */ What is "BDSM"? It almost seems like a strangely appropriate name for another DRM feature. It's actually somewhat hidden in our haswell driver because so much is now binary-only on Intel platforms. One thing that I've noticed browsing around Coreboot sources is that the source code is rather opaque - full of "magic constants" with little to no meaning. It may be "open-source" and GPL, but I don't think it's in the spirit of open-source to have code that can't really be understood. I can get the same depth of information by just disassembling a BIOS and seeing what addresses it writes with what values. If anything, it feels like someone has found a way to "contribute" to open-source without actually disclosing much. (Aside: how do binary-only blobs get let into Coreboot? It sort of defeats the purpose, doesn't it?) and see the system either not start at all, or reliably shut down after 30 minutes That second alternative is just scary. Really scary, like a hidden silent killswitch.
- pgeorgi 12y ago
  When all you do is to write a single opaque value in a register, and never use those bits again, it's slightly excessive to give each of them a name. This also reflects in chipset documentation, which sometimes comes with pages and pages of "write X to register Y", and not much more. The value is that the higher level structure is more easily visible when you know what is code and what is data (which is the main issue with disassembly), and the ability to quickly see that you haven't missed extra code that is executed in some sneaky place because everything in the output is accounted for somehow. The options we have with coreboot are to have 8MB of unaccounted stuff, or 500KB of unaccounted stuff. The latter can be reverse engineered more easily, since the scope is known, and the complexity is a magnitude smaller (no code decompressing other code, jumping into it, ...). That was actually done for sandybridge. We even built tools to simplify reverse engineering (www.serialice.com) As for the funnily named BDSM register: http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/4th-gen-core-family-mobile-u-y-processor-lines-vol-2-datasheet.pdf http://www.intel.com/content/dam/www/public/us/en/documents/... calls it "Base Data of Stolen Memory". Essentially, both GPU and ME get assigned some system memory to work in, and that register contains the first address that isn't available to the CPU due to this arrangement. That register itself is harmless. In older Intel chipsets, it was possible for the host CPU to get a peek into the ME's memory by messing with that register, which was used for some ME analysis in 2012 or 2013. Unfortunately they plugged that hole, and that register's role is more of the informative kind.