Konfigurer TEE'er til privat LLM-træning lokalt

At vælge den rigtige Trusted Execution Environment (TEE) til lokal træning af store sprog­modeller afhænger af både sikkerhedsniveau, ydelses­krav og tilgængelig hardware. Nedenfor gennemgås de mest udbredte TEE-teknologier og de praktiske krav, du skal have styr på, før du lægger udstyret i indkøbskurven.

1. Sammenligning af tee-teknologier

2. Gpu-beskyttelse

• NVIDIA H100 Confidential Computing (beta): Memory encryption + per-VM keying på H100-SXMz SKUs. Kræver Grace Hopper eller PCIe H100 med GH200 firmware & vGPU 17.3+.
• AMD MI300A/B: Under udvikling; forventes at arve SEV-SNP beskyttelse fra host-CPU over Infinity Fabric.
• Hvis beskyttelse ikke er tilgængelig, anvend data-maskering, split-learning eller hold sensitive pass-through-opgaver på CPU-enclaves.

3. Hardwarekrav

1. CPU
   
   • Intel: Xeon 3.^rd Gen (Ice Lake) eller nyere for SGX; Sapphire Rapids med TDX-event (GELAX) for VM-baseret kryptering.
   • AMD: EPYC 7xx3 (Milan) eller nyere for SEV-SNP; vælg modeller med “P” suffix for maksimal krypteringsnøgler (509 vCPUs).
   • ARM: AmpereOne (v9) eller kommende Neoverse V-serier der annoncerer CCA support.
2. Bundkort & chipset
   
   • Tjek Intel SGX/TDX Whitelist eller AMD Platform Security Feature (PSF) i producentens QVL.
   • PCIe 4/5 lanes nok til både GPU’er og NVMe-drev; kræves for at undgå IOMMU-sharing problemer.
3. BIOS/UEFI-indstillinger
   
   • Aktivér: Intel SGX (eller TDX), AMD SVM, IOMMU, SEV, SME, Secure Boot, fTPM/dTPM.
   • Sæt PrMRR til maks for SGX EPC-størrelse; på AMD - vælg Memory Encryption Mode: SEV-SNP.
   • Firmware opdateres til nyeste AGESA eller Intel MCU for at undgå CVE-låsninger.
4. Microcode & firmware
   
   • Tjek for SGX PSW ≥ 2.18, TDX Module ≥ 1.5 eller SEV-SNP Patch ≥ 0.4.
   • NVIDIA GPU: H100 firmware 94.00.xx.xx med Confidential-CC flag.

4. Os- og hypervisor­understøttelse

• Linux-kerne: 6.1 LTS har komplet SGX-v2, TDX-guest og SEV-SNP mainline. Brug 6.6 LTS for bedre NUMA-splitting.
• KVM: QEMU ≥ 8.1 med -object memory-backend-epc (SGX) eller -object sev-snp-guest.
• Container-runtime: Kata Containers 3.x (SGX, TDX, SNP), Enarx WASI shim, Docker LCOW for WSL2-gæster.
• Distributionsvalg: Ubuntu 22.04.4 LTS (kernel 6.5 HWE) eller Red Hat 9.4 med Confidential Computing Runtimes.

5. Indkøbs- og kompatibilitetsråd

1. Planlæg RAM overhead: SGX reserverer EPC, der ikke kan bruges af OS-et; undgå at køre træning hvis EPC < 64 GB.
2. Match PCIe root-port til TEE: SGX ikke IOMMU-isolerer tilføjede enheder; overvej TDX/SNP ved direkte GPU-passthrough.
3. Vælg NIC’er med TLS offload + DPDK: Krypteret trafik kan ellers blive flaskehals.
4. Test attestationsflow før indkøb: Brug cloud-sandboxes (Azure DCsv3, Google C3D, OCI AMD SNP) for at validere toolchain.
5. Inkludér TPM 2.0 modulet: Kræves af Secure Boot og uafhængig måling af firmware og kernel-image.

Med ovenstående tjekliste minimerer du risikoen for dyre kompatibilitetsfejl og sikrer, at din lokale LLM-træningsklynge er klar til at udnytte TEE’er uden at gå på kompromis med hverken ydelse eller compliance.

