Auckland Half Marathon #4

Official time 1:46:34, net time 1:45:14. This is my new personal best; I've been getting faster every year. This year I did a bit more training than last year, but I'm a bit disappointed because I didn't push myself as hard as last year.

At this pace and distance my feet aren't quite tough enough; both this year and last year a spot of skin on my right foot wore through and started bleeding. I don't feel it while I'm running but it's not a good look, so either I need to do more training or wear my Vibrams if I'm going to run faster or further.

Implications Of ASLR Side-Channel Attacks

This paper is a pretty interesting attack on kernel ASLR, based on observing timing differences in (invalid) accesses to kernel memory from user-space with Intel's TSX hardware transactional memory primitives. There is other recent work on kernel ASLR information leaks based on cache timing and BTB timing. I was a bit underwhelmed by the BTB attacks but this TSX-based attack is much stronger. My guess is that there are a lot more timing-channel and other side-channel attacks to be discovered under this thread model. While I was at Berkeley, I was quite stunned to hear that Intel's SGX enclave extension was designed for a threat model that explicitly excludes side-channel attacks!

This all reminds me of the wave of CFI bypass attacks. CFI and ASLR are supposed to reduce exploitability of bugs providing attack primitives like buffer overflows, but in the long run, they may not be much good. This increases the importance of denying attackers access to these primitives in the first place. Programming languages that reduce the TCB are an important part of that. Glad to be writing most of our new code in Rust!

Tangentially, I wonder whether the publication of the TSX-timing-channel paper was a good thing overall (other than for the careers of the researchers), given the paper's conclusion that there are no practical countermeasures without hardware changes or significant performance degradation ... not even a microcode update to disable TSX is available. Ostensibly the value of attack papers, like white-hat security analysis, is to stimulate the creation and deployment of defensive countermeasures, but in this case there really aren't any. Would we all be better off, in practice, if the issue had been reported to hardware vendors and silently fixed, with microcode updates available for older hardware, before publication? Like Andrew Myers, I feel that the incentives to favour attack research over defense mean we're spending a lot of public money to mostly make the security situation worse.

Valuing America

There's a lot of anti-Americanism around. Some of it is justified, but a lot of it is a knee-jerk reaction that is unjustified and dangerous. It's especially dangerous when it takes the form of false equivalence: "sure, Russia/China/North Korea/Iran/Saudi Arabia is bad, but the USA is bad too". That position is wrong, whether it's taken by left-wing activists or Donald Trump.

In the former countries (and many others), if you're a popular opponent of the government you are very likely to end up in prison or dead. To a first approximation, countries that look more like America in their economic systems and institutions deliver more freedom and less poverty to their citizens. (China's history is a great validating experiment.) It is no accident that Western Europe turned out better than Eastern Europe, or that former Soviet satellite states would rather be part of NATO and Europe than in the Russian orbit, or that South Korea and North Korea turned out very differently, or that Taiwan and Hong Kong turned out better than mainland China. I think it's telling that "peace activists" in New Zealand reliably protest all sorts of US military action but don't bother about Russia slaughtering civilians in Syria, for example; they unwittingly show their respect for the USA by holding it to a higher standard.

That false equivalence creates various problems. It undermines support for sanctions and other action against the more problematic countries. Worse, it encourages the idea that it would be good for US global power to be substantially curtailed. To me, that seems like a very bad idea: I am very concerned about existential threats, especially nuclear weapons proliferation, and without strong US leadership that will more quickly become a free-for-all with disastrous consequences for humanity. It would be excellent if other great powers, like China or the EU, decided to take these responsibilities seriously, but that doesn't seem to be happening. Indeed, Russia and China recklessly enable Iran, North Korea and others for their own short-term ends. They (and much of the West) privately expect the USA to be the world's policeman and clean up the mess, while publicly berating it whenever that goes wrong.

The opposite error would be to uncritically accept US systems and actions as good. Most people in New Zealand and elsewhere are pretty far away from that error (except when they cherry-pick evidence to support their arguments). Personally I think New Zealand, for example, gets a lot of things more right than the USA does. That does not make the USA dispensable.

Dell, Your Website Security Is Broken

