MC's Journal

Teleservice offers IPv6 over 6rd

The local ISP I use in my holiday home, Teleservice Skåne, doesn't offer native IPv6 to us lowly ADSL customers. However, they do operate a 6rd gateway! This configuration in my OpenWRT's /etc/config/network made all the difference:

config interface wan6
        option proto '6rd'
        option peeraddr ''
        option ip6prefix '2a02:83::'
        option ip6prefixlen 32

Ta-da! Thanks, Philip @ Teleservice!

Ask your local ISP if they can do the same!

Going native on a Chromebook

I've spent the last few days on my vaction experimenting with native GNU/Linux on my Toshiba Chromebook 2. I wrote about it in Native GNU/Linux on a Toshiba Chromebook 2. I'll try to keep the document updated.

Main points:

  • It's surprisingly easy to get a native distribution running.
  • Linux and friends have changed somewhat since I last used them on a machine close to me: new stuff like systemd, pulseaudio, et cetera.
  • X11 is still a security nightmare, but by running two sets of X servers you might be able to ward off the worst. Also, Wayland is coming along.
  • I've missed mcwm but find dwm utterly charming on this small screen.
  • I've missed my own keymap.

Running CP/M: Microbee, Compis, and Yaze-AG

A couple of days ago I talked with a friend about computers in our primary schools. At her school they had a set of Microbee computers, a family of Australian Z80-based micros running CP/M. I don't know exactly what model they had, but after asking around among other friends some sort of Microbees seems to have been rather common in Swedish school in the mid-80s.

I remember seeing ads for Microbees in the 1980s and much later had an opportunity to play with a 32IC for a while. Quite nice little machines.

From 1985/86 my school had Compis computers, which I think was slightly more common, Compis being The Official Swedish School Computer. Compis was a 80186-based CP/M-86 machine with really nice, low keyboard and fairly high resolution monitors.

The system at my school were 640x400 monochrome (green) and a single colour-based machine with much slower graphics that everyone avoided. Allegedly there was also a version with 1280x800 monochrome (b/w), but I never saw anything like that.

The machines had floppy drives but were also connected to a shared 10 MiB hard disk. The hard-drive was only available in read-only form, except for one drive letter which only could have one user at a time. I remember a program called boxloss which unmounted this virtual drive from anyone who happened to be using it and mounting it for you. The password was “Fredrika”. I don't remember how you were supposed to mount it without stealing it like this. Anyone?

There was some kind of menu system, but if you really wanted to you could get at the CP/M prompt. This prompt, unfortunately, was the standard CCP, not any of the fancy ZCPR stuff that people running CP/M on Z80s were used to by then.

One thing that struck me during our conversation, and from many other conversations about computers in Swedish primary schools in the 1980s, was that the computers were very seldom used for anything! For instance, we were not allowed to use the computers to write texts! There were no word processor or text editor available, at least to my knowledge, and we were certainly not allowed to use the computers outside of specific “computer classes”.

This is particularly interesting if you look at the Microbee, since as far as I can tell all models had a built-in text editor!

We weren't allowed to use any advanced development tools either. On the Compis we had to write programs in COMAL, a language looking a lot like BASIC, but with proper procedures and functions. Really frustrating when I had the wonderful Turbo Pascal at home and I knew that Turbo Pascal was available on CP/M and for the Compis as well.

After our conversation I decided to look back at some development environments on CP/M and see if I could have lived with the environments back then...

I looked around for a Microbee emulator and found an emulator in Javascript, NanoWasp. Code on GitHub.

NanoWasp is unfortunately limited to a tape-drive system. It would be fun to work with something with floppy disk support. Anyone?

I didn't find any Compis emulators, but thought I'd look around for some more generic emulator to run CP/M on.

A popular emulator for CP/M seems to be the YAZE-AG Z80 emulator.

YAZE-AG comes pre-loaded with CP/M 3.1 and a lot of development tools. I was totally blown away by Turbo Modula-2! Look at drive M:.

