The Most Secure Operating System in the World

Main ideas, concepts, and lessons

• QNX as an “unseen” operating system

  • The video argues that while most people focus on desktop operating systems (Windows, macOS, Linux, BSD/Unix), QNX is over 40 years old and is largely not installed by end users.
  • Despite low public visibility, its technology is used in hundreds of millions of vehicles and many safety/real-time domains—such as embedded automotive controllers, industrial machines, robots, and medical/embedded equipment.

• Security ≠ safety ≠ reliability

  • The speaker explicitly separates:
    • Security: preventing unauthorized access/manipulation/malicious behavior.
    • Safety: preventing dangerous conditions (not only from hackers, but also from bugs).
    • Reliability: continuing to work correctly when failures occur.
  • Central thesis: even if a system is “secure,” it must still be engineered for failure, isolation, and recovery.

• Where QNX ideas came from (early foundations)

  • The video traces QNX’s lineage to University of Waterloo via an earlier system called THOTH, designed around message passing.
  • Early contributors and founders:
    • Dan Dodge and Gordon Bell developed a multitasking real-time OS approach for microcomputers.
  • Naming/branding detail:
    • The OS was influenced by “Unix,” but AT&T’s trademark led to a name change (the story being “Unix” became “QNX” due to legal pressure).

• Message passing and distribution

  • A major architectural theme is message passing:
    • Communication can extend beyond a single machine.
    • Networks can be treated conceptually as an extension of the OS, enabling distributed processing.

• Microkernel design philosophy (fault containment through isolation)

  • The kernel stays small, focusing on mechanisms such as:
    • threads, scheduling, timers, interrupts, synchronization, and especially message passing.
  • Many other components run as separate processes rather than in privileged kernel space:
    • drivers, file systems, services/resource managers.
  • Lesson: if a component fails (e.g., a driver), damage can be contained:
    • kernel-space crashes can corrupt the whole kernel
    • user-space components can fail without necessarily taking everything down
  • The video contrasts this philosophy with Linux’s modular monolithic approach (where modules/drivers often run with high privilege).

• Real-time means determinism, not just speed

  • The video criticizes the misuse of “real time” as “fast average performance.”
  • True real-time behavior requires:
    • deterministic timing guarantees (completing within specified deadlines)

• Scheduling mechanisms for real-time correctness

  • Preemptive, priority-based scheduling
    • Higher-priority runnable threads can preempt lower-priority ones.
  • Priority inversion handling via priority inheritance
    • Prevents medium-priority work from blocking a low-priority task that holds a resource needed by a high-priority task.
  • Key point: scheduling choices directly impact reliability and timing guarantees.

• Security model: least privilege and controlled communication

  • Traditional Unix “root or not” is contrasted with QNX’s more granular approach:
    • privileged operations are divided into ~70 permissions
    • the documentation encourages avoiding running as root except for the system process proxy (wording varies by model/version)
  • QNX access control policies limit:
    • which resource managers can register
    • which services processes are allowed to communicate with
  • Because the system is built around message passing, controlling “who can talk to whom” becomes a strong isolation boundary.

• Security is not something you “install”

  • The speaker stresses that QNX is not magic:
    • secure outcomes depend on correct configuration, privilege assignment, threat modeling, patching, and correct use of access control and “PZI X” controls.
  • “Secure system architecture” is reframed as:
    • assume bugs happen
    • ask what they can reach
    • design containment and recovery paths

• High availability and recovery philosophy

  • The HAM (High Availability Manager) monitors processes and defines recovery actions:
    • detect failures/hangs
    • restart or react when services stop responding
  • Lesson: design for what happens after failure, not only success.

