Skip to Content
MDPIMDPI

Advanced

InformationInformation
PDF
  • Article
  • Open Access

13 September 2026

23 Pages

Evidence-Carrying Portability Contracts for Compiler Security Instrumentation: Differential Reconstruction of Shadow Call Stack Protocols

,
,
and
1
Faculty of Automatic Control and Computers, National University of Science and Technology POLITEHNICA Bucharest, 060042 Bucharest, Romania
2
Academy of Romanian Scientists, 3 Ilfov Str., 050044 Bucharest, Romania
3
Faculty of Electronics and Telecommunications, National Institute of Innovations in Cybersecurity “CYBERCOR”, Technical University of Moldova, 168 Stefan cel Mare Blvd, MD-2004 Chisinau, Moldova
*
Author to whom correspondence should be addressed.
Information2026, 17(9), 887;https://doi.org/10.3390/info17090887
This article belongs to the Special Issue Digital Privacy and Security, 3rd Edition
Version Notes
Order Reprints

Abstract

Compiler security instrumentation is portable only when the compiler, application binary interface, runtime, loader, operating system, and hardware preserve the same security contract. We present Evidence-Carrying Portability Contracts (ECPC), a machine-readable method that binds each versioned configuration to seven return-integrity obligations, typed cross-layer facts, authoritative decision rules, executable transition witnesses, and field-level provenance. We retrospectively evaluated eight shadow call stack configurations across x86_64, AArch64, and RISC-V. Three implications emerge: pointer publication order determines whether asynchronous handlers can corrupt slot ownership; capture, edge coverage, and slot ownership are independent properties; and hardware enforcement relocates obligations into loader, lifecycle, and non-local-control-flow support rather than eliminating them. The reconstruction distinguishes two ownership defects in the LLVM RISC-V D84414 draft, one in the landed 2020 form and none after D149099; a glibc commit-interval case identifies restore token search and RSTORSSP as decisive for cross-context longjmp. The Compact TLS x86_64 configuration is evaluated only as a specified design because its submitted artefacts conflict and implementation source is unavailable; we make no performance or production-readiness claim for it. Artefact version 2.1.0 and 30 semantic tests make every reported classification regenerable. The study demonstrates traceable retrospective discrimination among known states, not prospective defect-discovery accuracy.

1. Introduction

Compiler hardening is often presented as a command-line option. That interface is useful, but it can hide where the claimed protection actually comes from. A shadow call stack (SCS), for example, keeps a protected copy of each return address. Whether the copy is authoritative depends on more than the compiler pass: the processor decides where a call first places the return address; the ABI decides which registers other code may overwrite; the backend decides when a shadow slot becomes visible; the runtime creates per-thread state; the loader enables hardware features; and the operating system saves and restores state around signals. A feature can therefore compile on a new target while losing part of the intended guarantee.
The recurring problem is not merely that a portability judgement may be wrong. It is that the judgement is frequently difficult to audit. A table cell marked secure, supported, or conditional rarely identifies the exact version, decisive facts, rule, search bound, contradictory source, or runtime tuple. It may also conflate very different forms of support: a property guaranteed by instruction semantics, an inference from two sources, a counterexample found by bounded search, or simply the absence of a counterexample in one finite model.
We address this representation problem with an Evidence-Carrying Portability Contract (ECPC). The word contract denotes a structured, version-scoped claim, not a legal instrument and not a proof-carrying binary. Each ECPC names the guarantee and attacker/event model, identifies a configuration by architecture, platform, runtime, and change interval, records typed cross-layer facts, applies an explicit rule catalogue, and emits a result whose reasoning and provenance remain attached. This structure makes disagreement local: an analyst can challenge a protocol transcription or lifecycle fact without silently changing the guarantee or the rules.
Shadow call stacks provide a demanding worked domain. On AArch64 and RISC-V, a call normally materializes the return authority in a link register. On x86_64, CALL first writes it to the ordinary stack. Compact software designs maintain a second pointer, parallel designs derive an address from the ordinary stack, and Intel Control-flow Enforcement Technology (CET) performs protected architectural pushes and comparisons. The same high-level label thus spans different capture windows, publication protocols, ABI commitments, non-local-flow mechanisms, and failure responses [1,2,3,4,5,6,7,8,9,10,11].
We ask three research questions:
RQ1. What representation and derivation controls are required for a machine-readable portability judgement to keep outcome, reasoning, provenance, conditions, and bounded exploration distinct?
RQ2. When that representation and its rule catalogue are held fixed, can ECPC retrospectively distinguish version-pinned historical states and identify the exact obligation changed by each source delta?
RQ3. How does the same contract expose the assurance boundary of a fully specified compact TLS x86_64 design when implementation evidence is unavailable?
The questions form one evaluation chain. RQ1 defines the representation, rule authority, and evidence controls. RQ2 holds those elements fixed and varies only version-pinned historical facts, testing retrospective discriminative power. RQ3 holds the same contract fixed but withholds implementation evidence, testing whether the representation prevents design-level findings from being misreported as implementation validation. The paper makes four contributions. First, it defines a typed portability judgement that separates outcome, reasoning mode, source class, configuration identity, and deployment conditions. Second, it makes a machine-readable rule catalogue authoritative and checks every descriptor–obligation decision against a frozen expectation fixture. Third, it provides an executable ownership model whose traces identify the interrupted frame, handler, shadow slot, stored authority, and pointer transition. Fourth, it reconstructs LLVM RISC-V and glibc CET histories and derives three findings: publication order controls asynchronous slot ownership; capture, coverage, and ownership are independent; and hardware enforcement still requires a complete software lifecycle.
The central insight is that portability failures are usually not target-substitution failures. They are broken agreements between layers: a backend publishes state too late, an ABI does not reserve the governing register, a runtime omits a creation path, or a control transfer restores the ordinary stack without restoring its shadow counterpart. ECPC makes the layer that supplies—or fails to supply—each premise explicit.
Figure 1 maps the six contributing layers onto the seven ECPC obligations and shows that no individual layer discharges more than three of them.
Figure 1. Cross-layer premises for the seven ECPC return-integrity obligations. No individual layer supplies a complete portability argument.

3. ECPC Method

