| |||||||||||||
Exploiting races in system call wrappersExploiting races in system call wrappersPosted Aug 16, 2007 18:00 UTC (Thu) by flewellyn (subscriber, #5047)Parent article: Exploiting races in system call wrappers
Well, I can see why the "check inside the kernel" method works. But, I'm curious, how would this "message-passing" system work, that would eliminate the races?
(Log in to post comments)
Exploiting races in system call wrappers Posted Aug 16, 2007 20:06 UTC (Thu) by ms (subscriber, #41272) [Link] Well if you're using message passing, then once you've sent the message, you no longer have access to the data. This is hinting at what the real problem is: shared memory.
Erlang, with its message passing, can't ever have this sort of problem. Now of course, to make the implementation run fast, it uses shared memory under the bonnet, but this is never exposed to the programmer, so it's safe (err, well...). Other programming paradigms would also be able to protect programmers from this sort of issue - STM and other transactional memory systems may have ideas to contribute in this area too.
Exploiting races in system call wrappers Posted Aug 16, 2007 22:04 UTC (Thu) by flewellyn (subscriber, #5047) [Link] Sounds rather like the old "safety vs. performance" issue. Joy.
I can think of ways to make shared memory safe, in general, but most of them involve either locking critical sections, or using some kind of multiversion concurrency control, like many DBMSes do. Either one is going to cost.
In the "TOCTTOU" case, I suppose locking the "check and use" section of the code somehow, so that no other processes could access the resource being checked, would work, but again, performance hit. And complicated. And I might be wrong anyway, and that doesn't work after all.
|
|||||||||||||