• Automotive scale and business history

  • The video connects QNX’s vehicle footprint to ownership and smartphone-era business dynamics:
    • 2004: Harmon International buys QNX
    • 2010: BlackBerry buys QNX for $200 million, using it for PlayBook and BlackBerry 10
    • BlackBerry’s smartphone strategy fails (app ecosystem issues), but QNX continues and becomes deeply embedded in automotive systems
  • Clarification: “275 million vehicles” does not mean the entire vehicle OS is QNX; rather, QNX technology appears in multiple embedded domains alongside other OS/firmware stacks.

• Virtualization and software-defined vehicles

  • The future described is “software-defined vehicles” with centralized/stronger compute.
  • Challenge: safely co-locate less critical workloads (e.g., Android infotainment) with more critical functions on the same hardware.
  • Solution direction:
    • QNX hypervisor to run separate isolated environments
  • Isolation complexity mentioned:
    • CPU isolation, memory protection, interrupts, device ownership, boot recovery, DMA/IOMMU concerns (e.g., SMMU-style protections)

• Open-source access experiments

  • QNX is proprietary today, but the video notes earlier experiments:
    • Foundry 27 (2007): partial source release (libraries, system components, BSPs, and networking stack based on NetBSD-derived components)
  • Later initiative:
    • QNX “Everywhere” (non-commercial student/hobby license)
  • The video also mentions enthusiasts running QNX on consumer hardware (e.g., Raspberry Pi) with a desktop environment (XFCE).

• What the video claims is the better “security” question

  • The speaker rejects a universal “most secure OS” leaderboard.
  • Security depends on:
    • threat model, configuration, hardware, code, integration, and even how “security” is defined
  • CVE counts alone are insufficient (coverage bias can occur for less popular or more closed software).
  • More meaningful question:
    • Which OS design starts from isolation, determinism, message passing, least privilege, fault containment, recovery, and minimizing trusted code?

Engineering “methodology” checklist (instruction-like takeaways)

The video doesn’t provide a user procedure, but it repeatedly presents an engineering approach for secure and reliable systems. Consolidated into a checklist:

1. Design assuming software will contain bugs

   • Do not treat “security” as “software with zero bugs.”
   • Instead, design so bugs have limited consequences.

2. Build isolation boundaries

   • Prefer architectural separation so failures do not corrupt everything.
   • Keep crash-prone or less-trusted components out of the most privileged space when possible.

3. Limit privileges (least privilege)

   • Split privilege into granular permissions rather than “root everywhere.”
   • Avoid broad rights by default.

4. Control communication paths

   • When using message passing, restrict which services/processes can communicate.
   • Treat communication authorization as a major security boundary.

5. Target determinism for real-time systems

   • Define timing constraints for operations.
   • Use scheduling mechanisms that uphold deadlines (e.g., priority preemption + priority inversion handling).

6. Plan for recovery and failure handling

   • Use mechanisms like a high availability manager to detect failure and restart components.
   • Design operational behavior after failure (containment + recovery), not only success paths.

7. Treat security as operational practice

   • Secure configuration, threat modeling, patching, and correct use of access controls are required.
   • A “secure OS” branding/logo does not automatically secure a deployed system.

Speakers / sources featured

• Speaker: Video narrator (no name provided in the subtitles)

• Referenced people (historical contributors):

  • Dan Dodge
  • Gordon Bell (noted as a different person than the “famous Gordon Bell from Deck”)

• Referenced organizations / companies / entities:

  • University of Waterloo (Ontario, Canada)
  • AT&T (trademark/legal action)
  • Bell Northern Research
  • Quantum Software Systems Limited
  • CM Corp (Ontario school computer project)
  • Ontario Ministry of Education
  • Harmon International
  • BlackBerry / Research in Motion (RIM)
  • NetBSD (as an influence for the networking stack mentioned in Foundry 27)

• Referenced standards / certifications / advisories:

  • IEC 61508 SIL 3
  • ISO 26262 ASIL D (mentioned as “ASELD”)
  • ISO 26262 / automotive cyber security references
  • CVE-2021-22156 related to “Bad Alec”
  • SISA advisory (as mentioned)