This is the fifth of a series of articles examining a 2009 interview with Bjarne Stroustrup. The first part is here with links to the other parts:
Security
Stroustrup: “First of all: security is a systems issue”
This is correct. Security should be ensure by the system design of the platform and not left up to programmers or programming languages. Opposite to what C hype says, programmers cannot be trusted. We should not trust them with using insecure languages. It is important that programming languages reflect good platform semantics like bounds checking. But most platforms leave this up to languages.
Stroustrup: “Remember, even if all of your code was perfect, I could probably still gain access to your stored secrets if I could steal your computer of the storage device holding your backup.”
That is no excuse for not making each element, such as a programming language, as secure as possible. It is also why Apple refuses to have a master password to unlock everything. If (hopefully) trusted government agencies could unlock anything, then others could as well.
Stroustrup: “Secondly, security is a cost/benefit game: perfect security is beyond the reach of most of us…”
Again not an excuse for the security-poor semantics of C and C++. Poor security in this industry, particularly enabled by the poor security of buffer overruns and many other security holes in C/C++, costs the world billions, maybe trillions of dollars.
Stroustrup: “But what about programming languages and programming techniques? There is a dangerous tendency to assume that every line of code has to be “secure” (whatever that means)…”
Let’s just stop that there. Yes, EVERY line MUST be SECURE. Perhaps Stroustrup had never heard of Hoare Logic (the basis of DbC) which says that every element, line and expression in a program must be correct. Recursively, these define a correct system. Security and correctness are related. Expecting every line of code to be secure is not dangerous — it is Stroustrup’s reasoning here that is dangerous.
Proof of correctness and proof of security is related.
Stroustrup: “This is a most dangerous notion that leaves the code littered with unsystematic test guarding against ill-formulated imagined threats.”
Here he has a misguided point. I agree that programmers should never need to include bounds checks in their code since bounds checking should be done beneath the level of the program at the platform level. If the platform does not do it, the programmers need to. Don’t trust programmers to do it. Hackers will exploit it and not include checks. Certainly having to add sanity checks in C and C++ will pervert the meaning of the code and make it unclear. And that is why the checks should be done underneath the code, either by the compiler generating checks, or better in the platform because languages can’t be trusted either, especially C and C++. The language semantics should reflect those lower-level checks.
Programmers should only need to provide abstract checks that directly relate to the application.
Stroustrup: “It also makes code ugly, large, and slow. “Ugly” leaves places for bugs to hide,”
Well, C++ is actually quite ugly. This makes it difficult to reason about programs and identify bugs. Although there is more to it than just clean and clear syntax, just choosing a language on syntactic clarity is not a bad criterion. C++ fails that — it is ugly.
If security checks are at the platform level (in system design) then there is no necessity for programmers to add ugly code. C and C++ necessitate that extra effort of programmers, not only for security but many other things.
Stroustrup: ““Large” ensures incomplete testing, and “slow” encourages the use of shortcuts and dirty tricks that are among the most fertile sources of security holes.”
This is why the language and programmer should not be left to enforce security — it must be at system and processor level.
Stroustrup: “I think the only permanent solution to security problems is in a simple security model applied systematically by quality hardware and/or software to selected interfaces.”
And that is exactly what I have been saying here and previously for many years — build security in as low as possible. Rik Ferguson, renowned security expert, also says that security must be built in at the lowest levels, or it is an afterthought. But processor and system vendors are afraid to do that precisely because all C/C++ programs out there would break.
https://queue.acm.org/detail.cfm?id=3212479
WELL, BREAK THEM!
Stroustrup: “I do not think that you can design a programming language that is completely secure and also useful for real-world systems.”
Maybe not, but again this is not an excuse for C++. Real-world requirements need to be secure. That is the real world. Not only is this on multi-programming systems, but single-purpose embedded systems.
Stroustrup: “Obviously, that depends on the meaning of “secure” and “system”.”
Well, we can play semantic games, but again that is just excusing C++.
Stroustrup: “You could possibly achieve security in a domain-specific language, but my main domain of interest is systems programming (in a very broad meaning of that term), including embedded systems programming.”
Note that — C++ is designed FOR SYSTEMS PROGRAMMING, not for general application programming. We don’t need domain-specific languages to provide security — we can do much better with general-purpose languages, even system languages.
System programmers who think general applications programmers should use the same languages they use have not done their job. They probably don’t even understand what their job is. That is to handle the system details so that others are free to concentrate on their problem and not have to think about the platform or machine and so they can be flexible and independent of the platform. C and C++ fail in this separation of concerns (the fundamental base principle of system design) and thus achieve lock in for all the wrong reasons.
We should not let system programmers dictate how the rest of us should program. System programmers do not make good language or user-interface designers.
Stroustrup: “…type safety does not equal security.”
True. But class-based security is an aspect. Again security should be at a system level.
Stroustrup: “People who write C++ using lots of unencapsulated arrays, casts, and unstructured new and delete operations are asking for trouble.”
Well these are exactly the things that should not be in general languages, and not at most levels of system programming.
Stroustrup: “To use C++ well, you have to adopt a style that minimizes type safety violations and manage resources (including memory) in a simple and systematic way.”
Yes, in the way that is designed into other languages. These are not ‘training wheels for beginners’, or ‘crutches for weak programmers’ — they are essentials of well designed languages, ones that support genuine programmers and that prevent non-genuine programmers (hackers) wreaking havoc.
Since these incorrect philosophies were baked into the core of C++ from at least 1986 to 1997, they have formed the basis of much subsequent activity trying to fix C++. I suspect that the core philosophical reasons have never been addressed and that is why C++ continues to be ‘fixed’ version after version.
Stroustrup has completely wrong views on security.
Addendum
While I was preparing this for publication, the Microsoft/Crowdstrike problem struck worldwide, brining many systems in transport, business, universities to a halt. It was the most serious technology fail ever. Certainly we can say that the last part was poor practices on the part of Crowdstrike (a company name that should like it should be the name of a virus), not sufficiently testing an update in different environments.
But it is deeper than that. Certainly Microsoft does not escape unscathed in that their OS allows any third-party software to operated at that low-level of the system, even if it is supposedly to protect. The problem is that if the good guys can do it, so can the bad guys. It also shows that system validity testing has been taken out of the hands of administrators and operations to ensure updates work in their environment.
But let’s get to the real underlying problem which has now been revealed is that the software was written in C++ and C++ did not sufficiently test for a null pointer. Such a test would have helped Crowdstrike find the problem early saving mass chaos, and what is likely irreparable damage to the reputation of Crowdstrike. Yes this is due to C++, and very much embedded in the comments of Stroustrup I have illustrated above.
Tony Hoare originated the concept of null pointers and singles it out for specific mention in his talk “Null References: The Billion Dollar Mistake”:
http://www.infoq.com/presentations/Null-References-The-Billion-Dollar-Mistake-Tony-Hoare
But the very foundation of C and C++ are to perpetuate null references and many other of the worst practices of software production.
