

Attacking multicore CPUs - charzom
http://www.theregister.co.uk/2007/09/14/system_call_sploits/

======
thomasptacek
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.

------
gwenhwyfaer
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...?

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