Wikipedia tells me TM-2 was never marked by Borland but later became TopSpeed Modula-2 for MS-DOS. I had never used it before but it's really incredible. The environment is reminiscent of Turbo Pascal 3.0 with a small menu system and an WordStar-like editor, but the language is much richer.

According to this blurb the cost of TM-2 was $69.95. Tremendous value, indeed!

I would have been very happy indeed if this had been available at my school. I don't think TM-2 was available for CP/M-86, though, although it seems Logitech's Modula-2 compiler was. I think I would have been quite happy with just TP 3.0 as well, which was what I was programming in at home, but more important than this would have been access to the computers!

IPv6 Only FreeBSD

I'm setting up a couple of FreeBSD jails in an IPv6-only world. I was a bit surprised to note that although has a AAAA in DNS it's impossible to reach the DNS server that gives the AAAA answer over IPv6!

Only if I use a resolver that are both on IPv6 and legacy IP will I be able to install packages.

What can I do to help?

32th Chaos Communication Congress, part 4


More notes from my visit to 32C3. Part 1. Part 2. Part 3.

PQCHacks: A gentle introduction to post-quantum cryptography

Fahrplan link.

Daniel “djb” Bernstein & Tanja Lange.

Tanja and djb first had some soothing words: The D-wave quantum computer isn't universal:

  • can't store stable qubits.
  • can't perform basic qubit operations.
  • can't do shor's algoritm.

...but universal quantum computers are coming and are very scary. They break all public-key crypto! AES-256 still hard, though.

Post-quantum crypto: the adversary has a quantum computer but we have ordinary computers.

PQcrypto conference 2006–2017.

There might be an entity (Ahem... NSA) that records all your communication. In 10 or 15 years you might be a Person of Interest. Then they break your RSA with their new quantum computer and read all your old correspondence.

Initial recommendations of long-term secure post-quantum systems

  • symmetric - at least AES-256, Salsa20 with 256 bits.
  • symmetric authentication, GSM, Poly1305.
  • Public-key encryption, McEliece with binary goppa codes.
  • Public-key signatures, hash-based signatures.

Signature hashes

Lamport suggested one-time signatures in 79, Merkle extends to more signatures.

  • a signature scheme for empty messages: key generation.
  • a message that signs a panic button. a panic message.

For instance, use SHA3-256...

Can only send a single message. The message reveals the private key. And its hash is the public key.

A signature scheme for 1 bit messages: two private keys.

For 4 bits: 4 key pairs! Concatenate the public keys to create a new public key for the message.

Don't use the same secret key to sign two messages. Obviously, since we're revealing the private key when sending.

Lamports 1-time signature messages.

Merkle's 8-time signature system. Make 8 Lamport keys! And concate them and hash them. One hash is a public key, but many private keys.


  • post-quantum secure!
  • need secure hash function, nothing else. for instance SHA-3.
  • small public key.
  • security well understood
  • fast
  • proposed as an IETF standard.


  • big signature
  • stateful. You need to remember what private keys have been used. Imagine what happens if we restore from backup.

Solution to statefulness: eliminate the state! Build a big tree of certificate authorities:

  • signature inclues cert chain
  • each ca is a hash of master secret and tree position. deterministic so don't need to store results
    • random bottom-level ca signs message. many bottom-level cas, so one-time signature is safe.

Signature sizes:

  • 0.6 MiB for a signature: Goldreich signature with good 1 time signature scheme.
  • 0.041 MiB, 41 K! SPHINCS signature.

Code-based encryption

Based on coding theory. Examples of coding theory are parity checks, the ISBN control number or Hamming code.

  • -71 Goppa: Fast decoders for many matrices H.
  • -78 McEliece Use Goppa codes for public-key cryptography.
  • -86 Niederreiter: Simplified and smaller version of McEliece. public key: H with 1s on the diagonal secret key: fast goppa decoder encryption: randomly generate e with t bits set, send H # e.

Many more post-quantum suggestions

  • qc-mdpc: smaller keys but is it secure?
  • lattice based systems. some broken, some not.
  • multivariate-quadratic systems. some broken, some not. highlight: very small signatures.
  • isogeny-based crypto, ECC-like, supports DH.