This section answers RQ1 by defining both the judgement record and the controls that make its derivation reproducible. It progresses from configuration identity, through outcome precedence and obligations, to the authoritative rule catalogue and evidence trust. Figure 2 summarizes the complete evaluation pipeline; Section 4 then supplies the executable transition semantics used by the ownership rules.
Figure 2. ECPC evaluation pipeline. The machine-readable rule catalogue is authoritative; the frozen expectation fixture tests every descriptor–obligation mapping before publication outputs are generated.

3.1. Judgement and Configuration Identity

We represent a judgement as J = ⟨G, A, C, F, R, E⟩. G is the scoped guarantee; A is the attacker and event model; C identifies the mechanism, architecture, platform/runtime tuple, and version or change interval; F is a typed fact set; R is the authoritative, frozen selector-to-result catalogue; and E contains provenance, locators, the frozen rule-expectation fixture, search records, and generated outputs. The configuration is the unit of analysis. Names such as “RISC-V SCS” or “CET” are too broad because different commits, kernels, loaders, libraries, and build options can change the result.
Each fact is a record ⟨value, sources, locator, condition⟩. Sources are identifiers resolved through a registry. Locator is an instruction sequence, review discussion, section, commit, or artefact path. A condition records an unresolved deployment or threat model premise rather than hiding it in prose. The schema requires every empty source list to accompany an explicit unknown value. Before rule selection, the evaluator checks types, version scope, evidence completeness, and conflicts; a non-empty decisive condition is processed before satisfaction. response_policy remains structurally different from an integrity outcome.
Table 1 lists the input vocabulary used by the supplied corpus. The table is not decorative: each row corresponds to a required typed field checked by the schema, and Section 3.3, Section 3.4 and Section 3.5 explain how those fields enter rules.
Table 1. Typed input facts in the supplied ECPC corpus.

3.2. Outcome Semantics, Precedence, and Conflicts

The live outcome set is O = {satisfied, conditional, violated, unknown}. Not-applicable is absent from this corpus because every one of the seven integrity obligations applies to all eight configurations; a hardware mechanism can satisfy coverage by construction even though it has no compiler leaf predicate. A future domain may introduce not-applicable only with an explicit applicability proof and schema change.
  • Satisfied: The obligation is applicable, decisive facts are present and mutually consistent for C, all declared premises hold, and a construction or explicit derivation establishes the scoped property.
  • Conditional: The obligation can be established only when one or more named deployment, ABI, runtime, threat model, or event-scope conditions hold. The condition is part of the result.
  • Violated: An explicit rule refutes the obligation, or an executable/constructed counterexample reaches a forbidden state. One valid witness is decisive within the declared model.
  • Unknown: A decisive fact is missing, its version cannot be matched to C, or decisive sources conflict and the conflict has not been adjudicated. Unknown is not a midpoint between satisfied and violated.
The evaluator enforces the following precedence from rules.json: (1) applicability; (2) explicit violation or counterexample; (3) evidence integrity and version match; (4) unmet named conditions; and (5) satisfaction. It derives selector keys from each typed descriptor, selects the corresponding rule entry, and rejects any emitted outcome, reasoning mode, condition state, or rule ID that differs from the catalogue. Consequently, a current manual cannot silently satisfy a historical row, a clean bounded search cannot override a contradictory witness, and a condition-bearing construction cannot be displayed as unconditional satisfaction.
For conflicting sources, ECPC first asks whether they describe the same C. Version mismatch produces separate configurations rather than averaging. Within one configuration, architecture/ABI specifications govern architectural and ABI facts; upstream code/change records govern emitted sequences; platform/runtime implementation records govern integration; peer-reviewed papers govern their published design abstraction; and an author artefact governs only the artefact it actually contains. If two same-scope sources disagree on a decisive fact, the record preserves both and emits unknown until adjudication. Multiple sources may support a result, but each result has one decisive reasoning_mode and zero or more supporting_reasoning entries.

3.3. Seven Integrity Obligations and One Policy Record

Capture before exposure. The authority used by the mechanism must originate before attacker-accessible state can substitute it.
Coverage. Every dynamic return edge whose authority can become attacker-writable must be protected or remain safe by an equivalent invariant.
Unique slot ownership. Every live compact-shadow frame must own a distinct slot despite scoped asynchronous delivery.
Non-local balance. Exceptions, longjmp, user-context switches, and equivalent transfers in scope must restore the relation between ordinary and shadow state.
Lifecycle completeness. All included execution contexts must receive, inherit, and release valid mechanism state through a named owner.
Composition. Instrumented and uninstrumented objects, callbacks, loaders, libraries, and reserved registers must coexist under an explicit rule.
Isolation. Under attacker model A, ordinary attacker writes must not replace the authoritative entry or governing state.
Response policy is recorded separately as silent restoration, compare-and-trap, architectural fault, logging, or unknown. These categories matter operationally, but no satisfied/violated label is emitted. Integrity and incident observability are different requirements; a silent hardware-correct restore is not thereby an integrity violation.

3.4. Rule Catalogue

Table 2 is generated directly from the authoritative rules.json catalogue. The executable catalogue maps selector keys to exact outcomes and reasoning modes; the manuscript tables are generated consequences, not a second source of truth. Its precedence is enforced in code, and validation_cases/rule_expectations.json freezes the expected descriptor predicates, non-empty conditions, selector keys, rule IDs, outcomes, and decisive reasoning modes for all eight configurations and all 64 emitted records. The 30-test suite includes deliberate condition-precedence, rule-mismatch, and classification-locator failures and requires every non-firing rule to have an explicit catalogue rationale.
Table 2. Rule catalogue and permitted reasoning modes.
R-OWN-2 is retained deliberately as a reserved conditional branch: a future descriptor with a clean bounded search but incomplete ordering premises must not fall through to an unqualified satisfied result.
Figure 2 exposes the enforced direction of authority: descriptors produce selector keys; rules.json maps those selectors to outcomes and reasoning modes; the expectation fixture checks the mapping; and only then are audit records, tables, traces, and checksums generated.

3.5. Reasoning Mode, Source Class, and Trust

Reasoning mode answers how the conclusion was reached; source class answers where its premises came from. Table 3 states the trust assumption and control for each source class, while Table 4 states the validity boundary for each reasoning mode. The artefact therefore emits reasoning_mode, source_ids, source_classes, rule_ids, selector_keys, locators, conditions, and supporting_reasoning separately. This prevents, for example, an author-specified fact from being mistaken for an author-validated implementation result.
Table 3. Trust assumptions by source class.
Table 4. Validity conditions by reasoning mode.

