sgx enclave 中禁用 stl 和标准 c++ 运行时，因缺乏 os 服务、堆管理及系统调用；须用 sgx_tstdc/sgx_tcxx、启用堆支持、安全字符串操作及 trusted 头文件。
enclave 里不能用 STL 和标准 C++ 运行时
SGX enclave 的内存是受 CPU 硬件保护的，但它的运行环境极度受限：没有操作系统服务、无动态链接、无堆管理（默认）、无信号、无系统调用。这意味着 std::string、std::vector、new、malloc（除非显式启用堆支持）、甚至 printf 都直接报错或崩溃。
实际写代码时，常见错误现象是编译能过，但运行时报 Enclave call failed: 0x2004 或直接 segfault —— 很大概率是某处偷偷调用了 libcxx 或 glibc 的符号。
- 必须用 Intel 提供的
sgx_tstdc（而非libc）和sgx_tcxx（极简 C++ 支持，仅含operator new声明，不提供实现） - 若要用
new，得在 Enclave.config.xml 中开启堆支持：<heapsize>0x100000</heapsize>，并链接sgx_tstdc.a+sgx_tcrypto.a - 字符串操作优先用
char[]+strncpy_s（带 _s 的安全版本）、memcmp，避免std::string::compare - 所有头文件路径需指向 SGX SDK 的 trusted 版本，例如：
#include <trts.h></trts.h>，不是<thread></thread>或<mutex></mutex>
如何安全地在 enclave 内做加密和密钥操作
SGX 不自动保护密钥 —— 密钥一旦进 enclave，就只靠 EPC 内存隔离。但开发者常误以为“进了 enclave 就万事大吉”，结果在代码里硬编码密钥、或从 untrusted 区域直接 memcpy 密钥进来，导致侧信道泄露或越界读取。
典型错误现象：enclave 初始化成功，但解密失败返回 SGX_ERROR_INVALID_PARAMETER；或者用 sgx_read_rand 生成的随机数重复（因未正确初始化 RNG）。
- 密钥绝不能写死在源码里，应通过
sgx_create_report+ remote attestation 后由外部可信方安全注入 - 使用
sgx_aes_ctr_encrypt/sgx_aes_gcm_encrypt时，注意 IV/nonce 必须唯一且不可复用；GCM 模式下 AAD 长度不能超 16 字节 -
sgx_read_rand是 enclave 内唯一安全的随机源，但首次调用前需确保 enclave 已完成初始化（即已执行完sgx_create_enclave并进入ecall） - 敏感数据（如密钥缓冲区）建议用
memset_s清零，而不是memset（后者可能被编译器优化掉）
ecall/ocall 传参必须严格校验边界和所有权
ECALL 是 untrusted app 调用 enclave 的入口，OCALL 是 enclave 主动回调 untrusted 的出口。两者之间传递指针时，SGX SDK 默认不做内存拷贝 —— 它只验证地址是否在 untrusted 区域内，**不验证内容合法性**。这就成了绝大多数 buffer overflow 和 use-after-free 的根源。
常见错误现象：enclave 内对传入的 char* 调用 strlen 卡死、或访问到非法地址触发 SGX_ERROR_INVALID_ENCLAVE；OCALL 回调后 untrusted 端释放了内存，enclave 还在用原指针。
- 所有 ecall 参数中带指针的字段，必须在 EDL 文件里用
in/out/user_check显式标注；涉及长度的参数（如len）必须与指针参数配对，并在 enclave 函数开头用sgx_is_within_enclave或sgx_is_outside_enclave手动校验范围 - 不要在 ocall 中长期持有 untrusted 返回的指针；如需缓存，必须用
malloc在 enclave 内重新分配并 memcpy - EDL 中避免裸指针，优先用
size_t len+unsigned char data[len]结构体方式传二进制块 - ocall 函数签名必须与 untrusted 端完全一致，包括调用约定（
__cdecl），否则栈会被破坏
调试时别信日志，用 sgx_step_into_enclave + GDB 真机单步
你在 enclave 里插 printf 或 std::cout，要么不输出，要么 crash；加断点发现根本停不住；用 sgx_print_log 又只能看到有限几条。这不是你代码的问题，是 SGX 调试模型本身就不支持常规日志流。
真实调试场景下，90% 的“逻辑正确但行为异常”问题，都出在内存视图错位、EDL 类型映射偏差、或 ocall 返回值未检查上 —— 这些只有单步才能定位。
- 必须用 Intel 提供的
sgx-gdb（非系统自带 gdb），启动时加--ex "set follow-fork-mode child"，并在 ecall 入口处下断点：b ecall_myfunc - 在 GDB 中用
info registers查看rbp/rsp是否落在 EPC 地址范围内（通常 0x7f0000000000+） - 检查 EDL 生成的头文件（如
enclave_u.h），确认你调用的函数名和参数顺序与自动生成的 stub 完全一致 —— 手动改名或重排参数会导致静默错位 - Release 模式下调试几乎无效；务必用
Debug配置编译 enclave，并关闭 LTO 和部分优化（-O0 -g3）
最麻烦的从来不是写错算法，而是把一个本该在 untrusted 端做的 base64 解码，硬塞进 enclave 里用没链接的 libb64 —— 这类依赖链断裂，在编译期无声无息，运行期才爆 undefined symbol。得一层层查 readelf -d enclave.so 输出里的 NEEDED 条目。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