Coming 2017 summer school and workshops.

@pqc_eu on Twitter.

Verified Firewall Ruleset Verification: Math, Functional Programming, Theorem Proving, and an Introduction to Isabelle/HOL

Fahrplan link.

Cornelius Diekmann.

Cornelius told us about mathematical machine proofs for firewall rules. He cited previous works and said “tools do not understand real-world firewall rules”.

Needs to specify "what is a firewall?" a model of the semantics of Linux iptables.

Using a theorem prover, Isabelle.

Builds a model of the firewall, the filtering behavior. Only 11 filter behaviours defined in the complete semantics.

This is a mathematical specification - not an implementation. It describes what a firewall does. The specification for CallReturn, for instance, didn't use a call stack but had a description of calls to new iptables call chains.

Why do this?

You can use it to prove “semantics-preserving simplification”, for instance prove that the firewall filtering behaviour stays the same after optimization or after having removed logging.

Executable code

Specifications is done in Isabell, then exported to executable code. A selection of a languages: Haskell, for instance.


32th Chaos Communication Congress, part 3


More notes from my visit to 32C3. Part 1. Part 2.

Shopshifting: The potential for payment system abuse

Karsten Nohl, Fabian Bräunlein, and dexter.

Fahrplan link. Recording.

This talk was at the same time as the New memory corruption attacks so I saw the recording.

  • Cashier station to payment terminal: ZVT or OPI protocol.
  • Payment terminal to payment processor over Internet: Poseidon protocol/ISO 8583. Many countries have their own dialect of ISO 8583.

Payment terminal: reads the card's mag stripe or PIN/chip.

ZVT in the shop over a network connection. Very old installations use a serial port and the protocol is designed for this, which shows.

Attack 1: Against the customer

ARP spoofing to get a man in the middle on the local network. Inside the shop or, if using wifi, even outside.

We send only a command “read the card”, then we have the mag stripe! Then we go ahead with the transaction.

But how do we get the PIN?

ZVT payment terminals are supposed to work with an HSM: the PIN shouldn't be seen outside.

ZVT has a function: “Display a text, then enter a number” but this function must be signed. Can we sign it ourselves?

To find a valid MAC... The HSM leaks the correct MAC through a timing side channel! They found an active JTAG on the main CPU and could talk to the HSM. Brute force of the first byte and count the response time. It's compared byte by byte in the HSM! Returns immediately if it doesn't match!

Attack 2: Against the merchant

ZVT allows local terminal hijacking.

ARP spoofing to become MITM like before.

Reset the terminal ID to your own terminal ID. The attacker needs to be a merchant as well and have a terminal ID.

There is no authentication between cashier and pay terminal.

Attack 3: Attack on Poseidon

Poseidon is a dialect of global payment standard ISO 8583. De facto standard in Germany.

Authentication uses pre-shared keys. However the key is the same for many, many terminals! This leaves just a user name: the terminal id. Which is public information and printed on receipts!

For the attack to succeed:

  • Buy a payment terminal.
  • Service management password. Just google for it! Or brute-force over ZVT, or read it out with JTAG...
  • Your victim's Terminal ID. It's on the receipt! Or just guess. They are assigned incrementally, so if you know one good Terminal ID you know many others.
  • Port number on the backend which your victim uses. Hundred different alternatives? Try them all!

Now you can, for example, print pre-paid call codes for your phone.

Another possibility is to “refund”, initiate a money transfer with a negative value! From any bank account! Completely independent from any earlier transactions.

Attack 4: Hardware

Buy a payment terminal on Ebay. It uses an internal HSM to protect secrets.

The HSM is a battery-backed SRAM under plastic cover. When a metal mesh in this plastic cover is breached the secrets are erased.

But the mesh is only connected in the corners. Can we get something under it? Yes! Inject a hypodermic needle and ground it. Ta-da! Then simply remove the lid.

There was an active JTAG port!

What can be done?

Short term:

  • Individual keys! Different keys for all payment terminals. The good news is that the Poseidon protocol can be used to distribute new keys.
  • Switch off functionality that you don't need.
  • Refund is activated by default. Turn off!
  • Detect suspicious behaviour.