4. Executable Transition Model

This section supplies the operational detail requested by RQ1 and used in RQ2. Section 4.1 defines state and operations; Section 4.2 maps operations to version-pinned instruction sequences, and Figure 3 visualizes the publication boundary; Section 4.3 defines exploration and counting; and Section 4.4 states the ordering propositions that justify software satisfaction independently of clean search.
Figure 3. Compact shadow slot ownership under asynchronous interruption. Unsafe push publishes acquisition after the store; unsafe pop publishes release before the load. Reversing those orders prevents the modelled slot collision.

4.1. State and Operations

A state is σ = ⟨ssp, shadow [0, …, N − 1]⟩, with explicit 0 ≤ ssp ≤ N. Exploration starts at ssp = 2 with root0 and root1 as the caller context; metrics.json records this initial state. Capacity eight covers the deepest reported schedule: two roots, one interrupted outer frame, and at most three simultaneously live handlers require no more than six entries, leaving two entries as overflow headroom. Each active frame has a return authority ra and temporary fields ptr, captured, and observed. Reads and writes check 0 ≤ index < N; decrement and load reject ssp = 0; publication rejects ssp > N.
The software operations are capture_ra, read_ssp, store_ra, publish_inc, publish_inc_mem, load_old, publish_dec, compare, overwrite, and return. publish_inc models publication from a previously read pointer; publish_inc_mem models Clang 7’s direct in-memory GS-index increment before the updated index is read. The evaluator applies R-OWN-P2/P4 only to ordered compact software sequences. It evaluates AArch64 atomic push/pop under R-OWN-ATOMIC, FlashStack direct mapping under R-OWN-DIRECT, and CET architectural push/pop/compare under R-OWN-HARDWARE; these constructions are no longer mislabeled as software-order derivations.
A schedule inserts an instrumented handler at any boundary before, between, or after completed outer operations. The handler executes its own push and pop. At nesting level d > 1, a child handler is recursively inserted at every boundary of the parent handler. Level zero runs no interrupt; level one has one handler; level two is the manuscript default. The implementation checks the active top entry after each handler push and the observed authority after each pop.

4.2. Refinement to Real Instructions

Table 5 maps each version-pinned instruction sequence to the property-specific operations preserved by the model. The abstraction assumes a single hart and precise interruption only between architecturally completed instructions. On one hart, the relevant RISC-V add and store complete in programme order before a precise handler observes architectural state; cross-hart sharing is excluded. The RISC-V privileged and unprivileged specifications provide the trap vocabulary and execution-environment boundary [44,45]. RVWMO is therefore only a same-location sanity condition here, not a justification for general sequential consistency.
Table 5. Refinement from version-pinned operations to the ownership abstraction.
The abstraction is intentionally property-specific. It preserves completed instruction order, pointer publication, shared-slot selection, nested handler use of the published pointer, and authority observation. Figure 3 shows the two dual failure patterns: push publishes acquisition too late, whereas pop publishes release too early. It also shows why publish-before-store and load-before-decrement eliminate the modelled collision. The model omits speculation, caches, interrupts inside one architecturally indivisible instruction, DMA, cross-hart sharing, arbitrary handler assembly, and memory-safety faults outside the shadow array.

4.3. Exploration Bounds, Equivalence, and Measurements

Table 6 reports the generated depth-two measurements for every configuration. For each configuration, the explorer enumerates outer push and pop insertion boundaries and recursively generated handler variants at depth two. A retained failure class is keyed by outer phase, defective subprotocol, insertion boundary, and reason. This equivalence removes repeated traces with the same modelled explanation but retains phase and boundary distinctions. Counts scale with protocol length and exposed insertion points; they are diagnostics, not severity measures.
Table 6. Depth-two exploration measurements generated by artefact version 2.1.0.
At depth two, the generated corpus contains 684 candidate schedules and 15,070 abstract step calls, retaining 80 boundary-equivalence classes. The counts characterize the explored state space; the security result is the presence and identity of a return authority mismatch.
Sensitivity is reported for depths zero through three. The complete 2 → 1 → 0 RISC-V defect-family sequence already appears at depth one, matching the single-signal upstream scenario, and persists at depths two and three. Deeper bounds add witness variants but do not create a new historical conclusion. The post-D149099 P2/P4 sequence remains clean at every reported depth.

4.4. Scoped Ordering Propositions

P1 (capture). If the only authoritative value is copied by a callee from an ordinary writable x86 return slot after CALL, then the copy does not establish capture-before-exposure against an attacker able to corrupt that slot in the call-to-prologue interval. This is a direct consequence of the timing premise; it makes no claim about how exploitable that interval is in a particular programme.
P2 (load-before-decrement pop safety). Assume one hart, precise instruction-boundary interruption, an instrumented handler using published ssp, and a frame whose epilogue reads its old top entry before publishing ssp−1. A handler before the load uses the next free slot and restores ssp; the frame then reads its own entry. A handler after the load may reuse the released slot only after publication, but the frame has already captured the authority. Therefore the handler cannot substitute the modelled observed return authority.
P3 (compact non-local balance). If a non-local transfer discards k > 0 ordinary frames while a compact SCS pointer is neither restored from saved context nor adjusted by k, then ordinary and shadow depths diverge. The next protected return refers to a discarded frame’s entry or an invalid depth. This constructed trace refutes non-local balance for the specified event.
P4 (publish-before-store push safety). Assume the same interrupt model and a prologue that reserves logical slot p, publishes the successor state, and then stores its authority at p. Publication may use a previously read pointer or an in-memory index increment such as the Clang 7 GS sequence. A handler before publication may use p but restores the pointer before the interrupted frame stores; a handler after publication selects the successor slot. Thus no handler selects p while the interrupted frame owns it. P4 establishes slot ownership independently of capture and coverage.

5. Evaluation Design

This section connects the three questions. RQ1 supplies the fixed representation and authoritative rules; RQ2 applies them retrospectively to a known three-state compiler history and a runtime-layer commit interval; RQ3 applies the same controls to a specified design with missing implementation evidence. The evaluation therefore tests traceable reconstruction and claim discipline, not prospective bug-finding accuracy.

5.1. Configuration Corpus

