https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF

National Security Agency | Cybersecurity Information Sheet
Software Memory Safety

<quote>
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.
</quote>

<quote>
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.
</quote>

<quote>
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.
</quote>

Arne

PS: Only Java and Ruby are currently available on VMS.

On 2022-11-11, Arne Vajhøj <arne@vajhoej.dk> wrote:
>
><quote>
> Examples
> of memory safe language include C#, Go, Java, Ruby?, Rust, and Swift.
></quote>
>

There's a language missing from that list.

On a related note, I've just found out today that NVIDIA have made
a _very_ interesting decision with regards to moving towards using
a safer programming language:

https://developers.slashdot.org/story/22/11/13/010222/nvidia-security-team-what-if-we-just-stopped-using-c

I wonder if they will be a one-off or if more organisations will follow ?

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2022-11-14 18:46:59 +0000, Simon Clubley said:

> On 2022-11-11, Arne Vajhøj <arne@vajhoej.dk> wrote:
>>
>> <quote>
>> Examples of memory safe language include C#, Go, Java, Ruby?, Rust, and Swift.
>> </quote>
>>
>
> There's a language missing from that list.

Yes, there are various languages missing from that list. Hence the use
of the word "include" there, and not a word such as "comprise".

> On a related note, I've just found out today that NVIDIA have made a
> _very_ interesting decision with regards to moving towards using a
> safer programming language:
>
> https://developers.slashdot.org/story/22/11/13/010222/nvidia-security-team-what-if-we-just-stopped-using-c
>
>
> I wonder if they will be a one-off or if more organisations will follow ?

There have been other organizations making a similar shift.

And it gets easier. Rust kernel support is now part of Linux.
<https://docs.kernel.org/rust/index.html>

From a few years ago, Microsoft has been pondering and prototyping
Rust:
<https://msrc-blog.microsoft.com/2019/11/07/using-rust-in-windows/>

Apple was hiring for folks to migrate existing C system into Rust from
a few years ago, though with few details. ("The performance and
security of the systems we build are critical. We interface directly to
low-level Linux kernel interfaces, using asynchronous I/O and threads
to distribute workload. Following a very successful first foray into
Rust we are migrating an established codebase from C to Rust, and
building new functionality primarily in Rust." )

As for other languages for that list, Google have added Carbon
<https://github.com/carbon-language/carbon-lang>, so we'll see how that
works out.

This C-to-Rust transpiler looks like fun, not that I'd be in a rush to
push the resulting (unsafe) Rust code into production:
<https://github.com/immunant/c2rust>

As for transpiling or rewriting more generally, few places will go to
the effort of replacing the existing C or C++ code—or the existing
BLISS or Macro32 code, for that matter—to anything else. Not past
incremental work and updates, or replacement when substantial updates
are needed, or other issues arise. Issues such as when one vendor was
replacing their existing Ada code due to (a lack of) compiler support
on the target platform.

--
Pure Personal Opinion | HoffmanLabs LLC

On 11/14/2022 1:46 PM, Simon Clubley wrote:
> On 2022-11-11, Arne Vajhøj <arne@vajhoej.dk> wrote:
>> <quote>
>> Examples
>> of memory safe language include C#, Go, Java, Ruby?, Rust, and Swift.
>> </quote>
>
> There's a language missing from that list.

I assume you are thinking about Ada.

But first the Ada got a great future behind it.

Secondly Ada only address some of the listed
problems - not the deallocation problem. Or?

Arne

On Saturday, November 12, 2022 at 1:01:58 PM UTC+11, Arne Vajhøj wrote:
> https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF
>
> National Security Agency | Cybersecurity Information Sheet
> Software Memory Safety
>
> <quote>
> 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.
> </quote>
>
> <quote>
> 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.
> </quote>
>
> <quote>
> 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.
> </quote>
>
> Arne
>
> PS: Only Java and Ruby are currently available on VMS.

Functional languages?

What about the use of a specification language such as TLA+?

Seems there is a lot of things we can do to push for better software outcomes

On 2022-11-14, Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
> On 2022-11-14 18:46:59 +0000, Simon Clubley said:
>> On a related note, I've just found out today that NVIDIA have made a
>> _very_ interesting decision with regards to moving towards using a
>> safer programming language:
>>
>> https://developers.slashdot.org/story/22/11/13/010222/nvidia-security-team-what-if-we-just-stopped-using-c
>>
>>
>> I wonder if they will be a one-off or if more organisations will follow ?
>
> There have been other organizations making a similar shift.
>
> And it gets easier. Rust kernel support is now part of Linux.
><https://docs.kernel.org/rust/index.html>
>

Oh, it's _not_ Rust that NVIDIA are using in the above story. :-)

The choice here is MUCH more interesting. Still wondering if it will
be a one-off however or a sign of something more to come elsewhere.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 11/15/2022 5:34 AM, IanD wrote:
> On Saturday, November 12, 2022 at 1:01:58 PM UTC+11, Arne Vajhøj wrote:
>> https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF
>>
>> National Security Agency | Cybersecurity Information Sheet
>> Software Memory Safety
>>
>> <quote>
....
>> Examples
>> of memory safe language include C#, Go, Java, Ruby™, Rust, and Swift.
>> </quote>

>> PS: Only Java and Ruby are currently available on VMS.
>
> Functional languages?

> Seems there is a lot of things we can do to push for better software outcomes

FP centric languages and FP centric applications seems
to be very rare.

Most languages today has some FP support, but mostly used
to pass lambdas to list processing methods and similar,
which I consider convenience not FP centric.

Arne

In article <tkuadv$1rahv$1@dont-email.me>,
Stephen Hoffman <seaohveh@hoffmanlabs.invalid> wrote:
>[snip]
>As for other languages for that list, Google have added Carbon
><https://github.com/carbon-language/carbon-lang>, so we'll see how that
>works out.

Carbon is not particulary safe; they decided to take the
approach of "putting in safety after the fact", which seems like
a goal that will be difficult to realize.

>This C-to-Rust transpiler looks like fun, not that I'd be in a rush to
>push the resulting (unsafe) Rust code into production:
><https://github.com/immunant/c2rust>

I think the idea here is that you get it building with the Rust
compiler, avoiding the FFI barrier, and then you can start
wrapping it in a safe interface and then slowly rewrite it in
safe Rust.

>As for transpiling or rewriting more generally, few places will go to
>the effort of replacing the existing C or C++ code—or the existing
>BLISS or Macro32 code, for that matter—to anything else. Not past
>incremental work and updates, or replacement when substantial updates
>are needed, or other issues arise. Issues such as when one vendor was
>replacing their existing Ada code due to (a lack of) compiler support
>on the target platform.

The whole idea of Carbon is to give you transpiling from
idiomatic C++ to idiomatic Carbon; you get improved syntax and
so forth, and they can address a subset of C++ bugs that way.

Whether anyone other than Google adopts it remains to be seen
(disclaimer: I saw early versions of the spec when I was at
Google. It was hard then to imagine how Carbon would compete
against mature Rust and Swift ecosystems, and even harder now.
Their main selling point seems to be good compatibility with
large, existing C++ code bases, which Google certainly has).

- Dan C.

On 11/11/2022 9:01 PM, Arne Vajhøj wrote:
> https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF
>
> National Security Agency | Cybersecurity Information Sheet
> Software Memory Safety

> <quote>
> 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.
....
> 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.

Bjarne has replied to NSA:

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2739r0.pdf

Arne