Long term:

  • Create better protocols.


The main ZVT alternative is OPI, Open Payment Initiative. OPI still lacks authentication and encryption even though it's from 2003!

Poseidon's family: ISO 8583. Dialects used everywhere. The bad system-wide symmetric keys are not mandatory in the protocol and key distribution through Poseidon possible.

New memory corruption attacks

Mathias Payer & Nicholas Carlini.

HexHive Group,

Fahrplan link.


Status of deployed defenses

  • Data Execution Prevention, DEP. R-X on text segment. No new code can be injected, an attacker will have to use ROP or similar.
  • ASLR - Address space layout randomization, harder to use ROP especially on 64 bit architectures, since gadget addresses are not known.
  • Stack canaries. Place strategic values on the stack that shouldn't be overwritten.
  • Safe exception handlers.

ASLR and DEP only effective in combination.

Two proposals

  • Stack integrity
  • Control-flow integrity

Stack integrity

  • Enforce dynamic restriction on return instructions.
  • One example: protect return instructions through a shadow stack. Enforce on hardware label that we only can return to the calling function!

Control-flow integrity, CFI

  • Never leave the control-flow graph.
  • Find set of allowed targets for each location in compile time.
  • Online set check: check if we're allowed this target.

New attacks: control-flow bending

Bend a valid graph... Not calling new code, but allowed targets.

Circumvent control-flow integrety.

CFI'S limitation: statelessness.

Each state is verified without context. Unaware of constraints between states.

Weak CFI is already broken. Lots of papers about it.

Microsoft's control-flow guard is an instance of a weak CFI.

Strong CFI?

  • Precise control-flow graph: no over-approximation.
  • Stack integrity through a shadow stack.
  • Fully-precise static CFI: a transfer is only allowed if some benign execution uses it.

How secure is CFI? With and without stack integrity?

Analysis found a few functions, like memcpy() and malloc() that everyone uses. If everyone use them you can return to a lot of functions and build ROP chains easily.

Result: CFI without stack integrity is broken.

When we add stack integrity to the mix we can greatly increase the protection of the current systems, then:

  • ROP no longer an option
  • attacks becomes harder

However: an interpreter will still be vulnerable!

And there's lots of interpreters out there! An example is printf()! printf() format strings include: memory reads %s, memory writes %n, conditionals, %.#d, therefore: a Turing complete Brainfuck interpreter. In printf formats!

32th Chaos Communication Congress, part 2


More notes from my visit to 32C3. Part 1.

Unpatchable: Living with a vulnerable implanted device

Fahrplan link. Recording.

Marie Moe & Eireann Leverett.

Marie lives with a pacemaker: “A project to break my own heart.”

A rather low-key presentation with no alarming remote cracking of pacemakers, but interesting insights into medical implants. For instance, Marie's own pacemaker has two wireless interfaces: one near-field and another for remote monitoring/telemetry when used with an optional a base station in her home.

They bought a programmer for the pacemaker and some base stations on Ebay and did experiments. They could extend the programmable range to several metres!

Some issues:

  • Patient privacy issues.
  • Battery exhaustion.
  • Device malfunction - software bugs.
  • Death threats and extortion.
  • (Remote murder). More unlikely than the others, but this is what would get the press.

Some research needed:

  • Open source medical devices!
  • Medical device crypto. Any backdoors in crypto will end up here!
  • Personal area network monitoring

“We need to be able to verify the software that control our lives.”

“You to can do this research! Lots of low hanging fruit.”

There is na excemption to the Digital Millennium Copyright Act (DMCA) for research on medical devices and automotive devices. Reverse engineering possible without infringing copyright law.

The programmers are unique for the device. Some standardization, perhaps?

Much smaller pacemakers coming. Inside the heart!

“Are there laws requiring the doctor to tell them they are upgrading the software?”

No third party tests? No consumer laboratory?

How the Great Firewall discovers hidden circumvention servers

Fahrplan link.

Philipp Winter,