The eight complete configurations are: compact TLS x86_64 specified design; historical LLVM 7 x86_64; LLVM/Android AArch64; RISC-V D84414 draft; RISC-V landed 2020; RISC-V after D149099; FlashStack x86_64; and Intel CET under a pinned Linux/glibc tuple. Table 7 records identity-critical facts. Current documentation is never projected backward onto historical lifecycle rows.
Table 7. Identity-critical facts for the eight complete configurations.

5.2. Extraction and Provenance Controls

Protocol sequences were transcribed from historical LLVM documentation and review diffs. The provenance ledger stores each source-level sequence beside its explicit mapping to model operations; regression tests require descriptors to match those mappings. All fact source identifiers resolve through sources.json. The evaluator loads rules.json before classification, derives selector keys, and validates every result against the catalogue. A frozen expectation fixture independently asserts each descriptor predicate, condition, selected rule, outcome, and reasoning mode. Generated cells are read from ecpc_audit.json, and SHA256SUMS binds code, tests, descriptors, schemas, sources, fixtures, and outputs.
The source hierarchy is not used to turn documentation promises into runtime facts. For example, current Clang documentation says a runtime must be provided and identifies present register rules, but it does not prove which historical RISC-V platform owned lifecycle state in 2020. Those three lifecycle cells are therefore unknown. Likewise, CET coverage is satisfied by the architectural CALL/RET construction, while non-local balance remains conditional because the exact exception unwinder is not pinned even though signals and the scoped glibc longjmp path are evidenced.

5.3. Historical and Secondary Reconstruction Protocol

For the RISC-V sequence, the rule catalogue and model are fixed while push/pop facts change at documented review and commit boundaries. Expected qualitative changes are two defective subprotocols (draft), one (landed), and zero (post-D149099). The raw boundary-class counts are generated after classification and are not used to define success. Because the investigators encoded this already-known history, the result demonstrates retrospective reconstruction and localization of the changed obligation; it is not an estimate of prospective discovery accuracy.
For glibc, the frozen question is narrower: does __longjmp restore the target SSP when jumping from a user context whose target shadow stack differs and the old shadow stack contains a valid restore token? The pair is parent(35694d3416b2) → 35694d3416b2. Before the change, the sequence adjusts with INCSSP and cannot select another shadow stack; after the change, it searches for a token, executes RSTORSSP/SAVEPREVSSP, and then adjusts. The reconstructed scoped result changes from violated to satisfied by source construction.
The investigators encoded the glibc interval after the historical fix was known. Its role is to test whether the same representation transfers from compiler instruction ownership to runtime control-state restoration. The supplement records a separate protocol for any future independent reconstruction.
No second analyst performed a blinded encoding for this revision. External users and an independently encoded history would strengthen evidence about usability, inter-analyst agreement, and prospective utility. The present evidence supports a narrower claim: when version-pinned facts are supplied under a fixed catalogue, ECPC produces inspectable, regenerable retrospective distinctions and preserves uncertainty where implementation or platform evidence is absent.

5.4. Compact x86 Integrity Decision

The submitted materials contained an executable abstract model and a worked-case manifest but no recoverable LLVM patch, runtime source, emitted assembly, or FileCheck tests. The two supplied artefacts also conflict: the manifest lists decrement-before-load, while the executable model uses load-before-decrement. The revised analysis adopts the executable order only as a stated design assumption and preserves the conflict in worked_case_manifest.json. It withdraws the earlier implementation size, runtime line count, FileCheck count, compiled-backend, performance, upstreamability, and production-readiness claims.
RQ3 is consequently evaluated as a specified design. The result remains technically useful: it exposes capture, coverage, publication, non-local-flow, lifecycle, and composition failures in the design without attributing unverified code to LLVM. Recovered source would become a new configuration and trigger regeneration.

6. Results

This section reports generated outcomes together with reasoning modes and then explains the implications without requiring the reader to infer them from tables. The 56 integrity cells comprise 17 satisfied, 27 conditional, nine violated, and three unknown outcomes. The eight response policy entries are excluded from those totals. Compared with artefact v2.0.0, only FlashStack capture changes outcome (satisfied to conditional); three ownership rows keep their satisfied outcome but now cite construction-specific rules.

6.1. Outcome and Reasoning Matrix

Table 8 uses compact configuration labels and pair every outcome with its decisive reasoning mode: SAT, COND, VIOL, UNK and SC (source construction), DR (derived rule), BW (bounded witness), CT (constructed trace), DS (direct stipulation), and ME (missing). Text labels remain present in every cell; light shading is redundant visual grouping, not the sole carrier of meaning. Bounded-clean is never decisive for a satisfied software ownership cell.
Table 8. (a). Generated outcomes and decisive reasoning: capture through non-local balance. Abbreviations are defined in Appendix A; shading redundantly groups outcomes. (b). Generated outcomes and decisive reasoning: lifecycle through isolation, plus categorical response policy. Shading redundantly groups outcomes. Response policy labels are reader-facing display forms; exact schema tokens are listed in Appendix A.
The matrix exposes three patterns. First, link-register and hardware capture are constructed as satisfied, x86 callee-copy capture is derived as violated, and FlashStack’s dual-prologue construction is conditional on its published threat model under R-CAP-3. Second, many deployment-wide properties remain conditional because ABI, mixed-code, unwinder, or runtime premises are not universal. Third, the three historical RISC-V lifecycle cells are unknown because no version-matched platform owner was established.

6.2. RISC-V Differential Reconstruction (RQ2)

Table 9 makes the RQ2 historical progression explicit. A single interrupt is sufficient to recover it: the D84414 draft has two independent ownership failures; the landed 2020 form corrects the pop and retains only the push failure; and D149099 publishes the successor pointer before the store, removing the remaining failure. The result is 2 → 1 → 0 defective subprotocols at depth one, preserved at depths two and three.
Table 9. RISC-V differential reconstruction: the defect-family result is already complete with one interrupt.
The class counts in Table 9 rise from 2/1/0 at depth one to 38/20/0 at depth two because deeper schedules expose more boundaries; they are not severity scores. Table 10 then gives the generated single-interrupt witness for the landed push. The post-D149099 row is search-clean, while its positive scoped ownership result follows from R-OWN-P2/P4 over source-pinned instruction order.
Table 10. Generated single-interrupt witness for the landed 2020 push: the handler takes the outer frame’s unpublished slot.
As Table 10 shows, the decisive transition is concrete. The outer frame writes authority ‘outer’ to slot 2 while ssp remains 2. The handler also selects slot 2, replaces it with ‘handler-0’, publishes and returns. The outer frame then publishes its stale reservation and loads ‘handler-0’ from slot 2. This is the one-signal victim described in D84414: the interrupted frame loses its return authority.

