5 ms·

All Intel chips since 2010 or so have the management engine. There's a reason why the "reclaim your freedom" notebook is still a Lenovo X60. Some of them come

by pgeorgi 12y ago

All Intel chips since 2010 or so have the management engine. There's a reason why the "reclaim your freedom" notebook is still a Lenovo X60. Some of them come with larger firmware (5MB, making up vPro and AMT), others with the smaller one (1.5MB) that merely does the DRM stuff, but all of them have the full hardware access detailled in the article. AMD is clean on the chipset side until kaveri/kabini. After that, they come with a "platform security processor". I think the GPU has some DRM features (mostly concerned with adding Macrovision noise to the output signal), but I'm not into GPUs very much. Contemporary ARM stuff mostly comes with TrustZone, which can typically be used for DRM as well. AMD adopted the TrustZone model for their current CPUs, too. Since Protected A/V Path and similar DRM systems require OS cooperation, the easiest way to stay clear of them is to use Open Source media players, on an Open Source OS. If you want to avoid supporting proponents of such hardware assisted DRM systems, plain ARM systems that ship without fixed operating system (eg. the cuBox series, rPI & follow ups) are your best bet.

Audiophilip 12y ago
@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.
throwawayaway 12y ago
hello pgeorgi - you are a mine of information on this stuff. thanks for taking hte time to explain all of it! can you tell me if the odroid c1 is a good bet? http://www.cnx-software.com/2014/12/10/hardkernel-odroid-c1-is-a-35-development-board-powered-by-amlogic-s805-quad-core-processor/#ixzz3NqpeUOx4 http://www.cnx-software.com/2014/12/10/hardkernel-odroid-c1-... The company will provide images for Ubuntu 14.04 or Android 4.4 KitKat with Linux 3.10. I think other people can port os's to it. I think it's going to be my next computer!
- pgeorgi 12y ago
  I actually did a bit of a shortcut on ARM, since some of those chips are as bad as Intel's or worse. For example, the rPi was criticized for a long time because the CPU was essentially subordinate to the GPU, whose code was binary-only. That seems to change now. The issue with recommending suitable ARM chips is that there are so many different ones by all kinds of vendors following all kinds of philosophies. In fact it's the first time I heard of that particular chipset vendor. I looked at the chip's specs: Like most current ARM CPUs it comes with TrustZone (including advertising for a "trusted video path"), so an important part to decide if that's an open system is to check what code is running in that mode, and if that can be disabled or replaced. The open sourced u-boot code might be able to give insights here. The other thing is Mali graphics: those come with a closed source graphics driver. There's a reverse engineering project (lima), but they're relatively small and thus easily outperformed by chip vendors (release new iterations of the hardware every 6 months, and they'll never be able to support everything). Sorry that I can't give detailed answers, but it's just too much to stay current with the entire ARM market.
dmm 12y ago
Do you have an opinion on this project: https://www.crowdsupply.com/purism/librem-laptop https://www.crowdsupply.com/purism/librem-laptop ? It's a laptop designed to be free software and it's using coreboot.
- Gracana 12y ago
  That's a step in the right direction, and probably your best option for a modern and very-libre system, but like they say, it still contains firmware blobs. A thinkpad x60, t60, or a couple of similarly spec'd macbooks are the only reasonable completely-free (via libreboot and a free OS) systems you can run right now.
- pgeorgi 12y ago
  It's a noble goal, but they're using Intel hardware. They also don't claim to be free software down to the firmware. But assuming that's their goal: They say they talked with Intel about opening up things, but they're far from the first one to try (and not the most powerful ones either, be it by $$$ or influence, unless there's some background story they keep to themselves). My guess is that they intend well, talked to some sales folks, those promised the moon (and more, if necessary), and when things get serious, the sales persons will be nowhere to be found, while purism is too far down the road to start from scratch. In the end, purism has to compromise while Intel can celebrate another design win. So the end result will be that they use the smaller ME firmware (1.5MB is still a lot of unexplained cruft), the FSP binary (www.intel.com/fsp) and coreboot to glue things together - just like every other coreboot-using Intel based design does right now (there are a couple). The main difference to everybody else will be that purism builds neither embedded electronics that do things no consumer has ever heard of, nor chromebooks. That in itself is already a nice thing from a coreboot perspective, in that it provides exposure to the project and the issue, but I fear some purism backers will feel let down by such an outcome. http://puri.sm/posts/purism-software-freedom-deconstructed/ http://puri.sm/posts/purism-software-freedom-deconstructed/ looks like they try to indicate that "this BIOS code isn't all that much". No, it isn't - but it's exactly the part of the code that sets the rules under which the entire system later operates. In this, it's more important than the plain old (say) gimp binary in that huge top bucket, which has not much of an effect on the security or autonomy of the system or user. I'd love to be wrong here, since either way I 'win' (actually the more I'm wrong, the more I win :) ). I just think it's unlikely given that I'm involved in that mess for the better part of a decade by now, while the purism folks seem to be newcomers with a lot of idealism but few experience with dealing with Intel and their unusual definition of software freedom.

