Your Google Drive is not ready yet

Well, almost here…

Here is a quick comparison on some of the remote storage and file sync solutions that I consider important:

(For a list that is more complete, go to Wikipedia)

I find client-side encryption crucial for personal privacy, and having the client source code released is just as important. The benefit is that you don’t have to trust that the company that owns the storage will not compromise and disclose your data, either maliciously or clumsily.

In the diverse world of personal devices, compatibility with different platforms is also very convenient, if not necessary.

In this moment there’s no solution that offers these things together, and Google Drive does not fill this space. The services that come closer to my requirements are SpiderOak and Wuala, but unfortunately they don’t have an Open Source client.

The two personal services that I added in the table are quite promising, but lack two things to be successful in my opinion: the first is mobile access and the second is some company who already gives you an online service to sync to.

The possible attack scenarios that result in having our password compromised are very different, here are some examples:

• Phishing can trick you into giving away your credentials
• Trojans, viruses and other exploits could compromise your machine and grab what you type
• Man-in-the-middle attacks on the network could read your secrets sent on unencrypted (or poorly encrypted) channel
• Website security could be physically compromised, and the private data stolen
• Log-ins to websites could be discovered by brute force attacks
• Encrypted content could be decrypted with offline brute force attacks

In order to defend ourselves from some of these attacks (mainly the last ones), a strong password is required. But what is a strong password? Most guidelines tell us that:

• It should be long enough
• It must not be a “dictionary” word
• It shouldn’t contain “weak” patterns
• It should be composed of different character sets (letters, numbers, special characters)

The problem with these guidelines is that they clash with our brain’s ability to remember, because some of the things that makes a word stick in our brain are:

• Be short enough
• Be meaningful (like an existing word)
• Contain some sort of way to help remember it from other things (patterns)
• Phonetic (alphabetic)

For this reason, choosing a password is always a trade-off between security and usability. Sometimes websites enforce these policies, sometimes they give you a hard-to-remember password themselves. The famous webcomic XKCD tackled the problem in this strip, suggesting a simple method for common people to choose strong pass phrases. But in my opinion things can be even easier for a particular subset of people.

I assume most of my readers are programmers. We have a very peculiar job, we type stuff on our keyboards that doesn’t have any sense for the common people, but for us it sure has. We type so much that the muscles of our hands memorized the motions, together with the position of some unusual characters such as the “[ ]” square brackets, and we can type without even looking. Sometimes, especially after we debug an ugly problem, we examined a particular snippet of code so much that we can write it immediately off the top of our heads.

I believe programmers develop throughout the years a familiar way to remember and write strong passwords which are harder for computers to guess than the norm. If you’re a programmer, this is what you can do:

1. Pick a language that you are experienced with,
2. write a short piece of code,
3. insert letters, numbers, and special characters,
4. insert some kind of information related to the website (if it’s an online password) or the date (if the password expires regularly)

For example, I created one of the simplest examples I could think of:

 W = printf("93\n");

I am experienced in C programming, and inserted a “W” in the code to hint to WordPress site. How easy is it to remember? Easy (I print 93 and put the number of characters in “W“). How easy is it to write? Easy (if I don’t forget the semicolon). How hard is it to guess? Let’s see… I used the following online calculators to get their “opinion” on the strength of this password:

• Password Strength Test – Rumkin.com – Rumkin.com
• GRC’s | Password Haystacks: How Well Hidden is Your Needle?
• Password Strength Estimator

The results are that my 19-character password is strong, the character set is about 93 to 95 characters (between letters, numbers and specials, depending on how you divide them),  and the entropy is between 84 and 125 bits. To make some comparisons using the XKCD examples, the password “Tr0ub4dor&3” is 11 characters, a charset of 72 to 95, and an entropy of 51 to 72 bits. The password “correct horse battery staple” is 28 characters long, with a charset of 27 to 59 characters, and an entropy of 104 to 165 bits.

Using a method similar to XKCD I say that, knowing that the password is a piece of code, we have:

• Something like 20 possible common programming languages
• A hundred possible patterns (very conservative)
• Something like 5 different coding conventions (such as where to put the space)
• One function name/keyword, chosen from hundreds of possibilities
• Two short common variable names/strings, composed of up to four characters
• Each has a charset of size 64 (lowercase, uppercase, numbers, underscore and dot)

It results in this number of possibilities:

20*100*5*100*((64^4)^2) = 2.8*10^20

This number translates roughly into 68 bits of entropy.

I can think of some of the “cons” of choosing a line of code as a password:

