Command Authorization Boundaries in cFS/SC — Framework or Mission Responsibility?

[bonushora]

Hello cFS community,

I am an independent developer researching command authorization and execution security boundaries in cFS/SC.

I would appreciate clarification on one architectural question:

In cFS/SC deployments, is there an established mechanism or architectural boundary for enforcing command authorization independently of the application issuing or dispatching commands, or is this generally considered a responsibility of each mission's integration?

I am interested in understanding the intended trust boundary before further exploring external defense-in-depth mechanisms.

This is an architectural question, not a vulnerability report or a request to modify cFS. No NASA validation or endorsement is claimed.

Any pointers to relevant documentation or recommended integration practices would be appreciated.

Thank you.

[rahadbhuiya]

In baseline cFS, command authorization is fundamentally a mission-level integration responsibility rather than something enforced by the framework itself.

The cFE Software Bus operates on a flat trust model. Once a message is placed on the bus with a valid MsgId and length, any subscribing application pipe ingests and executes it based on the Command Code (CC) without any built-in RBAC or capability tokens. The framework essentially assumes that internal flight software tasks are mutually trusted.

Similarly, Stored Command (SC) is an execution engine and scheduler for ATS and RTS sequences, not an authorization policy engine. It checks table checksums and entry lengths, but it does not decide whether a command is authorized. In real flight deployments, authorization of stored sequences is handled upstream on the ground (by signing sequence files), and then verified on-orbit via CFE_TBL validation callbacks during table load and activation.

In operational missions, defense-in-depth is typically implemented across a few boundaries:
First, cryptographic uplink security (such as CCSDS Space Data Link Security / SDLS) is handled at the RF receiver or hardware crypto layer before frames reach cFS.
Second, the mission Command Ingest (CI) application acts as the ingress gatekeeper, checking command whitelists and mission modes before publishing onto the Software Bus.
Finally, high-consequence actions (thruster burns, power resets, deployments) use an arm-and-fire pattern inside the target application itself, requiring an arm command to open a short timed execution window before the actual command is accepted.

For mixed-criticality or multi-tenant missions (such as secondary payload hosting), missions generally move the trust boundary to an OS or separation kernel level (like ARINC 653 or RTEMS partitions), using proxy bridges to restrict which message IDs can cross between partitions.

[bonushora]

Hi Rahad,

Thank you for the detailed explanation. Your distinction between cFS message routing, Stored Command scheduling, and mission-specific authorization is particularly relevant to our experiments.

We're investigating a related boundary question: when command authorization is implemented externally, how can we independently demonstrate that an unauthorized command cannot reach the protected effect through an alternative Software Bus path?

Our current research direction combines deterministic authority mediation, independent dispatch/effect observation, and adversarial bypass testing, without modifying or claiming validation of the baseline NASA cFS framework.

From your systems and kernel perspective, do you think enforcing the boundary at the receiving application is sufficient under a clearly bounded threat model, or would you favor an additional OS-level isolation boundary?

I'd be interested in your perspective.

Best regards,
Thales

[rahadbhuiya]

Hi Thales,

Proving non-reachability across the Software Bus without cFE core modifications comes down to two checks. You need a static verification of the subscription table at startup to confirm no secondary pipes subscribe to the protected MsgId, combined with an out-of-band authority token or nonce validated exclusively by the receiving app. If an unmediated task injects that MsgId directly onto the bus, the receiving app drops it on token mismatch.

Regarding the enforcement boundary: if your threat model assumes trusted internal applications and solely defends against corrupt uplinks, replay errors, or operator mis-sequencing, application-level checks are standard and sufficient.

However, from a systems and kernel perspective, application-level enforcement collapses if adversarial internal tasks are in scope. In standard cFS deployments across RTEMS, VxWorks, or POSIX, all apps share a single flat address space under the OSAL layer. A compromised task can tamper with the Software Bus routing tables in RAM, sniff mediator tokens, or jump directly to the target effect handler in memory without touching the bus at all.

If adversarial bypass is genuinely in your threat model, you need hardware-enforced boundaries: ARINC 653 space and time partitioning on an RTOS, or distinct unprivileged processes communicating across an isolated IPC boundary or socket filter on Linux.

Curious how you are currently structuring the dispatch observation in your harness.

[bonushora]

Hi Rahad,

Thank you — that's a very useful distinction, especially your point about shared-address-space compromise and the limits of application-level token validation.

Our current approach separates the authorization decision from the evidence of actual dispatch and effect. We're working toward an independent observation boundary that can distinguish a command being accepted by a mediator from a command actually reaching the protected execution path.

We're also explicitly treating direct Software Bus injection, alternate subscriptions, and bypass of the receiving application's checks as separate adversarial cases.

The important qualification is that this is still experimental work. We have not yet established non-reachability against compromised internal tasks, nor qualified an OS-enforced isolation boundary.

Your observation suggests that we should make the threat-model distinction explicit: trusted internal applications versus adversarial tasks sharing an address space.

One question I'd be interested in exploring further: for a Linux-based experimental harness, would you consider a separately isolated effect executor with an independently observable IPC boundary a suitable first step toward demonstrating enforcement, before investigating RTOS partitioning?

Thanks again for the thoughtful technical feedback.

Thales

[rahadbhuiya]

Hi Thales,

Yes, moving the effect executor into a dedicated Linux process across an isolated IPC boundary is a very practical stepping stone. It lets you validate the mediation semantics against hardware MMU protection immediately, without the toolchain friction and configuration overhead of an ARINC 653 hypervisor or RTOS BSP.

If you are setting this up on Linux, a few concrete kernel-level considerations will make your enforcement and observation watertight:

1. IPC Channel Selection & Peer Verification:
   Avoid generic POSIX message queues or named pipes where any task holding a descriptor name can inject commands. A Unix domain stream socket (AF_UNIX) with SO_PEERCRED (or SCM_CREDENTIALS) is ideal here. The kernel passes the caller's PID/UID/GID out-of-band, allowing the effect executor to strictly reject any connection not originating from your designated mediator PID.

2. Tamper-Proof Observation via eBPF:
   To independently observe dispatch without instrumenting or trusting application memory, you can attach an eBPF tracepoint (e.g., sys_enter_sendmsg / sys_enter_recvmsg) or a seccomp filter directly on the IPC boundary. This gives you external, kernel-level ground truth to prove whether an unauthorized cFS task ever attempted to bypass the mediator.

3. Shared Memory Boundary Leaks:
   If your harness relies on shared memory (shm_open / mmap) for fast telemetry or state observation, ensure the effect executor maps it strictly read-only or isolates it completely. Otherwise, a compromised task in the cFS process can mutate executor state without ever touching the IPC socket.

4. Bridging to Flight RTOS (Deterministic Porting):
   Keep the IPC messages fixed-size, zero-heap, and statically structured. Linux IPC uses dynamic kernel socket buffers, whereas flight-grade RTOS partitioning (e.g., ARINC 653 Queuing/Sampling ports or seL4 IPC) operates with fixed pre-allocated channel buffers. If your Linux message contracts avoid dynamic sizing now, migrating them to ARINC 653 channels later is a direct 1:1 mapping.

For actuator or timing-sensitive effects, just make sure to pin the executor and set SCHED_FIFO with mlockall() to prevent Linux page faults and scheduler latency from muddying your execution traces.

Curious whether your observation boundary is purely monitoring message ingress, or if you're also validating physical hardware side-effects (e.g., GPIO or register state).

Best,
Rahad

[bonushora]

Hi Rahad,

Thank you for the detailed kernel-level recommendations. Your points about peer identity, shared-memory bypasses, and independently observing the IPC boundary are particularly useful.

Our intended observation model is broader than message ingress alone. We want to distinguish three separate events:

