Fail-Safe Operating-System Behavior Under Security and Hardware Failures

Problem statement

Investigate how Black Wall should respond when security services, authentication, storage, networking, or hardware components fail. Explore controlled degraded operation, recovery, and safety-preserving responses.

Why it matters

Security controls and safety properties can conflict during failure. A system that fails closed may become unavailable, while one that fails open may become unsafe, so the intended behaviour for each failure class has to be explicit.

Research questions

1. 01 Which failure classes must be distinguished, and what recovery policy applies to each?
2. 02 Which dependencies are security-critical, and what happens when one becomes unavailable?
3. 03 What degraded operating modes can be defined without silently disabling protection?
4. 04 How should availability, recovery time and safety properties be evaluated under simulated failure?

Research objectives

• Define failure classes and recovery policies.
• Identify security-critical dependencies.
• Design explicit degraded operating modes.
• Simulate authentication, storage, networking, and monitoring failures.
• Evaluate availability, recovery time, and safety properties.

Technical challenges

• Fail-closed and fail-open responses both carry unacceptable consequences in some scenarios.
• Recovery actions depend on components that may be the ones that failed.
• Degraded modes enlarge the attack surface unless their permissions are constrained.
• Safety and availability need measurable criteria rather than informal expectations.

Expected outcome

A documented failure-handling model and a prototype demonstrating controlled recovery.

Tags

fail-saferecoverydegraded operationresilienceavailabilitysafety

Related research

• A Reliable Boot Architecture for Virtualized and Physical Systems

  Investigate why Black Wall does not yet boot consistently across QEMU, UEFI-based physical machines and future hardware, and build stage-level diagnostics that separate firmware, bootloader, kernel and display failures.

  Under Investigation · Systems
• Authenticated and Resilient Communication for Distributed Black Wall Systems

  Secure communication between distributed Black Wall machines and robotic nodes while limiting the impact of compromised nodes, interrupted connectivity and unauthorised commands.

  Open Research Problem · Cybersecurity
• A Security Architecture for Black Wall in Autonomous Robotic Systems

  Isolate robotic workloads, constrain actuator access, authenticate component communication and keep behaviour predictable when software or the network fails.

  Open Research Problem · Robotics
• Black Wall for Robots

  Investigate a cyber-physical security architecture where a secure runtime — Black Wall — prevents compromised software from producing physically dangerous robot behavior, even when an attacker technically controls that software.

  Open · Robotics