## What Adds `docs/security-model.md`, a document describing the SDK's security model. The repository previously had no SDK-level security/trust-model documentation — only `SECURITY.md` (a vulnerability-reporting policy) and the README.
## Why SGX development differs from ordinary application development: code is partitioned into an untrusted host and a trusted enclave, and the ECALL/OCALL edge between them is the central security property. A single document that maps this trust model onto the codebase helps both human developers and automated/LLM security reviewers reason correctly — in particular, to focus on the real trust boundary and avoid false positives on code where the concern does not apply. ## Contents `docs/security-model.md` covers: 1. **Trust model** — TCB, adversary capabilities (full untrusted host incl. OS/VMM: arbitrary ECALL arguments, arbitrary OCALL return values, concurrent mutation of untrusted memory), and out-of-scope threats (side channels, speculative execution, availability, sealed-data rollback). 2. **The trust boundary** — the ECALL/OCALL edge; EDL pointer annotations (`[in]`/`[out]`/`[user_check]`/`[size]`/`[count]`) and what they guarantee; the SDK's range checks (`is_within_enclave`/`is_within_host` at `sgx_trts/src/enclave/mem.rs`, the `sgx_is_*` C ABI at `sgx_trts/src/capi.rs`); and the invariants enclave code must enforce (validate `[user_check]` pointers, copy-in to avoid TOCTOU/double-fetch, never trust an OCALL result for a security decision, don't leak via output buffers, fail closed). 3. **Trust-posture map of the repository** — a table mapping each crate to its domain (`sgx_t*` trusted vs. `sgx_u*` untrusted, the feature-split `sgx_crypto`/`sgx_rand`/`sgx_serialize`, shared/FFI, and `sgx_edl` as the boundary contract) and what to scrutinize. 4. **Sealing, attestation, secrets** — `MRENCLAVE` vs `MRSIGNER`, sealed-blob rollback, attestation establishing trust, OCALL results never as a security oracle, SGX-backed randomness. 5. **Dependencies and the supply chain** — every crate linked into the enclave runs inside the TCB and is measured into `MRENCLAVE`; `no_std` vs std-aware (`BUILD_STD`) as a TCB-size decision; build-time codegen/proc-macros affecting the measurement; and vetting recommendations. 6. **Guidance for automated / LLM security review** — where real findings concentrate, expected non-findings (false positives), and an explicit instruction to also review the enclave's dependency tree when tooling allows. Also links the new doc from `SECURITY.md`. This is documentation only; no code or behavior changes. 🤖 Generated with [Claude Code](https://claude.com/claude-code) You can view, comment on, or merge this pull request online at: https://github.com/apache/teaclave-sgx-sdk/pull/470 -- Commit Summary -- * docs: add security model describing the enclave trust boundary and TCB -- File Changes -- M SECURITY.md (7) A docs/security-model.md (341) -- Patch Links -- https://github.com/apache/teaclave-sgx-sdk/pull/470.patch https://github.com/apache/teaclave-sgx-sdk/pull/470.diff -- Reply to this email directly or view it on GitHub: https://github.com/apache/teaclave-sgx-sdk/pull/470 You are receiving this because you are subscribed to this thread. Message ID: <apache/teaclave-sgx-sdk/pull/[email protected]>