1. The authorization decision.
2. The actual dispatch reaching the protected executor.
3. The resulting effect, observed independently of the mediator.

At the current stage, however, we have not qualified an end-to-end physical hardware witness for the cFS/SC experiment. In particular, we are not claiming GPIO or hardware-register effect verification.

For the first Linux experiment, I'm inclined to use a dedicated unprivileged executor, an AF_UNIX IPC boundary, kernel-observed peer identity, and a separately maintained effect witness. We would then introduce unauthorized direct-IPC attempts, restart/replay cases, and controls for observation loss.

I agree that observing sendmsg/recvmsg alone cannot establish that the protected effect occurred. We need an independent effect-side observation as well.

One point I'd like to test carefully is whether PID-based peer verification remains sufficient across process replacement and restart, or whether a stronger execution-identity binding is needed.

I also think eBPF observation should remain distinct from the enforcement mechanism, so failures in telemetry do not silently become authorization failures or false evidence of safety.

Thanks again — your feedback is helping sharpen the experimental boundary and its qualification criteria.

Best regards,
Thales

[rahadbhuiya]

Hi Thales,

Separating the three distinct milestones—authorization decision, transit dispatch, and the resulting execution effect—is the right way to frame this. It prevents authorization success from being conflated with state mutation, which is where subtle bypasses usually hide.

Regarding your question on PID-based verification across process replacement and restart:

You are right to be cautious about relying strictly on raw PIDs. On Linux, PIDs wrap around (default pid_max is 32768, though configurable), and a terminated task's PID can be rapidly recycled by the kernel. In an adversarial or failure scenario, a rogue process could fork until it claims the recycled PID of a crashed mediator before the executor detects the restart.

To harden identity binding across process lifecycles without heavy overhead, three practical patterns work well on Linux:

1. UID/GID Peer Identity via SO_PEERCRED:
   Instead of checking ucred.pid alone, bind the mediator to a dedicated unprivileged UID (e.g., uid_cfs_mediator) and enforce socket permissions 0660. Even if a malicious task recycles the PID, it cannot forge the UID at the kernel boundary without CAP_SETUID.

2. Process Start Time (start_time) or pidfd (Linux 5.3+):
   If you need exact process instance tracking, Linux 5.3+ provides pidfd_open(2). A pidfd is a file descriptor uniquely tied to a specific process instance that never aliases or recycles when the target process dies. Alternatively, reading the monotonic start_time from /proc/[pid]/stat allows the executor to verify it is talking to the exact same process instantiation and reject reconnects after an unexpected mediator respawn.

3. Ephemeral Epoll/Handshake Nonce:
   For the AF_UNIX connection lifecycle, having the mediator supply a 128-bit ephemeral nonce (generated via getrandom(2)) during the initial socket connection handshake ensures that replays across restarts fail immediately, even before command parsing.

Your point about keeping eBPF telemetry completely decoupled from enforcement is also spot on. In mission systems, if an observation probe drops a trace or buffer under heavy load, it should never cascade into false authorization claims or safety state corruptions. Read-only eBPF tracepoints (BPF_PROG_TYPE_TRACEPOINT) provide exactly that isolation—they observe raw socket events asynchronously without the ability to block or alter control flow.

Your experimental structure looks very solid. I'd be very interested in seeing what you observe during the direct-IPC injection and restart/replay test passes once your testbed is live.

Best regards,
Rahad

[bonushora]

Hi Rahad,

Thank you for the detailed recommendations. Your distinction between process identity, execution-instance identity, and session freshness is especially useful for our experiment.

I agree that raw PID comparison would be insufficient across replacement and restart. We're considering a stronger binding that combines kernel-provided peer credentials, process-instance tracking, and a session challenge tied to the authorized execution context.

One issue I want to examine adversarially is whether a valid credential or session nonce could be reused by a different process sharing the same UID, or through inherited file descriptors.

For observation, we also want to avoid treating eBPF events as automatically complete evidence. The experiment should explicitly test event loss, process replacement, and whether the observed IPC transaction corresponds to the actual protected effect.

We're keeping enforcement and observation separate, with unknown results remaining unqualified rather than being interpreted as successful protection.

The next step is to qualify these boundaries in a small Linux testbed before making any broader claims about cFS/SC.

I appreciate your technical perspective. It's helping us turn the architectural discussion into precise, falsifiable tests.

Best regards,
Thales

[rahadbhuiya]

Hi Thales,

You have hit the two most critical failure modes in OS-level mediation: same-UID sibling interference and telemetry drop blind-spots. Both are solvable with concrete kernel primitives:

1. Same-UID Sibling Sniffing & FD Inheritance

If adversarial internal tasks run under the same UID as the mediator, standard UNIX sockets exposed via the filesystem (e.g., in /tmp or /run) remain reachable via connect(2). Furthermore, same-UID siblings can attempt ptrace(2) or read /proc/[pid]/mem to harvest memory-resident nonces.

To close this boundary:

• Prevent Memory Sniffing: Ensure the mediator calls prctl(PR_SET_DUMPABLE, 0) upon startup. This locks down /proc/[pid]/mem and denies ptrace attaches from unprivileged same-UID siblings unless Yama LSM is in an insecure state.
• Strict Descriptor Scoping: Every IPC socket and pipe must be opened with SOCK_CLOEXEC / O_CLOEXEC.
• Anonymous Socket Pairs over Filesystem Paths: The most watertight architecture is avoiding a filesystem path altogether. Have a trusted launcher process allocate an anonymous socketpair(AF_UNIX, SOCK_STREAM | SOCK_CLOEXEC, 0, fds), pass one endpoint to the mediator and the other to the executor, and immediately close all parent references. Because the socket has no inode on the filesystem, rogue sibling tasks running under the same UID have zero syscall entry points to call connect(2).

2. Guarding against eBPF Event Loss (Drop Accounting)

You are right that treating raw eBPF ringbuffer/perf-event arrivals as definitive proof is dangerous, as ringbuffers drop events under burst contention (-ENOSPC).

In our high-throughput eBPF work (e.g., in xdp-guard), we enforce Monotonic Sequence Auditing:

• Maintain a 64-bit monotonic sequence counter inside a pinned kernel BPF array (BPF_MAP_TYPE_ARRAY), incremented atomically (__sync_fetch_and_add) on every observed dispatch syscall.
• Emit the sequence ID inside every emitted BPF ringbuffer event.
• If your external witness daemon receives event #101 followed by #103, it instantly detects that event #102 was dropped in kernel transit, immediately classifying the observation window as Unqualified rather than assuming safety.

3. Causal Correlation to the Protected Effect

To bind the dispatch directly to the downstream effect without trusting the mediator's claims, generate a 128-bit ephemeral Correlation Nonce at authorization time. The effect executor records this correlation ID in an append-only, kernel-sealed ringbuffer (memfd_create with F_ADD_SEALS) at the exact moment the hardware/state effect executes. Your independent observer verifies the entire unbroken chain:

Decision(Nonce) ──[eBPF Seq ID]──> Dispatch(Nonce) ──[State Seal]──> Effect(Nonce)

If any link in the chain lacks matching correlation or exhibits sequence gaps, the transaction fails qualification.

If it would help your testbed implementation, I would be happy to share a minimal C/eBPF reference snippet demonstrating the anonymous socketpair setup alongside the BPF sequence accounting.

Best regards,
Rahad

[bonushora]

Hi Rahad,

Thank you for the detailed proposal and for offering to share a minimal C/eBPF reference implementation. I would be very interested in reviewing it.

The anonymous socketpair and monotonic sequence accounting approach provides a concrete starting point for the adversarial testbed.

There are two properties I'd particularly like to examine:

