Isolation Beyond Architectural State: Reasoning About Microarchitectural Leakage Codex (AI) | Commissioned review v1 | 2026-10-22 Architectural isolation and microarchitectural isolation concern different observations. A computation may leave its architectural outputs unchanged while influencing timing or shared resource state. This review relates Spectre, Meltdown, and MI6 to a defensive framework for specifying observers, shared state, and isolation boundaries. A binary-channel model quantifies why noisy observations can still carry information and how repeated independent observations can reduce classification error. The model is intentionally abstract: it contains no exploit procedure and is not a measurement of any processor. We distinguish mitigation of a demonstrated mechanism from a universal noninterference claim, and propose an evaluation protocol that reports hardware configuration, residual sharing, measurement sensitivity, and performance costs together. Isolation depends on what can be observed An architectural access-control rule may prevent a process from reading another process's memory through ordinary instructions. That rule constrains one interface. If execution changes a shared resource whose state affects another process's timing, the second process may obtain information through a different observation. The relevant question is therefore which observations the isolation claim includes. This is a specification issue before it is an implementation issue. A functional test that checks only returned bytes cannot detect an unintended timing dependence. A timing test that inspects one shared structure cannot establish independence of every other structure. A defensible isolation argument identifies the secret, public inputs, permitted outputs, observer capabilities, and resources shared across the boundary. Without that threat model, the word isolated is underspecified. The foundational demonstrations differ Spectre demonstrates that speculative execution can interact with microarchitectural state in ways that undermine intended software isolation. Meltdown demonstrates a distinct failure of isolation on affected implementations through transient behavior around privileged memory access. MI6 explores processor mechanisms for secure enclaves under a threat model that includes an untrusted operating system and microarchitectural observations. These sources establish important mechanisms and design responses, but they are not interchangeable attacks or universal statements about every processor. Historical demonstrations must be tied to the affected models and conditions. The transferable lesson is that architectural rollback or access rejection does not necessarily erase every observation. Our review uses that lesson to build a defensive reasoning framework, not to claim that a particular current machine is vulnerable. References: cs-09-1, cs-09-2, cs-09-3 A two-execution view of confidentiality To express confidentiality, compare two executions with the same public input but different secret values. An ideal noninterference condition requires the observer's permitted trace to be the same, or to have the same distribution in a probabilistic model. This is a relation between executions, not simply a rule about whether one forbidden read succeeds. The trace might include response time, resource occupancy, exceptions, or scheduler-visible events, depending on the threat model. Excluding an observation from the model can make a theorem easier to prove while narrowing its deployment relevance. That does not invalidate the theorem; it changes the statement. A review should make these exclusions explicit and ask whether the excluded observations are actually unavailable to the intended adversary in the real configuration. Noise does not imply absence of information Consider an unbiased secret bit S and an observed bit Y that equals S with probability one minus p and is flipped with probability p. For p between zero and one half, the mutual information is one minus the binary entropy of p. At p equal to one half, the observation is independent of the secret and carries zero information. At p equal to 0.1, it carries approximately 0.531 bits. This binary symmetric channel is an analytical construction. It does not estimate the leakage rate of Spectre, Meltdown, MI6, or any other implementation. Its role is to show why a noisy signal can still be informative. A defense that merely increases measurement variance has not necessarily established a confidentiality property. The effect depends on the residual conditional distributions, available repetitions, and the observer's prior information. Repeated observations can change the conclusion If the same bit is observed through independent channels with identical error probability below one half, a majority vote over an odd number of observations has an error probability given by a binomial tail. For p equal to 0.1 and three observations, that probability is 0.028. The second figure shows this idealized reduction for several error levels. Independence is critical. Correlated noise, a changing secret, observer interference, or rate limits can invalidate the calculation. Conversely, an observer may use a better estimator than majority vote when observations have unequal quality. The model therefore does not provide a universal attack-success formula. It provides a falsifiable warning: a one-shot error rate is insufficient to characterize repeated observation, and a security report should state the allowed repetition budget and dependence assumptions. Mechanism-specific mitigation and structural isolation A mitigation can target a particular instruction sequence, transition, prediction mechanism, or shared resource. Such a measure may be effective for the tested mechanism while leaving another observation path intact. Structural approaches instead attempt to partition or sanitize relevant state across security domains. Their strength depends on the completeness of the resource model. MI6 is useful as a design example because it treats isolation as an architectural and microarchitectural system problem rather than a single local patch. The broader engineering question is which state persists across domain switches and which components remain shared concurrently. A complete answer may require changes in scheduling, memory hierarchy, and transition protocols. The performance cost must be evaluated under the same isolation configuration used for the security argument. References: cs-09-3 A constant-time claim has a scope Source code without secret-dependent branches is not automatically constant time at every observable layer. Memory addresses, compiler transformations, instruction latency, and shared resources may still depend on secret data or interact with it. Conversely, a carefully justified implementation can establish a useful constant-time property under a specific machine and observer model. A review should name that model and preserve the relevant compilation and deployment conditions. The goal is not to demand an impossible statement about every physical phenomenon before accepting software. It is to ensure that the claim being made matches the observations actually controlled. If a library promises only a particular architectural timing discipline, its documentation should not silently imply protection against all co-tenant or physical side channels. Negative results require sensitivity controls Suppose an experiment finds no statistically distinguishable difference between two timing distributions. That result may indicate effective protection, insufficient samples, an insensitive measurement method, or an unsuitable workload. A negative result becomes more informative when the same harness detects a deliberately introduced synthetic dependence of a declared size. The proposed evaluation therefore includes a positive leakage control, a null control, randomized run order, and a predeclared observation budget. It should report confidence intervals or a clearly specified test with multiplicity handled, rather than searching many configurations and presenting only the least distinguishable one. This article does not conduct such a hardware study. Its exact channel calculations instead supply known reference cases with zero, partial, and full information for checking analysis code. Performance and isolation must be measured together A partitioning policy can reduce resource sharing while also changing cache capacity, scheduling flexibility, or utilization. A benchmark that disables the policy for the performance run and enables it for the security run describes two systems. The same issue arises when a mitigation is applied only to some processes or only during selected phases. A useful comparison records hardware and firmware versions, operating-system configuration, compiler options, workload placement, domain-switch frequency, and residual shared resources. It distinguishes median overhead from tail latency and throughput under contention. Those measurements can reveal a practical trade-off, but they do not assign a single numerical value to security. The security claim remains a statement about observations and assumptions, with performance reported for the configuration that satisfies it. Conclusion: protect the observation boundary The principal lesson of microarchitectural leakage research is that an isolation boundary must include the observations available outside it. Correct architectural output is necessary for functional correctness, but confidentiality can fail through a trace that the functional model omits. The channel examples show why adding noise or observing no immediate difference does not by itself establish protection. The literature demonstrates both failure mechanisms and more systematic isolation designs. A rigorous defensive evaluation names the observer, tests the measurement method's sensitivity, accounts for repeated observations, and measures the cost of the exact protection configuration. That is a stronger and more useful claim than an unqualified statement that a process or enclave is isolated. Executed finite checks Enumerated independent binary-channel majority errors 4 assertions passed. A hypothetical noisy-bit channel; no processor attack, exploit or secret collection. { "3": 0.02800000000000001, "5": 0.00856, "7": 0.002728 } Code: analysis/examples.py; results: analysis/example-results.json Equations (1) \mathcal L(O\mid S=s_0,P=p_0)=\mathcal L(O\mid S=s_1,P=p_0) Ideal probabilistic noninterference for observer O and fixed public input P; the permitted observation space must be defined. (2) H_2(p)=-p\log_2p-(1-p)\log_2(1-p) Binary entropy with the continuous convention 0 log 0 = 0. (3) I(S;Y)=1-H_2(p) Unbiased secret bit through a binary symmetric channel with crossover probability p. (4) P_{\mathrm{maj}}(n,p)=\sum_{k=(n+1)/2}^{n}\binom nk p^k(1-p)^{n-k} Odd n independent repeated observations of the same bit; majority-vote error probability, not a measured processor attack rate. Analytical figures Figure 1. A noisy bit can still carry information Uniform secret bit and independent symmetric errors. This hypothetical channel is not a measured processor side channel. figures/microarchitectural-isolation-1.csv Figure 2. Repeated observations can reduce decision error Independent repeated observations of the same bit and majority decoding. Correlated noise and nonstationary secrets invalidate this calculation. figures/microarchitectural-isolation-2.csv Comparison Claim | Necessary scope | Evidence that is insufficient alone Architectural isolation | Allowed instructions and memory accesses | Correct final return values Timing noninterference | Observer and timing model | No branch on a secret in source Mitigation effectiveness | Affected mechanism and configuration | One negative experiment Practical deployment cost | Same protected configuration | Unprotected throughput benchmark Proposed validation protocol 1. Define secrets, public inputs, observer capabilities, and shared resources. 2. List the exact hardware, firmware, compiler, and operating-system configuration. 3. Use null and synthetic-positive controls to validate measurement sensitivity. 4. Predeclare sample counts, repeated-observation budget, and statistical comparisons. 5. Evaluate residual state across transitions and concurrent sharing within the authorized test environment. 6. Measure performance under the exact mitigation and placement policy used for the isolation claim. Limitations 1. The executable calculations model a binary channel and do not implement a hardware side channel. 2. Repeated-observation results assume independent identically distributed errors and a fixed secret. 3. No current processor vulnerability assessment or mitigation benchmark was performed. 4. The three sources are selected historical mechanisms and design work, not a complete modern threat survey. Research questions 1. Which observations remain available across the intended security boundary? 2. Does repeated observation defeat a defense that appears effective in one-shot tests? 3. Are performance and isolation results obtained under exactly the same configuration? Source evidence cs-09-1: Speculative execution can leave microarchitectural effects that violate intended software isolation. Boundary: The demonstrated mechanisms and affected implementations must be distinguished from a universal processor claim. Locator: Abstract and mechanism overview. cs-09-2: Transient behavior on affected implementations can undermine architectural memory isolation. Boundary: The result is specific to affected designs and should not be generalized to every system. Locator: USENIX paper abstract and threat scope. cs-09-3: MI6 explores secure-enclave isolation for a speculative out-of-order processor with an explicit threat model. Boundary: Its modeled resources, implementation, and evaluation conditions remain part of the claim. Locator: Abstract and enclave isolation design. References cs-09-1. Paul Kocher, Jann Horn, Anders Fogh, Daniel Genkin, Daniel Gruss, Werner Haas, Mike Hamburg, Moritz Lipp, Stefan Mangard, Thomas Prescher, Michael Schwarz, Yuval Yarom. Spectre Attacks: Exploiting Speculative Execution. 2019 IEEE Symposium on Security and Privacy (SP) (2019). https://arxiv.org/abs/1801.01203 | DOI: 10.1109/sp.2019.00002 cs-09-2. Moritz Lipp, Michael Schwarz, Daniel Gruss, Thomas Prescher, Werner Haas, Anders Fogh, Jann Horn, Stefan Mangard, Paul Kocher, Daniel Genkin, Yuval Yarom, Mike Hamburg. Meltdown: Reading Kernel Memory from User Space. USENIX Security (2018). https://www.usenix.org/conference/usenixsecurity18/presentation/lipp cs-09-3. Thomas Bourgeat, Ilia Lebedev, Andrew Wright, Sizhuo Zhang, Arvind, Srinivas Devadas. MI6: Secure Enclaves in a Speculative Out-of-Order Processor. Proceedings of the 52nd Annual IEEE/ACM International Symposium on Microarchitecture (2019). https://arxiv.org/abs/1812.09822 | DOI: 10.1145/3352460.3358310 cs-09-1 access: Primary record, abstract and selected accessible text; not an exhaustive full-text or supplementary-material audit. cs-09-2 access: Primary record, abstract and selected accessible text; not an exhaustive full-text or supplementary-material audit. cs-09-3 access: Primary record, abstract and selected accessible text; not an exhaustive full-text or supplementary-material audit. Provenance A focused analytical review of three selected foundational primary sources, with original worked examples. This is not an exhaustive or systematic survey of the literature through 2026. Source access and version notes are recorded with the bibliography. Written and technically self-reviewed by Codex (AI). References identify the original researchers; the analytical constructions and proposed evaluation designs are attributed to this article. Covers are conceptual ImageGen illustrations. Technical figures are computed from declared models or finite examples, with Python and CSV supplied. They are not measurements of deployed products or reproduced performance benchmarks. This local draft has no independent peer-review or journal-acceptance record. Bounded executable examples check the stated small models; they are not formal verification of the cited systems.