Add C++ mbedTLS server-auth TLS enclave sample - #203
Conversation
This PR fixes the `cpp_ci` build failures by pinning the C++ CI jobs to the `windows-2022` runner image (Visual Studio 2022 / v143 toolset) instead of `windows-latest`. The `windows-latest` image migrated to Visual Studio 2026 (v18) in mid-June 2026. That image does not reliably provide the `v143` (VS2022) build tools that every project in the repo pins, so builds intermittently fail with `MSB8020: The build tools for Visual Studio 2022 (Platform Toolset = 'v143') cannot be found`; on runs where a v143 project did link, the VS2026 LTCG backend intermittently crashed with `LNK1257: code generation failed`. Both symptoms are the same root cause (the runner image change), which is why they appeared on unrelated, content-free PRs (#203, #204) at the same time. Details * `.github/workflows/cpp_ci.yml`: change all three jobs (build-edl-code-gen, run-edl-code-gen-tests, build-sdk) from `runs-on: windows-latest` to `runs-on: windows-2022`, with a comment explaining the pin. * Reverts the earlier `Directory.Build.targets` full-LTCG override, which targeted the `LNK1257` symptom rather than the underlying image migration and is unnecessary on the pinned VS2022 image. Tests * Confirmed from CI logs that failing jobs resolved to VS2026 (`...\Microsoft Visual Studio\18\Enterprise\...`, MSBuild 18.7.8) and that passing runs used the `v170` (v143) targets, while failing runs used the `v180` targets and reported MSB8020 for v143. * `windows-2022` remains a GitHub-supported runner image that ships VS2022 / v143, so it deterministically provides the pinned toolset. * Validated cpp_ci.yml is well-formed YAML. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 515cf42c-8709-4378-9d8a-8680e03acd18
This PR fixes the `cpp_ci` build failures by pinning the C++ CI jobs to the `windows-2022` runner image (Visual Studio 2022 / v143 toolset) instead of `windows-latest`. The `windows-latest` image moved to Visual Studio 2026 (v18), which does not reliably provide the `v143` (VS2022) build tools that every project in the repo pins, so builds intermittently fail with `MSB8020: The build tools for Visual Studio 2022 (Platform Toolset = 'v143') cannot be found`; on runs where a v143 project did link, the VS2026 LTCG backend intermittently crashed with `LNK1257: code generation failed`. Both symptoms share the same root cause (the runner image change), which is why they appear on unrelated, content-free PRs (#203, #204). Details * `.github/workflows/cpp_ci.yml`: change all three jobs (build-edl-code-gen, run-edl-code-gen-tests, build-sdk) from `runs-on: windows-latest` to `runs-on: windows-2022`, with a comment explaining the pin. * Drops the `Directory.Build.targets` full-LTCG override in favor of the runner pin, since it targeted the `LNK1257` symptom rather than the underlying image migration and is unnecessary on the pinned VS2022 image. Tests * Confirmed from CI logs that failing jobs resolved to VS2026 (`...\Microsoft Visual Studio\18\Enterprise\...`, MSBuild 18.7.8): failing runs used the `v180` targets and reported MSB8020 for v143, while passing runs used the `v170` (v143) targets. * `windows-2022` is a GitHub-supported runner image that ships VS2022 / v143, so it deterministically provides the pinned toolset. * Validated cpp_ci.yml is well-formed YAML. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 515cf42c-8709-4378-9d8a-8680e03acd18
This PR fixes the `cpp_ci` build failures by pinning the C++ CI jobs to the `windows-2022` runner image (Visual Studio 2022 / v143 toolset) instead of `windows-latest`. The `windows-latest` image moved to Visual Studio 2026 (v18), which does not reliably provide the `v143` (VS2022) build tools that every project in the repo pins, so builds intermittently fail with `MSB8020: The build tools for Visual Studio 2022 (Platform Toolset = 'v143') cannot be found`; on runs where a v143 project did link, the VS2026 LTCG backend intermittently crashed with `LNK1257: code generation failed`. Both symptoms share the same root cause (the runner image change), which is why they appear on unrelated, content-free PRs (#203, #204). Details * `.github/workflows/cpp_ci.yml`: change all three jobs (build-edl-code-gen, run-edl-code-gen-tests, build-sdk) from `runs-on: windows-latest` to `runs-on: windows-2022`, with a comment explaining the pin. Tests * Confirmed from CI logs that failing jobs resolved to VS2026 (`...\Microsoft Visual Studio\18\Enterprise\...`, MSBuild 18.7.8): failing runs used the `v180` targets and reported MSB8020 for v143, while passing runs used the `v170` (v143) targets. * `windows-2022` is a GitHub-supported runner image that ships VS2022 / v143, so it deterministically provides the pinned toolset. * Validated cpp_ci.yml is well-formed YAML. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 515cf42c-8709-4378-9d8a-8680e03acd18
There was a problem hiding this comment.
Pull request overview
Adds a new C++ VBS enclave TLS sample that terminates a TLS 1.3 client (mbedTLS) inside VTL1 while VTL0 only provides TCP transport callbacks, plus a deterministic local TLS test server and supporting build/signing tooling and documentation.
Changes:
- Introduces a shared
TlsTransport.edlhost↔enclave ABI with a run-to-completionTlsSample_RunScenarioentrypoint plus scenario metadata query. - Adds the C++ sample implementation (host + enclave + mbedTLS driver/config) including certificate-pin generation and enclave signing/VEIID steps.
- Adds a local TLS 1.3 test server, certificate generation scripts, and documentation/NOTICE/gitignore updates.
Reviewed changes
Copilot reviewed 23 out of 24 changed files in this pull request and generated 4 comments.
Show a summary per file
| File | Description |
|---|---|
| SampleApps/Tls/TlsTransport.edl | Defines the shared trusted/untrusted ABI for the TLS samples. |
| SampleApps/Tls/TestServer/Start-TestServer.ps1 | Implements the deterministic local TLS 1.3 test server. |
| SampleApps/Tls/TestServer/README.md | Documents test-server usage and prerequisites. |
| SampleApps/Tls/TestServer/generate-test-certs.ps1 | Generates self-signed server/client certs for local testing. |
| SampleApps/Tls/Scripts/Remove-TrustedSigningCert.ps1 | Removes the sample signing cert trust/install artifacts. |
| SampleApps/Tls/Scripts/Add-TrustedSigningCert.ps1 | Creates/trusts a self-signed enclave signing certificate. |
| SampleApps/Tls/README.md | Documents sample layout and end-to-end build/run steps. |
| SampleApps/Tls/Fetch-MbedTls.ps1 | Fetches a pinned mbedTLS commit into a git-ignored folder. |
| SampleApps/Tls/Cpp/TlsHost/TlsHost.vcxproj | Adds the host app project (EDL binding generation + build settings). |
| SampleApps/Tls/Cpp/TlsHost/packages.config | Declares NuGet deps for the host app (WIL + codegen). |
| SampleApps/Tls/Cpp/TlsHost/main.cpp | Implements the host TCP callbacks and enclave invocation flow. |
| SampleApps/Tls/Cpp/TlsEnclave/TlsEnclave.vcxproj | Adds the enclave DLL project, codegen integration, signing + VEIID steps. |
| SampleApps/Tls/Cpp/TlsEnclave/tls_enclave.cpp | Implements enclave entrypoints and wires transport callbacks into the driver. |
| SampleApps/Tls/Cpp/TlsEnclave/packages.config | Declares NuGet deps for the enclave (WIL + codegen). |
| SampleApps/Tls/Cpp/TlsEnclave/Generate-ScenarioPolicy.ps1 | Generates ScenarioPolicy.g.h with the pinned leaf cert SHA-256 and endpoint metadata. |
| SampleApps/Tls/Cpp/TlsEnclave/dllmain.cpp | Defines enclave image configuration (family/image IDs, policy). |
| SampleApps/Tls/Cpp/Tls.sln | Adds a solution to build the host + enclave sample together. |
| SampleApps/Tls/Cpp/nuget.config | Defines sample-specific package sources and repository path. |
| SampleApps/Tls/Cpp/Common/TlsMbedTlsDriver.h | Declares the enclave-friendly mbedTLS session driver and result types. |
| SampleApps/Tls/Cpp/Common/TlsMbedTlsDriver.cpp | Implements TLS 1.3 handshake, certificate pinning, bounded response consumption, and derived result computation. |
| SampleApps/Tls/Cpp/Common/TlsMbedTlsConfig.h | Configures mbedTLS for enclave constraints (no net/fs/time, etc.). |
| NOTICE.md | Adds third-party notice for fetching/using mbedTLS. |
| docs/TlsEnclaveSamples.md | Adds design/threat-model/staging documentation for TLS enclave samples. |
| .gitignore | Ignores generated pins, fetched mbedTLS source, and generated test certs. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
This PR fixes the `cpp_ci` build failures by pinning the C++ CI jobs to the `windows-2022` runner image (Visual Studio 2022 / v143 toolset) instead of `windows-latest`. The `windows-latest` image moved to Visual Studio 2026 (v18), which does not reliably provide the `v143` (VS2022) build tools that every project in the repo pins, so builds intermittently fail with `MSB8020: The build tools for Visual Studio 2022 (Platform Toolset = 'v143') cannot be found`; on runs where a v143 project did link, the VS2026 LTCG backend intermittently crashed with `LNK1257: code generation failed`. Both symptoms share the same root cause (the runner image change), which is why they appear on unrelated, content-free PRs (#203, #204). ## Details * `.github/workflows/cpp_ci.yml`: change all three jobs (`build-edl-code-gen`, `run-edl-code-gen-tests`, `build-sdk`) from `runs-on: windows-latest` to `runs-on: windows-2022`, with a comment explaining the pin. ## Tests * Confirmed from CI logs that failing jobs resolved to VS2026 (`...\Microsoft Visual Studio\18\Enterprise\...`, MSBuild 18.7.8): failing runs used the `v180` targets and reported MSB8020 for v143, while passing runs used the `v170` (v143) targets. * `windows-2022` is a GitHub-supported runner image that ships VS2022 / v143, so it deterministically provides the pinned toolset. * Validated `cpp_ci.yml` is well-formed YAML. > [!NOTE] > `pull_request` runs use the workflow file from the PR's head branch, so #203/#204 pick up this pin once they are rebased or retargeted onto this branch. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
9a649dd to
3fcc6ca
Compare
|
I'll let you take point on the TLK work and POC stuff. Ping when when you want to get things merged in. I think this branch needs to be retargeted to main. Also I'm experimenting with copilot reviews on Github for this repo and MXC, I have it set to review when new commits come in now that they have apparently improved it to find more things. Feel free to ignore any of them that don't make sense. |
This commit adds a C++ VBS enclave sample that runs a TLS 1.3 client (mbedTLS) entirely inside VTL1 while VTL0 only tunnels transport bytes, so session keys and decrypted server data never leave the enclave and only a bounded, derived result crosses back to the host. Details: - Shared TlsTransport.edl contract: a run-to-completion TlsSample_RunScenario export plus a TlsSample_GetScenarioMetadata query, with untrusted HostTcp* transport callbacks. - TlsEnclave DLL pins the test server's leaf-certificate SHA-256 into the image (ScenarioPolicy.g.h) so VTL0 cannot supply or relax the trust anchor; TlsHost supplies only sockets and drives the enclave. - TLS 1.3 test server with certificate/pin generation and pwsh provisioning, build, and signing scripts; the enclave DLL is VEIID-protected and signed with CN=TlsSampleEnclaveCert. - Requires the v145 platform toolset on VS 18; mbedTLS source is pinned and fetched via Fetch-MbedTls.ps1. - Design and threat-model documentation in docs/TlsEnclaveSamples.md. Test: - Built Debug and Release (x64) with msbuild; both produced a signed TlsEnclave.dll and TlsHost.exe. - Ran the host against the test server for both configurations: status=0, decision=Allow, output_value=1406, tls_version=0x304, cipher_suite=0x1302. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 3f90c337-7087-44f5-98d7-c0534d1f49b1
- TlsHost/main.cpp: add <cstring> and <memory> for std::memcpy/std::unique_ptr instead of relying on transitive includes. - TlsMbedTlsDriver.cpp: reject inputValue * multiplier overflow to match the parse-time overflow policy in ExtractMultiplier. - Generate-ScenarioPolicy.ps1: Dispose the X509Certificate2 after hashing. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 9adf4df7-9bf7-42aa-8eeb-41e289f63413
1358f89 to
a181aba
Compare
This PR changes the TLS sample host to use the shared VBS Enclave SDK lifecycle helpers and documents the session implementation boundary. Details * Add the published SDK package to TlsHost and replace direct enclave create, load, initialize, and cleanup calls with SDK helpers. * Preserve Debug-only enclave inspection and fully initialize the owner ID passed to the SDK. * Explain that TlsSession uses PImpl to hide and own mbedTLS/PSA state. Tests * Built TlsHost for Debug/Release on x64 and ARM64. * Built and signed the full TLS solution for Debug/Release x64; verified both DLL signatures and page hashes. * ARM64 enclave compilation and linking passed, but the x64 host cannot execute the ARM64 veiid.exe post-build tool. * The TLS server health check passed; enclave execution is unavailable on this machine with load error 0x80070241. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: b8216059-5419-451a-8d26-098618e0fd6b
There was a problem hiding this comment.
Review details
Suppressed comments (5)
SampleApps/Tls/TestServer/Start-TestServer.ps1:50
Start-Processjoins anArgumentListarray into one command line without adding per-item quoting. Consequently, the default child launch misparses-Fileand certificate paths whenever the repository path contains spaces. Quote/escape the path-valued arguments before passing them, or launch viaProcessStartInfo.ArgumentList, which preserves argument boundaries.
$process = Start-Process -FilePath (Get-Process -Id $PID).Path -ArgumentList $arguments -WorkingDirectory (Get-Location) -PassThru
SampleApps/Tls/TestServer/README.md:9
- The stated minimum is too low: PowerShell 7.0 runs on .NET Core 3.1, which does not provide the
X509Certificate2.CreateFromPem*andSHA256.HashDataAPIs used by these scripts. Require PowerShell 7.1+ (or a newer supported release) so the documented prerequisite actually runs.
Run these scripts with **PowerShell 7+ (`pwsh`)**; they use .NET APIs (`X509Certificate2.CreateFromPem`, `SHA256.HashData`, PEM export) that are not available in Windows PowerShell 5.1.
SampleApps/Tls/README.md:23
- PowerShell 7.0 uses .NET Core 3.1 and lacks the PEM and static hashing APIs used by the certificate scripts, so
PowerShell 7+is not a sufficient prerequisite. Document 7.1+ (or a newer supported release) here as well.
- Run all sample scripts with **PowerShell 7+ (`pwsh`)** — they use .NET APIs not present in Windows PowerShell 5.1, and the enclave build invokes `pwsh` for its pre-build pin generation and post-build signing.
NOTICE.md:79
- This says mbedTLS is fetched by the build, but
EnsureMbedTlsSourceonly fails with instructions to runFetch-MbedTls.ps1; the build never invokes the fetch script. Describe it as fetched before building so the notice matches the actual setup flow.
The C++ TLS enclave samples (`SampleApps/Tls`) build and statically link Mbed TLS
to terminate TLS inside the enclave. It is fetched at build time by
`SampleApps/Tls/Fetch-MbedTls.ps1` and is not redistributed in this repository.
SampleApps/Tls/Cpp/TlsEnclave/dllmain.cpp:4
- This enclave translation unit bypasses the repository's required enclave header ordering.
tests/EnclaveTests/CodeGenEndToEndTests/TestEnclave/dllmain.cpp:4-7states that every enclave.cppmust includewil_for_enclaves.hfirst; includingwindows.hdirectly omits the enclave-safe setup in this TU. Use the enclave WIL header as the first include (it provides these Windows declarations).
#include <windows.h>
- Files reviewed: 23/24 changed files
- Comments generated: 0 new
- Review effort level: Balanced
This PR adds a C++ VBS enclave sample that runs a TLS 1.3 client (mbedTLS) entirely inside VTL1 while VTL0 only tunnels transport bytes, so session keys and decrypted server data never leave the enclave and only a bounded, derived result crosses back to the host.
The sample deliberately favours simplicity: it shows a single enclave-to-web-server TLS connection end to end. Multi-connection multiplexing is out of scope and belongs in a later sample.
Details:
TlsTransport.edlcontract: a run-to-completionTlsSample_RunScenarioexport plus aTlsSample_GetScenarioMetadataquery, with untrustedHostTcp*transport callbacks.TlsEnclaveDLL pins the test server's leaf-certificate SHA-256 into the image (ScenarioPolicy.g.h) so VTL0 cannot supply or relax the trust anchor;TlsHostsupplies only sockets and drives the enclave.pwshprovisioning, build, and signing scripts; the enclave DLL is VEIID-protected and signed withCN=TlsSampleEnclaveCert.Fetch-MbedTls.ps1.docs/TlsEnclaveSamples.md.Test:
TlsEnclave.dllandTlsHost.exe.status=0,decision=Allow,output_value=1406,tls_version=0x304,cipher_suite=0x1302.Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com
Generated-with: claude-opus-4.8