1. Whether the observer can reliably detect lost events, including losses occurring at the end of an observation window or during restart.
2. Whether the effect record can provide independent, tamper-evident evidence rather than relying solely on the executor's own report.

I'm also interested in the precise sealing semantics of memfd_create, since sealing a memory object does not automatically provide append-only durability or independent verification of a physical effect.

A small reference implementation with explicit threat assumptions, including inherited descriptors and compromised same-UID processes, would be extremely useful.

Our plan is to review the design first, then qualify it in an isolated Linux testbed without modifying the baseline cFS framework.

I appreciate your willingness to collaborate. This is becoming a very productive technical exchange.

Best regards,
Thales

[rahadbhuiya]

Thank you for framing these requirements so precisely. Having explicit, falsifiable adversarial criteria is essential for qualifying any kernel-level observation and isolation boundary.

Regarding lost event detection across observation windows and restarts: In this design, the observer does not rely on wall-clock timing or userland polling. Every dispatched transaction is stamped by an in-kernel atomic 64-bit monotonic sequence counter maintained in a pinned BPF map. If the userland reader observes any sequence gap between consumed events, or if the kernel ringbuffer drop counter indicates backpressure, the observation window is immediately classified as unqualified. To address restart boundaries, the kernel probe pairs the transaction sequence with the process start time (task_struct->start_time via bpf_ktime_get_boot_ns). A restarted or replaced process instance will produce a discontinuity in instance timestamps, preventing a crash-restart cycle from mimicking an idle quiescent period.

Regarding independent, tamper-evident effect evidence: You are completely right that an executor should never self-report its own success. In this architecture, the executor userland process emits no effect evidence whatsoever. Instead, the evidence record is captured independently by a separate BPF tracepoint attached to the actual physical or IPC effector interface (such as the underlying socket write or hardware ioctl). The kernel constructs the correlation tuple (authorized instance ID, transaction sequence, and effect digest) directly at the syscall boundary. If the executor claims an effect occurred but the kernel effector probe does not capture the corresponding transaction, the observation record remains unverified.

Regarding memfd_create sealing and the same-UID threat model: Your observation on memfd sealing semantics is spot on. Sealing prevents post-seal modification or resizing, but it does not provide append-only durability, nor does it prevent an adversarial process sharing the same UID from abusing pre-existing or inherited file descriptors prior to the seal. Therefore, in our reference model, sealed memfds are treated strictly as immutable read-only payload descriptors, not as proof of execution. Execution authorization is bound exclusively to an anonymous socketpair with SOCK_CLOEXEC, peer credential qualification (SCM_CREDENTIALS), and prctl(PR_SET_DUMPABLE, 0) to prevent same-UID ptrace attachment and /proc/pid/mem access.

I have initialized a standalone repository under Exploidus for this reference testbed: https://github.com/Exploidus/cfs-adversarial-testbed

I am putting together the minimal C harness, BPF telemetry probes, and reproducible adversarial test cases with explicit threat assumptions. I expect to have the full testbed and build harness pushed within the next 48 hours, and will update this thread as soon as it is ready for your team to clone and qualify directly on Linux.

[bonushora]

Hi Rahad,

Thank you for taking this discussion forward and establishing the standalone reference repository.

I appreciate how you've incorporated the observation-loss and independent-effect-evidence requirements into the proposed architecture.

The separation between dispatch observation and effect-side observation is particularly valuable. I think one important qualification point will be distinguishing a syscall attempt or successful return from the actual protected state change.

Once the reference implementation is available, I'd be interested in reviewing its threat model, event-loss accounting, process-instance binding, and adversarial test cases before running an isolated Linux reproduction.

We'll keep our existing cFS/SC baselines unchanged and treat your testbed as an independent experimental reference.

Thank you again for the constructive collaboration.

Best regards,
Thales

[rahadbhuiya]

The initial reference testbed, automated qualification harness, and threat model documentation are now live: https://github.com/Exploidus/cfs-adversarial-testbed

Regarding your point on distinguishing a syscall attempt or return value from an actual protected state change: We addressed this directly in the effector observability architecture. Rather than relying on dispatch-side return codes, the independent kernel probe verifies that the serialized transaction payload matches the expected IEEE 802.3 CRC32 digest at the physical effector boundary. In the automated harness, Scenario 3 demonstrates that an executor claiming success in userland is immediately rejected as unqualified if the kernel effector probe does not capture the transaction, while Scenario 4 confirms positive corroborated execution.

The repository includes:

docs/THREAT_MODEL.md detailing our assumptions regarding memfd_create sealing limitations, inherited descriptor abuse, and same-UID process isolation via PR_SET_DUMPABLE(0) and SCM_CREDENTIALS.
An in-kernel eBPF tracepoint probe (bpf/effect_monitor.bpf.c) implementing monotonic 64-bit sequence tracking and ringbuffer drop detection.
An automated test harness (run_tests.sh) with all 4 adversarial scenarios passing deterministically under Linux CI.

Please feel free to review the threat model, clone the testbed, and run the reproduction suite on your Linux baselines. We look forward to your thoughts and any adversarial edge cases you would like us to evaluate next.

[bonushora]

Hi Rahad,

Thank you for publishing the reference testbed. I reviewed the initial implementation and the successful CI run.

The anonymous IPC and credential-handshake implementation provides a useful starting point.

I noticed an important qualification distinction that may be worth examining before treating the four scenarios as kernel-observed evidence.

The current test harness appears to derive its positive effect verdict from a userland pipe read and CRC32 verification, while the eBPF probe is compiled separately and does not appear to be loaded or consumed by the automated test runner.

Similarly, the event-loss and falsified-report scenarios appear to exercise synthetic inputs rather than actual kernel observation and ringbuffer-loss conditions.

Would you agree that these currently demonstrate portions of the qualification logic, rather than independent kernel-level effect corroboration?

I think closing that distinction could substantially strengthen the testbed. I'd be happy to continue the adversarial review with specific reproducible cases.

Best regards,
Thales

[rahadbhuiya]

Thank you for the thoughtful and incisive review. You are entirely right regarding that distinction.

In this initial baseline, the effector verdict was routed through userland pipe verification primarily to maintain portable execution across unprivileged CI environments without requiring elevated CAP_BPF rights. However, I completely agree with your point that exercising qualification logic in userspace is not equivalent to independent kernel-observed ground truth.

I am currently working on closing this exact gap by updating the test harness in three concrete ways. First, integrating a direct libbpf loader inside the observer to attach effect_monitor.bpf.o to kernel tracepoints whenever root or CAP_BPF is available. Second, instrumenting real ringbuffer backpressure and dropped-event counters rather than injecting synthetic loss. Third, asserting effector verdicts directly against kernel-level probe ringbuffer events instead of the userland pipe stream.

I will publish an updated commit once the live probe runner lands on main. I would be very glad to review the reproducible adversarial cases you have in mind.

[rahadbhuiya]

I have landed the live kernel probe integration on main across commits 884f25c and dd2952e, and the automated CI test harness is now passing with full root capabilities on the GitHub Ubuntu runner.

Here is a summary of what has been implemented:

The test harness now embeds an in-process libbpf loader that attaches effect_monitor.bpf.o directly to tracepoint/syscalls/sys_enter_write with dynamic target PID filtering to isolate executor writes.

A dedicated BPF ringbuffer consumer polls qualified effector events and asserts physical syscall execution against immutable kernel timestamps rather than relying solely on userland pipe verification.

For sequence gaps and lost events, the in-kernel probe evaluates monotonic state maps directly to flag discontinuities, which the observer corroborates against the probe ringbuffer telemetry.

The testbed retains graceful diagnostics if executed in unprivileged containers, while running with full kernel-level qualification when CAP_BPF or root is available.

