3 ms·
This is one of those rare cases where I can say "It's 2021, and we know that's not true now." C and C++ can not be secure at scale without unreasonable amounts
by jerf 6y ago
This is one of those rare cases where I can say "It's 2021, and we know that's not true now." C and C++ can not be secure at scale without unreasonable amounts of effort. It can't be secure at any non-trivial scale through sheer discipline alone.
40 years ago, the case could be made. But C and C++ are not new languages, and the fact that just barely shy of no one can demonstrate the existence of secure C or C++ code bases without staggering levels of effort put into that process is data now, not just anecdote.
(And let me emphasize the effort as my yardstick. Writing truly secure code is arguably something nobody has ever done at scale in any language... but C and C++ are certainly unique in the sheer level of effort it takes poured in to them to even match what a number of other languages come with out of the box, let alone exceed them. If you aren't using some very high quality and fairly expensive tools like Coverity on a routine basis, you aren't even close.)
- thesuperbigfrog 6y ago>> C and C++ can not be secure at scale without unreasonable amounts of effort. It can't be secure at any non-trivial scale through sheer discipline alone. Agreed. That is why C and C++ should be replaced with more reliable alternatives.
- pjmlp 6y agoNot even 40 years ago, because exactly in 1981, C.A. Hoare stated on his Turing award speech, "Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law."
- GeorgeTirebiter 6y agoI am astonished that HARDWARE does not help us much. When 'everybody' decided going like a bat-out-of-hell was more important that security and safety and easy-to-not-screw-up languages w/garbage collection and capabilities and hw-enforced typing and and ... we end up where we are: a mess that runs fast. And, specifically, I think that RISC-V rather missed the boat here, by not taking the security/safety banner and leading to a new way of building computer systems. Instead, we got a different (open) ARMish thing. Progress...
- lmm 6y agoPeople - or rather C compiler writers - don't even use the minimal safety capabilities that today's hardware has. Trapping NaNs? C is going to turn them off. Trap on null pointer dereference? The C compiler is going to optimize that away. Etc.
- pjmlp 6y agoThere are now efforts to turn computers into C Machines with hardware memory tagging. While Intel's MPX extensions were a failure, Solaris makes use of ADI on SPARC, iOS uses PAC, Google is researching adopting ARM MTE into Android, ARM sponsors CHERI with Morello project, Azure Sphere has Plutonium, and so forth. However these are all pontual efforts, and their large scale effects will take years or decades to start making a difference.
- xfer 6y agoCan you actually have a faster system with hardware checks compared to what we can do with x86 with all security checks in software? If not, I don't see the point. Noone is going to buy slower hardware that runs the same safe language(which we already have access to).
- pjmlp 6y agoYes, Solaris SPARC with ADI for example.