State is not always to blame

Nelson Elhage describes a cute Linux vulnerability, of which the heart is that Linux sometimes temporarily turns off its pointer validity checks, and then does things that aren't safe without those checks.

My reaction (after the initial wow, Linux has stupid mistakes too, as if it should be a surprise) was interestingly wrong: I blamed the problem on the use of state, and briefly supposed it should have been done with something like dynamic scope instead. But actually state had nothing to do with it. The problem was in turning off the checks over an unnecessarily large scope, and in not being clear about what operations were safe with the checks turned off. That they were turned off statefully was irrelevant; the result would have been the same regardless of the mechanism.

Zealous functional puritans blame all kinds of problems on state, and they have an unwholesome influence on other functional programmers. We learn that state is an acceptable target, that it's the usual suspect for any problem, that no evidence is necessary to accuse it. And so we do so even in cases like this vulnerability, where a moment's thought would reveal that state was innocent, and for many other problems whose causes are not so obvious. How many really have anything to do with state?

4 comments:

  1. Well, the stateful model was still to blame here; it's just that its statefulness wasn't the main problem.

    But yes, this specific problem is one of scope, not state.

    ReplyDelete
  2. How does the stateful model contribute? A purely functional implementation of scoped security settings would have exactly the same result.

    (Unless you mean that pointer writes are a stateful matter, which of course they are. But the distinction between trusted and untrusted input can easily exist without state.)

    ReplyDelete
  3. I mean that the entire model of the scope here was to blame, because it was too coarsely-grained; it also happens to be stateful. It is possible that if the Linux kernel were purely functional, the obvious system to design for this problem would end up not having this problem. That doesn't mean that state caused this bug, of course; it just means that the bug isn't entirely separate from the statefulness.

    ReplyDelete
  4. But then I guess that's unfair because it lets you say that absolutely every problem is related to C, since Linux was developed in C. Hmm.

    ReplyDelete

It's OK to comment on old posts.