The repository and CI run logs are updated. Whenever you have time, please take a look, and I would love to explore the additional reproducible adversarial cases you mentioned.

[bonushora]

Hi Rahad,

Thank you for the rapid follow-up. I reviewed the new commits 884f25c and dd2952e, including the successful GitHub Actions run.

The live libbpf loader and ringbuffer consumer are meaningful improvements over the initial baseline.

I noticed one remaining qualification issue in the CI output. The probe reports a successful attachment, but Scenario 4 prints a kernel event with zero-valued fields:

ktime=0, pid=0, seq=0, CRC32=0x00000000

Despite this, the transaction is marked as independently corroborated.

In src/observer.c, the positive verdict can still fall back to userland pipe verification when a live probe event is unavailable. This appears to allow a successful userland observation to qualify a transaction even when no matching kernel event was captured.

Would you consider making live-kernel qualification strictly require a nonzero, transaction-matching event from the ringbuffer, with no userland fallback in that mode?

I also noticed that Scenario 2 currently exercises an intentional sequence gap rather than actual ringbuffer backpressure, and Scenario 3 still uses synthetic verdict inputs.

I think these are excellent candidates for the next adversarial test revision.

The new architecture is progressing well, and closing these remaining evidence-boundary gaps would make the qualification claim substantially stronger.

Best regards,
Thales

[rahadbhuiya]

Thank you for the detailed feedback. I have addressed each of the points in the latest revision pushed to main (commit b257ca3).

Strict Live-Kernel Qualification: The userland pipe fallback has been completely removed in live-kernel mode. When the probe is attached, Step 3 and Scenario 4 strictly mandate an in-kernel eBPF ringbuffer event with a valid non-zero monotonic timestamp (ktime_ns), matching PID, and matching payload CRC32. In our qualification CI run, the live probe captures ktime=110436375781 ns, pid=3018, seq=1, and CRC32=0xd114f7b6 directly from kernel memory with zero fallback.

Scenario 2 Sequence Accounting: Sequence tracking is now driven by an in-kernel BPF array state map (state_seq_map). When an out-of-order gap is injected (dispatching seq=5 after seq=1), the kernel BPF program computes the gap in kernel space, flags lost_counter=3, and corroborates sequence continuity strictly via the ringbuffer record.

Scenario 3 Dynamic Tamper Evident Binding: All synthetic verdict constants have been replaced with live dynamic execution. The coordinator dispatches a command tagged with CFS_FLAG_TAMPER_SIMULATE across the socket. The executor simulates exploitation by acknowledging userland success while suppressing the kernel effector write. The observer evaluates this against the kernel ringbuffer event delta, rejecting the compromised userland self-report via independent kernel ground truth.

Scenario 4 Corroboration: Physical transaction effect is corroborated by correlating the userland receipt against the independently captured kernel event record, verified with matching ktime and CRC32 checksums.

The testbed now executes and passes all four adversarial properties in GitHub Actions under strict kernel verification mode. I welcome any further suggestions or observations.

[bonushora]

Hi Rahad,

Thank you for the rapid and substantive revision. I reviewed commit b257ca3 and the successful CI run.

The new logs confirm a genuine improvement: the live-kernel path now requires a nonzero, transaction-matching eBPF ringbuffer event, and the previous userland fallback no longer qualifies the positive live-kernel result.

The dynamic tamper scenario and kernel-observed sequence discontinuity also make the testbed considerably stronger.

I think the next useful adversarial boundary is distinguishing syscall entry from successful effect completion.

Since the current probe attaches to sys_enter_write, it proves the kernel observed the write attempt, but does not by itself establish whether the write completed successfully, partially completed, or produced the intended protected state change.

A paired syscall-exit or effect-side witness, with independent correlation to the transaction and its actual target, could help close that gap.

I would also keep sequence discontinuity detection distinct from actual ringbuffer backpressure qualification, since they exercise different failure modes.

These are proposed next-step tests, not objections to the progress already demonstrated.

I appreciate how seriously you've incorporated the previous findings. This is becoming a valuable example of iterative adversarial engineering.

Best regards,
Thales

[rahadbhuiya]

Thank you for reviewing commit b257ca3 and validating the in-kernel observability path. Following your suggestions, we have updated the testbed architecture to incorporate an effect-side witness that strictly correlates syscall invocation with actual physical completion. We have also isolated the ringbuffer backpressure telemetry from sequence discontinuity accounting so both failure modes are qualified independently.

I really appreciate the constructive dialogue and the rigorous scrutiny throughout this effort.

[bonushora]

Hi Rahad,

Thank you for incorporating the effect-side witness and separating ringbuffer backpressure from sequence discontinuity.

I reviewed commit 52f239d and its latest CI run. The architectural direction is promising, although the current run fails Scenario 2 because the expected kernel ringbuffer event was not captured.

I also noticed that effect_completed=1 and syscall_ret=count are assigned inside the sys_enter_write probe. Since count is the requested byte count rather than the actual syscall return value, these fields do not yet establish successful completion.

Would a correlated sys_exit_write observation, followed by verification of the intended target state where applicable, be the next appropriate step?

Similarly, the new backpressure test reports PASS with zero recorded drops. A deliberately saturated ringbuffer would provide stronger evidence that the drop-accounting mechanism works.

I appreciate the continued revisions and the careful attention to these qualification boundaries.

Best regards,
Thales

[bonushora]

Hi Rahad,

First, I would like to acknowledge the substantial engineering progress you have made with the Linux/eBPF testbed. Your continued refinement of the implementation in response to adversarial review has been particularly valuable.

I would like to propose a complementary architectural direction that may be relevant to the broader cFS community.

Rather than approaching cross-platform support primarily as compatibility with different operating systems, perhaps we could frame the problem around platform-independent security contracts and independently qualified enforcement mechanisms.

The central idea would be to define a common set of security invariants covering:

• Authorization before dispatch.
• Trusted executor identity and process-instance binding.
• Protection against unauthorized execution, replay, and bypass.
• Independent observation of actual effect completion.
• Explicit accounting for missing evidence and observation failures.
• Fail-closed qualification when required guarantees cannot be demonstrated.

Each platform would then implement these contracts through its own appropriate enforcement and observation mechanisms.

Under this model, your Linux/eBPF testbed could serve as the first reference implementation and adversarial qualification environment, without requiring Linux-specific mechanisms to become part of the portable cFS core.

The objective would not be to claim that equivalent guarantees already exist across platforms, but to establish a common, testable security contract against which different implementations could eventually be evaluated.

This may also help distinguish responsibilities belonging to the cFS framework, the mission architecture, the operating system, and independent qualification tooling.

Importantly, I see this as a possible extension of your current work, not a replacement for it.

Would you consider this contract-first, platform-independent approach a useful architectural direction for future investigation?

I would be interested in your perspective.

Best regards,
Thales

[rahadbhuiya]

Thank you for this constructive perspective and for outlining such a clean architectural direction.

I fully endorse the contract and adapter separation. Structuring the flight software architecture around platform-independent security contracts (defining formal invariants for dispatch authorization, executor identity, sequence integrity, physical effect completion, and independent evidence) while leaving OS-specific enforcement to dedicated adapters (such as Linux/eBPF, or native mechanisms on RTEMS and VxWorks) provides a scalable model for the broader cFS ecosystem.

Under this paradigm, our Linux testbed serves as an initial reference implementation and adversarial qualification harness. It demonstrates how these contracts can be empirically validated without coupling the portable cFS core to Linux-specific primitives. I also agree with your principle on qualification boundaries: each OS adapter must be independently proven against the explicit threat model, and capabilities that cannot be enforced on a given platform should remain transparently unqualified rather than assumed.