An analysis of how China's Great Firewall blocks traffic and knows what to block.

“We know what is blocked, how it is blocked, where it is topologically.”

“Most measurements are one-off, continuous measurements challaneging.”

Even if you use DNS resolver outside of China, a DPI looks at your traffic and spoofs the results. If you wait for a while... you get the real DNS reply as well! Not filtered!

  • Many keywords are blocked: DPI looks at your GET request, sends RST to your browser before the TCP connection is fully established. HTTPS helps, but see above about DNS.
  • Encrypted tunnels help - but DPI looks at port numbers, type of encryption, handshake parameters, flow info.
  • Active probing: Checks the cipher list in the TLS client hello from client in China to server in Germany. Vanilla Tor (not using any obfuscation) looks special. Is it Tor? The GFW starts a short-lived probe and tries to speak the Tor protocol to the server. If it is, it blocks client to access this server.

Several data sets collected to see where the probes come from.

  • Shadow data set: they did a test with clients in cernet, unicom in china and Tor bridges using vanilla tor, obfs 3, and obfs 4.
  • The Sybil data set, clients in china with 600 ports on a tor server.
  • Log dataset: web server with logs dating back to 2010.

Collected 16 000 unique probe ip addresses! 95% addresses seen only once!

Reverse DNS with “adsl” in them... Looks like ISP addresses. The single IP address was almost 50% of the probes!?

Majority of probes comes from three ASes: 4837, 4134, 17622.

Do they hijack these addresses for GFW use? While the probe is active no communication with them possible: traceroute times out, no ping...

What do they have in common?

  • Narrow ttl distribution.
  • Uses source ports in the entire 16 bit port range!
  • Exhibit patterns in TCP TSval.
  • Does not seem like off-the-shelf TCP/IP stack. A user space stack?
  • Strange tcp's initial sequence numbers... not really random... zig zag pattern. Perfectly correlated with time. State leakage!
  • Probes all share an auncommon TLS client hello.
  • No random-generated SNI.
  • A unique cipher list.

Physical infrastructure

  • State leakage shows that probes are centrally controlled.
  • Not clear how they control probes.
  • A proxy network?
  • Off-path device in ISP'S data centre? Machines connected to switch ports?

Blocking is reliable but fails predictable

In 2012 probes were batched, perhaps started by cron.

Now real time. Median arrival time only 500 ms.

Blocked protocols

  • SSH blocked in 2011 but no longer.
  • VPN, Openvpn sometimes? Softether.
  • Tor, vanilla, obfs2 & obfs 3.
  • Appspot - possibly because they're looking for GoAgent proxies.
  • TLS.

The probes doesn't seem to be using reference software. Handcrafted!? The probes look very different from ordinary software and can be easily identified.

Find your own probes


DPI must re-assemble the stream before pattern matching. Make the protocol harder ro reassemble. Server-side manipulation of TCP window size can hide the protocol signature. Used in brdgrd.

TCP/ip based circumvention difficult to deploy: “use this unknown kernel module, will you?”

Tor project pluggable transport to the rescue! Pluggable transports that work in China

  • scramblesuit - clients share a shared secret.
  • obfs4 - extends scramblesuit.
  • meek - tunnels traffic over cdns! amazon, azure, google
  • fte - shapes ciphertext based on regular expressions
  • more.... perhaps something webrtc-based?

CloudABI: Pure capability-based security for UNIX

Fahrplan link.

Ed Schouten,

A new Unix runtime with capabilities.

What's wrong with unix?

Unix doesn't stimulate you to run software securely. A web service only needs a specific set of capabilites but can do everything.

Access controls like apparmor not a real solution. Puts the burden on the package maintainers.

Untrusted third-party programs are also extremely unsafe. Can the OS provide better isolation?


Capabilities: Example, Capsicum. Programs starts as an ordinary process, opens all files it needs, then calls cap_enter(), process can still use file descriptors, read(), write() but can't use open() et cetera. Returns ENOTCAPABLE.

Used in FreeBSD by some programs: dhclient, hastd, ping, sshd, tcpdump, et cetera.

