7 ms·

How do they deal with the intel management engine in all intel chips? https://libreboot.org/faq/ https://libreboot.org/faq/

teaearlgraycold 10y ago
Didn't know about this. They should have gone with AMD.
- mordocai 10y ago
  https://libreboot.org/faq/#amd https://libreboot.org/faq/#amd. ARM maybe?
  - Cyph0n 10y ago
    ARM has TrustZone.
    - monocasa 10y ago
      TrustZone is, for practical purposes, a little more open if you're the one designing the board. Most of the time, the crypto is opt in, and you as the final assembler control the keys.
    - subway 10y ago
      TrustZone alone is much closer to a SecureBoot or TPMish feature than ME. It's possible it would allow implementation of an ME-like software stack running inside the TEE. It's worth mentioning that there is at least one OSS implementation of a TEE software stack, OP-TEE, making this even less of an issue. Assuming your device/soc mfg doesn't lock you out. http://www.linaro.org/blog/core-dump/op-tee-open-source-security-mass-market/ http://www.linaro.org/blog/core-dump/op-tee-open-source-secu...
- calcifer 10y ago
  AMD has it too: https://libreboot.org/faq/#amdpsp https://libreboot.org/faq/#amdpsp
- DashRattlesnake 10y ago
  If you want to get away from that kind of thing, right now I think you're options are POWER8: https://www.raptorengineering.com/TALOS/prerelease.php https://www.raptorengineering.com/TALOS/prerelease.php AMD has something similar to the Intel Management Engine: https://libreboot.org/faq/#amd https://libreboot.org/faq/#amd
  - dorfsmay 10y ago
    Not SPARC?
    - nickpsecurity 10y ago
      Specifically, the OpenSPARC T2: http://www.oracle.com/technetwork/systems/opensparc/opensparc-t2-page-1446157.html http://www.oracle.com/technetwork/systems/opensparc/openspar... The ASIC implementation was nice: https://en.wikipedia.org/wiki/UltraSPARC_T2 https://en.wikipedia.org/wiki/UltraSPARC_T2 On a 65nm node... very outdated one... it might get 8 threads in 8 cores at 1.6GHz each with hardware RNG, crypto accelerators, and hypervisor support. That's the kind of implementation that would be useless for an open-source, secure workstation, server, or HPC node. ;) Especially if one slightly increased single-core performance or cache when porting it to 45nm. Forget that, though. Let's see what IBM will charge for their admittedly-faster pile of complicated silicon that only certain people can see which they've already turned into non-backdoored chips for you. ;)
      - apaprocki 10y ago
        Sadly the T1/T2 are ancient now. The non-open SPARC is up to T7, which is 20nm process, 256 threads on 32 cores.
        nickpsecurity 10y ago
        Sort of. I run the bloated Web, movies, IDE's, servers, and VM's on a Core Duo with 2 cores under 2GHz done on 65nm. I'd loose some single-threaded performance probably with an OpenSPARC T2 but otherwise it should handle my modern workload. Doesn't quite feel ancient. ;) The cool thing about open-source CPU's is one can always improve on them to, say, have an extra dozen cores on more recent nodes. Like Oracle does but probably less impressive with less money.
- hackermailman 10y ago
  My Rockchip Chromebook doesn't have proprietary microcode, libreboot supported, costs $200. Only proprietary issue is the 3D acceleration
  - Johan-bjareholt 10y ago
    That is the case with many ARM processors. There is a lot of work being made on iGPUs on ARM processors aswell currently such as freedreno, will hopefully be possible to have a good fully open source experience in a few years with arm linux computers.
mthoms 10y ago
FTA: This project is about having a standard, physically secure computer that anyone can use – as open as we can make it. All these concepts are important, and they mean that x86 and flawless out-of-the-box Windows support are not optional. There are reasons everyone is using x86, even in the security community and in governmental agencies around the world: compatibility, performance, and security. Make no mistake, some of us own Yeeloongs, and others are veterans of the silicon industry. We would love to ship a completely free and usable desktop processor, but we know very well that there is no alternative. Some people seem to think that switching to AMD can solve problems related Intel’s Management Engine (ME), microcode, or SMM. It doesn’t, as there are equivalents of these technologies in all recent x86 processors.
- na85 10y ago
  That's all fine and good but they should not advertise it as secure if it's not.
  - briceb8e 10y ago
    It's secure, "trust us".
  - nickpsecurity 10y ago
    They advertise it as "physically-secure" in the text. I didn't watch the video. They explicitly call out many risks, why they're there, and what they do about them.
    - talltower 10y ago
      We have built a list of hacks that we addressed and how. Please feel free to read up on all of these and more in our Product Description in the section "Potential attacks prevented" : https://www.orwl.org/wiki/index.php?title=File:ORWL_PRD_v0.61.pdf https://www.orwl.org/wiki/index.php?title=File:ORWL_PRD_v0.6...
  - lallysingh 10y ago
    There's no such thing as "secure", and frankly complaining that anything that has better security than regular products shouldn't advertise as such is ridiculous. How else is there any progress when the community's just pulling everyone down with this "it's no good if it isn't completely perfect" crap?