Første beslutning handler om, hvor tæt man vil være på den underliggende TEE og hvor meget man vil overlade til en højere abstraheret runtime.

Til en lokal LLM-pipeline er en kombination ofte ideel:

1. Start data-maskering og pre-processing i en SCONE/Gramine enclave for hurtig porting af eksisterende Python-scripts.
2. Kør træningen i en SEV-SNP baseret Confidential VM med GPU-passthrough for maksimal HW-udnyttelse.
3. Pak inferens-servicen i en Enarx-wasmtime container for let deploy til både x86-64 og ARM.

Attestation: Fra silicium til software

Formålet med attestation er at bevise overfor en remote eller lokal policymotor, at din kode kører i den TEE-konfiguration du forventer.

• Intel SGX (DCAP): Via aesmd kontaktes Intel Provisioning Certificate Service for et Quote, signeret af EPID/DCert. Lokalt kan man cache PCK-certifikater for offline-miljøer.
• AMD SEV-SNP: Hypervisor udstiller /dev/sev-guest; et evidence buffer sendes til AMD KDS eller egen verifier. Sørg for at slå RMP-Key-Sharing fra i BIOS for fuld isolation.
• ARM Confidential Compute Architecture (CCA): Bruger Realm attest tokens (RAT), baseret på EAT/JWS. Forvent - endnu - tooling i upstream KVM og i projekt Stratosphere.

Flow i praksis

1. Enclave/VM kalder get_quote() og modtager rå målinger (mr_enclave, mr_signer, firmware-version).
2. Quote sendes til en Remote Attestation Service (f.eks. HashiCorp Vault plugin, AWS KMS External Key Store eller eget Flask-endpoint).
3. Tjenesten validerer certifikatkæden mod producentens Root CA og udsteder en session-nøgle eller unwrap’er en modelcheckpoint-key.

Nøglehåndtering & sealing

• Policy-drevet key release: Udnyt labels som prod/dev, TCBSV og Git commit hash i MRSIGNER til at styre hvilke builds der får adgang.
• Sealing: Brug SGX EGETKEY eller SNP VMPCK0 til at kryptere modelværdier lokalt - kun samme CPU (og firmwareversion) kan dekryptere.
• Krypteret I/O: SCONE FS-Shield eller Gramine’s protected-file system giver transparent AES-GCM på filniveau; til blockdevice-kryptering kan dm-crypt kombineres med LUKS2 + TPM seals.
• S3/MinIO artifact store: Aktivér server-side encryption med en kunde-styret KMS-key, leveret efter attestations-check.

# Eksempel: atesteret nøgleudlevering via VaultVAULT_SNP_ROLE="llm-train-node"QUOTE=$(dd if=/dev/sev-guest bs=4096 count=1 2>/dev/null | base64 -w0)curl -X POST https://vault.local/v1/attest/snp/$VAULT_SNP_ROLE \ -d "{\"evidence\":\"$QUOTE\"}" \ | jq -r '.data.wrapped_key' | base64 -d > model.key

Supply-chain sikring

En TEE giver intet, hvis build-artefakterne er kompromitteret. Følg derfor et SBOM-first princip:

1. Byg container-images i en isoleret CI-runner inden de pakkes til enclave (f.eks. via gramine-sgx-sign).
2. Generér CycloneDX SBOM og underskriv med Sigstore/ cosign. Placér digest + SBOM-hash i enclave manifestet (.mr_enclave).
3. Aktiver reproducible builds (SOURCE_DATE_EPOCH, hermetisk toolchain). Differences i mr_enclave afslører ikke-reproducerbare binære artefakter.
4. Scanner gæstekernen for CVE’er med Trivy/Grype som del af pre-attestation. TCB-SV-versioner outside policy afvises automatisk.

Med ovenstående tiltag kan du trygt udstede nøgler til et build kun når følgende alle matcher:

• Firmware ≥ vendor-defineret minimum
• SBOM-hash = godkendt release-tag
• Attestations-quote validerer mod producentens CA og din lokale policy

Opsummering

Ved at kombinere modne LibOS’er og Confidential VMs, et robust attestation-flow og policy-styret nøgleudlevering, kan en lokal LLM-træningsklynge opnå næsten samme sikkerhedsniveau som cloud-tilbud - uden at kompromittere hverken ydeevne eller udvikleroplevelse.