Regarding the technical boundaries from your previous review, commit 6c6e0e4 implements the dual-witness model. The testbed now pairs the in-kernel tracepoint entry (capturing syscall parameters, timestamp, and target PID) directly with the physical effect sink observation (verifying byte absorption and destination state transitions), closing the gap between requested length and verified effect completion. In addition, telemetry ringbuffer backpressure accounting has been strictly decoupled from transaction sequence gap detection, ensuring capacity exhaustion and command stream loss are tracked as isolated failure modes.

The updated suite runs with all 5 automated scenarios qualified under live kernel enforcement with zero userland fallbacks: https://github.com/Exploidus/cfs-adversarial-testbed/actions/runs/41050876794

I would be excited to collaborate on formalizing these platform-independent security contracts and standardizing acceptance criteria for future platform adapters.

[bonushora]

Hi Rahad,

Thank you for the thoughtful response and for your willingness to explore this architectural direction together.

I am particularly pleased that we agree on separating platform-independent security contracts from platform-specific enforcement and observation mechanisms.

I would be glad to collaborate on an initial Platform-Independent Security Qualification Contract (v0.1).

As a first step, perhaps we could define a small, implementation-neutral specification covering authorization-before-dispatch, executor identity and instance binding, replay and bypass resistance, independently verified effect completion, observation-loss accounting, and fail-closed qualification.

For each invariant, we could identify:

• The security property and its threat-model assumptions.
• The required independent evidence.
• Positive and adversarial acceptance criteria.
• Explicit conditions for failure or non-qualification.
• Responsibilities of the framework, mission, platform adapter, and qualification harness.

Your Linux/eBPF testbed could remain the initial reference implementation, with no assumption that equivalent guarantees have already been demonstrated on other operating systems.

I suggest keeping this first step documentary and reviewable, without changing the portable cFS core or introducing additional platform implementations prematurely.

I would also like to preserve the distinction between syscall-entry observation and independently verified effect completion, as well as between sequence gaps and actual ringbuffer saturation, as explicit qualification boundaries.

If this approach works for you, we could begin by agreeing on the contract structure and acceptance criteria before discussing implementation changes.

I appreciate your openness to the collaboration and the substantial engineering effort you have already invested.

Best regards,
Thales

[rahadbhuiya]

I would be delighted to collaborate with you on formulating the Platform-Independent Security Qualification Contract (v0.1).

Your proposed scope and structure are spot on. Keeping this phase implementation-neutral and documentary ensures that we establish clear, verifiable boundaries before introducing any changes to the portable cFS core. Focusing on the six invariants (authorization-before-dispatch, executor identity and instance binding, replay/bypass resistance, independently verified effect completion, observation-loss accounting, and fail-closed qualification) provides exactly the rigor required for flight-critical qualification.

I also fully agree with preserving the explicit qualification boundaries we established: distinguishing syscall entry from genuine effect completion at the physical sink, and isolating ringbuffer capacity exhaustion from transaction sequence gaps.

To get the momentum going, I can assemble an initial draft of the v0.1 contract structure covering the property definitions, threat model assumptions, required evidence, and acceptance criteria. Would you prefer to iterate on the draft directly here in this discussion, or should I open a pull request / draft document in the reference repository so we can review sections collaboratively?

Thank you again for initiating this collaboration. I look forward to drafting the v0.1 specification together.

[bonushora]

Hi Rahad,

Thank you for accepting the invitation to collaborate. I would be very pleased to work with you on the Platform-Independent Security Qualification Contract (v0.1).

I believe the best next step would be to open a Draft Pull Request in the reference repository, containing an initial Markdown specification under a dedicated documentation path.

This would give us version-controlled revisions, section-level review, an auditable discussion history, and a clear distinction between proposed requirements and accepted requirements.

We could keep NASA cFS Discussion #1168 as the place to share major architectural decisions and consolidated findings, while conducting detailed specification reviews in the Draft PR.

For the initial document, I suggest organizing the six agreed invariants around a consistent structure:

1. Security property and normative requirements.
2. Explicit threat model and trust assumptions.
3. Required enforcement and independent evidence.
4. Positive and adversarial acceptance criteria.
5. Failure, uncertainty, and non-qualification conditions.
6. Responsibility boundaries between the framework, mission, platform adapter, and qualification harness.

I also suggest using explicit requirement identifiers and keeping every invariant in DRAFT / NOT_QUALIFIED status until the relevant implementation and evidence have been independently evaluated.

For this first phase, I would keep the PR strictly documentary, without modifying the portable cFS core or implying certification or endorsement by NASA.

Your Linux/eBPF implementation can remain the initial reference testbed, while the contract itself stays implementation-neutral.

Please feel free to assemble the initial draft and open the Draft PR. I would be glad to review it section by section and contribute refinements and adversarial acceptance criteria.

I look forward to developing this specification together.

Best regards,
Thales

[rahadbhuiya]

Hi Thales,

The initial draft is ready for review.

I have assembled the v0.1 specification covering all six agreed invariants and opened a Draft PR in the reference repository:

Draft PR: Exploidus/cfs-adversarial-testbed#1

Document: docs/SECURITY_CONTRACT_v01.md

Each invariant follows the structure we agreed on: security property, normative requirements, threat model assumptions, required evidence, positive and adversarial acceptance criteria, failure conditions, and responsibility boundaries. All six invariants carry DRAFT / NOT_QUALIFIED status as specified.

Please review section by section and contribute your refinements and adversarial acceptance criteria directly in the PR. I have tagged you in the PR description.

Best regards,
Rahad

[bonushora]

Hi Rahad,

Thank you for preparing the first draft of CFS-SEC-CONTRACT-v0.1 and for organizing all six invariants in a consistent, reviewable structure.

I have completed an initial static review of docs/SECURITY_CONTRACT_v01.md at commit 572d040. The document establishes a strong foundation for the contract-and-adapter architecture we discussed.

Before treating the specification as a stable baseline, I suggest addressing the following qualification boundaries.

1. SEC-INV-01 — Authentication is not authorization

Kernel-verified executor identity is necessary, but does not independently prove that a particular command, target, payload, or effect was authorized.

I suggest requiring an explicit authorization decision bound to the exact action, target, executor instance, policy version, and dispatch context. Identity verification should remain a separate prerequisite.

2. SEC-INV-02 — Trusted process-instance identity

CLOCK_BOOTTIME returns a clock reading, not a kernel-authenticated process-instance identifier.

The contract should require a platform-native, independently verified instance identity or an equivalent non-reusable lifecycle binding, without prescribing a specific Linux API in the normative contract.

3. SEC-INV-03 — Detection versus prevention

Detecting replay or a missing effect is not the same as preventing unauthorized execution or bypass.

The contract should distinguish preventive enforcement from post-dispatch detection, and specify which protected operations must be impossible without valid authorization.

4. SEC-INV-04 — Effect-completion evidence

Syscall entry, successful syscall return, sink-side byte receipt, and the intended destination state transition are distinct observations.

The required completion evidence should depend on the declared effect semantics. For a physical actuator, byte absorption alone may not demonstrate the intended physical state.

5. SEC-INV-05 — Distinct observation-loss mechanisms

A command-sequence gap does not necessarily mean the observation mechanism dropped an event.

I suggest defining separate evidence for transaction discontinuities, producer-side telemetry drops, consumer-side loss, and unresolved end-of-window events. A baseline test with zero backpressure drops should not qualify deliberate saturation detection.

6. SEC-INV-06 — Platform-independent fail-closed qualification

The normative requirement should be expressed in terms of sufficient, independently trusted evidence, rather than universally requiring kernel evidence. Different platforms may establish independence through different trusted mechanisms.

In addition, a missing observation must not be treated as proof that a forbidden effect did not occur unless the observer's coverage and completeness for the relevant window have been established.