Sanddancer 10y ago
In order for the Management Engine to really do much, you need to have a network card that the management engine knows how to talk to. If you don't have such a network interface, the ME can't do all that much, and any adverse security risks are near zero. Add to that things like the firmware write line being controlled by a completely separate microcontroller, and the big things that are discussed are completely infeasible. I'd be much more worried about the lack of microcode updates that libreboot users shun in the name of "freedom".
- Karunamon 10y ago
  In order for the Management Engine to really do much, you... ...have to trust Intel's publicly available documentation. In other words, this has to be taken on pure faith that it does exactly what they say it does in exactly the way they say it does it, and no more. The problem with ME is that it consists of unauditable code that could be doing literally anything on the computer, completely transparent to the user. Furthermore, even if there is nothing untoward happening when the chip leaves the fab (again, must be taken on faith), a documented threat is having hardware interdicted, modified, and sent on its way.
  - Sanddancer 10y ago
    Interdiction could happen with open source hardware too. Swipe the SoC, and no one would be the wiser. Given everything that has to be in place for vPro/the ME to work, looking at the pcb would give enough information to tell exactly how much, if any, information it could steal, if all the malicious items were in place. All of which could be easily undone by reflashing it, because the write line on the bios is not controlled by the CPU. A lot of steps have to be done, physically and in software in order to exploit it, and that exploit would melt away on the first bios flash. I'd be much more concerned about the security of the software running on the system than any theoretical hack on the ME.
    - Karunamon 10y ago
      >Swipe the SoC, and no one would be the wiser. It would have to get swiped on the way from the manufacturer to the OEM. Once the OEM has sent it out, it's protected against this exact kind of attack. And while it may make sense for interdiction of a single package to a known target, doing the same with an entire batch of chips seems prohibitively expensive. >Given everything that has to be in place for vPro/the ME to work Again, per Intel's documentation. For all anyone here knows, data exfil begins the moment a certain sequence of bits crosses the right registers - and it's not like this is beyond the capabilities of what ME lets you do. There is no good reason that the entire subsystem can't be disabled by the user, permanently. But, come to find out about it, the chips are configured to shut the system down within 30 minutes if the ME firmware doesn't pass checksum. That, in my mind, puts it uncomfortably close to malware territory. Every one of these concerns evaporate if the ME area could be wiped or dumped - it's not as if remote management is some secret competitive advantage.

teaearlgraycold 10y ago

Didn't know about this. They should have gone with AMD.

mordocai 10y ago
https://libreboot.org/faq/#amd https://libreboot.org/faq/#amd. ARM maybe?
- Cyph0n 10y ago
  ARM has TrustZone.
  - monocasa 10y ago
    TrustZone is, for practical purposes, a little more open if you're the one designing the board. Most of the time, the crypto is opt in, and you as the final assembler control the keys.
  - subway 10y ago
    TrustZone alone is much closer to a SecureBoot or TPMish feature than ME. It's possible it would allow implementation of an ME-like software stack running inside the TEE. It's worth mentioning that there is at least one OSS implementation of a TEE software stack, OP-TEE, making this even less of an issue. Assuming your device/soc mfg doesn't lock you out. http://www.linaro.org/blog/core-dump/op-tee-open-source-security-mass-market/ http://www.linaro.org/blog/core-dump/op-tee-open-source-secu...
calcifer 10y ago
AMD has it too: https://libreboot.org/faq/#amdpsp https://libreboot.org/faq/#amdpsp
DashRattlesnake 10y ago
If you want to get away from that kind of thing, right now I think you're options are POWER8: https://www.raptorengineering.com/TALOS/prerelease.php https://www.raptorengineering.com/TALOS/prerelease.php AMD has something similar to the Intel Management Engine: https://libreboot.org/faq/#amd https://libreboot.org/faq/#amd
- dorfsmay 10y ago
  Not SPARC?
  - nickpsecurity 10y ago
    Specifically, the OpenSPARC T2: http://www.oracle.com/technetwork/systems/opensparc/opensparc-t2-page-1446157.html http://www.oracle.com/technetwork/systems/opensparc/openspar... The ASIC implementation was nice: https://en.wikipedia.org/wiki/UltraSPARC_T2 https://en.wikipedia.org/wiki/UltraSPARC_T2 On a 65nm node... very outdated one... it might get 8 threads in 8 cores at 1.6GHz each with hardware RNG, crypto accelerators, and hypervisor support. That's the kind of implementation that would be useless for an open-source, secure workstation, server, or HPC node. ;) Especially if one slightly increased single-core performance or cache when porting it to 45nm. Forget that, though. Let's see what IBM will charge for their admittedly-faster pile of complicated silicon that only certain people can see which they've already turned into non-backdoored chips for you. ;)
    - apaprocki 10y ago
      Sadly the T1/T2 are ancient now. The non-open SPARC is up to T7, which is 20nm process, 256 threads on 32 cores.
      - nickpsecurity 10y ago
        Sort of. I run the bloated Web, movies, IDE's, servers, and VM's on a Core Duo with 2 cores under 2GHz done on 65nm. I'd loose some single-threaded performance probably with an OpenSPARC T2 but otherwise it should handle my modern workload. Doesn't quite feel ancient. ;) The cool thing about open-source CPU's is one can always improve on them to, say, have an extra dozen cores on more recent nodes. Like Oracle does but probably less impressive with less money.