Følgende referencearkitektur samler de bedste praksisser til at køre et privat, lokalt LLM-setup i en Confidential Computing-kontekst. Eksemplet kan skaleres fra én workstation til en lille on-prem-klynge (4-8 noder) uden at ændre de grundlæggende byggesten.

1. Komponentoversigt

2. Pipeline-flow (e2e)

1. Dataklargøring i enclave
   
   • Rå datasæt indlæses krypteret (age/ChaCha20) fra en S3-kompatibel bucket.
   • Gramine-baseret data-prep enclave udfører:
     - PII-detektion (presidio)
     - Maskering (faker), tokenisering (tiktoken)
     - Optional: Differential Privacy (Opacus-noise) eller syntetisk data-augmentering (GPT-fw-based)
   • Output skrives til et krypteret tmpfs mount (/encrypted_buf), derefter til MinIO bucket m/ server-side SSE-KMS.
2. Træningsorkestrering
   
   • I single-node køres docker compose med Kata Confidential Containers som runtime; i klynge anvendes kubernetes Jobs + Ray cluster.
   • GPU-passthrough:
     • AMD SEV-SNP & NVIDIA H100 CC kræver vfio-pci binding + attesteret driver (nvidia-modprobe --secureboot-on).
     • SR-IOV panorama: Hver virtuel GPU (vGPU) gives til Ray-worker-pod med topologyKeys for NUMA-optimering.
   • LLM trænes i pytorch 2.3 + DeepSpeed eller Megatron-LM inde i en Gramine-wrapper, som linker til GPU biblioteker via /dev/accel proxy.
3. Krypterede checkpoints
   
   • DeepSpeed aktiverer checkpoint_secure=gruut (custom hook) så model-vægte AES-GCM-krypteres med node-specifik KEK (hentet fra HashiCorp Vault gennem SEV-attestation).
   • Ved multi-node uploades checkpoints til Artifact Store (Harbor OCI registry) som layers signeret med Cosign + Rekor transparency log.
4. Evaluering & inferens
   
   • Eval-jobs kører i lettest mulige enclave (debug-stripped, kun læseadgang).
   • Inferens-API eksponeres som /v1/generate via Enarx Keep med mutual-TLS; token → prompt sendes i proto-buf, svar returneres direkte fra enclave for at undgå sidekanaler.
   • Eventuel kvantisering (bitsandbytes.int4) sker i separat quantize pod for at spare DRAM-footprint.

3. Ci/cd & supply-chain

• Kildekoden lever i et isoleret Repo med GitLab Protect-Branches og pre-commit SBOM-scanning (Syft/Grype).
• Build-jobs bruger reproducible builds (Deterministic pip wheel --no-binary :all: + Bazel remote cache).
• Når en container er bygget, kører Remote Attestation (SEV-SNP Report → OCA) og build-pipeline aborterer hvis målinger ikke matcher EXPECTED_MRENCLAVE.

4. Observability

• Metrics: En attesteret Prometheus exporter (otel-collector-cc) scrapes GPU/CPU & memory counters via vSocket, så alle målinger er forseglet i transit.
• Logs: Gramine sender stdout/stderr til /dev/ttyS0; en serial-tap sidecar forwarder til Loki efter at have tilføjet attestation hash i hver log-linje.
• Tracing: OpenTelemetry spans pakkes med nonce + MAC for at afvise replay-angreb.

5. Privacy-enhancing techniques

• Differential Privacy: Vælg epsilon=8, delta=1e-5 for sprogdata - valideres automatisk i CI via unit-tests (Opacus budget-tracker).
• Syntetisk data: En mindre foundation-model (GPT-J-6B) kører i egen enclave til at generere semi-syntetiske prompts, som udvides med privacy filters før de gemmes i versionsstyret datasæt.
• Access control: Vault udsteder tidsbegrænsede wrapped tokens; kun enclaves med gyldig måle-hash kan åbne nøglerne (Vault recovery mode disabled).

6. Hurtig tjekliste til implementering

