Prospective vision: Optional Strict Memory Safety for Swift #2581

DougGregor · 2024-10-01T21:43:40Z

No description provided.

apple-fcloutier · 2024-10-01T21:51:00Z

visions/memory-safety.md

+In addition, an `@unsafe` attribute would be added to the language and would be used to mark any declaration that is unsafe to use. In the standard library, the following functions and types would be marked `@unsafe` :
+
+* `Unsafe(Mutable)(Raw)(Buffer)Pointer`
+* `(Closed)Range.init(uncheckedBounds:)`


Does this lead to memory unsafety?

Yes, because bounds checking for various collection operations taking an range as input assume that the invariants hold for the range.

apple-fcloutier · 2024-10-01T21:51:45Z

visions/memory-safety.md

+
+Since its inception, Swift has provided memory safety for the first four dimensions. Lifetime safety is provided for reference types by automatic reference counting and for value types via [memory exclusivity](https://www.swift.org/blog/swift-5-exclusivity/); bounds safety is provided by bounds-checking on `Array` and other collections; type safety is provided by safe features for casting (`as?` , `is` ) and `enum` s; and initialization safety is provided by “definite initialization”, which doesn’t allow a variable to be accessed until it has been defined. Swift 6’s strict concurrency checking extends Swift’s memory safety guarantees to the last dimension.
+
+Providing memory safety does not imply the absence of run-time failures. Good language design often means defining away runtime failures in the type system. However, memory safely requires only that an error in the program cannot be escalated into a violation of one of the safety properties. For example, having reference types by non-nullable by default defines away most problems with NULL pointers. With explicit optional types, the force-unwrap operator (postfix `!` ) meets the definition of memory safety by trapping at runtime if the unwrapped optional is `nil` . The standard library also provides the [`unsafelyUnwrapped` property](https://developer.apple.com/documentation/swift/optional/unsafelyunwrapped) that does not check for `nil` in release builds: this does not meet the definition of memory safety because it admits violations of initialization and lifetime safety that could be exploited.


having reference types bybe non-nullable

apple-fcloutier · 2024-10-01T21:52:33Z

visions/memory-safety.md

+
+The rules described above make it possible to detect and report the use of unsafe constructs in Swift.
+
+An `@unsafe` function should be allowed to use other unsafe constructs without emitting any diagnostics. However, there are also library functions that encapsulate unsafe behavior in a safe API, such as the standard library’s `Array` and [`Span`](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0447-span-access-shared-contiguous-storage.md)that are necessarily built from unsafe primitives. Such functions need some way to acknowledge the unsafe behavior while still being considered safe from the outside, such as an `unsafe { ... }` code block or a `@safe(unchecked)` attribute.


Missing space between span link and "that"

Joannis · 2024-10-06T14:49:36Z

visions/memory-safety.md

+* **Lifetime safety** : all accesses to a value are guaranteed to occur during its lifetime. Violations of this property, such as accessing a value after its lifetime has ended, are often called use-after-free errors.
+* **Bounds safety**: all accesses to memory are within the intended bounds of the memory allocation, such as accessing elements in an array. Violations of this property are called out-of-bounds accesses.
+* **Type safety** : all accesses to a value use the type to which it was initialized, or a type that is compatible with that type. For example, one cannot access a `String` value as if it were an `Array`. Violations of this property are called type confusions.
+* **Initialization safety** : all values are initialized property to being used, so they cannot contain unexpected data. Violations of this property often lead to information disclosures (where data that should be invisible becomes available) or even other memory-safety issues like use-after-frees or type confusions.


"Initialized property" is this meant to be "properly"?

Joannis · 2024-10-06T14:58:43Z

visions/memory-safety.md

+```swift
+myInts.withSpan { span in
+  globalSpan = span // error: span value cannot escape the closure
+  print(span[myArray.count]) // runtime error: out-of-bounds access


myArray was probably intended to be myInts

…g proposed

… work Also add a short paragraph on auditability that relates to the above

…the default

rolson · 2024-12-16T21:09:22Z

visions/memory-safety.md

+* **Lifetime safety** : all accesses to a value are guaranteed to occur during its lifetime. Violations of this property, such as accessing a value after its lifetime has ended, are often called use-after-free errors.
+* **Bounds safety**: all accesses to memory are within the intended bounds of the memory allocation, such as accessing elements in an array. Violations of this property are called out-of-bounds accesses.
+* **Type safety** : all accesses to a value use the type to which it was initialized, or a type that is compatible with that type. For example, one cannot access a `String` value as if it were an `Array`. Violations of this property are called type confusions.
+* **Initialization safety** : all values are initialized property to being used, so they cannot contain unexpected data. Violations of this property often lead to information disclosures (where data that should be invisible becomes available) or even other memory-safety issues like use-after-frees or type confusions.


Suggested change

* **Initialization safety** : all values are initialized property to being used, so they cannot contain unexpected data. Violations of this property often lead to information disclosures (where data that should be invisible becomes available) or even other memory-safety issues like use-after-frees or type confusions.

* **Initialization safety** : all values are initialized prior to being used, so they cannot contain unexpected data. Violations of this property often lead to information disclosures (where data that should be invisible becomes available) or even other memory-safety issues like use-after-frees or type confusions.

geoffreygaren · 2025-01-07T23:34:28Z

visions/memory-safety.md

+
+### Expressing memory-safe interfaces for the C family of languages
+
+The C family of languages do not provide memory safety along any of the dimensions described in this document. As such, a Swift program that makes use of C APIs is never fully “memory safe” in the strict sense, because any C code called from Swift could undermine the memory safety guarantees Swift is trying to provide. Requiring that all such C code be rewritten in Swift would go against Swift’s general philosophy of incremental adoption into existing ecosystems. Therefore, this document proposes a different strategy: code written in Swift will be auditably memory-safe so long as the C APIs it uses follow reasonable conventions with respect to memory safety. As such, writing new code (or incrementally rewriting code from the C family) will not introduce new memory safety bugs, so that adopting Swift in an existing code base will incrementally improve on memory safety. This approach is complementary to any improvements made to memory safety within the C family of languages, such as [bounds-safety checks for C](https://clang.llvm.org/docs/BoundsSafety.html) or [C++ standard library hardening](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3471r0.html).


so long as the C APIs it uses follow reasonable conventions with respect to memory safety

Instead of "reasonable conventions", it might be more precise to say "declarable conventions" and also to specify "that are consistent with Swift's approach to memory safety". There exist some C conventions that are arguably reasonable, but also

impractical to declare (e.g. printf); and/or

inconsistent with Swift's view of the universe (e.g. the Boehm Garbage Collector)
Such conventions will remain @unsafe in this proposal, not because they are intrinsically unsafe, but rather because we are unable to represent their notion of safety in a way that Swift can verify.

a Swift program that makes use of C APIs is never fully “memory safe” in the strict sense, because any C code called from Swift could undermine the memory safety guarantees Swift is trying to provide.

I believe the same is true of a Swift program that makes use of Swift APIs, since Swift APIs may internally use unsafe features that undermine memory safety, whether intentionally or accidentally. The same goes for a Swift program that makes use of an OS or a piece of hardware.

I would suggest that the important distinction is something like this: "Though Swift is memory safe by default, a Swift program that makes use of C APIs is not. C APIs do not describe their memory safety invariants, so Swift today must suspend memory safety enforcement when invoking C APIs."

geoffreygaren · 2025-01-07T23:52:29Z

visions/memory-safety.md

+
+* The various `Unsafe` pointer types are the only way to work with contiguous memory in Swift today, and  the safe replacements (e.g., `Span`) are new constructs that will take a long time to propagate through the ecosystem. Some APIs depending on these `Unsafe` pointer types cannot be replaced because it would break existing clients (either source, binary, or both).
+* Interoperability with the C family of languages is an important feature for Swift. Most C(++) APIs are unlikely to ever adopt the safety-related attributes described above, which means that enabling strict safety checking by default would undermine the usability of C(++) interoperability.
+* Swift's current (non-strict) memory safety by default is likely to be good enough for the vast majority of users of Swift, so the benefit of enabling stricter checking by default is unlikely to be worth the disruption it would cause.


Another way to make this point, without predicting that safety by default will prove "good enough" in the end, is: "Many Swift projects contain very little unsafe code, but not zero. A new default could break the build in many projects, causing significant disruption, in exchange for very little net reduction in unsafe code (or none at all, if haggard engineers simply turn off the new default or hastily add @safe(checked) blocks)."

Prospective vision: Optional Strict Memory Safety for Swift

7f9488e

apple-fcloutier reviewed Oct 1, 2024

View reviewed changes

Joannis reviewed Oct 6, 2024

View reviewed changes

rjmccall added vision Prospective vision document LSG Contains topics under the domain of the Language Steering Group labels Nov 13, 2024

DougGregor added 6 commits December 9, 2024 14:48

Switch withSpan example over to the "storage" property currently bein…

1699c5a

…g proposed

Introduce more about lifetimebound and C++

662120e

Be clear about how unsafe { ... } blocks or @safe(unchecked) actually…

347c367

… work Also add a short paragraph on auditability that relates to the above

Add a section on incremental adoption

5a72f8e

Add a section of whether strict memory safety checking should become …

a8a8771

…the default

Add a few notes about ABI stability and interaction with Embedded Swift

50d7211

rolson reviewed Dec 16, 2024

View reviewed changes

geoffreygaren reviewed Jan 7, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Prospective vision: Optional Strict Memory Safety for Swift #2581

Prospective vision: Optional Strict Memory Safety for Swift #2581

DougGregor commented Oct 1, 2024

apple-fcloutier Oct 1, 2024

DougGregor Oct 14, 2024

apple-fcloutier Oct 1, 2024

apple-fcloutier Oct 1, 2024

Joannis Oct 6, 2024

Joannis Oct 6, 2024

rolson Dec 16, 2024

geoffreygaren Jan 7, 2025

geoffreygaren Jan 7, 2025 •

edited

Loading


		Since its inception, Swift has provided memory safety for the first four dimensions. Lifetime safety is provided for reference types by automatic reference counting and for value types via [memory exclusivity](https://www.swift.org/blog/swift-5-exclusivity/); bounds safety is provided by bounds-checking on `Array` and other collections; type safety is provided by safe features for casting (`as?` , `is` ) and `enum` s; and initialization safety is provided by “definite initialization”, which doesn’t allow a variable to be accessed until it has been defined. Swift 6’s strict concurrency checking extends Swift’s memory safety guarantees to the last dimension.

		Providing memory safety does not imply the absence of run-time failures. Good language design often means defining away runtime failures in the type system. However, memory safely requires only that an error in the program cannot be escalated into a violation of one of the safety properties. For example, having reference types by non-nullable by default defines away most problems with NULL pointers. With explicit optional types, the force-unwrap operator (postfix `!` ) meets the definition of memory safety by trapping at runtime if the unwrapped optional is `nil` . The standard library also provides the [`unsafelyUnwrapped` property](https://developer.apple.com/documentation/swift/optional/unsafelyunwrapped) that does not check for `nil` in release builds: this does not meet the definition of memory safety because it admits violations of initialization and lifetime safety that could be exploited.


		The rules described above make it possible to detect and report the use of unsafe constructs in Swift.

		An `@unsafe` function should be allowed to use other unsafe constructs without emitting any diagnostics. However, there are also library functions that encapsulate unsafe behavior in a safe API, such as the standard library’s `Array` and [`Span`](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0447-span-access-shared-contiguous-storage.md)that are necessarily built from unsafe primitives. Such functions need some way to acknowledge the unsafe behavior while still being considered safe from the outside, such as an `unsafe { ... }` code block or a `@safe(unchecked)` attribute.

	* Initialization safety : all values are initialized property to being used, so they cannot contain unexpected data. Violations of this property often lead to information disclosures (where data that should be invisible becomes available) or even other memory-safety issues like use-after-frees or type confusions.
	* Initialization safety : all values are initialized prior to being used, so they cannot contain unexpected data. Violations of this property often lead to information disclosures (where data that should be invisible becomes available) or even other memory-safety issues like use-after-frees or type confusions.


		### Expressing memory-safe interfaces for the C family of languages

		The C family of languages do not provide memory safety along any of the dimensions described in this document. As such, a Swift program that makes use of C APIs is never fully “memory safe” in the strict sense, because any C code called from Swift could undermine the memory safety guarantees Swift is trying to provide. Requiring that all such C code be rewritten in Swift would go against Swift’s general philosophy of incremental adoption into existing ecosystems. Therefore, this document proposes a different strategy: code written in Swift will be auditably memory-safe so long as the C APIs it uses follow reasonable conventions with respect to memory safety. As such, writing new code (or incrementally rewriting code from the C family) will not introduce new memory safety bugs, so that adopting Swift in an existing code base will incrementally improve on memory safety. This approach is complementary to any improvements made to memory safety within the C family of languages, such as [bounds-safety checks for C](https://clang.llvm.org/docs/BoundsSafety.html) or [C++ standard library hardening](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3471r0.html).

Prospective vision: Optional Strict Memory Safety for Swift #2581

Are you sure you want to change the base?

Prospective vision: Optional Strict Memory Safety for Swift #2581

Conversation

DougGregor commented Oct 1, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

geoffreygaren Jan 7, 2025 • edited Loading

Choose a reason for hiding this comment

geoffreygaren Jan 7, 2025 •

edited

Loading