原生C++代码能否越界读写C#托管内存？如何防范？

为什么未标记unsafe却存在内存风险？ #

C#的unsafe关键字仅用于标记托管代码内直接操作指针的场景，但P/Invoke和C++/CLI本质是跨边界调用原生代码——这部分完全不受C#编译器的安全检查约束。

原生代码运行在同一进程的非托管执行环境中，能直接访问进程地址空间内的所有内存（包括托管堆）。CLR的内存防护机制只针对托管代码生效，一旦你把托管内存的指针传递给原生代码，就等于绕过了CLR的防护，原生代码的越界读写自然不会被拦截，甚至不会立刻触发错误（比如越界到未被使用的内存区域时）。

为什么相关资料很少提及这个问题？ #

这属于原生代码集成的固有风险，是所有托管语言调用原生代码都会面临的共性问题，并非C#独有。大部分教程聚焦于“如何实现跨语言调用”，而非“如何防范原生代码的错误/恶意操作”——毕竟开发者在决定使用原生交互时，就默认需要承担原生代码不受托管环境约束的风险。

防范这类问题的可行方法 #

1. 内存隔离（最可靠方案） #

避免直接传递托管内存指针给原生代码，改用内存拷贝的方式：

• 在原生代码中分配非托管内存，将托管数据拷贝至该区域，操作完成后再将结果拷贝回托管内存。
• 或在托管侧用Marshal.AllocHGlobal分配非托管内存，同样通过拷贝传递数据。
  这种方式让原生代码只能操作隔离的非托管内存，完全无法触及托管堆。

2. Windows平台的内存页保护 #

利用Windows的VirtualProtect API修改内存页的保护属性：

• 在传递托管内存指针前，先用GCHandle.Alloc固定该内存（避免GC移动），再调用VirtualProtect将对应内存页设为PAGE_READONLY。如果原生代码尝试写入，会直接触发访问违规（Access Violation），终止非法操作。
• 注意：这种方式有一定性能开销，且只能针对特定内存段，无法全局禁止原生代码访问托管内存。

3. 代码层面的约束 #

• 最小化权限：只给原生代码传递必要的内存范围，避免传递大段托管内存指针。
• 校验操作结果：在托管侧检查原生代码写入的数据长度是否符合预期，及时发现越界行为。
• C++/CLI场景下，优先使用安全的托管类型（如array<T>）交互，而非直接传递原生指针。

总结 #

C#的内存防护是针对托管代码的设计，原生代码作为进程内的“不受控模块”，天然具备访问进程内所有内存的能力——这不是C#的设计缺陷，而是原生交互的必然代价。想要兼顾性能与安全，内存隔离+必要的权限限制是最有效的方案，不要依赖CLR的防护机制来约束原生代码。

内容的提问来源于stack exchange，提问作者emmenlau