Start Date
1-5-2026 12:00 PM
End Date
1-5-2026 1:00 PM
Description
Introduction & Problem Statement
Shared scientific computing platforms are built for speed and utilization, but they create a security problem that isolation alone can't fully solve. Even with TEEs, containers, or a privilege separation in place, the hardware underneath remains a shared resource. Speculative execution, cache contention, interconnect timing, and similar microarchitectural effects can leak information or create integrity risks across protection boundaries without any malicious code involved. For CI operators running graph workloads, HPC kernels, or ML pipelines in co-tenanted systems, the threat is inherent in normal execution. The real question isn't whether these vulnerabilities exist, but it's what kinds of attacks they enable, how serious those attacks are, and exactly where in the program they arise. No tools currently exist to answer those questions at the application level, leaving operators without the tools to make informed security-performance tradeoffs. This project builds an instrumentation-driven framework to change that, structured around three components: workload-grounded vulnerability primitives that characterize recurring microarchitectural attack patterns in scientific applications; an empirical harness that annotates vulnerable regions directly in the program and assigns each a severity classification based on the attacks they enable; and an open reference benchmark suite with decision-support tools for reproducible security-performance tradeoff analysis.
Methods
This project builds an instrumentation-driven framework structured around three components: workload-grounded vulnerability primitives that characterize recurring microarchitectural attack patterns in scientific applications; an empirical annotation harness that instruments program regions directly and assigns each a severity classification — Low, Medium, or Severe — based on the attack class it enables; and an open reference benchmark suite with decision-support tools for reproducible security-performance tradeoff analysis.
The framework decouples program features (e.g., secret-dependent branches, stride-encoded array accesses) from architectural features (e.g., speculative execution depth, cache associativity) to enable generalization across new programs and new hardware. This decoupling is what makes the framework a reusable infrastructure rather than a per-system tool.
Results & Findings
The framework design and early analysis yield three key findings. First, vulnerability severity must be annotated at the region level, not aggregated per program — a single gadget such as the Spectre V1 bounds-check bypass correctly receives a SEVERE classification while surrounding code remains benign, confirming that coarse-grained per-program scoring obscures the actual threat surface. Second, decoupling program features from architectural features is necessary for the framework to generalize: the same secret-dependent branch pattern triggers different severity levels depending on whether the underlying hardware supports speculative execution, making the two dimensions independently meaningful. Third, for the Spectre V1 gadget, LFENCE insertion is the minimum sufficient defense — it eliminates the cache side-channel without the overhead of full hardware isolation via a TEE, demonstrating that the framework can produce targeted, low-cost defense recommendations rather than blanket mitigations.
Microarchitectural Vulnerabilities and Performance Tradeoffs in Shared Scientific Computing
Introduction & Problem Statement
Shared scientific computing platforms are built for speed and utilization, but they create a security problem that isolation alone can't fully solve. Even with TEEs, containers, or a privilege separation in place, the hardware underneath remains a shared resource. Speculative execution, cache contention, interconnect timing, and similar microarchitectural effects can leak information or create integrity risks across protection boundaries without any malicious code involved. For CI operators running graph workloads, HPC kernels, or ML pipelines in co-tenanted systems, the threat is inherent in normal execution. The real question isn't whether these vulnerabilities exist, but it's what kinds of attacks they enable, how serious those attacks are, and exactly where in the program they arise. No tools currently exist to answer those questions at the application level, leaving operators without the tools to make informed security-performance tradeoffs. This project builds an instrumentation-driven framework to change that, structured around three components: workload-grounded vulnerability primitives that characterize recurring microarchitectural attack patterns in scientific applications; an empirical harness that annotates vulnerable regions directly in the program and assigns each a severity classification based on the attacks they enable; and an open reference benchmark suite with decision-support tools for reproducible security-performance tradeoff analysis.
Methods
This project builds an instrumentation-driven framework structured around three components: workload-grounded vulnerability primitives that characterize recurring microarchitectural attack patterns in scientific applications; an empirical annotation harness that instruments program regions directly and assigns each a severity classification — Low, Medium, or Severe — based on the attack class it enables; and an open reference benchmark suite with decision-support tools for reproducible security-performance tradeoff analysis.
The framework decouples program features (e.g., secret-dependent branches, stride-encoded array accesses) from architectural features (e.g., speculative execution depth, cache associativity) to enable generalization across new programs and new hardware. This decoupling is what makes the framework a reusable infrastructure rather than a per-system tool.
Results & Findings
The framework design and early analysis yield three key findings. First, vulnerability severity must be annotated at the region level, not aggregated per program — a single gadget such as the Spectre V1 bounds-check bypass correctly receives a SEVERE classification while surrounding code remains benign, confirming that coarse-grained per-program scoring obscures the actual threat surface. Second, decoupling program features from architectural features is necessary for the framework to generalize: the same secret-dependent branch pattern triggers different severity levels depending on whether the underlying hardware supports speculative execution, making the two dimensions independently meaningful. Third, for the Spectre V1 gadget, LFENCE insertion is the minimum sufficient defense — it eliminates the cache side-channel without the overhead of full hardware isolation via a TEE, demonstrating that the framework can produce targeted, low-cost defense recommendations rather than blanket mitigations.