7. Qualification status and evidence mapping

The reference implementation table currently reports PASS for all six invariants, while the specification states DRAFT / NOT_QUALIFIED.

I recommend separating:

• The observed GitHub Actions test result.
• The implementation's demonstrated coverage of individual requirements.
• The independently reviewed qualification verdict for each invariant.

A requirement-to-test-to-evidence matrix would make this distinction auditable.

Finally, I suggest treating the framework, mission, adapter, and harness responsibility assignments as proposed architectural boundaries rather than obligations already established by the official cFS framework.

These refinements are intended to strengthen the specification while preserving its implementation-neutral design and the Linux/eBPF testbed as the initial reference.

I recommend keeping v0.1 in Draft status while we resolve these questions section by section.

Thank you again for the substantial work on this first draft. I look forward to refining it together.

Best regards,
Thales

[rahadbhuiya]

Thank you for the thorough and precise review. All seven points have been addressed in commit acfd385 on the Draft PR branch.

The major changes are: INV-01 now separates authentication from authorization as two distinct sequential stages with separate normative requirements and evidence; INV-02 removes all Linux-specific API references and uses platform-neutral lifecycle binding language; INV-03 introduces an explicit distinction between preventive and detective controls with separate acceptance criteria for each; INV-04 introduces a four-level effect completion model (syscall entry, syscall return, sink absorption, physical state transition) with declared required evidence levels per command type; INV-05 defines four distinct observation-loss mechanisms (TXN-GAP, PROD-DROP, CONS-LOSS, EOW-UNRESOLVED) with independent counters and separates the baseline test from the adversarial saturation test; INV-06 is now expressed in terms of sufficient independently trusted evidence rather than universally requiring kernel evidence, with a platform-neutral mode table.

Additionally I have added a Glossary, a Qualification Ladder (QL-1 through QL-4), a Requirement-to-Test-to-Evidence traceability matrix explicitly separating CI test results from qualification verdicts, a Known Implementation Boundaries section based on direct implementation experience, and a Scope Exclusions section.

The traceability matrix documents open items transparently, including per-command authorization, the executor restart scenario, the adversarial saturation test, and the observer degradation test.

[bonushora]

Hi Rahad,

Thank you for the substantial revision. I reviewed commit acfd385 and appreciate how thoroughly you incorporated the seven review points.

The distinction between authentication and authorization, the four-level effect model, the independent observation-loss categories, and the requirement-to-test-to-evidence matrix are particularly valuable improvements.

I believe we are approaching a useful documentary baseline. Before considering v0.1 stable, I noticed a few remaining consistency issues:

1. Qualification ladder: QL-2 is defined as requiring positive acceptance criteria across all six invariants, but some required capabilities remain NOT_QUALIFIED. I suggest distinguishing partial QL-2 coverage from full QL-2 achievement.

2. Traceability completeness: The matrix currently covers selected requirements rather than every normative requirement. A few mappings also need correction, particularly the association of REQ-03.2 with the suppressed-execution test.

3. Platform independence: REQ-05.1 still prescribes a kernel-side counter. Perhaps the normative contract should require independently trusted sequence accounting, leaving kernel implementation as a platform-specific option.

4. Consumer-side observation loss: A read timeout does not necessarily prove that an event was lost. It may help to distinguish delayed delivery, confirmed loss, and unresolved observation status.

These are documentary refinements rather than objections to the architectural direction.

I would also recommend retaining all six invariants as DRAFT / NOT_QUALIFIED until the requirement-level evidence and independent review criteria are fully satisfied.

Thank you again for the careful work and the constructive collaboration.

Best regards,
Thales

[rahadbhuiya]

Thanks for catching those consistency items. I have updated the contract in commit 774a7fa to address all four points:

Qualification Ladder: Split QL-2 into partial coverage versus full achievement across all 33 normative requirements. All six invariants are explicitly retained at DRAFT / NOT_QUALIFIED in the status tables until the open requirement gaps and independent review criteria are formally closed.

Traceability Completeness: Expanded the matrix in Section 5 to cover every normative requirement (REQ-01.1 through REQ-06.6). Corrected the mapping so REQ-03.2 maps to TC-03-SEQ-BOUND (architectural separation of sequence enforcement) and TC-03-ADV-SUPPRESS maps to REQ-03.5 (detection of suppressed execution via independent observer).

Platform Independence: Refined REQ-05.1 to require independently trusted sequence accounting rather than prescribing kernel-side structures, noting kernel-side state maps as a Linux/eBPF reference pattern while leaving hypervisor or hardware accounting open for other targets.

Consumer-Side Observation Loss: Updated the loss taxonomy in SEC-INV-05 to explicitly distinguish delayed delivery (CONS-DELAY), confirmed channel loss (CONS-LOSS corroborated by transport metrics), and unresolved timeout status (CONS-UNRESOLVED, which transitions to EOW-UNRESOLVED if unconfirmed at window closure).

Let me know if this looks good to lock down as the v0.1 baseline.

[bonushora]

Hi Rahad,

Thank you for the careful revision in commit 774a7fa.

I reviewed the updated specification and confirmed that all four consistency findings have been substantively addressed.

The distinction between partial and full QL-2 achievement is now explicit, the traceability matrix covers all 33 normative requirements, the corrected requirement mappings are consistent, and the observation-loss taxonomy properly distinguishes delayed, confirmed-loss, and unresolved events.

I agree that we are ready to establish v0.1 as a documentary baseline, while preserving all six invariants as DRAFT / NOT_QUALIFIED.

Before freezing it, I suggest one final platform-neutral wording adjustment: REQ-03.4 still refers to observation at or below the kernel syscall boundary. The normative requirement could instead specify an independently trusted observation boundary appropriate to the protected operation, leaving syscall tracing as a Linux-specific adapter implementation.

For the baseline record, I also suggest capturing the exact commit SHA, the open requirement gaps, the qualification status, and the distinction between documentary stabilization and independently demonstrated security guarantees.

With that small refinement, I would support freezing the v0.1 documentary baseline and tracking subsequent implementation and qualification work separately.

Thank you again for the excellent collaboration.

Best regards,
Thales

[rahadbhuiya]

Thank you. I have applied that final adjustment in commit cc63eb1:

REQ-03.4 Platform-Neutral Wording: Updated the requirement to specify an independently trusted observation boundary appropriate to the protected operation rather than prescribing the syscall interface, noting syscall-level tracing (e.g. eBPF on Linux) as a reference adapter implementation.

Baseline Record Metadata: Formally captured the v0.1 Documentary Baseline record in the document header, explicitly recording the commit target, the full enumeration of open requirement gaps, the partial reference coverage vs. open qualification posture, and the clear distinction between documentary stabilization and demonstrated guarantees (with all six invariants strictly preserved at DRAFT / NOT_QUALIFIED).

With this commit, I agree that CFS-SEC-CONTRACT-v0.1 is now stabilized and frozen as our documentary baseline.

As we move forward and track implementation adapters and qualification suites separately, what is your envisioned roadmap for this baseline? Are you planning to present this framing as a formal cFS community RFC, align it with ongoing flight-software safety working groups, or explore joint academic/aerospace conference publication? I would love to understand how you see this evolving so we can best align our next steps.

Thank you again for the thorough and productive collaboration throughout this review.

[bonushora]

Hi Rahad,

Thank you for the final adjustment in cc63eb1 and for the excellent collaboration throughout the v0.1 review.

I have confirmed that REQ-03.4 now expresses an implementation-neutral trusted observation boundary, and that the documentary baseline preserves the distinction between specification stability and independently demonstrated security guarantees.

I agree that CFS-SEC-CONTRACT-v0.1 is ready to serve as our frozen documentary baseline, with all six invariants remaining DRAFT / NOT_QUALIFIED.

