macosx

Building an ARM cross-toolchain with binutils, gcc, newlib, and gdb from source

Update: Please don't use this script, a fixed and updated version is now maintained in the summon-arm-toolchain git repo. Direct download: summon-arm-toolchain.

I've been planning to write about building custom ARM toolchains for a while (I used stuff from gnuarm.com in the past, but I switched to the lastest and greatest upstream versions at some point). Among other things, recent upstream versions now have ARM Cortex support.

First you will need a few base utilities and libs (this list may not be complete):

  $ apt-get install flex bison libgmp3-dev libmpfr-dev libncurses5-dev libmpc-dev autoconf texinfo build-essential

Then you can use my tiny build-arm-toolchain script, which will download, build, and install the whole toolchain:

  $ cat build-arm-toolchain
  #!/bin/sh
  # Written by Uwe Hermann <uwe@hermann-uwe.de>, released as public domain.
  [...]

Update: Please don't use this script, a fixed and updated version is now maintained in the summon-arm-toolchain git repo. Direct download: summon-arm-toolchain.

The final toolchain is located in /tmp/arm-cortex-toolchain per default, and is ca. 170 MB in size. I explicitly created the build script in such a way that it minimizes the amount of disk space used during the build (ca. 1.2 GB or so, compared to more than 3 GB in the "naive" approach).

Using the "-j 2" option for make (see script) you can speed up the build quite a bit on multi-core machines (ca. 30 minutes vs. 60 minutes on an AMD X2 dual-core box). Also, you can change the script to build for other target variants if you want to (arm-elf or arm-none-eabi, for example).

Checkout the blog entry How to build arm gnu gcc toolchain for Mac OS X by Piotr Esden-Tempski for similar instructions for Mac OS X users.

Oh, and while I'm at it — does anybody have any idea why there are no pre-built toolchains for embedded (microcontroller) ARM targets in Debian? There are some toolchains for other microcontroller architectures (avr, m68hc1x, h8300, z80) but not too much other stuff. Is there some specific reason for the missing ARM toolchains (other than "nobody cared enough yet")?

I have heard about Emdebian, but from a quick look that seems to be more intended for toolchains with Linux/libc, not for microcontroller firmware (i.e. no MMU, no Linux, no libc etc.), but maybe I'm wrong?

Update: Please don't use this script, a fixed and updated version is now maintained in the summon-arm-toolchain git repo. Direct download: summon-arm-toolchain.

Lest We Remember: Cold Boot Attacks on Encryption Keys

Just in case you haven't already read about this... Some researchers from Princeton have published a paper about methods which can be used to attack full-disk-encryption (FDE) schemes.

They have demonstrated that at least BitLocker (Windows Vista), FileVault (MacOS X) and dm-crypt (Linux) are vulnerable to this type of (partly hardware-based) attack scenarios. Quite likely lots of similar other solutions are vulnerable as well.

The main problem is that (contrary to popular belief) RAM does indeed retain its data for a non-trivial amount of time after power is cut (seconds, even minutes or hours if it's cooled down enough), so you can mount some new attacks such as:

  • Get physical access to laptop/computer, cut power to it (the hard way), reboot with a special live CD or USB thumb drive and some special software which dumps the RAM contents to an external disk (or sends it via network). As RAM contents are still there a few seconds after the power is cut, this works astonishingly well.
  • Get physical access to laptop/computer, open it, remove RAM DIMMs while the computer is running, insert them into your own prepared computer and read the RAM contents using some special software.

Yes, all attacks assume that the attacker has physical access to your PC/RAM, in which case you already have several other problems. Still, the new thing about this is that even full-disk-encryption doesn't help much in some cases. You probably shouldn't depend too much on it (but you shouldn't stop using disk encryption either, of course!).

Full paper: coldboot.pdf. There are also some demo videos and pictures.

More coverage at Boing Boing, Bruce Schneier's weblog, Freedom to Tinker, Slashdot, Heise (German), and many more...

Make sure to read the comments of the various articles for more scenarios and possible ideas for how to prevent such attacks. Some ideas include enabling the BIOS RAM checks (which might explicitly erase RAM contents on reboot; that doesn't help in all cases, though) or using coreboot (previously LinuxBIOS) to erase RAM contents at boot-up and/or shutdown.

It's a highly non-trivial issue, though, there's no easy and complete fix so far. The only sure way is to not have your laptop or PC stolen and to not give attackers physical access to your computers.

Syndicate content