• Many programmers are used to look at the screen while writing, to have a feedback that the code they’re writing is correct. With passwords you can’t see what you are typing.
• If you use an existing line of an open source software you are working on, then you could theoretically be more vulnerable to a dictionary attack tailored for you.
• Code written in a language obeys to common patterns derived from the syntax.
• If you are on a different PC, the language of the keyboard may impede the correct typing of the special characters.

In the end, I am not saying that if you are a programmer you have to use a line of code as a password because it’s the best way. I’m suggesting that this choice has many benefits for the common programmers, because it exploit some qualities of the programming work to shift the compromise between security and usability. But in the end it boils down to finding the place in this compromise where you personally feel comfortable.

The ARM926 is able to detect and manage a certain number of exceptions, for example:

• “undefined” exception: when the core tries to execute an instruction that is not mapped on the instruction set
• data abort: when the system bus reports an error in trying to access one of the peripherals
• IRQ: the most common exception is the arrival of an interrupt request (IRQ) from a peripheral.

When an exception occurs, the ARM926 core changes its operating “mode” and jumps to the beginning of the memory, with an offset from address 0 that depends on the exception. For example, when an “undefined” exception happens, the core jumps to address 4. By placing instruction at those addresses, it is possible to manage these exceptions with custom functions. The common way is to place a “jump” at each of those addresses, creating an “exception vector table” (where the vector is the jump instruction).

The following is an assembly file called “vectors.S” that shows an example of vector table and reset handler, which contains the minimal initialization that needs to be done before jumping to C code.

 .text
 .code 32

 .global vectors_start
 .global vectors_end

vectors_start:
 LDR PC, reset_handler_addr
 LDR PC, undef_handler_addr
 LDR PC, swi_handler_addr
 LDR PC, prefetch_abort_handler_addr
 LDR PC, data_abort_handler_addr
 B .
 LDR PC, irq_handler_addr
 LDR PC, fiq_handler_addr

reset_handler_addr: .word reset_handler
undef_handler_addr: .word undef_handler
swi_handler_addr: .word swi_handler
prefetch_abort_handler_addr: .word prefetch_abort_handler
data_abort_handler_addr: .word data_abort_handler
irq_handler_addr: .word irq_handler
fiq_handler_addr: .word fiq_handler

vectors_end:

reset_handler:
 /* set Supervisor stack */
 LDR sp, =stack_top
 /* copy vector table to address 0 */
 BL copy_vectors
 /* get Program Status Register */
 MRS r0, cpsr
 /* go in IRQ mode */
 BIC r1, r0, #0x1F
 ORR r1, r1, #0x12
 MSR cpsr, r1
 /* set IRQ stack */
 LDR sp, =irq_stack_top
 /* Enable IRQs */
 BIC r0, r0, #0x80
 /* go back in Supervisor mode */
 MSR cpsr, r0
 /* jump to main */
 BL main
 B .

.end

Some details about the assembly code:

The vector table must be placed at address 0, but when the program is executed, it is possible that it is not loaded at the beginning of the memory. For example QEMU loads the binary code at address 0x10000. For this reason the vector table needs to be copied before being useful. This is done by using global symbols to mark the beginning (vectors_start) and end (vectors_end) of the vectors area, and then using a function (copy_vectors, implemented below in the C code) to copy it to the correct location.

When the core receives an exception it changes operating mode, and this means (among other things) that it uses a different stack pointer. For this reason before enabling interrupts it is necessary to configure the stack for the modes that we intend to use.

The operating mode can be changed manually by accessing the Program Status Register (cpsr), which must also be used to enable IRQs. More information on the ARM9EJ-S Technical Reference Manual.

I want to use the UART as a simple peripheral that uses IRQ to function. The Versatile manual indicates that an Interrupt Controller is used to manage the various IRQs. The following manuals are needed to understand what to do:

• RealView Platform Baseboard for ARM926EJ-S User Guide
• PrimeCell UART (PL011) Technical Reference Manual
• PrimeCell Vectored Interrupt Controller (PL190) Technical Reference Manual

In order to enable IRQ for UART, the interrupt must be enabled in three places:

• The IRQs must be enabled in the ARM cpsr
• The UART IRQ must be enabled in the Interrupt Controller
• The interrupt generation must be enabled in UART registers for the chosen events

I will use the “RX” event to fire an interrupt that manages the arrival of a byte from the UART, and then send it back as a sort of “echo”. The following “test.c” file shows how to do it:

#include <stdint.h>

#define UART0_BASE_ADDR 0x101f1000
#define UART0_DR (*((volatile uint32_t *)(UART0_BASE_ADDR + 0x000)))
#define UART0_IMSC (*((volatile uint32_t *)(UART0_BASE_ADDR + 0x038)))