6.3. glibc CET Commit-Interval Reconstruction (RQ2)

Table 11 isolates the glibc parent-to-commit change. The scoped result changes from violated to satisfied only for cross-user-context longjmp with a valid restore token: the commit adds restore token search and RSTORSSP before depth adjustment. It does not establish aggregate CET non-local balance for arbitrary exceptions or a deployment with an unspecified unwinder; the full CET matrix–cell therefore remains conditional.
Table 11. Scoped glibc parent-to-commit CET longjmp reconstruction.

6.4. Compact TLS x86_64 Specified Design (RQ3)

Four negative conclusions are justified, but they use three reasoning modes. Capture is a derived violation because CALL exposes the ordinary stack authority before callee copy. Coverage is a derived violation because the specified hasCalls-style omission leaves x86 return authority on writable ordinary memory. Unique slot ownership is violated by a bounded push witness: store-before-publish lets an instrumented handler select and overwrite the same slot. Non-local balance is violated by a constructed trace in which longjmp discards ordinary frames without restoring compact SSP.
Under the declared load-before-decrement sequence, the pop satisfies P2; the compact design’s ownership defect is confined to push publication. The submitted manifest’s conflicting order is retained in the artefact rather than blended into the result. The remaining system findings are direct: the constructor/pthread lifecycle misses raw clone, local-exec TLS constrains composition, and information hiding does not provide hardware write isolation.

6.5. Comparative Implications

Historical LLVM 7 x86 illustrates the independence of ownership from capture and coverage. Its documented capture, in-memory index increment, pointer read, and store order reserves a unique slot before the store and is ownership-safe under P4. Yet CALL exposes the authority before the callee can capture it, and Clang 7 explicitly leaves very short x86_64 leaf functions uninstrumented. Those leaves retain CALL-created authority on writable ordinary memory, so coverage is violated rather than conditional [3,4,5]. A correct publication protocol therefore cannot compensate for an exposed source authority or an unprotected return edge.
AArch64, FlashStack, and CET show why ownership must be construction-specific. AArch64 atomic post-index/pre-index operations satisfy R-OWN-ATOMIC; FlashStack’s direct mapping satisfies R-OWN-DIRECT; and CET architectural push/pop/compare satisfies R-OWN-HARDWARE. Their ownership outcomes remain satisfied, but none is now attributed to compact software P2/P4. FlashStack capture is separately conditional under its published threat model, while CET deployment still requires compatible hardware, kernel, loader/runtime, objects, and event-specific restoration.

7. Discussion

7.1. Pointer Publication Is the Ownership Boundary

The RISC-V history exposes a general concurrency rule for compact metadata stacks. The publication step is the linearization point that transfers a slot from free to owned. Store-before-publication lets an asynchronous handler select the same slot; decrement-before-load releases a slot while its owner still needs the value. The two bugs are duals: one publishes acquisition too late, while the other publishes release too early. D84414 and D149099 therefore document a reusable protocol principle, not two unrelated instruction-order accidents.
The one-interrupt witness makes the principle operational. It identifies the victim, the colliding slot, the overwriting authority, and the final incorrect observation. Nested exploration is useful for regression depth, but it is not needed to explain the historical defect.

7.2. Capture, Coverage, and Ownership Are Independent

The comparative matrix rejects the shortcut of treating any correct push/pop as the whole defence. LLVM 7 x86 has safe compact software slot ownership but copies authority only after CALL has exposed it and leaves very short leaf functions uninstrumented. The compact TLS design fails all three dimensions. AArch64, FlashStack, and CET satisfy ownership by different constructions—atomic addressing, direct mapping, and architectural hardware state—while their capture, coverage, and deployment premises remain separately evaluated.
This decomposition also clarifies engineering priorities. Fixing publication order removes a real asynchronous corruption path, but it does not close an architectural call-to-prologue window. Reserving a register preserves governing state across mixed code, but it does not initialize new threads. A portability review that checks only emitted instructions will miss both classes of failure.

7.3. Hardware Shifts Obligations into the System Stack

CET supplies the strongest local construction in the corpus: architectural dual pushes, RET comparison, and ordinary-write exclusion. Its remaining dependencies move outward—to loader enablement, object compatibility, signal state, user-context transfer, and unwinding. The glibc longjmp reconstruction shows why those dependencies are substantive: INCSSP can adjust depth but cannot select another shadow stack; restore token search and RSTORSSP are required to rebind the architectural state.
Version precision is equally important in software. D84414 and the landed 2020 RISC-V implementation use x18/s2; D146463 later changes the ABI commitment to x3/gp [46]. Treating gp as timeless would erase a real composition change even though the push/pop ownership result is unchanged. ECPC records both facts, allowing security-equivalent instruction order and ABI-incompatible register ownership to coexist in the same history.

7.4. Prospective Bug-Finding and Independent Validation

Prospective evaluation should freeze the ECPC schema, rule catalogue, and search bounds before selecting unseen targets, and then apply them to newly proposed compiler ports or security instrumentation changes for which maintainers have not yet disclosed an outcome. Analysts would encode only the public specifications, patches, tests, and runtime evidence available at the decision date. ECPC would produce predicted violated or conditional obligations and concrete witnesses; these predictions would be timestamped and sent to maintainers before adjudication. Maintainer confirmation, patch changes, or independent executable evidence would provide ground truth. Reporting confirmed defects, false alarms, missed defects, time to diagnosis, and outcomes by obligation would measure prospective bug-finding value without conflating it with retrospective reconstruction.
Independent validation should use at least two analysts who are not given the historical labels or each other’s encodings. A preregistered codebook would define fact types, decisive evidence thresholds, and conflict handling. Each analyst would receive the same immutable source bundle, create descriptors independently, and run the frozen catalogue and explorer. Before adjudication, the study would report agreement for all fact values and separately for decisive facts, selected rule IDs, outcome labels, and generated witnesses, together with completion time and unresolved questions. A third maintainer or domain expert would adjudicate disagreements from source locators rather than majority vote. Repeating the protocol with external compiler security teams and releasing the blinded encodings would test reproducibility and usability across analysts and institutions.