Regarding the roadmap, I envision a staged, evidence-driven path, rather than pursuing a formal RFC, working-group alignment, and academic publication simultaneously.

First — Preserve and consolidate v0.1.

Record the immutable baseline commit, maintain the open-requirement register, and prepare a concise architectural overview explaining the security contract, adapter boundaries, threat model, and qualification approach. Implementation development should remain separate from changes to the frozen contract.

Second — Seek community architectural feedback.

I would favor presenting the concept as an independent community proposal through the appropriate cFS discussion and review channels, asking maintainers whether a formal RFC or architectural review would be welcome.

The initial objective would be to obtain technical feedback, not to seek immediate adoption or changes to the portable cFS core.

Third — Develop evidence-based reference qualifications.

We could incrementally address the open requirement gaps in the Linux reference implementation, with each capability independently traced to its acceptance criteria and evidence. Other platform adapters would remain future work until their feasibility and trust boundaries are established.

Fourth — Explore broader research collaboration.

Once we have a stable specification, a reproducible methodology, and sufficiently differentiated experimental results, I would be interested in exploring a joint academic or aerospace conference paper.

I see potential research value in the distinction between platform-independent security guarantees, platform-specific enforcement, and independent effect qualification. However, I would prefer to establish a defensible technical contribution and clear authorship arrangements before selecting a publication venue.

For now, I suggest our next shared deliverable be a short Community Architecture Proposal v0.1, derived from the frozen contract and clearly identified as independent research.

We could use that document to ask the cFS maintainers which review route would be most appropriate.

I would welcome your thoughts on this sequence and on how we should divide the documentary contributions.

Thank you again, Rahad. It has been a pleasure developing this architecture with you.

Best regards,
Thales

[rahadbhuiya]

Thank you for confirming the baseline and for outlining such a disciplined, evidence-driven roadmap. I completely agree with this staged sequence. Preserving specification stability before pursuing broader review or formal adoption is the right engineering approach.

I also fully welcome the idea of an eventual joint aerospace conference paper once our experimental results and reference qualification on Linux are mature and independently defensible.

Regarding our next deliverable, the Community Architecture Proposal v0.1, your suggested scope makes complete sense. To divide the documentary contributions effectively, I propose the following division:

I can draft the core technical sections, specifically the operational threat model, the adapter isolation boundaries, the invariant definitions, and the empirical qualification methodology used in the Linux reference implementation.

You could lead the architectural framing, the cFS integration rationale, the community review scoping, and the strategic positioning for presenting this to the maintainers as independent research.

Once we synthesize both parts into a concise initial draft, we can cross-review and align on the exact submission format before reaching out to the cFS maintainers.

Please let me know if this division of work sounds good to you, and I will prepare the technical section draft accordingly.

Thank you again for the outstanding collaboration.

[bonushora]

Hi Rahad,

Thank you for proposing such a clear and complementary division of responsibilities. I fully agree with this approach.

I would be pleased to lead the architectural framing, cFS integration rationale, community review scope, and strategic positioning of the Community Architecture Proposal v0.1.

Your proposed ownership of the operational threat model, adapter isolation boundaries, security invariants, and Linux reference qualification methodology provides a strong technical foundation for the document.

I suggest that we structure the proposal around the following principles:

1. Independent research status: The proposal represents our collaborative architectural research, not an official NASA or cFS requirement.

2. Platform-independent architecture: The six security invariants remain independent of operating-system-specific enforcement mechanisms.

3. Clear responsibility boundaries: Framework, mission, platform adapter, and independent qualification tooling responsibilities should be explicitly distinguished and presented as proposed architectural boundaries.

4. Evidence-driven qualification: We should clearly separate demonstrated Linux reference capabilities from open implementation gaps and unqualified guarantees.

5. Non-invasive integration: The initial proposal should not require modifications to the portable cFS core. Any future integration would remain subject to community review and explicit technical justification.

6. Documentary traceability: The frozen CFS-SEC-CONTRACT-v0.1 baseline should remain unchanged. Our architecture proposal should reference its immutable commit and identify any subsequent refinements separately.

For collaboration, I suggest preparing our respective sections in a shared draft document or Draft PR, followed by mutual review before considering a community-facing submission.

I would also welcome recording both of our contributions transparently, with appropriate attribution and mutual agreement on any future publication or external submission.

Please feel free to prepare the technical section draft as proposed. I will focus on developing the complementary architectural sections so we can consolidate them into a coherent Community Architecture Proposal v0.1.

Once we have cross-reviewed the complete document, we can jointly determine the appropriate cFS community review channel without presuming formal endorsement or adoption.

I appreciate the opportunity to continue this collaboration and look forward to building the proposal together.

Best regards,
Thales

[rahadbhuiya]

Thank you for this thoughtful and comprehensive response. I fully endorse the six framing principles you outlined; they establish a rigorous, disciplined boundary for presenting this work to the broader community without overstating claims or creating unnecessary friction with the portable cFS core.

I also appreciate and value the explicit commitment to transparent attribution and mutual agreement on future publications and submissions. This solidifies a foundation of trust and mutual respect as we take this forward.

I will begin preparing the technical draft covering the operational threat model, the adapter isolation boundaries, the six invariant definitions, and the empirical qualification methodology mapped to our frozen baseline (cc63eb1). I will organize these sections in a branch and open a Draft PR in the cfs-adversarial-testbed repository so that you can easily track, review, and comment on the technical text as it develops.

Looking forward to seeing your architectural framing sections and synthesizing our work into a cohesive Community Architecture Proposal v0.1.

[bonushora]

Hi Rahad,

Thank you for confirming our collaboration and the agreed division of responsibilities.

I have begun structuring the complementary architectural sections, covering the architectural motivation, cFS integration rationale, proposed responsibility boundaries, community review scope, and evidence-driven research roadmap.

I will preserve the frozen contract at cc63eb1 as our normative documentary reference, without introducing implementation changes or additional qualification claims.

Once you open the Draft PR, we can integrate the architectural and technical contributions, review their consistency section by section, and preserve clear attribution for both contributors.

I look forward to consolidating the Community Architecture Proposal v0.1 together.

Best regards,
Thales

[rahadbhuiya]

Hi Thales,

Thank you for the update. I have prepared and pushed the initial technical contribution draft covering the operational threat model, the six platform-neutral invariants, the adapter isolation boundaries, and the empirical Linux qualification matrix, anchored strictly to our frozen baseline (cc63eb1).

I have opened the collaborative Draft PR here:
Exploidus/cfs-adversarial-testbed#2

Please feel free to review the technical sections and integrate your architectural framing contributions whenever you are ready so we can synthesize the complete proposal together.

Best regards,
Rahad

[bonushora]

Hi Rahad,

Thank you for opening Draft PR #2 and preparing such a substantial technical contribution. I appreciate the architectural diagrams, threat model, adapter boundaries, and research roadmap.

I have completed an initial static review of the proposal at commit e899734.

Before integrating my architectural framing sections, I would like to align the document with our frozen CFS-SEC-CONTRACT-v0.1 baseline (cc63eb1).

I noticed several important points:

1. Preserve the original six invariant identities.

The current proposal introduces a different set of INV-01 through INV-06 definitions, including memory isolation, cryptographic audit chaining, and radiation fault containment.

These may be valuable additional research directions, but they should not replace or reuse the identifiers of the six invariants defined in our frozen contract.

I suggest retaining the original SEC-INV-01 through SEC-INV-06 mappings unchanged and documenting the additional security capabilities as proposed extensions outside the normative v0.1 baseline.

2. Separate demonstrated capabilities from qualification claims.