#define VIC_BASE_ADDR 0x10140000
#define VIC_INTENABLE (*((volatile uint32_t *)(VIC_BASE_ADDR + 0x010)))

void __attribute__((interrupt)) irq_handler() {
 /* echo the received character + 1 */
 UART0_DR = UART0_DR + 1;
}

/* all other handlers are infinite loops */
void __attribute__((interrupt)) undef_handler(void) { for(;;); }
void __attribute__((interrupt)) swi_handler(void) { for(;;); }
void __attribute__((interrupt)) prefetch_abort_handler(void) { for(;;); }
void __attribute__((interrupt)) data_abort_handler(void) { for(;;); }
void __attribute__((interrupt)) fiq_handler(void) { for(;;); }

void copy_vectors(void) {
 extern uint32_t vectors_start;
 extern uint32_t vectors_end;
 uint32_t *vectors_src = &vectors_start;
 uint32_t *vectors_dst = (uint32_t *)0;

while(vectors_src < &vectors_end)
 *vectors_dst++ = *vectors_src++;
}

void main(void) {
 /* enable UART0 IRQ */
 VIC_INTENABLE = 1<<12;
 /* enable RXIM interrupt */
 UART0_IMSC = 1<<4;
 for(;;);
}

The main code enables the interrupt and then waits forever. When a character is received from the UART, the IRQ is fired and the irq_handler function is called, transmitting back the modified character.

In order to create the complete binary code, we need a linker script that is aware of the memory map of the system. In our case QEMU loads the code to address 0x10000. The following is the linker script “test.ld” that is used to link the complete program:

ENTRY(vectors_start)
SECTIONS
{
 . = 0x10000;
 .text : {
 vectors.o
 *(.text .rodata)
 }
 .data : { *(.data) }
 .bss : { *(.bss) }
 . = . + 0x1000; /* 4kB of stack memory */
 stack_top = .;
 . = . + 0x1000; /* 4kB of irq stack memory */
 irq_stack_top = .;
}

To compile the program I used CodeSourcery bare metal toolchain, but the commands can be adapted to work with other GCC toolchains such as the Emdebian ones. The commands are the following:

arm-none-eabi-gcc -mcpu=arm926ej-s -c -o test.o test.c
arm-none-eabi-gcc -mcpu=arm926ej-s -c -o vectors.o vectors.S
arm-none-eabi-gcc -T test.ld test.o vectors.o -o test
arm-none-eabi-objcopy -O binary test test.bin

This creates a “test.bin” binary file that contains our code. To simulate the program, the command to launch QEMU is the following:

qemu-system-arm -M versatilepb -serial stdio -kernel test.bin

The “-serial stdio” option will redirect the terminal input/output to the emulated UART that we want to test. If you type some letters in the terminal where you launched the command, you will see them echoed back to you, modified by the interrupt handler.

Possible next steps from here are:

• Managing different sources of interrupt from the same peripheral
• Managing IRQs from different peripherals
• Dynamically remapping the exception handlers
• Fully using the features of the Vectored Interrupt Controller
• Enabling nested interrupts

Here is a guide that contains much information about it: Building bare metal ARM with GNU [html]

Unfortunately most of the videos have really bad audio quality, so maybe this time reading the slides will be more effective.

The most interesting topics for me are the following:

• The Kernel report
• Binary Blobs Attack!!!
• Status of embedded Linux
• Experiences With Device Tree Support Development For ARM-Based SOC’s
• The Internet of things
• Board Bringup: LCD and Display Interfaces
• Userland Tools and Techniques For Linux Board Bring-Up and Systems Integration
• Getting the First Open Source GSM Stack in Linux

Every year the market produces tons of new products that run on ARM cores, and are able to run operating systems such as Linux. While most of these products are quite expensive (think about smartphones, development kits or evaluation boards) it’s possible to explore the world of Linux on ARM freely, thanks to software emulators like QEMU.

I am going to show how to compile the kernel and emulate the boot. To simplify things, the boot will not include a complete filesystem but uses a minimal ramdisk to show the kernel executing just one program.

I chose to emulate the Versatile Express product because it’s well supported both by the mainline Linux kernel and by mainline QEMU. Moreover, this hardware platform runs on the Cortex-A9 core, which is an ARM CPU that is included in many smartphones today.

Requirements

In order to follow the same steps that I did, you need some tools.

First of all, anything I do is performed on a Linux machine, specifically a Debian testing distribution, in a bash shell.

To manage the kernel compilation, GNU make should be installed (it is usually in build-essential package)