8. Validity Boundaries and Reproducibility

8.1. Model Boundary

The ownership explorer models precise same-hart interruption between completed operations. It excludes cross-hart sharing, speculative effects, DMA, and arbitrary handler assembly. Within that boundary, a return authority mismatch is a decisive counterexample. Positive compact software ownership follows from R-OWN-P2/P4; atomic, direct-mapping, and hardware results follow from their construction-specific rules. Because the corpus was encoded from known histories, the study establishes retrospective discrimination and traceability, not prospective sensitivity, specificity, or defect-discovery accuracy.
The seven obligations target return address integrity. Applying the representation to forward-edge CFI, memory tagging, safe stacks, or pointer authentication requires mechanism-specific facts, rules, and transition refinements rather than reuse of the present ownership semantics.

8.2. Evidence and Reproduction

Two provenance tiers remain explicit. For push_steps and pop_steps, source-level instructions and their abstract mappings are stored together and independently cross-checked against the descriptors. For the other nine analyst-classified facts, results/classification_fact_pairs.json records each value beside its locator, and a frozen digest rejects value-to-locator drift; this control detects undocumented reclassification but does not independently verify the analyst’s interpretation of the cited source. Versioned register ownership is schema-checked, and every generated result is checksum-bound. Artefact version 2.1.0 reproduces all tables and witnesses with standard-library Python and passes 30 semantic tests; Supplementary Files S1 and S2 are archived as one immutable, versioned Zenodo record [47]. Five complete runs on the recorded Windows 11, CPython 3.12.13, 12-logical-processor ARMv8 environment had a median wall time of 1.8660 s (range 1.8425–1.9076 s); benchmark.py repeats this measurement. The timing characterizes artefact execution only. The compact x86 implementation remains unavailable, so that row is a specified design; no implementation measurements are attributed to LLVM.

9. Conclusions

This study yields three substantive findings. First, shadow stack pointer publication is an ownership boundary: late acquisition and early release are dual asynchronous corruption patterns, and the RISC-V history resolves them from two defects to one to zero. Second, capture, edge coverage, and slot ownership are independent; a correct push/pop sequence cannot repair authority that was already exposed or an edge that was never instrumented. Third, hardware enforcement relocates rather than eliminates portability obligations, as CET still depends on loader policy, lifecycle, and control transfer restoration.
ECPC makes those findings durable by binding each result to a configuration interval, source-level sequence, typed cross-layer premises, an authoritative selector-to-result rule, and—where relevant—an executable witness. The rule catalogue repair itself demonstrates the value of that discipline: FlashStack’s named threat model condition now forces a conditional capture outcome, whereas AArch64, FlashStack, and CET ownership results retain satisfaction under rules that match their actual constructions. The artefact is a differential regression record showing exactly which layer, obligation, rule, and conclusion changed.

Supplementary Materials

The following supporting information can be downloaded at: https://www.mdpi.com/article/10.3390/info17090887/s1. Supplementary File S1, Supplement_information-17-00887.docx, provides the ECPC operational specification, evidence ledger, rule-change log, and reproduction guide; Supplementary File S2, ECPC_Artifact_v2.1.0.zip, provides the executable model, descriptors, authoritative rules, expectation fixture, tests, provenance ledger, generated results, benchmark, checksums, licence, and citation metadata. Both files are permanently archived in Zenodo at https://doi.org/10.5281/zenodo.22638613 (accessed on 9 September 2026) [47].

Author Contributions

All authors have equal contributions to this article. Conceptualization, E.R., Ș.-D.I., R.R. and D.Ț.; methodology, E.R., Ș.-D.I., R.R. and D.Ț.; software, E.R. and Ș.-D.I.; validation, E.R., Ș.-D.I., R.R. and D.Ț.; formal analysis, E.R. and Ș.-D.I.; investigation, E.R., Ș.-D.I., R.R. and D.Ț.; resources, E.R., Ș.-D.I., R.R. and D.Ț.; data curation, E.R. and Ș.-D.I.; writing—original draft preparation, E.R., Ș.-D.I., R.R. and D.Ț.; writing—review and editing, E.R., Ș.-D.I., R.R. and D.Ț.; visualization, E.R. and Ș.-D.I.; supervision, R.R. and D.Ț.; project administration, R.R. and D.Ț. All authors have read and agreed to the published version of the manuscript.

Funding

This work was partially supported by DACISLab: Virtual Laboratory on Open Data and Open Science in the New Generation of Continuum Computing Systems, project number PN-IV-PCB-RO-MD-2024-0364, within PNCDI IV.

Institutional Review Board Statement

Not applicable.

Data Availability Statement

All data and code used to generate the reported matrices and witnesses are openly available in Zenodo at https://doi.org/10.5281/zenodo.22638613 (accessed on 9 September 2026) [47]. The same immutable files are supplied to MDPI as Supplementary Files S1 and S2; no external mutable repository is required to reproduce the reported results.

Acknowledgments

During the preparation of this manuscript, the authors used Claude AI (Opus 4.8) for language proofreading and stylistic editing.

Conflicts of Interest

The authors declare no conflicts of interest.

Appendix A. Compact Syntax and Abbreviations

Outcome abbreviations: SAT = satisfied; COND = conditional; VIOL = violated; UNK = unknown. Reasoning abbreviations: DS = direct stipulation; DR = derived rule; SC = source construction; BW = bounded-search witness; BC = bounded-search clean; CT = constructed trace; ME = missing evidence. Source provenance is reported separately and may contain multiple source classes.
Core technical abbreviations: ABI = application binary interface; SCS = shadow call stack; SSP = shadow stack pointer; TLS = thread-local storage; CET = Control-flow Enforcement Technology; CFI = control-flow integrity; RA = return address/return authority.

Appendix B. Reproduction

Unpack ECPC_Artifact_v2.1.0.zip and execute ‘python reproduce.py’ with CPython 3.11 or later. No third-party package is required. A successful execution validates the corpus and authoritative rule catalogue, runs 30 semantic tests, regenerates results including the classification value-to-locator ledger and round-two change log, and rewrites checksums and the manifest. Consult README.md for model scope and archival status. The permanently archived S2 snapshot is available at https://doi.org/10.5281/zenodo.22638613 (accessed on 9 September 2026) [47].

