NSA om programmeringssprog

https://media.defense.gov/2022/Nov/10/2003112742/-...

National Security Agency | Cybersecurity Information Sheet
Software Memory Safety

While developers often perform rigorous testing to
prepare the logic in software for surprising conditions, exploitable software
vulnerabilities are still frequently based on memory issues. Examples include
overflowing a memory buffer and leveraging issues with how software allocates and de-
allocates memory. Microsoft revealed at a conference in 2019 that from 2006 to 2018
70 percent of their vulnerabilities were due to memory safety issues. Google also
found a similar percentage of memory safety vulnerabilities over several years in
Chrome.

Commonly used languages, such as C and C++, provide a lot of freedom and flexibility
in memory management while relying heavily on the programmer to perform the needed
checks on memory references. Simple mistakes can lead to exploitable memory-based
vulnerabilities. Software analysis tools can detect many instances of memory
management issues and operating environment options can also provide some
protection, but inherent protections offered by memory safe software languages can
prevent or mitigate most memory management issues. NSA recommends using a
memory safe language when possible. While the use of added protections to non-
memory safe languages and the use of memory safe languages do not provide absolute
protection against exploitable memory issues, they do provide considerable protection.
Therefore, the overarching software community across the private sector, academia,
and the U.S. Government have begun initiatives to drive the culture of software
development towards utilizing memory safe languages.

Using a memory safe language can help prevent programmers from introducing certain
types of memory-related issues. Memory is managed automatically as part of the
computer language; it does not rely on the programmer adding code to implement
memory protections. The language institutes automatic protections using a combination
of compile time and runtime checks. These inherent language features protect the
programmer from introducing memory management mistakes unintentionally. Examples
of memory safe language include C#, Go, Java, Ruby™, Rust, and Swift.

Bjarne har svaret NSA:

https://www.open-std.org/jtc1/sc22/wg21/docs/paper...

#2

Han brokker sig samtidig med at hans først paragraf giver en ret præcis analyse af problemet:

Unfortunately, much C++ use is also stuck
in the distant past, ignoring improvements, including ways of dramatically improving safety

Derudover er der ikke særlig meget "vigtigt" software jeg kan forstille mig er værd at udvikling i C/C++ i dag.

Hvis man har fri mulighed for at vælge teknologi til et problem, hvorfor ville man dog nogensinde vælge C eller C++?

Og jeg er ret sikker på at hvis et projekt som Chromium eller Firefox blev startet i dag, ville det blive udvikling i Rust eller lign.

Ja, Stroustrup har brugt 30 år på at rette sine enorme store fejl i C++. Men er det virkelig et god grund til at blive ved med at bruge C++?

Claus Jørgensen (3) skrev:

Derudover er der ikke særlig meget "vigtigt" software jeg kan forstille mig er værd at udvikling i C/C++ i dag.

Hvis man har fri mulighed for at vælge teknologi til et problem, hvorfor ville man dog nogensinde vælge C eller C++?

C/C++ brug er i høj grad drevet af eksisterende kode baser (men det er de ikke ene om).

Ny kode i C/C++ er vel drevet af specielle krav:
- direkte hardware adgang
- gode real time egenskaber
- lavt memory forbrug
kombineret med manglende vilje til at prøve nyere sprog (Rust, Go) eller spritnye sprog (Zig, Hare) eller fremtidige sprog (Carbon).

Claus Jørgensen (3) skrev:

Og jeg er ret sikker på at hvis et projekt som Chromium eller Firefox blev startet i dag, ville det blive udvikling i Rust eller lign.

FF og Chrome har besluttet at bruge Rust (FF er en af de oprindelige ophavsmænd bag Rust), så det virker meget plausibelt at startede de dag ville de kun bruge Rust.

Claus Jørgensen (3) skrev:

Ja, Stroustrup har brugt 30 år på at rette sine enorme store fejl i C++. Men er det virkelig et god grund til at blive ved med at bruge C++?

C++ blev designet tilbage i midten af 80'erne. Dengang var HW situationen helt anderledes end idag. UCSD p-Machine var en fiasko selvom det grundliggende er samme teknologi som senere successer som JVM, CLR etc..

arne_v (4) skrev:

midten af 80'erne. Dengang var HW situationen helt anderledes end idag.

Vi kunne have 110 interaktive brugere som kørte typisk enten (tekst) editor + Pascal compiler eller tekstbehandling (WP 5). på en VAX 6000-420 med 2 CPU @ 35 MHz og 32 MB RAM.