You can download firmware and BIOS updates from Dell. Unfortunately the download link is plain HTTP :-(. Fortunately the page provides SHA hashes for the download, which are even correct --- though I imagine practically no-one checks them. Unfortunately, the download page itself is plain HTTP so those hashes can't be trusted either :-(.

Interestingly, the download page is available via HTTPS as well, but Google searches for "Dell bios update" etc point to the insecure version of the site. I have no idea why that would be.

Pivoting To Cyber-Forestry

Forestry work is dangerous. Wouldn't it be great if we could save money and lives using autonomous drones to trim trees in rural and urban areas? We could call it cyber-forestry, or we could call it frickin' flying chainsaws ... I could go either way.

You may be thinking of potential downsides, like what happens if the flying chainsaws get hacked. Don't worry, our security people will be the best in the business. Well, among the best. Well, as good as Yahoo's anyway.

Government regulation could become an issue. We'll use the Uber approach: scale first, lobby later. With thousands of flying chainsaws deployed everywhere, who dares regulate us?

Yeah OK, I admit this could turn out badly for humanity. But hey, if we don't do it, someone else will. Better for us to be first, because we're wiser and smarter than them. Whoever they are.

Ironic World Standards Day

Apparently World Standards Day is on October 14. Except in the USA it's celebrated on October 27 and in Canada on October 5.

Are they trying to be ironic?

Tawharanui Revisited

Today I visited Tawharanui peninsula again with some friends and family. The weather wasn't great --- it was a bit wet, windy and cold at times --- but it was still a good trip.

Tawharanui is protected by a predator-proof fence, and has populations of some of NZ's endangered native birds. We were lucky enough to see some North Island saddlebacks.

At a lookout at the end of the peninsula we could see a number of extremely large "lion's mane" jellyfish in the water. These have also been washing up further north recently. My parental vanity was gratified by my children immediately recalling the Sherlock Holmes story The Adventure Of The Lion's Mane.

rr Paper: "Lightweight User-Space Record And Replay"

Earlier this year we submitted the paper Lightweight User-Space Record And Replay to an academic conference. Reviews were all over the map, but ultimately the paper was rejected, mainly on the contention that most of the key techniques have (individually) been presented in other papers. Anyway, it's probably the best introduction to how rr works and how it performs that we currently have, so I want to make it available now in the hope that it's interesting to people.

Update The paper is now available on arXiv.

Bay Area Talks About rr And Beyond, October 2-7

I'm visiting the Bay Area in the coming week to talk about rr and where it could go. It's a mix of organised talks and smaller meetings. The talks are as follows:

• Monday October 3, 2:30pm: Dropbox (SF office, 333 Brannan St)
• Tuesday October 4, 11:00am: Google (MTV-PLY-2)
• Thursday, October 6, 10:00am: Intel (Santa Clara, 3600 Juliette Lane)
• Friday, October 7, 3:30pm: Berkeley (511 Soda Hall)

I haven't scheduled anything at Mozilla this time. They've already heard me talk about rr a lot :-).

Thanks to all the people who helped me organise this. I still have some free time in my schedule for additional meetings as necessary.

rr 4.4.0 Released

I just pushed out the release of rr 4.4.0. It's mostly the usual reliability and syscall coverage improvements. There are a few highlights:

• Releases are now built with CMAKE_BUILD_TYPE=Release. This significantly improves performance on some workloads.
• We support recording and replaying Chromium-based applications, e.g. chromium-browser and google-chrome. One significant issue was that Chromium (via SQLite) requires writes performed by syscalls to be synced automatically with memory-maps of the same file, even though this is technically not required by POSIX. Another significant issue is that Chromium spawns a Linux task with an invalid TLS area, so we had to ensure rr's injected preload library does not depend on working glibc TLS.
• We support Linux 4.8 kernels. This was a significant amount of work because in 4.8, PTRACE_SYSCALL notifications moved to being delivered before seccomp notifications instead of afterward. (It's a good change, though, because as well as fixing a security hole, it also improves rr recording performance; the number of ptrace notifications for each ptrace-recorded syscall decreases from 3 to 2.) This also uncovered a serious (to rr) kernel bug with missing PTRACE_EVENT_EXIT notifications, which fortunately we were able to get fixed upstream (thanks to Kees Cook).
• Keno Fischer contributed some nice performance improvements to the "slow path" where we are forced to context-switch between tracees and rr.
• Tom Tromey contributed support for accessing thread-local variables while debugging during replay. This is notable because the "API" glibc exports for this is ghastly.