Skip to content

Update memory-safety with known issues #364

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
agocke wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Update memory-safety with known issues #364

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
9c98515
Update memory-safety with known issues
agocke Mar 25, 2026
129b748
Update accepted/2025/memory-safety/caller-unsafe.md
agocke Mar 25, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion accepted/2025/memory-safety/caller-unsafe.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -156,7 +156,9 @@ According to the above definition, there are two valid constructors: the explici

These data races are considered fundamental to the .NET type system. The safe subset of C# does not protect against them.

- Resource lifetime. Some code patterns, like object pools, require manual lifetime management. When this management is done incorrectly bad behaviors can occur, including improper memory reuse. Notably, none of those behaviors include invalid memory access, although it can include symptoms that look like memory corruption. Because invalid memory access is not possible, this is considered safe.
- Resource lifetime. Some code patterns, like object pools, require manual lifetime management. When this management is done incorrectly bad behaviors can occur, including improper memory reuse. Notably, none of those behaviors include invalid memory access, although it can include symptoms that look like memory corruption. Because invalid memory access is not possible, this is considered safe. Any resource lifetime issues that can cause invalid memory access _are_ considered unsafe.
Copy link
Copy Markdown
Member

@jkotas jkotas Mar 25, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I disagree with this position.

If we are not going to address memory safety issues of the global ArrayPool in this project, we have failed.


Copy link
Copy Markdown
Member

@jkotas jkotas Mar 25, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Mutable global state in .NET makes it possible to create APIs that are prone to produce symptoms identical to memory corruptions caused by lifetime management bugs in user code. `ArrayPool<byte>.Shared` is the prime example of such API. Even though API implementation may be 100% safe code, we will take a discretion to mark such APIs in core libraries as unsafe and propose safe alternatives to replace the most common usage patterns.

This is my counterproposal.

Copy link
Copy Markdown
Member Author

@agocke agocke Mar 25, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not adjust our safety rules to include memory reuse from ArrayPool? That is, rather than create an exception for ArrayPool without putting it in the rules, I'd be OK just putting the ArrayPool approach in our rules directly.

Copy link
Copy Markdown
Member

@danmoseley danmoseley Mar 25, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just curious what would be a safe alternative? Isn't the issue fundamental to array pooling, the caller may return and continue use?

Copy link
Copy Markdown
Member

@jkotas jkotas Mar 26, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just curious what would be a safe alternative?

There are common patterns that we can introduce safe alternatives for. A local scratch buffer pattern is the prime example (dotnet/runtime#52065).

Copy link
Copy Markdown
Member

@jkotas jkotas Mar 26, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not adjust our safety rules to include memory reuse from ArrayPool?

We have more global pool-like APIs. For example, System.Runtime.InteropServices.GCHandle. It happens to be implemented in C++, but it would be possible to re-implement it in safe C# and ensure that accessing the handle does not ever perform invalid memory access even when user code has use-after-free or double-free bugs. A safe implementation like that would not move the needle on GCHandle safety. It would be as unsafe as it is today.

Copy link
Copy Markdown
Member

@jkotas jkotas Mar 26, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The problematic API pattern is: Global, typically low-level, API with manual lifetime management, that many higher-level components depend on.

- Reflection. Reflection is a known hole in the current unsafe model. Reflection can be used to call unsafe methods or access unsafe properties without the reflection code containing any unsafe blocks. A simple solution to close this hole would be to mark reflection invoke APIs as unsafe. We believe that doing so would be too difficult to adopt in user code. This may be addressed in a future proposal.

### Evolution

Expand Down
Loading