
The Monumental Impact of C - seomint
https://opensource.com/article/19/10/command-line-heroes-c
======
pjmlp
> Bell Labs pulled out of the Multics program in 1969. Multics wasn't going to
> happen.

Not only did Multics happened, even without the help of Bell Labs, a later DoD
security assessment proved that thanks to the fact of Multics being written in
PL/I it wasn't susceptible to the security exploits that plague UNIX clones to
this day.

[https://multicians.org/b2.html](https://multicians.org/b2.html)

~~~
bediger4000
I particularly liked this item from the "b2.html" page:

> The call stack grew from lower addresses to higher, making it less likely
> that a buffer overrun would damage a return address pointer.

I believe that's from Jerome Saltzer's 1974 paper
([https://multicians.org/saltzer-pacisim.pdf](https://multicians.org/saltzer-
pacisim.pdf)) but I can't for the life of me find it in there today. I know
I've read it in the past.

Two things about that:

1\. They knew about buffer overflows, and had them despite writing everything
in PL/1 (or whatever). Buffer overflows may be endemic to C programs, but
they're not limited to C programs.

2\. HP's "HP-PA" RISC architecture had the same stack up/heap down behavior. I
found HP's software to be so old that development on HP-UX was a chore, but
maybe someone who has done more could address how many buffer overflows became
security problems.

~~~
pjmlp
Surely they knew about buffer overflows, that is something that Burroughs
B5500 (nowadays known as Unisys ClearPath) were already trying to tackle in
1961 with ESPOL/NEWP, and C.A.R Hoare has a couple of Algol-60 papers talking
about safety and use of bounds checking as one of the preventive measures.

Sure bound exploits aren't limited to C, however there is a big difference
between having them in easily locatable unsafe blocks, or areas where one has
to explicitly disable them, and having every line of code being a possible
source of exploits due to either memory corruption or UB.

According to Google's security team 68% of security exploits in Linux kernel
are caused by buffer overflows. Check their talk at Linux Kernel Summit 2018.

At Linux Kernel Summit 2019, they have a couple of newer statistics and are
adding hardware memory tagging to Android, based on their collaboration with
ARM. And Android's native code (including NDK) are probably the most locked
down after OpenBSD, in terms of security frameworks that can't be turned off.

SPARC Solaris, is the only other UNIX that can actually tame C security
issues, and even ADI doesn't cover 100% of all possible cases.

