Skip to content

Add C++ mbedTLS server-auth TLS enclave sample - #203

Merged
Branden Bonaby (bbonaby) merged 3 commits into
mainfrom
user/gudge/tls-samples/cpp-sample-1
Aug 3, 2026
Merged

Add C++ mbedTLS server-auth TLS enclave sample#203
Branden Bonaby (bbonaby) merged 3 commits into
mainfrom
user/gudge/tls-samples/cpp-sample-1

Conversation

@MGudgin

Copy link
Copy Markdown
Member

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:

  • Shared TlsTransport.edl contract: a run-to-completion TlsSample_RunScenario export plus a TlsSample_GetScenarioMetadata query, with untrusted HostTcp* transport callbacks.
  • The 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
Generated-with: claude-opus-4.8

Gudge (MGudgin) added a commit that referenced this pull request Jul 11, 2026
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
Gudge (MGudgin) added a commit that referenced this pull request Jul 11, 2026
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
Gudge (MGudgin) added a commit that referenced this pull request Jul 11, 2026
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
@MGudgin
Gudge (MGudgin) changed the base branch from main to user/gudge/fix-ci-ltcg-crash July 11, 2026 05:12

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.edl host↔enclave ABI with a run-to-completion TlsSample_RunScenario entrypoint 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.

Comment thread SampleApps/Tls/Scripts/Remove-TrustedSigningCert.ps1
Comment thread SampleApps/Tls/Cpp/TlsHost/main.cpp
Comment thread SampleApps/Tls/Cpp/Common/TlsMbedTlsDriver.cpp
Comment thread SampleApps/Tls/Cpp/TlsEnclave/Generate-ScenarioPolicy.ps1
Gudge (MGudgin) added a commit that referenced this pull request Jul 15, 2026
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>
@MGudgin
Gudge (MGudgin) force-pushed the user/gudge/tls-samples/cpp-sample-1 branch from 9a649dd to 3fcc6ca Compare July 15, 2026 00:46
Comment thread SampleApps/Tls/Cpp/Common/TlsMbedTlsDriver.h
Comment thread SampleApps/Tls/Cpp/TlsEnclave/packages.config
Comment thread SampleApps/Tls/Cpp/TlsEnclave/TlsEnclave.vcxproj
@bbonaby

Copy link
Copy Markdown
Contributor

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.

@MGudgin
Gudge (MGudgin) changed the base branch from user/gudge/fix-ci-ltcg-crash to main July 31, 2026 23:19
Gudge (MGudgin) and others added 2 commits July 31, 2026 16:32
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
@MGudgin
Gudge (MGudgin) force-pushed the user/gudge/tls-samples/cpp-sample-1 branch from 1358f89 to a181aba Compare July 31, 2026 23:32
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
Copilot AI review requested due to automatic review settings August 1, 2026 00:04

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Review details

Suppressed comments (5)

SampleApps/Tls/TestServer/Start-TestServer.ps1:50

  • Start-Process joins an ArgumentList array into one command line without adding per-item quoting. Consequently, the default child launch misparses -File and certificate paths whenever the repository path contains spaces. Quote/escape the path-valued arguments before passing them, or launch via ProcessStartInfo.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* and SHA256.HashData APIs 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 EnsureMbedTlsSource only fails with instructions to run Fetch-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-7 states that every enclave .cpp must include wil_for_enclaves.h first; including windows.h directly 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

@bbonaby
Branden Bonaby (bbonaby) merged commit 93e77a3 into main Aug 3, 2026
16 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants