I just wasted 30 minutes of my time trying to figure out a strange bug in a Perl script generating Atmel AVR assembly code —for a hardware hacking project I will blog about soon. A function was computing an odd parity bit, and it was generating a correct bit only in some cases...
As it turns out, this was due to unintentional backslashes at the end of lines in a numeric expression (the code was copied from a C macro). Judge by yourself:
$ cat broken.pl
printf "A = %d\n", (1 ^ \
printf "B = %d\n", (1 ^
A = 135611809
B = 0
I am puzzled as to how Perl is interpreting my code. Why is the backslash causing it to return a non-zero value for "A"? And why, with warnings and strict mode enabled, does Perl think a human writing this code knows exactly what he is doing and would expect this kind of result without throwing a warning.
It is 4am and I cannot think straight. I will revisit this later.
[Update 2010-07-27 11:38pm: the newline between the backslash and the digit 1
was making it less obvious, but a night of sleep made it more so: Perl was treating
this as a reference to 1, and was XORing the value of the reference
—effectively a memory address— instead of the value 1.]
message to the A51 mailing list,
Frank A. Stevenson announced the release of an A5/1 cracker called
the Kraken, capable of using the Berlin set of rainbow tables to
decrypt GSM traffic.
A5/1 has been cracked many times already,
but tools to do so have never been released to the public.
Most recently, in February 2008, David "h1kari" Hulton and Steve Muller
presented at Black Hat their A5/1 rainbow tables built with FPGAs. They
were planning to release them publicly, but never did so for unknown
reasons. I have met David in person and asked him but his response
was evasive. Perhaps they preferred to simply recolt the fruits of their
work by selling commercial A5/1 cracking products.
Because of the lack of public A5/1 cracking tools, the GSM Association
was claiming until very recently that it is not practical to attack A5/1
and that A5/1 is "still" secure enough.
It is in this context that the A5/1
Security Project was started by Karsten Nohl. They wrote code to compute
A5/1 rainbow tables, went through multiple iterations. The last version of
the code is very well optimized to run on ATI GPU cards. They built with
it what is known as the Berlin A5/1 rainbow table set (see
post about the story behind the name), which is about 2TB in size.
The Kraken is the first tool able to perform successful lookups in the
From now on, we can expect the project to focus more on intercepting GSM
frames off the air. People have been intercepting individual frames for
a while with devices like the
USRP, but some hurdles remain to be solved, such as channel hopping.
Nvidia's latest "Intel's Insides" comic made me laugh out loud:
This is a parody of the Nebulae supercomputer
in which 80.1% of the raw FLOPS computing power is provided by
the Nvidia Tesla C2050 GPUs, and the remaining 19.9% by the Intel
Xeon X5650 CPUs.
(This comic could be found at
except that the domain is now owned by squatters. Nvidia apparently let the
domain registration expire on July 10!)
There was an interesting talk at
last week with Tom Cook from Facebook. I particularly enjoyed learning
about how their engineering and operations teams work with each other.
I am a firm believer that excellent inter-team cooperation, and minimizing
the need for communication (or making it really good), are crucial factors
in making a company efficient and successful.
- A global changelog is maintained by engineers and IT when any change is made
on the infrastructure (anyone can look into it, information not segregated
into exclusive mailing lists)
- Internal news portal to announce features, or critical outages
- IRC used heavily (again, anyone can read)
- Nagios and Ganglia are used for monitoring (had to extend Nagios)
- All of the Nagios alerts are fed into other tools to aggregate them
(emails cause too much noise)
- Configuration management implemented with CFengine and sync every 15min
("Puppet is a fantastic option", "Chef is newer and looks great")
- Configuration management should be implemented regardless of how many
servers you run
- Very short dev cycles: code is pushed daily (mostly bugfixes), new features
pushed every week
- Version control everything
- Testing performed by engineers, not by separate QA teams
- Ops people are integrated with engineering teams, and engineering heavily
involved into deploying code to prod
- Advantages: ops people know the applications well and can help
troubleshoot problems, and engineering helps making the deployment successful
(no "commit and quit").
- Instrument everything: hardware, software, OS, etc
Here is the
of the talk.
In a technical paper published on June 23, 2010, at the International Symposium
on Computer Architecture (ISCA) in Saint-Malo, France,
Debunking the 100X GPU vs. CPU myth,
Intel —who lacks a high-performing GPU due to their Larrabee GPU project
having been delayed multiple times— attempts to debunk the claim that
"GPUs deliver substantial speedups (between 10x and 1000x) over multi-core
Intel's research paper is seriously flawed.
Traditional virtualization infrastructures with a need of some type of
shared storage are expensive to deploy and hard to scale up.
Imagine an infrastructure built on a cluster of hosts
running guest systems where each host contributes a fraction of its
inexpensive local storage space to establish a distributed storage system used
across the entire cluster. This storage layer provides advanced features
such as snapshotting, cloning, thin provisioning. Guest disk images are
stored on this system and are therefore accessible
to any host part of the cluster. Imagine also that this infrastructure
has built-in fault tolerance and automatically replicates data to handle
hosts added to or removed from the cluster (as it can happen in case of
hardware failure). Such a system would provide:
- Good performance scalibility at all levels: CPU, RAM, and storage
all scale linearly because a host contributes each of these resources to the cluster.
Whereas traditional virtualization infrastructures are hard to scale up due to
the inherent throughput and latency bottlenecks of a centralized SAN/NAS.
- Excellent reliability due to the fault tolerance and
lack of a single point of failure such as a SAN/NAS.
- Convenient ability to live migrate any guest from any
host to any other host without the need of centralized storage.
- Ability to replace/upgrade 100% of the parts of a cluster,
over time, with zero downtime.
A project to accomplish all the above exists! MORITA Kazutaka,
FUJITA Tomonori, and MORIAI Satoshi, all working for NTT Cyber Space
Laboratories —I am trying to imagine what NTT might be doing—,
started the Sheepdog project for
QEMU/KVM. Their backgrounds reveal these guys are kernel developers,
Xen hackers, and storage experts. They have worked on the kernel block
layer, Xen Kemari (Virtual Machine Synchronization for Fault Tolerance),
the SCSI layer, and much more.
I am very excited to hear about this project. A Sheepdog block driver
for QEMU/KVM has already gone through multiple iterations of reviews.
The latest patch posted to the qemu-dev@ mailing list was
June 6, 2010. Hopefully it will soon make it to an official release.
This whole project is very innovative. As far as I know, no other
virtualization vendor offers anything remotely similar to Sheepdog.