[cap-talk] Hybrid Cap Systems redux
daw at cs.berkeley.edu
Tue Feb 19 00:46:00 EST 2008
Jonathan Shapiro writes:
>Two problems here:
> 1. C is unsafe, therefore these safety checks violate C semantics (and
> do so in practice, not just on paper).
> 2. It is a continuing source of wonder to me that people think it is
> good to induce failure in working C programs by adding checks that
> cause perfectly good programs to fail.
>It isn't good enough to guarantee that misbehaved programs fail. What we
>need is to guarantee that programs do not misbehave.
Can you explain these two comments? If you mean something more
than "safety checks alone are not sufficient", I'd like to understand
what you mean. I know you've thought about this a lot and so I suspect
you may be hinting at something non-obvious...
Here are my reactions to your comments:
1. Safety checks, like checking that array dereferences are in-bounds,
do not violate the C spec. The C language spec allows compilers to
perform array bounds checks, though that is obviously not required.
If the program is writing out-of-bounds, then it has "undefined
behavior" (a term of art in the C spec), which means that the
compiler is free to do anything at all that it wants -- including
terminate the program.
2. If the program is writing out-of-bounds, it's probably not a
"perfectly good" program; there is a significant chance that
the program has a security vulnerability. Therefore, I'd think a
better way of describing this would be to say that it causes flawed
and quite possibly vulnerable programs to fail. You're right that
there may be some programs which write out-of-bounds (and thus are
very poorly written) but just happen to work and just happen not
to be vulnerable, and adding safety checks will break those poorly
written programs. In many cases, that's an acceptable tradeoff.
I don't understand your source of wonder.
Of course safety checks are not the full answer; they are an imperfect
mitigation for a legacy problem. The mitigation may not be "good
enough" to fully solve the problem, but it's better than nothing.
More information about the cap-talk