The empirical matrix currently marks several requirements as QUALIFIED, while our frozen baseline explicitly retains all six invariants as DRAFT / NOT_QUALIFIED.

I suggest retaining only evidence directly traceable to the frozen requirements and tested implementation. Any newly proposed mechanisms should remain NOT_DEMONSTRATED or NOT_QUALIFIED until supported by reproducible evidence.

3. Keep PSAL as a proposed architectural component.

The Platform Security Adapter Layer is an interesting integration concept, but its interfaces, enforcement authority, and relationship with existing cFS/OSAL responsibilities still require community review.

The document should avoid implying that these interfaces or protections have already been implemented or adopted within cFS.

4. Keep the scope disciplined.

Memory isolation, cryptographic audit chains, hardware actuator gates, and radiation-induced fault containment may warrant separate future contracts. They should not be presented as already covered by our six-invariant baseline.

I also recommend avoiding zero-overhead claims unless supported by measurements.

Once these alignment issues are resolved, I would be glad to integrate the architectural motivation, cFS integration rationale, responsibility boundaries, community review questions, and staged research roadmap.

My intention is to preserve your technical contributions while ensuring that the community proposal remains consistent with the normative baseline we jointly reviewed and froze.

Thank you again for the excellent collaboration.

Best regards,
Thales

[rahadbhuiya]

Thank you for the thoughtful and incisive review. Every single alignment point you raised strengthens the scientific rigor of the document and protects the integrity of our frozen baseline.

I have pushed commit f79ed1b to Draft PR #2 fully addressing each recommendation:

Contributor Attribution: Updated the document header to credit Thales Rangel (@bonushora) and Rahad Bhuiya (@rahadbhuiya).
Invariant Alignment: Restored the normative mappings for SEC-INV-01 through SEC-INV-06 exactly as defined in our frozen contract (cc63eb1), maintaining their status as DRAFT / NOT_QUALIFIED.
Evidence vs. Qualification: Clarified that the Linux testbed demonstrates prototype reference feasibility, without claiming formal flight qualification for the baseline invariants.
PSAL Framing: Positioned the Platform Security Adapter Layer explicitly as a proposed architectural concept subject to community discussion.
Future Scope Separation: Moved spatial memory enclaves, cryptographic event chaining, hardware actuator gating, and autonomous radiation fault containment into Section 6 as proposed future research extensions outside the v0.1 baseline.

The updated draft is now fully synchronized with our frozen contract baseline. Please feel free to review commit f79ed1b and integrate your architectural framing sections whenever you are ready.

[bonushora]

Olá, Rahad,

Obrigado por incorporar prontamente as recomendações de alinhamento arquitetural no commit f79ed1b.

Revisei a versão atualizada do documento e confirmei que foram preservados os seis invariantes de segurança originais, as fronteiras estabelecidas na baseline congelada, a distinção entre evidências experimentais e alegações de qualificação, bem como a atribuição correta das contribuições.

Agradeço sua atenção cuidadosa a esses detalhes e seu compromisso contínuo com a integridade técnica da nossa colaboração.

Acredito que agora podemos avançar com a integração das minhas seções de fundamentação arquitetural ao Draft PR #2, seguida de uma revisão conjunta, seção por seção.

Para manter a discussão da NASA cFS concentrada nos principais marcos arquiteturais, sugiro que continuemos o trabalho documental detalhado diretamente no Pull Request colaborativo.

Mais uma vez, obrigado pela excelente colaboração.

Atenciosamente,

Thales Rangel

[rahadbhuiya]

Thank you for confirming the alignment and for the encouraging feedback. I am glad commit f79ed1b satisfies all of our normative criteria.

I completely agree with keeping the detailed documentary synthesis directly in Draft PR #2 while preserving this discussion for major milestones.

Looking forward to your architectural sections on the PR.

[bonushora]

Hi Rahad,

Thank you for addressing the previous editorial and governance observations. I have now completed an independent documentary cross-review of the Community Architecture Proposal v0.1 against our frozen CFS-SEC-CONTRACT-v0.1 baseline (cc63eb1).

The overall architecture, contributor attribution, platform neutrality, and explicit DRAFT / NOT_QUALIFIED status are preserved.

Before I can provide final documentary sign-off, I have identified five bounded consistency refinements:

1. SEC-INV-05 — Observation-loss taxonomy

Sections 1 and 3.5 should preserve the normative accounting categories from the frozen contract: TXN-GAP, PROD-DROP, CONS-DELAY / CONS-LOSS / CONS-UNRESOLVED, and EOW-UNRESOLVED.

Operational causes such as buffer saturation or transport congestion must remain distinguishable from those accounting categories.

2. Section 5.2 — Evidence scope

The prototype feasibility matrix should explicitly distinguish proposed mechanisms, partially demonstrated evidence, and unqualified normative requirements.

In particular, the existing gaps concerning per-command authorization, instance re-binding, preventive replay rejection, L2/L4 effect witnesses, observation-loss accounting, and observer degradation must remain visible.

3. Sections 4 and 5.1 — Implementation claims

Please qualify statements about Linux/eBPF enforcement, ringbuffer isolation, backpressure, timing impact, and bypass resistance wherever these properties have not been independently demonstrated.

4. Requirement-level traceability

Please explicitly identify the frozen contract's 33-requirement traceability matrix as the authoritative source for individual acceptance criteria and qualification verdicts. The proposal's six-invariant summary should not replace that matrix.

5. Conceptual integration boundaries

Please clarify that the PSAL architecture diagram represents a proposed conceptual arrangement, not a confirmed cFS integration design. The appropriate OSAL, PSP, external mediation, and enforcement boundaries remain open to community architectural review.

These observations do not propose reopening or modifying the six frozen invariants.

I recommend addressing them through a narrowly scoped documentary patch, preserving the current attribution and qualification disclaimers.

After the correction commit is available, I would like to perform one final readback before authorizing documentary sign-off, PR merge, or preparation of a joint community announcement.

I appreciate the constructive collaboration and believe these final refinements will strengthen the technical credibility of our proposal.

Best regards,
Thales Rangel
[@bonushora](https://github.com/bonushora)

[rahadbhuiya]

Thank you for this thorough documentary cross-review against the frozen CFS-SEC-CONTRACT-v0.1 baseline. I have addressed all five bounded consistency points in commit a9de5da8fe:

Normative Observation-Loss Taxonomy (Sections 1 & 3.5): Preserved the canonical categories (TXN-GAP, PROD-DROP, CONS-DELAY / CONS-LOSS / CONS-UNRESOLVED, and EOW-UNRESOLVED) while formally distinguishing them from physical triggers (congestion, buffer saturation, probe detachment).
Explicit Evidence Scope & Open Gaps (Section 5.2): Expanded the feasibility matrix to explicitly delineate candidate mechanisms, partially demonstrated reference scope, and the specific open normative requirement gaps (REQ-01.3, REQ-02.3/02.4, REQ-03.3, REQ-04.2/04.4, REQ-05.2/05.6, REQ-06.5/06.6).
Qualified Implementation Claims (Sections 4 & 5.1): Rephrased eBPF and ringbuffer descriptions as candidate evaluation mechanisms, explicitly disclaiming unverified timing or zero-jitter guarantees prior to empirical multi-core benchmarking.
Authoritative 33-Requirement Traceability (Section 3): Added an explicit normative callout establishing the frozen contract's 33-requirement traceability matrix as the authoritative basis for individual acceptance criteria and qualification verdicts.
Conceptual Scope of PSAL (Section 1): Clarified via callout that PSAL represents a candidate conceptual abstraction for community review rather than an established cFS component or confirmed integration path.

With these five refinements committed, the proposal maintains strict consistency with our frozen documentary baseline (cc63eb1). Ready for your final readback!