References

  1. Burow, N.; Zhang, X.; Payer, M. SoK: Shining Light on Shadow Stacks. In Proceedings of the 2019 IEEE Symposium on Security and Privacy (SP), San Francisco, CA, USA, 19–23 May 2019; pp. 985–999. [Google Scholar] [CrossRef] [Scilit]
  2. Zou, C.; Gao, Y.; Xue, J. Practical Software-Based Shadow Stacks on x86-64. ACM Trans. Archit. Code Optim. 2022, 19, 61. [Google Scholar] [CrossRef] [Scilit]
  3. Clang Team. ShadowCallStack, Clang 7.0.1 Documentation. Available online: https://releases.llvm.org/7.0.1/tools/clang/docs/ShadowCallStack.html (accessed on 9 September 2026).
  4. Tsyrklevich, V. Delete x86_64 ShadowCallStack Support. LLVM D59034. 2019. Available online: https://reviews.llvm.org/D59034 (accessed on 9 September 2026).
  5. Clang Team. ShadowCallStack, Current Documentation. Available online: https://clang.llvm.org/docs/ShadowCallStack.html (accessed on 23 August 2026).
  6. Zheng, Z. [RISCV] Support Shadow Call Stack. LLVM D84414. 2020. Available online: https://reviews.llvm.org/D84414 (accessed on 9 September 2026).
  7. Kirth, P. [RISCV] Make SCS Prologue Interrupt Safe on RISC-V. LLVM D149099; Commit bface3947ea1. 2023. Available online: https://reviews.llvm.org/D149099 (accessed on 9 September 2026).
  8. Android Open Source Project. ShadowCallStack. Available online: https://source.android.com/docs/security/test/shadow-call-stack (accessed on 23 August 2026).
  9. Arm Limited. Procedure Call Standard for the Arm 64-bit Architecture (AAPCS64), 2025Q1. Available online: https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst (accessed on 9 September 2026).
  10. x86-64 psABI Project. System V AMD64 ABI. Available online: https://gitlab.com/x86-psABIs/x86-64-ABI (accessed on 23 August 2026).
  11. Intel Corporation. Control-Flow Enforcement Technology Specification, Revision 3.0; Intel Corporation: Santa Clara, CA, USA, 2019. [Google Scholar]
  12. Cowan, C.; Pu, C.; Maier, D.; Hinton, H.; Walpole, J.; Bakke, P.; Beattie, S.; Grier, A.; Wagle, P.; Zhang, Q. StackGuard: Automatic Adaptive Detection and Prevention of Buffer-Overflow Attacks. In Proceedings of the 7th USENIX Security Symposium, San Antonio, TX, USA, 26–29 January 1998; pp. 63–78. [Google Scholar]
  13. MITRE. CWE-121: Stack-Based Buffer Overflow. Available online: https://cwe.mitre.org/data/definitions/121.html (accessed on 9 September 2026).
  14. MITRE. CWE-787: Out-of-Bounds Write. Available online: https://cwe.mitre.org/data/definitions/787.html (accessed on 9 September 2026).
  15. Aleph One. Smashing the Stack for Fun and Profit. Phrack 1996, 7, 49, File 14 of 16. Available online: https://phrack.org/issues/49/14 (accessed on 9 September 2026).
  16. Shacham, H. The Geometry of Innocent Flesh on the Bone. In Proceedings of the 14th ACM Conference on Computer and Communications Security, Alexandria, VA, USA, 29 October–2 November 2007; pp. 552–561. [Google Scholar] [CrossRef] [Scilit]
  17. Abadi, M.; Budiu, M.; Erlingsson, U.; Ligatti, J. Control-Flow Integrity. In Proceedings of the 12th ACM Conference on Computer and Communications Security, Alexandria, VA, USA, 7–11 November 2005; pp. 340–353. [Google Scholar] [CrossRef] [Scilit]
  18. Tice, C.; Roeder, T.; Collingbourne, P.; Checkoway, S.; Erlingsson, Ú.; Lozano, L.; Pike, G. Enforcing Forward-Edge Control-Flow Integrity in GCC and LLVM. In Proceedings of the 23rd USENIX Security Symposium, San Diego, CA, USA, 20–22 August 2014; pp. 941–955. [Google Scholar]
  19. Kuznetsov, V.; Szekeres, L.; Payer, M.; Candea, G.; Sekar, R.; Song, D. Code-Pointer Integrity. In Proceedings of the USENIX OSDI, Broomfield, CO, USA, 6–8 October 2014; pp. 147–163. [Google Scholar]
  20. Clang Team. Control Flow Integrity. Available online: https://clang.llvm.org/docs/ControlFlowIntegrity.html (accessed on 9 September 2026).
  21. Liljestrand, H.; Nyman, T.; Gunn, L.J.; Ekberg, J.-E.; Asokan, N. PACStack: An Authenticated Call Stack. In Proceedings of the 30th USENIX Security Symposium, Virtual, 11–13 August 2021; pp. 357–374. [Google Scholar]
  22. Li, J.; Chen, L.; Xu, Q.; Tian, L.; Shi, G.; Chen, K.; Meng, D. Zipper Stack: Shadow Stacks without Shadow. In Proceedings of the 25th European Symposium on Research in Computer Security (ESORICS 2020), Guildford, UK, 14–18 September 2020; pp. 338–358. [Google Scholar] [CrossRef] [Scilit]
  23. Dang, T.H.Y.; Maniatis, P.; Wagner, D. The Performance Cost of Shadow Stacks and Stack Canaries. In Proceedings of the 10th ACM Symposium on Information, Computer and Communications Security, Singapore, 14–17 April 2015; pp. 555–566. [Google Scholar] [CrossRef] [Scilit]
  24. Zou, C.; Wang, X.; Gao, Y.; Xue, J. Buddy Stacks: Protecting Return Addresses with Efficient Thread-Local Storage and Runtime Re-Randomization. ACM Trans. Softw. Eng. Methodol. 2022, 31, 35e. [Google Scholar] [CrossRef] [Scilit]
  25. Zou, C.; Xue, J. Burn After Reading. In Proceedings of the 42nd International Conference on Software Engineering, Virtual, 6–11 July 2020; pp. 258–270. [Google Scholar] [CrossRef] [Scilit]
  26. Gravani, S.; Hedayati, M.; Criswell, J.; Scott, M.L. Fast Intra-Kernel Isolation and Security with IskiOS. In Proceedings of the 24th International Symposium on Research in Attacks, Intrusions and Defenses, San Sebastian, Spain, 6–8 October 2021; pp. 119–134. [Google Scholar] [CrossRef] [Scilit]
  27. Zhou, J.; Du, Y.; Shen, Z.; Ma, L.; Criswell, J.; Walls, R.J. Silhouette: Efficient Protected Shadow Stacks for Embedded Systems. In Proceedings of the 29th USENIX Security Symposium (USENIX Security 20), Boston, MA, USA, 12–14 August 2020; pp. 1219–1236. [Google Scholar]
  28. Linux Kernel. Control-Flow Enforcement Technology (CET) Shadow Stack, Linux 6.6 Documentation. Available online: https://docs.kernel.org/6.6/arch/x86/shstk.html (accessed on 23 August 2026).
  29. Lu, H.J. x86/cet: Enable Shadow Stack During Startup. GNU C Library Change Record, Commit 541641a3de8d89464151bd879552755e882c832e. Available online: https://sourceware.org/pipermail/glibc-cvs/2024q1/083780.html (accessed on 9 September 2026).
  30. Lu, H.J. x86-64/cet: Check the Restore Token in Longjmp. glibc Commit 35694d3416b273ac19d67ffa49b7969f36684ae1. 2024. Available online: https://sourceware.org/pipermail/glibc-cvs/2024q1/083828.html (accessed on 9 September 2026).
  31. Lu, H.J. [PATCH v2 00/16] x86/cet: Update CET Kernel Interface. libc-alpha. December 2023. Available online: https://sourceware.org/pipermail/libc-alpha/2023-December/153354.html (accessed on 9 September 2026).
  32. GNU C Library. Created Tag glibc-2.39; Release Record. 31 January 2024. Available online: https://sourceware.org/pipermail/glibc-cvs/2024q1/084106.html (accessed on 9 September 2026).
  33. ISO/IEC/IEEE 15026-2:2022; Systems and Software Engineering—Systems and Software Assurance—Part 2: Assurance Case. ISO: Geneva, Switzerland, 2022. Available online: https://www.iso.org/standard/80625.html (accessed on 9 September 2026).
  34. Object Management Group. Structured Assurance Case Metamodel (SACM), Version 2.3. October 2023. Available online: https://www.omg.org/spec/SACM/2.3 (accessed on 9 September 2026).
  35. Assurance Case Working Group. Goal Structuring Notation Standard, Version 3. Available online: https://scsc.uk/gsn-standard (accessed on 9 September 2026).
  36. Hawkins, R.; Kelly, T.; Knight, J.; Graydon, P. A New Approach to Creating Clear Safety Arguments. In Advances in Systems Safety: Proceedings of the Nineteenth Safety-Critical Systems Symposium; Springer: Berlin/Heidelberg, Germany, 2011; pp. 3–23. [Google Scholar] [CrossRef] [Scilit]
  37. Necula, G.C. Proof-Carrying Code. In Proceedings of the 24th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, Paris, France, 15–17 January 1997; pp. 106–119. [Google Scholar] [CrossRef] [Scilit]
  38. Clarke, E.M.; Grumberg, O.; Peled, D.A. Model Checking; MIT Press: Cambridge, MA, USA, 1999. [Google Scholar]
  39. Anderson, S.N.; Blanco, R.; Lampropoulos, L.; Pierce, B.C.; Tolmach, A. Formalizing Stack Safety as a Security Property. In Proceedings of the 2023 IEEE 36th Computer Security Foundations Symposium (CSF), Dubrovnik, Croatia, 10–14 July 2023; pp. 356–371. [Google Scholar] [CrossRef] [Scilit]
  40. Pnueli, A.; Siegel, M.; Singerman, E. Translation Validation. In TACAS 1998; LNCS; Springer: Berlin/Heidelberg, Germany, 1998; Volume 1384, pp. 151–166. [Google Scholar] [CrossRef] [Scilit]
  41. Zeng, B.; Tan, G.; Erlingsson, U. Strato: A Retargetable Framework for Low-Level Inlined-Reference Monitors. In Proceedings of the 22nd USENIX Security Symposium, Washington, DC, USA, 14–16 August 2013; pp. 369–382. [Google Scholar]
  42. Văduva, J.-A.; Culic, I.; Radovici, A.; Rughiniș, R.; Dascălu, Ș.-G. Vulnerability Analysis Pipeline Using Compiler Based Source-to-Source Translation and Deep Learning. eLearning Softw. Educ. 2020, 1, 645–652. [Google Scholar] [CrossRef] [Scilit]
  43. Stăniloiu, C.E.; Epure, R.-Ș.; Deaconescu, A.R.; Nițu, R.G.; Rughiniș, R.V. Scalable Concolic Execution of COTS Binaries with the River Framework. UPB Sci. Bull. Ser. C Electr. Eng. Comput. Sci. 2023, 85, 79–94. [Google Scholar]
  44. RISC-V International. The RISC-V Instruction Set Manual, Volume I: Unprivileged Architecture. Available online: https://docs.riscv.org/reference/isa/v20240411/unpriv/intro.html (accessed on 9 September 2026).
  45. RISC-V International. The RISC-V Instruction Set Manual, Volume II: Privileged Architecture. Available online: https://docs.riscv.org/reference/isa/_attachments/riscv-privileged.pdf (accessed on 9 September 2026).
  46. Kirth, P. LLVM D146463: [CodeGen][RISCV] Change Shadow Call Stack Register to X3. Commit aa1d2693c256. 2023. Available online: https://reviews.llvm.org/D146463 (accessed on 9 September 2026).
  47. Resul, E.; Iordache, Ș.-D.; Rughiniș, R.; Țurcanu, D. ECPC Supplementary Materials and Reproducibility Artifact for Evidence-Carrying Portability Contracts; Version 2.1.0; Zenodo: Geneva, Switzerland, 2026. [Google Scholar] [CrossRef]
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

Article Metrics

Citations

Article Access Statistics

Journal Statistics
Multiple requests from the same IP address are counted as one view.
WPIS: Machine Learning-Driven E-Commerce Churn Prediction Integrating Technical Metrics and Information Quality for Strategic MIS Decision Support
Previous
Task-Bound Authorization and Compliance Auditing with Quantum-Safe Task Passports for Privacy-Preserving Computation in Trusted Data Spaces
Next