hackermailman 10y ago
My Rockchip Chromebook doesn't have proprietary microcode, libreboot supported, costs $200. Only proprietary issue is the 3D acceleration
- Johan-bjareholt 10y ago
  That is the case with many ARM processors. There is a lot of work being made on iGPUs on ARM processors aswell currently such as freedreno, will hopefully be possible to have a good fully open source experience in a few years with arm linux computers.

mthoms 10y ago

FTA: This project is about having a standard, physically secure computer that anyone can use – as open as we can make it. All these concepts are important, and they mean that x86 and flawless out-of-the-box Windows support are not optional. There are reasons everyone is using x86, even in the security community and in governmental agencies around the world: compatibility, performance, and security. Make no mistake, some of us own Yeeloongs, and others are veterans of the silicon industry. We would love to ship a completely free and usable desktop processor, but we know very well that there is no alternative. Some people seem to think that switching to AMD can solve problems related Intel’s Management Engine (ME), microcode, or SMM. It doesn’t, as there are equivalents of these technologies in all recent x86 processors.

na85 10y ago
That's all fine and good but they should not advertise it as secure if it's not.
- briceb8e 10y ago
  It's secure, "trust us".
- nickpsecurity 10y ago
  They advertise it as "physically-secure" in the text. I didn't watch the video. They explicitly call out many risks, why they're there, and what they do about them.
  - talltower 10y ago
    We have built a list of hacks that we addressed and how. Please feel free to read up on all of these and more in our Product Description in the section "Potential attacks prevented" : https://www.orwl.org/wiki/index.php?title=File:ORWL_PRD_v0.61.pdf https://www.orwl.org/wiki/index.php?title=File:ORWL_PRD_v0.6...
- lallysingh 10y ago
  There's no such thing as "secure", and frankly complaining that anything that has better security than regular products shouldn't advertise as such is ridiculous. How else is there any progress when the community's just pulling everyone down with this "it's no good if it isn't completely perfect" crap?

Sanddancer 10y ago

In order for the Management Engine to really do much, you need to have a network card that the management engine knows how to talk to. If you don't have such a network interface, the ME can't do all that much, and any adverse security risks are near zero. Add to that things like the firmware write line being controlled by a completely separate microcontroller, and the big things that are discussed are completely infeasible. I'd be much more worried about the lack of microcode updates that libreboot users shun in the name of "freedom".

Karunamon 10y ago
In order for the Management Engine to really do much, you... ...have to trust Intel's publicly available documentation. In other words, this has to be taken on pure faith that it does exactly what they say it does in exactly the way they say it does it, and no more. The problem with ME is that it consists of unauditable code that could be doing literally anything on the computer, completely transparent to the user. Furthermore, even if there is nothing untoward happening when the chip leaves the fab (again, must be taken on faith), a documented threat is having hardware interdicted, modified, and sent on its way.
- Sanddancer 10y ago
  Interdiction could happen with open source hardware too. Swipe the SoC, and no one would be the wiser. Given everything that has to be in place for vPro/the ME to work, looking at the pcb would give enough information to tell exactly how much, if any, information it could steal, if all the malicious items were in place. All of which could be easily undone by reflashing it, because the write line on the bios is not controlled by the CPU. A lot of steps have to be done, physically and in software in order to exploit it, and that exploit would melt away on the first bios flash. I'd be much more concerned about the security of the software running on the system than any theoretical hack on the ME.
  - Karunamon 10y ago
    >Swipe the SoC, and no one would be the wiser. It would have to get swiped on the way from the manufacturer to the OEM. Once the OEM has sent it out, it's protected against this exact kind of attack. And while it may make sense for interdiction of a single package to a known target, doing the same with an entire batch of chips seems prohibitively expensive. >Given everything that has to be in place for vPro/the ME to work Again, per Intel's documentation. For all anyone here knows, data exfil begins the moment a certain sequence of bits crosses the right registers - and it's not like this is beyond the capabilities of what ME lets you do. There is no good reason that the entire subsystem can't be disabled by the user, permanently. But, come to find out about it, the chips are configured to shut the system down within 30 minutes if the ME firmware doesn't pass checksum. That, in my mind, puts it uncomfortably close to malware territory. Every one of these concerns evaporate if the ME area could be wiped or dumped - it's not as if remote management is some secret competitive advantage.