Attacking multicore CPUs

I was on the committee for Usenix WOOT, and this was one of my favorite submissions. But it has very little to do with concurrency or multicore CPUs.

Watson's paper points out that where there are indirections inside the kernel (for instance, filenames to vnodes), you have to be careful about TOCTTOU bugs. If you chase the same indirection twice, there is no guarantee you will arrive in the same place. This is a famous, hoary source of problems in userland.

Watson's results were that things like Systrace (which firewall processes off from the rest of the system) have lots of TOCTTOU issues because they try to enforce policy on things like filenames. Because of the way they're architected, as a "layer" over/under the actual system call handlers, the security check and the actual system call do two seperate lookups. Race condition.

This result doesn't depend on multicore; it happens on uniprocessor systems as well. TOCTTOU filesystem races in userland accounted for a good percentage of the 8lgm-era SunOS advisories.

Turns out that the problem isn't concurrency per se, but shared mutable memory that an attacking process can sneak in and rewrite before the kernel reads it - and any schoolchild knows that if someone can sneak in and scribble all over something, they will. As if all the other problems with mutable state weren't quite bad enough... :)

I wonder how the history of computer architecture would have been altered had someone discovered a memory technology where writing into empty cells was very easy, but altering them extremely difficult, back in 1953? Such a memory technology would have been perfectly utilised by functional programming techniques, but would have made traditional mutable state extremely expensive (not impossible, as monads demonstrate, but not primitive). What would be different today...?

Thank god I don't use anti-virus systems or security policy enhancement frameworks. Somehow they seem to be the wrong approach anyway.