C#无法在SGX Enclave内执行文件I/O，因Enclave无OS支持、无系统调用能力，所有文件操作必须由Untrusted Host通过OCALL代劳，且参数需为POD类型、内存手动管理；.NET库如System.IO会直接导致enclave崩溃。
C# 无法直接在 SGX Enclave 内操作文件——Enclave 是隔离的、无系统调用的执行环境，fopen、CreateFile、FileStream 全部不可用，所有文件 I/O 必须由外部（Untrusted）进程代劳，通过 ECALL/OCALL 严格受控地进出。
为什么 Enclave 里连 System.IO 都会崩溃
SGX Enclave 运行在“无 OS”上下文：没有堆栈映射到用户空间以外的地址、没有 C runtime 的文件句柄表、没有 NT 系统调用入口。任何尝试调用 File.ReadAllText 或 new FileStream 的代码，会在运行时触发 sgx_status_t = SGX_ERROR_ENCLAVE_CRASHED，且不会抛出 .NET 异常，而是直接终止 enclave。
常见错误现象：Enclave initialization failed: SGX_ERROR_OUT_OF_EPC（因链接了不兼容的 CRT）、或更隐蔽的 SGX_ERROR_INVALID_ENCLAVE（因 IL 里隐含了不支持的 API 调用）。
- Enclave 项目必须使用
sgx_urts.lib+sgx_uae_service.lib，不能引用System.IO或System.Runtime.InteropServices中的非白名单类型 - .NET Native AOT 编译（如
Microsoft.NETCore.App.Runtime.win-x64）仍会带入不安全的 P/Invoke，需手动裁剪或改用 C++/C 版本 enclave - Visual Studio 的 “SGX Debug Mode” 不会拦截非法系统调用，只有真机运行或模拟器（
sgx-lkl）才能暴露问题
正确做法：用 OCALL 把文件操作“外包”给 Untrusted Host
文件读写逻辑必须拆成两层：Enclave 内只做加密/解密/校验，所有路径解析、打开、读取、写入、权限检查全交给 host 进程。
典型流程：
- Enclave 内调用
ocall_read_file，传入加密后的文件 ID（如 SHA256(path+nonce)）和缓冲区大小 - Host 收到 OCALL 后，用白名单校验该 ID 是否合法（避免路径遍历），再调用
File.ReadAllBytes读取原始数据 - Host 将明文数据加密（如 AES-GCM）后，连同 tag 一起回传给 Enclave
- Enclave 解密并验证 tag，确认数据未被篡改
注意：ocall_read_file 的参数必须是 POD 类型（如 uint8_t* + size_t），不能传 std::string 或 .NET 对象；C# 侧需用 Marshal.AllocHGlobal 分配非托管内存，并确保生命周期与 OCALL 同步。
C# 侧关键约束：不能用 .NET Core 的 SGX SDK，得靠 native bridge
目前没有稳定、生产可用的纯 C# SGX SDK。微软的 Intel.SGX NuGet 包已归档，sgx-csharp 社区项目仅支持 Linux + Open Enclave，且不兼容 Windows 上的 Intel PSW。
可行路径只有：
- 用 C/C++ 写 enclave（.ec文件）和 untrusted host（.dll/.exe），C# 通过
P/Invoke调用 host 提供的导出函数（如init_enclave、ecall_process_data） - host 层用 C++/CLI 做胶水，把 enclave 的 OCALL 回调暴露为 .NET 事件，C# 订阅处理（但回调函数本身仍不能做 I/O）
- 绝对不要尝试用
AssemblyLoadContext动态加载 enclave 相关 DLL —— EPC 内存页不可执行托管代码
示例片段（C# host 调用）：
IntPtr ctx = ecall_init_enclave();<br>int result = ecall_process_secret(ctx, inputPtr, inputLen, outputPtr, outputLen);其中
ecall_process_secret 是 enclave 定义的 ECALL 函数，它内部绝不能出现 fopen 或 CreateFileA。
容易被忽略的坑：文件完整性 ≠ enclave 安全性
即使你用 OCALL 读了一个“签名过的配置文件”，只要 host 进程被攻破，攻击者就能伪造 OCALL 返回值 —— Enclave 无法区分真实磁盘读取和恶意构造的字节流。
真正能信任的只有三件事：
- Enclave 代码的度量值（MRENCLAVE）是否匹配预期
- OCALL 参数是否经过 enclave 内部校验（比如文件 ID 是否在预注册白名单中）
- 返回数据是否附带由 enclave 密钥签发的 MAC 或加密 tag（不能依赖 host 计算）
换句话说：文件内容本身不是可信源，只是需要被 enclave 处理的“输入载荷”。它的来源合法性、传输完整性、用途边界，全靠 enclave 自己用密码学手段控制。漏掉任意一环，整个安全模型就垮了。
