(Note to self: learn to scan the full digest for later messages in a thread before replying to an earlier message.)
Your reply to John answered some of my questions, but not all, and raised a new one:
Maybe I should have been a bit clearer; we're really interested in full
memory and type safety. We want to harden the system against memory
corruption vulnerabilities. Process isolation isn't an issue, as we are
in an embedded context where we don't have processes.
Do you also care about use-after-free and free-after-free errors? Handling free-after-free is not too hard, but general use-after-free can be expensive, unless you’re willing to spend a fair amount of extra memory. If dynamic allocation isn’t an issue for your (embedded) applications, that makes this whole problem go away, of course.
This brings me to the new question: exactly what unsafe features do you need to be concerned about? Our first paper in the SAFECode project focused on identifying a subset of C for which type and memory safety could be enforced without *any* run-time checks or GC. We found that array bounds checks were the biggest problem; ignoring these, we can ensure the safety of pointer and dynamic memory usage in all the embedded benchmarks we tried without any run-time checks. The paper appeared at LCTES:
Like the later work, this did not eliminate use-after-free but used APA to ensure that any use-after-free errors are “harmless” in that they did not violate all the other type- and memory-safety guarantees.
Let me know if you have any questions about this.
// Vikram S. Adve
// Professor, Department of Computer Science
// University of Illinois at Urbana-Champaign
// "A ‘No’ uttered from the deepest conviction is better than
// a ‘Yes’ merely uttered to please, or worse, to avoid trouble."
// --Mahatma Gandhi