However, problems: code isn't designed to have system calls disabled!

  • C library: locales unusable, incorrect timezone, et c
  • crypto library: non-random PRNG!
  • capsicum doesn't scale: using in-house maintained code it works (Chrome)
  • but using off-the-shelf libraries becomes harder.

Introducing CloudABI

A new posix-like runtime environment.

  • No more state. Capsicum is always turned on.
  • Capsicum-conflicting APIs have been removed.
  • Bugs becomes compiler errors.
  • Global namespaces are entirely absent.
  • Processes can no longer hardcode paths and identifiers.
  • Resources cannot be acquired out of the blue.

Default rights

  • allocate memory, create pipes, socket pairs.
  • can fork.
  • cannot: open paths on disk.
  • cannot create network connections.

Additional rights: file descriptors

Make sure you have the right set of file descriptors when starting the process.

A file descriptor is its own chroot.

Process descriptors: replacement for wait()/kill(). Special fork gives you a process descriptor. These descriptors can't be passed over Unix sockets.

File descriptors have permission bitmasks allowing fine-grained limiting of actions performed on them.

Example file descriptors for a web server:

  • A listening network socket used to receive incoming HTTP requests,
  • One or more file descriptors to directories containing resources accessible through the web,
  • One or more network sockets connected to backend services used by the web server (e.g., database servers),
  • A file descriptor pointing to a log file.

This web server will be limited to the above and can't escape.


POSIX becomes tiny if you remove all interfaces that conflict with capabilities. Only 58 system calls available.

Goal: add support to existing posix operating systems.

Allows reuse of binaries without recompilation.

Upstreams: freebsd/arm64, /x86-64

Beta: Linux.

Developing for CloudABI

CloudABI ports - a collection of cross compiled libraries and tools.

Builds native packages: Freebsd pkg and Debian packages.

Use cases of CloudABI

  • Secure hardware appliance.
  • High-level cluster management.
  • CloudABI as a service: no virtualization overhead. No need to maintain entire systems, just applications. Can be written in any language.

32th Chaos Communication Congress, part 1


Never underestimate the bandwidth of a van full of cypherpunks hurling down the highway. Never mind that the van originally wouldn't start and that we had to get off and push it until it finally started. Now we were hurling along the Autobahn towards Berlin, praying silently to Eris that we wouldn't get an engine failure right there, with BMW's and Porsche's being shot from a cannon behind us.

Hours later we ended up in a fairly up-scale collective, or as the inhabitants called it, a “Wohnungsgemeinschaft”, in Kreuzberg. There was beer cooling in the snow on the balcony, fair wifi and plans for a vegan buffet for New Year's Eve.

The real treat of the trip was of course the ~4000 hackers that were noisily gathering close to Alexanderplatz for the annual Chaos Communication Congress.

This was the start of my first ever C3 conference, a wonderful gathering of hackers and makers that I for a long time had mistakenly thought was just about computer security. I was so wrong. The conference is very much about technology and politics and how they interact and far from being just about computer (in)security.

Now, many years later, the many C3s I've been to have been the best conferences of my life. The organizers and the many volunteers continue to impress me, for example by having their own phone networks (one GSM, one DECT), a working pneumatic tube system covering the entire congress, and one of the best conference networks ever made: this year 4 * 10 Gigabit/s upstream and a wifi with a peak of 8150 clients.

They also offer a temporary co-location facility for your own servers for the duration of the conference.

All talks are streamed in real-time, now without Flash, on some talks including real-time interpretation and subtitling to English and/or German, as well recording everything and offering it to the public.

The talks, workshops and, perhaps best of all, the chance meetings with interesting individuals is why I keep going back year after year.

32C3 Highlights

The 2015 version of the C3 had increased to about 14000 attendees with ~170 talks spread over four days from 11:30 to midnight every day.

If you just watch one of the talks, you should watch Shopshifting, where Karsten Nohl et al breaks commonly used payment protocols by... reading the manual! This includes attacks both against the customer and against the merchant.

If you have time for more, you should watch Alex Halderman's & Nadia Heninger's great talk about logjam: Diffie-Hellman, discrete logs, the NSA, and you. See, especially, the web page they have set up for helping mitigate the logjam:

