4 ms·

> This open-source requirement of ours ended up influencing the selection of almost every piece of hardware, including the main CPU, the battery controller, and

> This open-source requirement of ours ended up influencing the selection of almost every piece of hardware, including the main CPU, the battery controller, and the Wi-Fi module. For example, we couldn’t use Intel’s x86 microprocessors because they can accept firmware updates that we cannot debug or inspect. Instead we chose an ARM-based Freescale i.MX6 system-on-a-chip, which has no such updatable code embedded. (A system-on-a-chip, or SoC, is similar to a microprocessor except it has more of the supporting hardware, such as memory and peripheral interfaces, needed to make a complete computer.) The i.MX6 does have some code burned into it to coordinate the computer’s boot-up process, but this firmware can’t be changed, and its unencrypted binary code can be read out and analyzed for possible security problems. I'm confused. They claim the open source requirement prevented them from going with an intel chip, but then they say the reason why was because intel could push firmware updates. Furthermore, the Freescale SoC has firmware built in, but it's not open source. Is this what we consider open source these days? Sure, a good whitepaper is nice, but it's not open source. Don't get me wrong, this is still nice effort on the open front, but calling this a "laptop with no secrets" seems like a stretch.

mmastrac 11y ago
Intel firmware is obfuscated, closed-source and very low-level which means that it could be running nearly anything -- you don't know what it is. The SoC has closed-source blobs, but it's all debugging and reversible which is not as good as OSS, but not as bad as opaque blobs from Intel.
- agumonkey 11y ago
  I really can't wait for the first fully open down to the metal system. A few arm cores, a few vulcan-ish gpu cores, optional fpga. Just nice compute power easy to tap into for oss devs. ps: I shouldn't have written ARM, I meant simple ARM-like ISA (from what I understand it's way smaller than x86).
  - joezydeco 11y ago
    What's the probability that ARM will open-source their CPU core designs?
    - mafuyu 11y ago
      ARM isn't open sourcing anything anytime soon. Take a look at OpenRISC and RISC-V. They're aiming at a fully open source SoC implementation in silicon. http://openrisc.io/ http://openrisc.io/ http://riscv.org/ http://riscv.org/
      - agumonkey 11y ago
        But IIRC (some blog benchmark) they are very very slow.
        zhemao 11y ago
        (Disclaimer: I am a PhD student in the Berkeley computer architecture group, which designs RISC-V) An ISA can't be "fast" or "slow". It's just a specification. There's no reason you can't build a RISC-V core that's just as fast as an ARM or x86 core. The only reason we haven't done so is because we don't have access to the modern fabrication technologies that Intel and commercial ARM licensees use.
        theresistor 11y ago
        Instruction sets very much can be fast or slow, at least in the context of discussing specific use cases. Many of the inner loops that take up most of the active cycles on a CPU today (crypto, compression, imaging, signal processing, linear algebra) have very specific code patterns that are can be targeted with specialized instructions that provide integer-multiple reductions in instruction count. Let's assume that application-targeted instructions can reduce the size of the inner loops in these applications by 2x. Even the RISCiest cores do not, in practice, run at 2x the clock speed or 2x the issue rate of cores with application-targeted instructions. Thus, ISAs with baked in support for these use-case accelerating instructions will be more performant. The RISCy core probably wins on mm^2, but a perf/mm^2 analysis will be highly dependent on how well designed the application-specific instructions are for area conservation.
kawsper 11y ago
People are afraid of the Intel Management Engine, and you can read about it here: http://libreboot.org/faq/#intel http://libreboot.org/faq/#intel It is a dense and very detailed text, but basically your Intel CPU contains Active Management Technology (AMT) which lets remote users control your computer, which may or may not be what you want, and there might be backdoors hiding here. It also includes Intel Boot Guard, which prevents users from installing their own firmware (such as libreboot and coreboot) because it needs to be signed with a key from Intel. The page sums it up like this: > In summary, the Intel Management Engine and its applications are a backdoor with total access to and control over the rest of the PC. The ME is a threat to freedom, security, and privacy, and the libreboot project strongly recommends avoiding it entirely. Since recent versions of it can't be removed, this means avoiding all recent generations of Intel hardware.
- voltagex_ 11y ago
  I've asked a couple of times here, but I haven't had an answer: I've got an X1 carbon where the vPro/AMT/ME setup screen doesn't load (CTRL+P on boot does nothing, missing UEFI binary?). Can I still activate it in Linux for my own purposes?
- jakeogh 11y ago
  Also see Joanna Rutkowska's recent paper: https://news.ycombinator.com/item?id=10458318 https://news.ycombinator.com/item?id=10458318 (fun reading).
xobs 11y ago
The theory is that the boot firmware is executed with the MMU off, and then jumps to your code and is done. Unless you specifically call into ROM, it just sits there unused. Now it could be that there is some hardcoded exception handler in the memory controller that jumps to a specific area of ROM when a certain instruction is hit, and that causes exfiltration of data. But to do that would require a lot of separate components interacting, including ones that Freescale doesn't have access to (i.e. the A9 RTL, and possibly the PL-310 and the memory controller) and would require Freescale put the data exfiltration routine in ROM, or maybe there's an exfiltration routine hardcoded into the PL-310, in which case I wonder how they actually get data out of the machine. As you say, that firmware can't be changed. It can be read out and analyzed for possible security problems, and I hope someone does that. The code is mostly concerned with validating signed boot images for "secure boot" where manufacturers don't want third-party firmwares to be used. It checks the firmware signature / decrypts the firmware using a key burned into OTP fuse bits. Novena doesn't use fuse bits, and in fact doesn't even blow the "boot source" fuses, meaning you're free to change the boot source from internal SD to external SD to SSD to booting from USB. You can actually blow the fuses yourself and load a key known only to you, which means only you can sign firmware that it'll boot.
- nascentmind 11y ago
  xobs, What was your experience working with the CPU vendors to open up the ROM or atleast provide a method to by pass the ROM and use an external ROM?
  - pjc50 11y ago
    "Bypass the ROM" would be a custom chip, albeit a small variation. So that's not going to happen. However the boot ROM isn't actually a secret, it's right there in the memory map for the processor and as Bunnie says you can just read it out. Given that it's a ROM and not reprogrammable, and not used after it transfers control to the user bootloader, I think it's fair to treat it more as part of the silicon than as a piece of software. It might be worth auditing for bugs in the boot assurance crypto though. (If the hardware is malicious, it would be far simpler and less detectable to do it as a silent peripheral, possibly even a whole other processor, than in the boot ROM)
rsync 11y ago
"Instead we chose an ARM-based Freescale i.MX6 system-on-a-chip, which has no such updatable code" Genuinely curious ... in a previous HN discussion: https://news.ycombinator.com/item?id=10458318 https://news.ycombinator.com/item?id=10458318 ARM chips with special "9th cores" were discussed: https://news.ycombinator.com/item?id=10459158 https://news.ycombinator.com/item?id=10459158 Do ARM based Freescale chips, like the i.MX6, have "features" like this ?

mmastrac 11y ago

Intel firmware is obfuscated, closed-source and very low-level which means that it could be running nearly anything -- you don't know what it is. The SoC has closed-source blobs, but it's all debugging and reversible which is not as good as OSS, but not as bad as opaque blobs from Intel.

agumonkey 11y ago
I really can't wait for the first fully open down to the metal system. A few arm cores, a few vulcan-ish gpu cores, optional fpga. Just nice compute power easy to tap into for oss devs. ps: I shouldn't have written ARM, I meant simple ARM-like ISA (from what I understand it's way smaller than x86).
- joezydeco 11y ago
  What's the probability that ARM will open-source their CPU core designs?
  - mafuyu 11y ago
    ARM isn't open sourcing anything anytime soon. Take a look at OpenRISC and RISC-V. They're aiming at a fully open source SoC implementation in silicon. http://openrisc.io/ http://openrisc.io/ http://riscv.org/ http://riscv.org/
    - agumonkey 11y ago
      But IIRC (some blog benchmark) they are very very slow.
      - zhemao 11y ago
        (Disclaimer: I am a PhD student in the Berkeley computer architecture group, which designs RISC-V) An ISA can't be "fast" or "slow". It's just a specification. There's no reason you can't build a RISC-V core that's just as fast as an ARM or x86 core. The only reason we haven't done so is because we don't have access to the modern fabrication technologies that Intel and commercial ARM licensees use.
        theresistor 11y ago
        Instruction sets very much can be fast or slow, at least in the context of discussing specific use cases. Many of the inner loops that take up most of the active cycles on a CPU today (crypto, compression, imaging, signal processing, linear algebra) have very specific code patterns that are can be targeted with specialized instructions that provide integer-multiple reductions in instruction count. Let's assume that application-targeted instructions can reduce the size of the inner loops in these applications by 2x. Even the RISCiest cores do not, in practice, run at 2x the clock speed or 2x the issue rate of cores with application-targeted instructions. Thus, ISAs with baked in support for these use-case accelerating instructions will be more performant. The RISCy core probably wins on mm^2, but a perf/mm^2 analysis will be highly dependent on how well designed the application-specific instructions are for area conservation.

kawsper 11y ago

People are afraid of the Intel Management Engine, and you can read about it here: http://libreboot.org/faq/#intel http://libreboot.org/faq/#intel It is a dense and very detailed text, but basically your Intel CPU contains Active Management Technology (AMT) which lets remote users control your computer, which may or may not be what you want, and there might be backdoors hiding here. It also includes Intel Boot Guard, which prevents users from installing their own firmware (such as libreboot and coreboot) because it needs to be signed with a key from Intel. The page sums it up like this: > In summary, the Intel Management Engine and its applications are a backdoor with total access to and control over the rest of the PC. The ME is a threat to freedom, security, and privacy, and the libreboot project strongly recommends avoiding it entirely. Since recent versions of it can't be removed, this means avoiding all recent generations of Intel hardware.

voltagex_ 11y ago
I've asked a couple of times here, but I haven't had an answer: I've got an X1 carbon where the vPro/AMT/ME setup screen doesn't load (CTRL+P on boot does nothing, missing UEFI binary?). Can I still activate it in Linux for my own purposes?
jakeogh 11y ago
Also see Joanna Rutkowska's recent paper: https://news.ycombinator.com/item?id=10458318 https://news.ycombinator.com/item?id=10458318 (fun reading).

xobs 11y ago

The theory is that the boot firmware is executed with the MMU off, and then jumps to your code and is done. Unless you specifically call into ROM, it just sits there unused. Now it could be that there is some hardcoded exception handler in the memory controller that jumps to a specific area of ROM when a certain instruction is hit, and that causes exfiltration of data. But to do that would require a lot of separate components interacting, including ones that Freescale doesn't have access to (i.e. the A9 RTL, and possibly the PL-310 and the memory controller) and would require Freescale put the data exfiltration routine in ROM, or maybe there's an exfiltration routine hardcoded into the PL-310, in which case I wonder how they actually get data out of the machine. As you say, that firmware can't be changed. It can be read out and analyzed for possible security problems, and I hope someone does that. The code is mostly concerned with validating signed boot images for "secure boot" where manufacturers don't want third-party firmwares to be used. It checks the firmware signature / decrypts the firmware using a key burned into OTP fuse bits. Novena doesn't use fuse bits, and in fact doesn't even blow the "boot source" fuses, meaning you're free to change the boot source from internal SD to external SD to SSD to booting from USB. You can actually blow the fuses yourself and load a key known only to you, which means only you can sign firmware that it'll boot.

nascentmind 11y ago
xobs, What was your experience working with the CPU vendors to open up the ROM or atleast provide a method to by pass the ROM and use an external ROM?
- pjc50 11y ago
  "Bypass the ROM" would be a custom chip, albeit a small variation. So that's not going to happen. However the boot ROM isn't actually a secret, it's right there in the memory map for the processor and as Bunnie says you can just read it out. Given that it's a ROM and not reprogrammable, and not used after it transfers control to the user bootloader, I think it's fair to treat it more as part of the silicon than as a piece of software. It might be worth auditing for bugs in the boot assurance crypto though. (If the hardware is malicious, it would be far simpler and less detectable to do it as a silent peripheral, possibly even a whole other processor, than in the boot ROM)

rsync 11y ago

"Instead we chose an ARM-based Freescale i.MX6 system-on-a-chip, which has no such updatable code" Genuinely curious ... in a previous HN discussion: https://news.ycombinator.com/item?id=10458318 https://news.ycombinator.com/item?id=10458318 ARM chips with special "9th cores" were discussed: https://news.ycombinator.com/item?id=10459158 https://news.ycombinator.com/item?id=10459158 Do ARM based Freescale chips, like the i.MX6, have "features" like this ?