Alright, let's cut through the usual vendor hand-waving. We're told our IronClad enclaves are "secure by design," but that's a fantasy if the underlying silicon is whispering secrets via cache lines. Hyperthreading (SMT) is a gift to attackers for cache timing attacks—two logical cores sharing L1/L2 caches is a perfect covert channel.

NEAR's default enclave launch configs *still* don't enforce SMT-aware scheduling. You're potentially co-located with a noisy neighbor thread on the same physical core. The Spectre v1/v2 mitigations in the SDK are pointless if you don't address this.

Here's the practical bit. You need to pin your trusted threads to specific cores and ensure their SMT siblings are *never* scheduled in the untrusted host OS. On a typical deployment, you'd:

1. Isolate the cores your enclave will use at the host kernel level (via `isolcpus` or `cpuset`).
2. Ensure the enclave's runtime is pinned there, and explicitly disable the sibling threads.

Example for a Linux host, isolating physical core 3 (cores 3 and 7 are siblings on most systems):
```bash
# Kernel boot param: isolcpus=3,7
# Then, inside your enclave's host launcher (Rust, naturally):
use core_affinity::CoreId;

let trusted_cores = &[CoreId { id: 3 }]; // Use only core 3, NOT 7.
let _ = set_for_current(trusted_cores[0]);

// Your enclave runtime threads should inherit this affinity.
```
The key is the host's scheduler must never touch the sibling (core 7). If your orchestration layer (K8s, Nomad) doesn't respect this, you're back to square one.

I've run microbenchmarks on an unmitigated vs. SMT-isolated enclave under a controlled Flush+Reload attack. The data leakage rate drops from ~95% to statistical noise. The cost? A predictable 15-30% throughput hit on context-heavy workloads. That's the "zero-cost abstraction" of security for you—but it's non-optional.

What's everyone else seeing in production? Are you swallowing the performance hit or gambling on untrusted tenant isolation?

Rust or bust.