To compile the kernel for ARM architecture, a cross-compiler must be installed. The difference between a traditional compiler and a cross-compiler is that the traditional compiler runs on an architecture (for example x86_64) and produces binaries for the same architecture. A cross-compiler produces binaries for a different architecture (in our case ARMv7). Depending on your distribution and what works for your setup, you can choose from different toolchains:

• Emdebian; here some instructions on how to install,
• Linaro; if you run a newish version of Ubuntu you can install it directly with “sudo apt-get install gcc-arm-linux-gnueabi“,
• Fedora ARM cross-toolchain,
• Sourcery Codebench (was CodeSourcery); available for free only under registration,
• other toolchain suggestions by eLinux.

Cross-compilers offer a set of programs, mainly GCC and binutils, that start with a prefix indicating the architecture, the operating system of the libraries and the binary interface of the compiled programs. In my case I use Emdebian toochain, which has the “arm-linux-gnueabi-” prefix.

Finally the emulator that I use is QEMU, in particular the program to emulate ARM hardware is “qemu-system-arm“. You must install the correct package depending on your distribution; sometimes distributions split the QEMU programs into different packages, for example Ubuntu packs it into the “qemu-extras” package.

The short story

Create a clean directory, then create a file called “init.c“, which contains the following simple C code:

#include <stdio.h>

void main() {
  printf("Hello World!\n");
  while(1);
}

Then in the same directory execute the following commands in order:

wget http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.2.tar.bz2
tar xjf linux-3.2.tar.bz2
export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabi-
cd linux-3.2
make vexpress_defconfig
make all
cd ..
arm-linux-gnueabi-gcc -static init.c -o init
echo init|cpio -o --format=newc > initramfs
qemu-system-arm -M vexpress-a9 -kernel linux-3.2/arch/arm/boot/zImage -initrd initramfs -serial stdio -append "console=tty1"

The kernel compilation (the “make all” command) could take some minutes or hours depending on your host machine power.

The last command opens a QEMU window, that shows a black background and many boot messages, and towards the end the “Hello World!” string is displayed.

The long story

The steps are:

1. Get Linux kernel source code
2. Prepare for compilation
3. Configure and compile
4. Prepare and create ramdisk
5. Emulate kernel boot and ramdisk execution

Get Linux kernel source code

The official site for mainline Linux kernel is at www.kernel.org. The kernel version that I will use is the 3.2, be aware that if you want to use a different version you may have different results, even though most of the functionality used here is simple enough that it should not change between versions.

Download linux-3.2.tar.bz2 from the FTP site, or simply run from the command line:

wget http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.2.tar.bz2

Then extract the kernel source. One way to do it is by running in the same directory:

tar xjf linux-3.2.tar.bz2

This will create a new subdirectory called linux-3.2 containing the full source of the Linux kernel.

Prepare for compilation

We are going to compile for ARM architecture by using a cross-toolchain, so we need to tell it somehow to the Linux build system. There are two environmental variable for this: ARCH and CROSS_COMPILE. The valid values for ARCH are basically the subdirectories of the “arch” directory. For CROSS_COMPILE we need to provide the prefix of the toolchain, which is the name of the compiler program minus the gcc at the end. For example if we are using arm-linux-gnueabi-gcc, we need to set CROSS_COMPILE to arm-linux-gnueabi-. On the terminal, run:

export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabi-

make vexpress_defconfig

make all

make -j 2 all

#include <stdio.h>

void main() {
  printf("Hello World!\n");
  while(1);
}

arm-linux-gnueabi-gcc -static init.c -o init

$ file init
init: ELF 32-bit LSB executable, ARM, version 1 (SYSV), statically linked, for GNU/Linux 2.6.18, BuildID[sha1]=0xf78b4955773f3c5dfecdb11c62dae094a99ba8f9, not stripped

echo init|cpio -o --format=newc > initramfs

$ cpio -t < initramfs
init
1090 blocks

qemu-system-arm -M vexpress-a9 -kernel linux-3.2/arch/arm/boot/zImage -initrd initramfs -append "console=tty1"

qemu-system-arm -M vexpress-a9 -kernel linux-3.2/arch/arm/boot/zImage -initrd initramfs -serial stdio -append "console=ttyAMA0"

The most interesting videos for me are the following:

• ARM BoF: state of the ARM architecture porting of various Linux distros (54:40 video)
• Debian secrets: useful information to get started on using or developing Debian (41:24 video)
• Multiarch: why it is important (39:52 video)
• Coreboot: an open source alternative to BIOS in our PCs (36:52 video)
• Minemu: an emulator to catch security bugs while the program is running (16:12 video)
• Openremote: home automation project (15:42 video)
• Unhosted: a new paradigm for the web where web apps and data are separated to be more secure and free (15:13 video)
• Virtualization with KVM: an explanation on the current state of virtualization and a roadmap for the future (44:46 video)

