Assurance that adversaries cannot read or write to memory locations other than those intended by the programmer.
A significant percentage of software vulnerabilities have been attributed to memory safety issues [NSA22], hence memory safety is of critical importance.
Examples of violations of memory safety can be found in the discussion of common weakness CWE-787 and CWE-125.
Type safety is a formal guarantee that the execution of any program is free of type errors, which are undesirable program behaviours resulting from attempts to
perform on some value an operation that is inappropriate to the type of the value.
For example, applying a factorial function to any value that is not an integer should result in a type error.
Type safety ⇒ memory safety, but the converse is not true [SM07, Sec. 6.5.2], hence type safety is commonly considered to be a central theme in language-based security [Fru07].
Type-safe programming languages, e.g., Java , Ruby, C#, Go, Kotlin, Swift and Rust, have been around for a while. However, memory-unsafe languages are still being used because:
Type-safety features come at the expense of performance. There is for example overhead associated with checking the bounds on every array access [NSA22].
Even the current speed champion, Rust, among the type-safe languages, and the only type-safe language that has made it to the Linux kernel [VN22] and Windows kernel [Thu23], is not efficient enough for all use cases [Iva22]. This is one of the reasons why Google is still trying to create a successor to C++ called Carbon.
Type-safety features also come at the expense of resource requirements. Most memory-safe languages use garbage collection for memory management [NSA22], and this translates to higher memory usage.
Although most type-safe languages are supported on the mainstream computing platforms (e.g., Wintel), the same cannot be said of embedded platforms.
It can be challenging to program a resource-constrained platform using a type-safe language.
There is already a vast amount of legacy code in C/C++ and other memory-unsafe languages.
The cost to port legacy code, including the cost of training programmers, is often prohibitive.
Depending on the language, interfacing memory-safe code with unsafe legacy code can be cumbersome.
Besides invoking unsafe code, it is all too easy to do unsafe things with a type-safe language, e.g., not checking user input, not implementing access control.
Programmers often use this as an excuse to not use a different language than what they are familiar with.
Nevertheless, adoption of type-safe languages, especially Rust, has been on the rise [Cla23].
Thread safety rounds up the desirable properties of type-safe languages.
The avoidance of data races, which occur when data are set to either correct or incorrect values, depending upon the order in which multiple threads access and modify the data.
Watch the following LinkedIn Learning video about thread safety:
D. Wagner, N. Weaver, P. Kao, F. Shakir, A. Law, and N. Ngai, Computer security, online textbook for CS 161 Computer Security at UC Berkeley, 2021. Available at https://textbook.cs161.org/.