A natural extension of the logjam talk is a talk about what happens if your adversary has a quantum computer (pro tip: they don't, yet) and how you might be able to mitigate that with post-quantum cryptography: PQCHacks with Daniel “djb” Bernstein and Tanja Lange.

Every year at least one of the talks at the C3 gets picked up by mainstream press. This year I would have guessed that the Shopshifting talk would get all the press. I was surprised to note that the thing the Swedish tabloids picked up was a closer look on a North Korean Linux distribution, Lifting the Fog on Red Star OS! I didn't even go to that talk, mostly because it seemed to mirror a similar talk on an earlier conference.

Below are some of my notes from the talks I attended and some that I watched later.

All talks are available at:

The congress main page is kept up at:

The schedule or, as the C3 people call it, die Fahrplan:


The keynote was held by a newcomer (as she called refugees), Fatuma Musa Afrah. I confess I didn't quite understand her talk or why she was at C3. Not quite as embarassing as Alec from Atari Teenage Riot was last year, though.

Towards (reasonably) trustworthy x86 laptops

Fahrplan link.

Joanna Rutkowska.

Joanna Rutkowska is perhaps mostly known for the Qubes operating system. This talk was about all the state that is kept in a modern x86 computer and some of the components you have to trust, for instance the mysterious Intel Management Engine, that can do just about anything, runs it own OS, can access RAM, and continues to run even in sleep mode.

Memorable quote: “Trusted doesn't mean secure” and “The war is lost on x86”.

She suggested to keep most of the state outside of the laptop to keep it safer — have a trusted stick with all firmware code and everything else you need to bring up your laptop.

The talk has a corresponding paper: State considered harmful A proposal for a stateless laptop but see also her, in my opinion more interesting, Intel x86 considered harmful.

A Free and Open Source Verilog-to-Bitstream Flow for iCE40 FPGAs

Fahrplan link.

Clifford Wolf.

The talk introduced three projects:

  • Project IceStorm - an almost complete reverse engineering of Lattice iCE40 FPGAs! 7680 4-input LUTs. Comes in reasonable packages that can be soldered by hand. Cheapest dev stick, Lattice ICE stick < 25USD!

  • Arachne-pnr - an FPGA place-and-route tool for these FPGAs. Works with Berkely Logic Interchange Format (BLIF) and outputs Icestorm's ASCII .txt format. Can use extra files for physical constraints.

  • Yosys - a Verilog synthesis suite to netlists. Reads Verilog, BLIF, Liberty cell libraries. Writes Verilog, BLIF, EDIF, SPICE decks, SMT2. Performs RTL synthesis and log optimizations, maps designs to FPGA and ASIC cell libraries. “LLVM for hardware”!

The workflow presented was: Verilog -> yosys -> Berkeley BLIF file -> arachne-pr -> icestorm .txt file -> icepack -> FPGA bitstream.

Multiple succesful tape-outs with these tools. People make silicon with this!

An interesting development board, IcoBoard was mentioned — an FPGA development board for Raspberry Pi HAT.

Clifford showed a Demo SoC built with his workflow. He used his own RISC-V compatible CPU, PicoRV32.


Using Hugo as a blog generator

I just switched from Pelican to Hugo for my blog. Hugo, written in Go, is much more interesting than Pelican and I think this means I will update more often.

Most of the old URLs to individual blog items should work. However, the feed URLs changed. I apologize. I hope people subscribing will notice and find the new feed URL easily. It should be auto-discoverable.

mub - a minimalist IRC client in Go

Me and some friends wrote an IRC client in Go. We have tried it under OS X, FreeBSD, GNU/Linux and even on Windows.

Project page here:

By default it gives you a readline-like user interface with command history and the usual command line editing with arrow keys and Emacs keys. If you give it the argument -sub it uses a dumb TTY interface instead which may be usable if you write your own UI interface. So far we have a graphical user interface written in C# (not yet released) that works under Windows and an experimental websockets interface in its early phases.

Tell me what you think!