Tony Hoare provided my favorite definition of security in his Turing Award lecture “The Emperor’s Old Clothes”:
The first principle was security: The principle that every syntactically incorrect program should be rejected by the compiler and that every syntactically correct program should give a result or an error message that was predictable and comprehensible in terms of the source language program itself
He mentions spatial memory safety in particular, as it is the first and unavoidable kind of unsafety we encounter. (I’d say both as individuals, when we start learning C and assembly, and also in the history of software development — programs in the era he is talking about often did not have object lifetimes other than static and stack, so temporal safety was less of an issue.)
But if we work through the implications of Hoare’s 1st principle, it becomes clear that safety must mean (at least) all of spatial and temporal memory safety, and also type safety. It’s worth noting that the need for lifetime safety was recognized and implemented almost immediately after the first dynamic language was invented. And we know he regrets inventing meaningless references.
So Hoare wants for machines to never be weird, in Thomas Dullien’s sense. It must at least be possible to program a computer, even if difficult. This is especially important given the unavoidable complexity of programming:
Programmers are always surrounded by complexity; we cannot avoid it. Our applications are complex because we are ambitious to use our computers in ever more sophisticated ways. Programming is complex because of the large number of conflicting objectives for each of our programming projects. If our basic tool, the language in which we design and code our programs, is also complicated, the language itself becomes part of the problem rather than part of its solution.
Unwarranted complexity, such as weirdness and underspecified and inconsistent APIs, becomes hostile to safety, utility, efficiency, our ethical duty, and cost.
11 years after Hoare, some people in New Jersey would also go on to implement another dialect of Algol. But they ignored this 1st principle of system design. For 51 years, we have accepted extremely — and increasingly! — weird and unnecessarily complex machines as normal. It’s hard to overstate how much software engineering regressed in the 1970s. 50 years later, we have not dug ourselves out of the pit. There are people who benefit from this state of affairs. Hoare had a spicy take on that:
In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law.
I’m actually not sure it’s true that it would long have been against the law; much product safety regulation was relatively new at the time he wrote this. In any case, the seemingly in-the-weeds topic of memory safety is now a topic of policy discussion. (See also the whole Buying Down Risk series.)
Hoare’s 2nd principle of language design is in the same vein. I’ll take the liberty of re-phrasing it a bit, for emphasis: Efficiency (particularly space-efficiency) is critical — both for its own sake, but also so that you can use the headroom to further improve reliability. He even goes as far as to say “rugged”, which is such a beautiful vision for software.
3rd and 4th are developer experience principles: Composition must be efficient, so that we can use it heavily; and, The write/test/debug loop must be low-latency.
As ‘obvious’ as these principles may seem, it’s fun to think: which programming environments do you use that reliably satisfy all 4? I think there are a few (woo hoo!) but that we don’t often enough demand that this be the baseline.
I love Hoare’s lecture/essay so much because it is such a pithy summary of hard-won and deep insights into many aspects of software development: safety, obviously, but also usability, reliability, business management, project and program management. The copy on ACM’s site is a fairly janky PDF, so I’ve reformatted it as plain HTML for easier reading and correct copying and pasting. (The PDF’s text is OCR with errors, alas.)
See also Adrian Colyer’s similar paean! And you might like Hoare’s Software Design: A Parable.
如有侵权请联系:admin#unsafe.sh