by pgeorgi 12y ago

Audiophilip 12y ago

@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.

throwawayaway 12y ago

hello pgeorgi - you are a mine of information on this stuff. thanks for taking hte time to explain all of it! can you tell me if the odroid c1 is a good bet? http://www.cnx-software.com/2014/12/10/hardkernel-odroid-c1-is-a-35-development-board-powered-by-amlogic-s805-quad-core-processor/#ixzz3NqpeUOx4 http://www.cnx-software.com/2014/12/10/hardkernel-odroid-c1-... The company will provide images for Ubuntu 14.04 or Android 4.4 KitKat with Linux 3.10. I think other people can port os's to it. I think it's going to be my next computer!

pgeorgi 12y ago
I actually did a bit of a shortcut on ARM, since some of those chips are as bad as Intel's or worse. For example, the rPi was criticized for a long time because the CPU was essentially subordinate to the GPU, whose code was binary-only. That seems to change now. The issue with recommending suitable ARM chips is that there are so many different ones by all kinds of vendors following all kinds of philosophies. In fact it's the first time I heard of that particular chipset vendor. I looked at the chip's specs: Like most current ARM CPUs it comes with TrustZone (including advertising for a "trusted video path"), so an important part to decide if that's an open system is to check what code is running in that mode, and if that can be disabled or replaced. The open sourced u-boot code might be able to give insights here. The other thing is Mali graphics: those come with a closed source graphics driver. There's a reverse engineering project (lima), but they're relatively small and thus easily outperformed by chip vendors (release new iterations of the hardware every 6 months, and they'll never be able to support everything). Sorry that I can't give detailed answers, but it's just too much to stay current with the entire ARM market.

dmm 12y ago

Do you have an opinion on this project: https://www.crowdsupply.com/purism/librem-laptop https://www.crowdsupply.com/purism/librem-laptop ? It's a laptop designed to be free software and it's using coreboot.

Gracana 12y ago
That's a step in the right direction, and probably your best option for a modern and very-libre system, but like they say, it still contains firmware blobs. A thinkpad x60, t60, or a couple of similarly spec'd macbooks are the only reasonable completely-free (via libreboot and a free OS) systems you can run right now.
pgeorgi 12y ago
It's a noble goal, but they're using Intel hardware. They also don't claim to be free software down to the firmware. But assuming that's their goal: They say they talked with Intel about opening up things, but they're far from the first one to try (and not the most powerful ones either, be it by $$$ or influence, unless there's some background story they keep to themselves). My guess is that they intend well, talked to some sales folks, those promised the moon (and more, if necessary), and when things get serious, the sales persons will be nowhere to be found, while purism is too far down the road to start from scratch. In the end, purism has to compromise while Intel can celebrate another design win. So the end result will be that they use the smaller ME firmware (1.5MB is still a lot of unexplained cruft), the FSP binary (www.intel.com/fsp) and coreboot to glue things together - just like every other coreboot-using Intel based design does right now (there are a couple). The main difference to everybody else will be that purism builds neither embedded electronics that do things no consumer has ever heard of, nor chromebooks. That in itself is already a nice thing from a coreboot perspective, in that it provides exposure to the project and the issue, but I fear some purism backers will feel let down by such an outcome. http://puri.sm/posts/purism-software-freedom-deconstructed/ http://puri.sm/posts/purism-software-freedom-deconstructed/ looks like they try to indicate that "this BIOS code isn't all that much". No, it isn't - but it's exactly the part of the code that sets the rules under which the entire system later operates. In this, it's more important than the plain old (say) gimp binary in that huge top bucket, which has not much of an effect on the security or autonomy of the system or user. I'd love to be wrong here, since either way I 'win' (actually the more I'm wrong, the more I win :) ). I just think it's unlikely given that I'm involved in that mess for the better part of a decade by now, while the purism folks seem to be newcomers with a lot of idealism but few experience with dealing with Intel and their unusual definition of software freedom.