In this example I am creating a binary blob of 16 bytes of random data in file “blob.bin“:

$ dd if=/dev/urandom of=blob.bin bs=1 count=16
16+0 records in
16+0 records out
16 bytes (16 B) copied, 8.7424e-05 s, 183 kB/s
$ hexdump -C blob.bin
00000000  2a 3b cb 0f 43 66 56 77  fd cc 5a e9 b9 73 a7 b2  |*;..CfVw..Z..s..|
00000010

Then I need to use objcopy to transform it; the command is of the form:

$ objcopy -I binary -O <target_format> -B <target_architecture> <binary_file> <object_file>

If you are not sure about the target architecture and target format, they can be found with something like:

$ > arch.c
$ gcc -c arch.c -o arch.o
$ objdump -f arch.o

arch.o:     file format elf32-i386
architecture: i386, flags 0x00000010:
HAS_SYMS
start address 0x00000000

$ rm -f arch.c arch.o

So, in my case the command is:

$ objcopy -I binary -O elf32-i386 -B i386 blob.bin blob.o

This command created a “blob.o” file that contains the symbols to access the data within:

$ objdump -t blob.o

blob.o:     file format elf32-i386

SYMBOL TABLE:
00000000 l    d  .data    00000000 .data
00000000 g       .data    00000000 _binary_blob_bin_start
00000010 g       .data    00000000 _binary_blob_bin_end
00000010 g       *ABS*    00000000 _binary_blob_bin_size

These symbols can be accessed by C code (and assembly too). Here’s a simple program that uses them:

#include <stdio.h>

extern unsigned char _binary_blob_bin_start;
extern unsigned char _binary_blob_bin_end;
extern unsigned char _binary_blob_bin_size;

int main()
{
  unsigned char *pblob = &_binary_blob_bin_start;
  while(pblob < &_binary_blob_bin_end)
  {
    printf("%d: %02X\n", pblob - &_binary_blob_bin_start, *pblob);
    pblob++;
  }
  printf("size: %d\n", &_binary_blob_bin_size);

  return 0;
}

Now we can compile the program and run it to see that the binary data can be accessed correctly.

$ gcc    -c -o test_blob.o test_blob.c
$ gcc   test_blob.o blob.o   -o test_blob
$ ./test_blob
0: 2A
1: 3B
2: CB
3: 0F
4: 43
5: 66
6: 56
7: 77
8: FD
9: CC
10: 5A
11: E9
12: B9
13: 73
14: A7
15: B2
size: 16

It is also possible to rename the symbols that are created by objcopy using the “--redefine-sym” option, and also put the data in a section with a different name and different flags, using “--rename-section“.

I’ve also seen a method that involves translating the blob into a C source file containing an array of data. The C file can then be compiled and linked into the program. I think both methods have their advantages, for example the objcopy method has fewer steps and needs less space on the disk, whereas the “C array” method can be useful if you want to commit the array into a versioning control system that works better with text file than with binary files.

Everything in this page can be achieved also with cross-compilers, by adding the prefix of the toolchain (for example “arm-linux-gnueabi-” or “avr-“) to the gcc, objcopy and objdump commands.

JTAGWhisperer is a solution to program FPGAs and CPLDs using Arduino and a small client-side Python script. It reads files in the XSVF format, which stands for Xilinx Serial Vector Format and is one of the formats used to program Xilinx chips.

There are potentially cheaper solutions, but this projects allows hobbyist hardware developers who already have an Arduino to easily use it also as a XSVF programmer.

He is convinced that today there’s plenty of enabling factors to make Open Source Hardware a big thing, just like Linux did at the time thanks to the enabling factors of the Internet, cheap PCs and efficient compilers.

In my opinion there are still at least two factors that make the Open Source Hardware movement slower than Open Source Software, especially in the field of electronics:

• The number of electronic experts in the world is so much lower than the number of software experts.
• The cost to copy software and have a new “finite product” is almost zero, the cost to copy a “thing” is linked to the cost of manufacturing and is still quite high.

I hope that the second problem will soon be overcome thanks to the constant progress of the technology of electronic board manufacturing and the lowered cost of programmable logic chips. The first problem instead will simply be something to be acknowledged, that affects the variety of the ecosystem, the speed of progress and the number of bugs that can be solved by public review.

2012 Embedded Linux Conference | Schedule | Linux Foundation Events.