Clarify properties of memory safety in .NET programs

accepted/2025/memory-safety/caller-unsafe.md

@@ -114,7 +114,7 @@ public sealed class RequiresUnsafeAttribute : System.Attribute
 
 ### Global invariants
 
-Two properties which should always hold in .NET programs are:
+Properties which should always hold in .NET programs are:
 
 * Memory safety
 * No access to uninitialized memory
@@ -184,6 +184,15 @@ The last notable area of impact is source generation. Most users will only see c
 
 One concession we could make to source generation would be to allow more fine-grained enabling and disabling of the warning scope. This proposal does **not** recommend such configuration switches. The `unsafe` feature is specifically designed to catch dangerous situations and source generation does not eliminate that risk. Therefore our recommendation would be to **avoid enabling the feature** until all source generators are updated to produce compatible code.
 
+### Requirements
+
+To uphold the global safety invariants, user code must uphold certain requirements.
+
+In particular, managed references have the following requirements:
+
+- Managed references must be aligned in safe code. Managed refereces are often pinned as unmanaged pointers and passed to native code using C/C++ conventions. C/C++ requires that all pointers are properly aligned, the behavior is undefined otherwise and it can lead to memory safety violations.
+- Managed references may be null, but if they are non-null then they must point to valid memory, _even in unsafe code_. For these purposes, one element past the end of an array is considered valid memory, as is pointing just past the end of the object. Managed references pointing past objects may not be dereferenced in either safe or unsafe code.
+
 ### Examples and APIs
 
 **ArrayPool.Rent**