1. Opdater BIOS & AGESA til seneste SEV-SNP enablede release.
2. Verifier SNP Policy=0x1F (allow debug=false).
3. Installer amd-sev-tool og kør validate_quote.
4. Aktivér SR-IOV på H100: echo 16 > /sys/bus/pci/devices/0000:82:00.0/sriov_numvfs.
5. Brug Kata 3.4+ med confidential-guest template.
6. Konfigurer Ray head-node med --block + --disable-tui (mindsker side-channel).
7. Sæt deepspeed_zero_stage=2 og gradient_accumulation_steps efter GPU-VRAM.
8. Verificér at Vault transit/rewrap virker efter genstart.

Med denne arkitektur kan organisationer træne og køre nyere sprogmodeller på følsomme, proprietære datasæt uden at kompromittere hverken ydeevne eller juridiske forpligtelser.

Husk: GPU-baserede LLM’er flytter den kritiske flaskehals fra CPU-kryptering til PCIe-roundtrips. NVIDIA H100 Confidential Computing (beta) kræver SR-IOV + IOMMU-pass-through og reducerer overhead til <5 %.

Typiske fejl og debugging uden datalækage

1. Enclave-initialiseringsfejl
   Symptom: SGX_ERROR_INVALID_ENCLAVE/TDVF: VM launch failed.
   Løsning: Tjek BIOS-flags (SGX/TDX Enable, MAX Mode), microcode-version og signer-hash. Brug sgx-detect eller sevctl til at validere platformen.
2. Attestations-afvisning
   Symptom: KMS returnerer 401 / QE_ID_MISMATCH.
   Løsning: Roter root-certifikat, kontroller TCB-komponenter via get-supported-tcb. Brug blind quotes hvis service ikke må kende CPU-serienummer.
3. EPC out-of-memory under træning
   Debug-strategi: Eksportér kun aggregerede metrics (step_loss, EPC_hit_rate) i attestert Prometheus-format. Undgå rå gradient-dump.
4. GPU-passthrough time-outs
   Tip: Aktivér pci=realloc og tilføj GPU’en til samme IOMMU-gruppe som enclaven; ellers foretages DMA-abort som tæller som sikkerhedsbrud og lukker VM’en.

Til step-for-step debugging anbefales Gramine-Debug Mode eller SCONE Hardware DB, hvor logkryptering kun kan dekrypteres af udviklerens dekrypteringsnøgle, aldrig på produktion.

Patch- & sårbarhedshåndtering

• Følg altid Intel PSIRT/AMD SEV advisory RSS-feeds. Sikkerhedsrettelser kræver ofte re-signering af enclaves (mrEnclave ændres).
• Automatisér gen-attestation i CI/CD: Nye QE/TEE-certifikater trigger GitHub Action der bygger SBOM, kører reproducible build og offentliggør nyt mrenclave.txt.
• Brug live migration af Confidential VMs til at opnå “zero-downtime” ved kernel-patches; kræver AMD SEV-SNP vTOM eller Intel TDX 1.5.

Backup, genopretning & driftssikkerhed

• Krypterede checkpoints
  Mønster: Checkpoint → tar → LUKS2 container i enclaven → streaming upload til S3 kompatibel storage.
  Nøgleflow: Session-key for hver epoch forsegles (SGX sealing / SNP VMSave) og placeres i HashiCorp Vault med lease ttl = epoch’s varighed.
• Disaster Recovery
  Replicer både krypterede artefakter og measurement metadata til off-site. Ved restore skal TCB-niveau matche eller overstige originalt niveau; ellers kræves nøgle-re-wrap.
• Driftssikkerhed
  
  • Health-checks via Remote Attestation Service; restart pods hvis quote udløber.
  • Overvåg enclavens temperatur & power-throttling (RAPL counters) for at minimere performance variance.

Compliance: Gdpr, iso 27001 & nis2

• Verificér at BIOS/UEFI kører seneste microcode; lav hash-baseline af firmware.
• Kør sgx-auto-update/amd-sev-firmware.sh som systemd-timer.
• Stress-test enclaven med syntetisk data (Fake Data Generator) for at sikre, at metrics ikke afslører persondata.
• Dokumentér SBOM + attestation evidence i dit Change Management-system.
• Planlæg årlig key-rotation drill inkl. recovery fra cold-storage.

Typiske pitfalls: Overse gästens NUMA-topologi, glemme at opdatere QE-certifikatkæde, eller at logge klartekst-fejlbeskeder fra biblioteket libtorch udenfor enclaven.