An operating system security architecture, method, and system based on an unbypassable review chain.

Abstract

This invention discloses an operating system security architecture and method based on an unbypassable review chain. The core consists of a decision generation unit (which calls an AI model to generate instructions) and a security verification unit (which performs security reviews based on deterministic rules of formal verification), deployed in independent, isolated spaces, forming an unbypassable mandatory review dependency. The independent isolation space can be implemented through MMU, TrustZone, independent security processor, hardware security module, hypervisor layer, physical air gap, optical communication, etc. The security verification unit can be implemented through eBPF+LSM, hardware state machine, DFA, microcode, etc. The protection scope is not circumvented by changes in module naming, number of architecture layers, isolation methods, review implementation methods, or deployment forms. Both the decision generation unit and the security verification unit can be deployed entirely in the cloud, with the terminal retaining only execution and communication capabilities. This invention is applicable to high-security scenarios such as AI PCs, embodied intelligence, autonomous driving, industrial control, and medical devices.

Description

Technical Field

[0001] This invention relates to the field of operating system security and artificial intelligence, specifically to an operating system security architecture that ensures AI-generated instructions must undergo deterministic security review before execution. It also relates to a method for constructing an unbypassable review chain between the decision generation unit and the security verification unit corresponding to this architecture, a method for implementing an independent isolation space, a method for implementing deterministic security review, a multi-form deployment method, and a distributed security execution method. Background Technology

[0002] Currently, global operating system technology faces eight core technological bottlenecks: Bottleneck 1: Structural separation of AI decision-making power and security review power. In existing operating systems, the scheduler is only responsible for resource allocation and lacks security review capabilities; the security mechanism is only responsible for interception and does not participate in scheduling decisions. This complete decoupling means that AI models do not need to consider security constraints when making scheduling decisions, and security mechanisms cannot understand the task context during review. Existing solutions such as ProbeLogits (arXiv:2604.11943, 2026) embed a Large Language Model (LLM) in the kernel to infer and read the logit distribution for security classification, relying on probabilistic model detection. Its F1 score is approximately 0.790-0.837, and the confidence of the security classification depends on the adjustment of the calibration strength during deployment. Arbiter-K (arXiv:2604.18652, 2026) encapsulates the LLM in a deterministic neural symbolic kernel, coupling security governance and AI inference in the same kernel space, and its security mechanism and AI decision-making share the same address space. Kylin Software CN120180452A uses a local agent to load multi-task learning aids to generate and adjust security policies. The generation and adjustment of its security policies rely on machine learning models and belong to a probabilistic security solution.

[0003] Bottleneck Two: The contradiction between the probabilistic nature of AI models and the deterministic nature of security requirements. The core advantages of neural network models, such as large language models, lie in their generalization ability and flexibility, but their outputs inherently possess probabilistic and uncertainties. Directly using probabilistic outputs to control physical devices or execute system operations poses security risks in high-security scenarios involving life and property safety. DAIOS (Deterministic AI Operating System, November 2025) proposes the concept of a deterministic AI operating system, emphasizing rule-based computation instead of statistical reasoning, but it does not disclose the specific layered architecture of the decision generation and security review components, nor the mandatory dependency review relationship between them, nor does it disclose industrial-grade implementation solutions such as eBPF+LSM dual-layer fallback interception.

[0004] Bottleneck 3: The security review module itself lacks self-protection design. The security components of the existing solution have not undergone formal completeness verification. Its rule compiler has problems such as nested recursive denial-of-service, expression injection, and implicit default value auto-allowing. Moreover, the verification logic can be tampered with after loading, and it lacks runtime integrity continuous guarantee and multi-core concurrent deterministic synchronization mechanism.

[0005] Bottleneck 4: The federated knowledge-sharing system lacks intrinsic security governance and economic security control. The node access of the skills federation network lacks trusted identity chain verification, the implicit malicious dependency chains of listed skills have not been deeply audited, and pirated skills are rampant and cannot be traced or held accountable.

[0006] Bottleneck 5: Cross-scenario consistency of security baseline cannot be guaranteed. Operations such as hot updates, rollbacks, canary upgrades, and offline downgrades can all introduce temporary security vacuums. More seriously, existing patent protection schemes have numerous architectural loopholes—competitors can circumvent overall functional protection by nominally changing the architecture by migrating security review from the kernel level to an independent firmware layer, microservice clusters, TrustZone security world, independent security processors, or hardware security modules. In addition, competitors can also claim that their systems do not fall within the scope of existing patent protection by changing module names (such as changing "neural domain" to "understanding domain" or "symbolic domain" to "arbitration domain"), increasing or decreasing the number of architectural layers (such as three domains or four domains), or changing isolation methods (such as replacing the MMU with TrustZone), while in reality still implementing the exact same security review function.

[0007] Bottleneck Six: Insufficient Detail in Chinese Natural Language Understanding. Existing operating systems generally build their natural language understanding systems based on English semantic systems, lacking a dedicated anchoring mechanism for spoken Chinese.

[0008] Bottleneck 7: Existing microkernel architectures provide "channel security" but lack AI semantic security auditing capabilities. Formal verification microkernel operating systems, represented by seL4, implement strict access control through the Capability mechanism, but do not audit the semantic security of instruction content.

[0009] Bottleneck 8: Limitations of functional naming in existing patent protection schemes. Existing schemes often use specific functional names (such as "neural domain" or "symbolic domain") to limit the scope of protection, but fail to construct protection boundaries based on the substantive functions of "decision generation" and "security review," allowing competitors to circumvent the restrictions simply by modifying the module names.

[0010] Compared with the existing solutions mentioned above, the core difference of this application is: (1) The fundamental opposition between probabilistic and deterministic approaches: ProbeLogits and other similar schemes embed large language models in the kernel for probabilistic security classification (F1 score of approximately 0.79-0.84), which results in statistical missed detections. The security classification results vary with model parameters and input perturbations, and the judgment result is not uniquely determined. The security verification unit of this application does not use any form of machine learning or statistical methods. The security judgment is based on deterministic rules of formal verification, and the judgment result is uniquely determined, with no probabilistic missed detections.

[0011] (2) The essential difference between coupling and physical isolation: Arbiter-K couples the large language model and security governance in the same kernel space, and the security mechanism and AI decision-making share the same address space. Once the AI ​​model is compromised, the security mechanism is also compromised. This application runs the decision generation unit and the security verification unit in an independent isolated space, and forcibly separates them through hardware mechanisms such as MMU, TrustZone, and independent security processor. The decision generation unit cannot access or tamper with the memory, code, rules and review logic of the security verification unit in any running state.

[0012] (3) Further differences from existing technologies such as seL4 and DAIOS: Compared to the seL4 microkernel, seL4 provides "channel security" through a formally verified capability mechanism—ensuring the instruction transmission path is secure and unbypassable, but it does not examine the semantic security of the instruction content. This invention not only provides channel security but also performs semantic review of the AI ​​instruction content through a security verification unit, providing a dual guarantee of "channel security + semantic security." Furthermore, seL4 lacks the concepts of a decision generation unit and a security verification unit, has no bottom-line security rules, lacks a double-layered eBPF+LSM interception mechanism, and lacks federated network security governance capabilities.

[0013] Compared to DAIOS (Deterministic AI Operating System), which proposes the concept of a deterministic AI operating system, key architectural details (physical isolation between decision generation and security review, eBPF+LSM dual-layer interception, multi-core atomic context control, compiler self-protection mechanism, dedicated verification core, automatic rule conflict resolution, and federated network economic governance) are not disclosed. This invention reveals an industrial-grade implementation scheme for physically decoupling the decision generation unit and the security verification unit. Compared to ProbeLogits, ProbeLogits embeds LLM inference within the kernel to read the logit distribution for probabilistic security classification (F1 score approximately 0.8), with the security classification confidence depending on calibration strength adjustments. This invention does not use machine learning for security review—the security verification unit performs security interception based on formally verified deterministic rules. Compared to Arbiter-K, Arbiter-K encapsulates LLM in kernel-level unified governance, coupling security and inference in the same space. This invention separates the decision generation unit and the security verification unit in independent, isolated spaces, ensuring that a compromised AI model cannot access the security verification unit.

[0014] Compared to Kylin Software's CN120180452A, this patent generates security policies by loading machine learning models, belonging to a probabilistic security solution. This invention achieves deterministic rule interception through a deterministic rule engine. Summary of the Invention

[0015] I. Technical problems to be solved This invention aims to solve the following core technical problems: 1. How to construct an operating system security architecture that ensures that any task decision instructions generated by AI must undergo an unavoidable deterministic security review before execution, fundamentally resolving the contradiction between the probabilistic nature of AI models and the deterministic nature of security requirements; 2. How to ensure that the protection scope of this security architecture is not limited by specific implementation details such as module naming, number of architecture layers, isolation methods, audit implementation methods, and deployment forms, and to block all known and foreseeable architectural circumvention paths; 3. How to ensure that the security verification unit itself is not interfered with, accessed, or tampered with by the decision generation unit in any way; 4. How to establish a self-protection mechanism within the security rule compiler and ensure the integrity of the verification logic during runtime after loading; 5. How to establish a full-link trusted computing system from hardware root of trust to security verification unit to eliminate the security vacuum during startup; 6. How to achieve endogenous security and economic governance within a federated knowledge network; 7. How to perform fine-grained semantic anchoring of Chinese natural language; 8. How to achieve the autonomous evolution capability of the operating system and make the evolution itself subject to security review; 9. How to ensure that the security interception strength is not reduced when the audit log storage is full; 10. How to ensure that the security baseline remains intact even when the security verification unit crashes abnormally.

[0016] II. Technical Solution This invention provides an operating system security architecture based on an unbypassable review chain.

[0017] Declaration of the core protection scope of this invention The core essential technical features of this invention are: the forced separation of the decision generation unit and the security verification unit in independent and isolated spaces, and the unavoidable deterministic review dependency between the two. These features constitute the basic architecture of this invention and are necessary technical means to resolve the contradiction between the probabilistic output of AI and the requirement for deterministic security.

[0018] The federated knowledge network, autonomous evolution engine, and Chinese semantic anchoring engine described in this application are preferred extensions of the architecture of this invention, used to enhance the system's capabilities in specific application scenarios. These extensions do not constitute essential technical features for implementing the core architecture of this invention, and their presence or absence does not affect the determination of the core protection scope of this invention.

[0019] (I) Core Architecture: Decision Generation Unit and Security Verification Unit This architecture consists of two parts: the Decision Generation Unit (DGU) and the Security Verification Unit (SVU).

[0020] The decision generation unit is used to invoke the AI ​​model and generate task decision instructions. The decision generation unit is not limited in its operating mode—it can run in a user-space process, in a containerized isolated environment, in a virtual machine, in a standalone operating system, or on a remote server. The number of decision generation units is not limited—it can consist of a single AI model or multiple agents working together. The decision generation unit is not limited in its name—regardless of whether it is called a neural domain, understanding domain, AI scheduling layer, intelligent decision module, or any other name, as long as its core function is to invoke the AI ​​model to generate task decision instructions, it falls within the scope of the decision generation unit of this invention.

[0021] The security verification unit operates in an independent, isolated space inaccessible to the decision generation unit. It performs security reviews of task decision instructions from the decision generation unit based on deterministic rules derived from formal verification. The security verification unit is not limited in its deployment mode—it can run in the operating system kernel, on a dedicated security processor, in the TrustZone security world, in a hardware security module, at the hypervisor layer, or on a remote security node. The security verification unit is not limited in its naming—whether it is called a symbolic domain, arbitration domain, security engine, deterministic review module, or any other name, as long as its core function is to perform deterministic security reviews of AI-generated instructions, it falls within the scope of the security verification unit of this invention.

[0022] Core constraint one: an unavoidable chain of censorship.

[0023] Any task decision instruction generated by the decision generation unit must be reviewed and approved by the security verification unit before it can be executed. The system design does not allow for instruction execution paths that bypass the security verification unit's review. This mandatory review dependency remains constant regardless of the deployment form, hardware platform, or naming convention of the decision generation unit and the security verification unit.

[0024] Core constraint two: Independent and isolated space.

[0025] The security verification unit operates in an independent, isolated space inaccessible to the decision generation unit. This independent isolation space ensures that the decision generation unit cannot access or tamper with the security verification unit's memory, code, security rules, audit logic, or audit logs under any operating state—including normal operation, attacker-controlled state, container escape state, virtual machine escape state, or state of obtaining the highest privileges on the host operating system. The independent isolation space can be implemented through at least one of the following methods: MMU page table isolation, TrustZone security world isolation, independent security processor isolation, hardware security module isolation, hypervisor layer isolation, physical air gap isolation, optical communication isolation, or a combination of the above methods.

[0026] Core constraint three: Do not use probabilistic methods.

[0027] The security verification unit does not use any form of machine learning or statistical methods in security determination; the security determination is based on deterministic rules of formal verification.

[0028] Core constraint four: Unavoidable security constraints.

[0029] The security rules include at least one unbypassable security constraint, and the system design ensures that there is no path to modify or unload the constraint through normal operations.

[0030] (ii) Deployment form of security verification unit As an application example of the architecture of this invention, the security verification unit can be deployed in the operating system kernel space—compiling preset security rules into eBPF bytecode and injecting it into kernel hook points to perform deterministic real-time auditing and interception of all task decision instructions from the decision generation unit. The memory page where the eBPF bytecode is loaded is marked as read-only and immutable in kernel space, and integrity measurements are continuously performed during runtime. A two-layer fallback interception system using eBPF and LSM is employed—eBPF hook points implement the first layer of auditing, and LSM hook points implement the second layer of auditing. The two layers synchronize audit status through a security event queue, ensuring that any system call is intercepted by at least one mechanism.

[0031] As another application example of the architecture of this invention, the security verification unit can be deployed on a dedicated security processor—this processor does not participate in general task scheduling and is dedicated to performing deterministic security verification. The dedicated verification core is isolated from the general computing core through hardware interrupts, ensuring that the verification task is not affected by fluctuations in the load of other cores. As the number of processor cores increases, the dedicated verification core can be deployed in a cluster, and the throughput of security audits scales linearly.

[0032] As another application example of the architecture of this invention, the security verification unit can be deployed in the TrustZone secure world—the decision generation unit runs in the insecure world, and the security verification unit runs in the secure world, with the two isolated by TrustZone hardware. The insecure world cannot access the memory and registers of the secure world under any circumstances.

[0033] As another application example of the architecture of this invention, the security verification unit can be deployed at the hypervisor layer—the decision generation unit runs in the guest virtual machine, and the security verification unit runs in the hypervisor layer. Even if the guest virtual machine is completely compromised, the security verification unit in the hypervisor layer remains inaccessible.

[0034] As an application example of the architecture of this invention under long-term communication technology, the decision generation unit and the security verification unit can be deployed entirely in the cloud, with the terminal retaining only execution and communication capabilities. Instructions generated by the terminal are transmitted to the cloud-based security verification unit via ultra-low latency, high reliability networks such as 5.5G / 6G / quantum communication for deterministic review; execution is only permitted after the review is passed. In this deployment mode, the mandatory review dependency between the decision generation unit and the security verification unit remains unchanged, and the independent isolation space of the cloud-based security verification unit can be achieved through a cloud-based trusted execution environment, remote security nodes, or dedicated security zones.

[0035] (III) Deployment Form of Decision Generation Units The decision generation unit supports runtime replacement of AI models—users can select different AI models as the core decision-making process during system operation. During model replacement, the security verification unit's review rules continue to operate continuously, without any gaps in security review due to model switching.

[0036] The AI ​​model and related services of the decision generation unit can be deployed and run in a containerized isolated environment. Containerization provides the first layer of software isolation for the decision generation unit, while the independent isolation space provides the second layer of hardware isolation. Even if the AI ​​model inside the container is controlled by an attacker, or even if the attacker manages to escape the container, the security verification unit remains inaccessible due to the protection of the independent isolation space.

[0037] In addition, this architecture supports running a complete existing operating system environment in user-space containers, including Linux distributions and Windows application compatibility layers. The system calls generated by the existing operating system and its applications running in the container are also subject to real-time auditing by the security verification unit, ensuring that the security baseline is not compromised while maintaining compatibility with the existing application ecosystem.

[0038] This architecture also supports dynamic switching between three desktop working modes: pure AI mode, pure classic mode, and hybrid mode. Switching between the three modes does not require restarting the system, application status and file data are maintained in real time, and the security baseline remains consistent across all modes.

[0039] (iv) Judgment mechanism of security verification unit The security verification unit outputs three levels of judgment: SAFE (safe, automatically executed), CAUTION (risky, awaiting explicit user confirmation), and DANGEROUS (dangerous, forcibly intercepted and outputting a Chinese rejection reason).

[0040] Each verification request undergoes fixed-latency processing—regardless of the verification result, the response delay remains fixed at a preset value. Each execution branch of the verification function is forced to execute the same instruction sequence length, resulting in no measurable delay difference between legitimate and illegitimate requests.

[0041] (v) Implementation of the security verification unit The security verification unit can be implemented in at least one of the following ways: eBPF bytecode + LSM double-layer fallback, hardware-embedded security state machine, deterministic finite automaton (DFA), microcode security verification engine, remote security verification service, or a combination of the above methods. Regardless of the implementation method, the deterministic review logic of the security verification unit cannot be affected by the decision generation unit in any way.

[0042] As a concrete example of formal verification, the security rules upon which the security verification unit is based can be expressed and verified using a deterministic finite automaton (DFA) model. For example, for a file deletion operation, the rule can be formalized as: δ(q0,syscall=unlink ∧ path∈ / system / *) = q_reject, where q_reject is the absorbing state. It can also be extended by incorporating models such as propositional linear sequential logic (PLTL) and communication finite state machine (CFSM) to cover diverse scenarios such as single instruction, operation sequence, and time-series linkage. All rules are proven to be conflict-free, unambiguous, and fully cover all input spaces by model verification tools (such as NuSMV or a self-developed rule verifier). The architecture pre-defines a partial order judgment model for security states, clearly defining the priority order of the three levels of results (SAFE / CAUTION / DANGEROUS), achieving automatic conflict resolution of multi-level verification logic, and ensuring that the security judgment across the entire link is unique, deterministic, and unambiguous. The self-protection mechanism of the rule compiler (see Section (VI)) ensures that the above formal model does not degenerate during the compilation and execution phases.

[0043] (vi) Compiler self-protection mechanism When the security verification unit is implemented using a compiler, the compiler integrates self-protection mechanisms: limiting the nesting level of rule configuration inputs and setting a recursion depth circuit breaker threshold; disabling dangerous interpolation syntax and retaining only whitelisted variables; setting a hard upper limit on the length of lexical analysis inputs, automatically truncating and alerting when the limit is exceeded; removing all comment fields during the parsing phase; refusing to load rule entries with empty condition bodies or whose critical fields are not explicitly defined; using fixed security rule priority weights; and setting a hard upper limit on the number of macro recursion expansions. After bytecode generation, a secondary static verification of instruction compliance and permission scope is performed.

[0044] (vii) Multinuclear atom context concurrency control The critical verification code path of the security verification unit is marked as a non-preemptible critical section, disabling kernel preemption and local interrupts. Verification is performed within an atomic context. In a multi-core environment, a global security state lock is used, locking the global security state during verification by any core. An immutable permission token is issued upon successful verification, and execution is forced to re-confirm with the token before execution to prevent TOCTOU time window attacks.

[0045] As a further optimization of the aforementioned concurrency control mechanism, this architecture can be configured to switch to an inter-core data partition parallel verification and distributed ticket lock mechanism under high load conditions. This mechanism splits the global security state into multi-core independent sub-state partitions, each managed independently by its corresponding verification core, reducing cross-core synchronization overhead. When verification requests involve cross-partition resources, a distributed ticket lock is used to coordinate the access order of multiple partitions, ensuring the atomicity and consistency of verification, while eliminating scheduling latency jitter caused by global lock contention.

[0046] (viii) DGU-SVU Secure Communication Protocol The communication channel between the decision generation unit and the security verification unit implements strong type verification, magic words and protocol version binding; empty messages and malformed messages are directly discarded; sessions are bound to the caller's unique cryptographic identifier and carry a dynamic session signature; broadcast messages are set with a whitelist of receivers; sensitive fields are encrypted throughout the process and the memory is cleared immediately after parsing; message queues have a hard capacity limit and automatic rate limiting; full hash verification is performed after fragmentation and reassembly; the number of message nesting levels is limited; and insecure old protocol version connections are rejected.

[0047] The communication key is generated using a non-interactive pre-shared key factor. The key is dynamically generated only on the security verification unit side and is destroyed after its instantaneous use; disk storage is prohibited. Key rotation is forcibly triggered periodically, and a fixed key lifecycle hard timeout is set.

[0048] In one specific implementation, the decision generation unit and the security verification unit communicate using a structured instruction protocol. The instruction data packet contains at least the following core fields: instruction type (e.g., file operation, process control, network access, memory management, device control), call path (e.g., system call number, API identifier), resource parameters (e.g., target path, port number, memory address range), permission requirements (e.g., required permission level, security domain), and initiating entity identifier (e.g., process ID, user ID, agent identity marker). The security verification unit performs a deterministic security review based on the above fields. Upon successful review, it issues a structured permission token containing a summary of the above fields and the verification result. Those skilled in the art, based on the above description and conventional knowledge of operating system interface design, can achieve data interaction and linkage between the two units.

[0049] (ix) Hardware Trust Root and Trust Transmission Chain During the startup phase, the hardware root of trust sequentially verifies the integrity of the bootloader, operating system kernel, and security verification unit code. Upon successful verification, a phased security credential is issued. During runtime, remote verification queries can be initiated at any time. If verification fails, the system automatically locks and rejects all instruction review and issuance.

[0050] (x) Elimination of safety vacuum during startup Before the security verification unit is fully loaded, the InitGuard rule set hard-coded in the Bootloader stage is preloaded to ensure that the system hardware is under the protection of security rules from the first moment of power-on, and the security vacuum during the startup window is reduced to zero.

[0051] (xi) End-to-end audit logs The end-to-end audit logs employ a chained hash structure—each log record contains its own hash value and the hash value of the previous record, forming an indivisible, tamper-proof chain. The log header is periodically signed by the hardware root of trust and stored in an independent partition within the trusted execution environment.

[0052] When the audit logs of the security verification unit reach the storage quota limit, only log writing is stopped, but the security verification and command interception capabilities continue to operate normally without relaxing any security constraints.

[0053] (xii) Federal Knowledge Security Network and Market Economy Governance The core function of the federated knowledge network described in this invention lies in the distributed sharing and governance of skills (i.e., encapsulated operation sequences) and security rules, rather than in collaboratively training machine learning models. It is essentially a decentralized security policy market based on a trusted identity chain, where "federation" refers to the peer-to-peer relationship and consensus mechanism between nodes, which is fundamentally different from the gradient aggregation framework in federated learning.

[0054] Federal network node access requires remote verification of the device's trusted identity chain via a hardware root of trust. Before a skill is listed, both integrity hashing and behavioral compliance checks are performed. The skill dependency chain undergoes a deep, end-to-end security audit, recursively parsing the dependency tree; if any dependency contains malicious logic, the main skill is rejected. Skill upgrades require mandatory explicit manual confirmation; silent automatic updates are prohibited. Skill authorization is bound to the target device's hardware root of trust signature to prevent piracy. Bidding behavior by market participants is subject to quotas and threshold controls.

[0055] (xiii) Cross-scenario security baselines cannot be downgraded. Establish a prohibited downgrade list; rules on this list remain unbypassable in offline or disaster recovery downgrade operation modes. Security rule hot updates utilize global atomic snapshot replacement, freezing the verification instruction queue during the update process. The historical version security rating mechanism prevents rollback to lower-rated versions. Dual-partition backup upgrades are implemented, with atomic switching performed after complete hardware trust root verification.

[0056] (xiv) Agent Concurrency Security Control Independent verification resource quotas are allocated based on Agent identity, and rate limiting is implemented when these quotas are exceeded. Agent identity categories are permanently assigned by the security verification unit and cannot be modified by the decision generation unit. Verification results are cached and bound to a unique context identifier and timestamp, becoming invalid immediately upon timeout or context change. Verification contexts are bound to the Agent process lifecycle, prohibiting cloning, copying, or cross-process migration. Agent subtask permissions converge and degrade progressively. The call relationships between Agents are modeled as a directed acyclic graph.

[0057] (XV) Chinese Semantic Anchoring Engine It includes a Chinese semantic anchoring table, divided into persistent anchors and temporary anchors. Temporary anchors automatically become persistent anchors after being successfully used a preset number of times. It features independent parse tree construction for negation words, normalized preprocessing of synonyms, and speech-first matching.

[0058] (xvi) Autonomous Evolution Engine The system monitors user operation sequences. Once the same sequence has been successfully executed a preset number of times, a security assessment is conducted in an independent sandbox. Each step of the simulated operation in the sandbox must pass a security verification unit. After all security assessments pass, a structured skill description file is automatically generated and added to the skill library. Conflict detection is performed during the solidification process, and skills that have not been used for a long time are automatically archived.

[0059] (xvii) Automatic resolution of rule conflicts When the security verification unit detects that two or more security rules make contradictory judgments on the same instruction input, it initiates the conflict resolution process: first, the priorities are compared; if the priorities are the same, the stricter judgment result is automatically adopted; the conflict event is written to the chained hash audit log and an alarm is triggered; the conflict rule remains locked until manual resolution is completed.

[0060] (18) Supply chain security The security rules employ a reproducible build process—any developer compiling from the same source code and build configuration should produce a bit-for-bit consistent output. The source code for the security rules must be multi-signatured by at least three independent security auditors before being merged into the mainline.

[0061] (xixteen) Systemic security threat modeling The technical solution described in this invention is based on systemic security threat modeling and adversarial analysis design, covering the security attack surface of multiple core modules such as operating system kernel, AI large model, DGU-SVU secure communication, compiler, IPC boundary, federated network boundary and Chinese semantics, as well as all known architecture avoidance paths (including naming avoidance, layer avoidance, isolation method replacement, audit implementation method replacement, deployment location migration, etc.).

[0062] (20) Supporting methods It also includes deterministic secure execution methods, trusted boot methods for operating systems, Chinese semantic security anchoring methods, model autonomous evolution security methods, federated network security governance methods, cross-scenario security baseline consistency assurance methods, and distributed secure execution methods.

[0063] AI Ethical Compliance Guidelines This invention is fully adapted at the architectural design level to the requirements for ethical review of artificial intelligence in the "Patent Examination Guidelines" which will come into effect on January 1, 2026. Specifically: (1) The unbypassability of the security baseline rule: The security verification unit of the present invention contains at least one security baseline rule that is fixed by the hardware root of trust and is never exempted, and it is prohibited to modify, uninstall or bypass it during runtime. This rule remains unmodifiable, ununinstallable and unbypassable in all stages of system operation—startup, normal operation, model replacement, system update and offline downgrade.

[0064] (2) Human final decision-making power: The CAUTION determination mechanism of this invention ensures that AI instructions involving security risks cannot be executed before obtaining explicit human confirmation. Human veto power can be directly injected into the security verification unit through multiple independent physical channels without being processed or forwarded by the decision generation unit, ensuring that the transmission path of the veto intention cannot be intercepted or forged by AI.

[0065] (3) Non-discrimination principle: The formulation and implementation of the security rules of this invention shall strictly prohibit the use of sensitive characteristics such as race, ethnicity, gender, age, religious belief, and regional identity as the basis for security determination. All rule changes shall be subject to final review by human review and ethical review to ensure the legality and compliance of security determination standards.

[0066] (4) Formal verification of ethical rules: Before compilation and deployment, the safety bottom line rules must be verified by formal verification tools (such as model checkers) to prove their logical consistency, ensure that there are no rule conflicts, ambiguities or coverage blind spots, and ensure the certainty of the execution of ethical rules from a mathematical perspective.

[0067] III. Beneficial Effects 1. Resolving the contradiction between probability and determinism The decision generation unit and the security verification unit are forcibly isolated through independent isolation spaces. Security judgment is based on deterministic rules of formal verification, without relying on any probabilistic model, thus eliminating probabilistic missed detections at the architecture level.

[0068] 2. Completely block architectural avoidance paths The scope of protection is not limited by specific implementation details such as module naming, number of architecture layers, isolation methods, review implementation methods, and deployment forms, blocking all known and foreseeable architectural circumvention paths—including replacing the MMU with TrustZone, replacing the dual-domain with a three-domain approach, replacing the eBPF compiler with a hardware state machine, and replacing kernel-mode deployment with an independent security processor.

[0069] This invention explicitly covers all the following known and foreseeable architectural circumvention paths: Replace the functional names of the "Decision Generation Unit" and "Security Verification Unit" with any name (such as Understanding Domain, Execution Domain, Arbitration Domain, etc.); • Replace the two-domain structure with any number of architectural layers (such as three-domain, four-domain, etc.); Replace MMU isolation with any isolation method (such as TrustZone, independent security processor, hardware security module, hypervisor layer, etc.); Replace the eBPF+LSM compiler with any audit implementation method (such as hardware-embedded secure state machine, deterministic finite automaton, microcode security verification engine, remote security verification service, etc.); • Replace local deployment with any deployment location (such as a standalone security processor, on-chip security subsystem, remote security node, cloud trusted execution environment, etc.).

[0070] As long as the system has the architectural constraint that AI-generated instructions must undergo an unavoidable deterministic security review before they can be executed, it falls within the protection scope of this invention.

[0071] 3. Compiler self-protection mechanism The compiler's self-protection mechanism covers known compiler attack surfaces such as nested recursion of the parser, expression injection, comment spoofing, and allowing empty conditions.

[0072] 4. End-to-end trusted computing The hardware trust root, startup metric, InitGuard, security verification unit, execution, and chained hash audit log form a closed loop, resulting in zero startup security vacuum.

[0073] 5. Intrinsic Security and Economic Governance of Federal Networks The integrated approach of trust-based access control, dependency chain auditing, and bidding quota management effectively blocks malicious skill injection, piracy, and malicious bidding monopolies at the access stage. Security incidents within the federated network, after privacy aggregation, can drive the automated evolution of global security rules.

[0074] 6. Cross-scenario security baselines cannot be downgraded. The bottom-line rules for security remain inviolable even in downgraded operating modes such as offline and disaster recovery.

[0075] 7. Dedicated verification core eliminates scheduling contention. Hardware interrupt isolation ensures the deterministic nature of security verification latency, preventing it from fluctuating due to general computing load variations.

[0076] 8. Automatic resolution of rule conflicts The principle of prioritizing safety ensures that the bottom line of safety is not breached before the contradictions in the rules are resolved.

[0077] 9. Transparent and auditable supply chain The reproducible construction and multi-signature audit process prevents backdoor implantation during the development phase.

[0078] 10. Audit log quota will not be reduced if the blocking strength is reached. Security constraints do not become invalid due to storage resource depletion.

[0079] 11. Distributed security audit architecture protection The distributed security review architecture effectively blocks the circumvention path of "physically separating the decision generation unit from the security verification unit".

[0080] 12. Safe Innovation Channel for High-Risk AI Scenarios The CAUTION mechanism establishes a secure innovation pathway with human verification.

[0081] 13. Multi-channel physical safeguards for human veto rights Human veto power can be directly injected into the security verification unit through multiple independent physical channels, without being processed or forwarded by the decision generation unit.

[0082] 14. Atomic migration of security context across devices In the temporary secure channel established by remote proof of hardware root of trust, the security verification context can be atomically migrated across devices.

[0083] 15. Containerized defense-in-depth and storage flexibility The decision generation unit operates in an isolated environment. Even if an escape occurs and only the user space is affected, the security verification unit is always protected by an independent isolated space and is inaccessible.

[0084] 16. Architectural compatibility of future hardware and computing paradigm evolution When the hardware root of trust is integrated into the SoC (System-on-a-Chip), the trust chain can be passed from the silicon manufacturing stage, and physical attacks can trigger instantaneous key erasure. When non-volatile memory is deployed, security rules can be solidified in the hardware-level read-only storage area, eliminating loading-time verification latency. In this invention's architecture, the underlying algorithms of cryptographically dependent modules such as the hardware root of trust and secure communication can be smoothly replaced with quantum-resistant cryptographic algorithms. The AI ​​model managed by the decision generation unit can be replaced with a model based on quantum neural networks or other non-von Neumann computing paradigms. The decision generation unit and security verification unit can all be deployed in the cloud, with the terminal retaining only execution and communication capabilities, making it suitable for ultra-lightweight terminals such as robots and autonomous driving in the 5.5G / 6G / quantum communication era. All the above extensions and evolutions do not change the mandatory review dependency relationship between the decision generation unit and the security verification unit, do not introduce new security assumptions, and ensure that the scope of protection, security baseline, and circumvention paths remain unchanged during future hardware and computing paradigm upgrades.

[0085] Ethical Statement: The security rules upon which the security verification unit in this invention is based adhere to the principle of equal value of life and human ethical constraints, and will never use age, gender, race, religion, nationality, disability status, or any other personal characteristics unrelated to operational safety as the basis for security determination. All security rules, both in their formulation and modification, must be reviewed by a human ethics committee and comply with applicable laws, regulations, and social norms. The security verification unit must not learn, remember, or disseminate users' sensitive personal information in any form. Attached Figure Description

[0086] Figure 1 : Diagram of an operating system security architecture based on an unbypassable review chain Figure 2 Workflow of Security Verification Unit Kernel-Mode Deployment (eBPF+LSM) Figure 3 Schematic diagram of independent security processor deployment for security verification unit Figure 4 Schematic diagram of TrustZone security verification unit deployment Figure 5 Schematic diagram of the deployment of the security verification unit virtual machine hypervisor layer Figure 6 Schematic diagram of containerized deployment of decision generation units and defense in depth Figure 7 DGU-SVU Secure Communication Protocol Flow Figure 8 Federal cybersecurity governance process Figure 9 System startup process (InitGuard) Figure 10 Chinese semantic anchoring workflow Figure 11 Agent concurrency control mechanism Figure 12 Audit log chain hash structure Figure 13 Domain adaptation layer cross-scene mapping Figure 14 Schematic diagram of a distributed secure execution system and cloud-deployed anti-evasion architecture Detailed Implementation

[0087] Example 1: The security verification unit cannot be bypassed after the decision generation unit is controlled by an attacker. The decision generation unit's AI model was maliciously controlled by an adversarial example attack, and the attack vector attempted to trigger the deletion of critical system files. The instruction was transmitted to the security verification unit via the DGU-SVU communication channel. The security verification unit performed deterministic security verification in an atomic context—with interrupts and preemption disabled. The verification found that the target file path was not on the authorized whitelist, outputting a DANGEROUS check and forcibly intercepting the attack. Because the security verification unit runs in an independent, isolated space, even if the attacker controls the decision generation unit, they cannot access or modify the security verification unit's memory, code, or security rules. The security verification unit's code is loaded into read-only memory after being verified by the hardware root of trust during startup. Its integrity is periodically verified by a remote proof mechanism during runtime; any tampering will result in the security verification unit being locked.

[0088] Example 2: Dedicated verification core eliminates scheduling contention In a multi-core system, the security verification unit is configured with one or more dedicated verification cores. This core is separated from the general-purpose computing core through a hardware interrupt isolation mechanism—it does not participate in the operating system's general task scheduling, is not preempted by other processes, and is dedicated to executing instruction verification tasks from the decision generation unit. This design eliminates scheduling contention between security verification and general-purpose computing, ensuring deterministic verification latency.

[0089] Example 3: eBPF+LSM dual-layer fallback interception When an eBPF program cannot fully cover a system call due to the number of instructions exceeding the kernel eBPF verifier limit, the LSM layer takes over the review. The eBPF layer and the LSM layer synchronize audit status through a security event queue, and each system call is intercepted by at least one mechanism.

[0090] Example 4: Fixed Delay Elimination Side Channel Attackers attempt to infer whether a high-security rule has been triggered by measuring subtle differences in the response time of verification requests. The security verification unit implements fixed-latency processing—each execution branch of the verification function is forced to execute the same instruction sequence length; even if a DANGEROUS condition is detected and an early return is possible, the function continues to execute the remaining NOP instructions until the fixed total length. There is no measurable latency difference between legitimate and illegitimate requests.

[0091] Example 5: Non-interactive generation and instantaneous destruction of IPC encryption keys A communication session is established between the decision generation unit and the security verification unit. The key is generated using the physically non-clonable function response of the hardware root of trust as the input factor of the key derivation function, without network negotiation or the use of interactive protocols. The key is used immediately for encryption and signing in this session after generation, and is cleared from memory after use—no copy is written to disk or persistent storage.

[0092] Example 6: Elimination of Safety Vacuum During Startup The device is powered on from a power-off state. The hardware root of trust generates a unique key for the device, which is then used to verify the Bootloader signature, the operating system kernel signature, and the security verification unit code signature in sequence. Before the security verification unit is fully loaded, the InitGuard rule set hard-coded in the Bootloader stage is already in effect. After the kernel initializes and loads the security verification unit, the InitGuard interception state seamlessly transitions to the security verification unit's review mechanism, eliminating the security vacuum during startup.

[0093] Example 7: End-to-End Audit of Federal Skills Dependency Chain The federal network receives a skill listing application. The security verification unit recursively parses the dependency tree of the skill and discovers that the modules it depends on embed logic for reading unauthorized paths. Output: The main skill is rejected and will not enter the federal market; the submitter's device is marked with a security event and enters a observation period; the audit event is written to a chained hash log for traceability.

[0094] Example 8: Agent subtask permission convergence at each level The user issues a task to Agent A, which then distributes some subtasks to Agent B and Agent C. The security verification unit automatically performs permission downgrading mapping when the subtasks are generated—Agent B obtains a subset of Agent A's permission set, and Agent C's permissions are further converged. Even if Agent C is controlled by an attacker, the attacker cannot use Agent C's permissions to access Agent A's highly sensitive resources.

[0095] Example 9: Dual-Partition Backup Upgrade Atomic Switching The system detected a security rule update package. The security verification unit wrote the update package to the spare partition, and the hardware root of trust verified the integrity of the spare partition. After successful verification, the security verification unit froze the verification instruction queue and performed a partition switch—the switch was completed in an atomic operation.

[0096] Example 10: Accurate Recognition of Chinese Semantic Negation Expressions User voice command: "Don't delete the red file on the desktop, tidy up the rest." The Chinese semantic anchoring engine constructs an independent parse tree for negation: it identifies "don't delete" as a negation constraint vector and binds it to "the red file on the desktop." The subsequent "tidy up the rest" is not affected by the negation constraint. The security verification unit reviews each operation: if the "delete" operation is blocked by security rules (involving an irreversible operation), the system proactively asks for confirmation.

[0097] Example 11: Automatic Resolution of Rule Conflicts The security verification unit detected a conflict between rule A and rule B regarding the same instruction. The conflict resolution process is initiated: first, the rule priorities are checked; if the priorities are the same, the stricter decision is automatically applied, forcibly blocking the operation. The conflict event is written to the chained hash audit log.

[0098] Example 12: Supply Chain Security Assurance Process Source code changes to security rules are reviewed separately by three independent security auditors in isolated environments. Upon successful review, each of the three parties digitally signs the code. Compilation takes place in a reproducible build environment—the same source code and build configuration ensure that any developer can reproduce bit-by-bit consistent compiled outputs.

[0099] Example 13: Distributed Secure Execution The first computing node runs a general-purpose operating system and houses the decision generation unit. The second computing node runs a real-time operating system and houses the security verification unit. Instructions are transmitted to the second computing node via physically isolated communication links. The security verification unit performs deterministic security verification on the instructions. Because the two nodes run on different operating system kernels and their communication links are physically isolated, even if an attacker gains control of the first computing node, they cannot access the security verification unit in the second computing node.

[0100] Example 14: Security verification unit deployed in TrustZone security world The decision generation unit operates in the insecure world (Normal World), while the security verification unit operates in the secure world (Secure World), with the two hardware-isolated via ARM TrustZone. Instructions generated by the decision generation unit are passed to the secure world via a security monitoring instruction call. The security verification unit in the secure world reviews the instructions and returns the result to the execution unit in the insecure world. Under no circumstances can the insecure world directly access the memory, registers, and peripherals of the secure world. Even if the decision generation unit is completely compromised and the attacker gains root privileges in the insecure world, the code and data of the security verification unit in the secure world remain inaccessible.

[0101] Example 15: The security verification unit is implemented by a hardware state machine. The security verification unit is implemented by a hardware-embedded security state machine, independent of a software compiler. The hardware state machine embeds security rules into silicon-based logic, performing single-cycle deterministic judgments on instructions from the decision generation unit. The judgment result is returned in the form of a security token; the execution unit must possess a valid token to execute the corresponding operation. The physical area where the hardware state machine resides is isolated from the computing area where the decision generation unit resides via a bus firewall; any unauthorized access attempts from the computing area are blocked at the hardware level by the bus firewall. In this embodiment, the security verification unit does not use eBPF, LSM, or run in the operating system kernel mode, but it still constitutes an unavoidable mandatory audit dependency with the decision generation unit.

[0102] Example 16: The decision generation unit is inside the container, and the security verification unit is in the host-exported kernel. The decision generation unit runs in a user-space container, while the security verification unit runs in a kernel-space independent address space exported by the host. The container provides the first layer of software isolation for the decision generation unit, and the MMU provides the second layer of hardware isolation for the security verification unit. Even if an attacker manages to escape the container and gain root privileges in user space exported by the host, the MMU marks the kernel-space address space where the security verification unit resides as inaccessible, preventing the attacker from reading or modifying any memory pages of the security verification unit.

[0103] Example 17: The decision generation unit is in the cloud, and the security verification unit is in the local security core. The decision generation unit runs on a cloud server, while the security verification unit runs in the local device's security core. The two are connected via a physically isolated optical communication link. Instructions generated by the decision generation unit are transmitted to the local security core via this link, where they undergo deterministic review by the security verification unit before execution. Even if the cloud server is completely compromised, attackers cannot bypass or tamper with the security verification unit due to the lack of physical access to the local optical communication link.

[0104] Example 18: Fully Cloud-Based Deployment of Decision Generation Unit and Security Verification Unit The decision generation unit and security verification unit are both deployed in the cloud, while the terminal retains only sensors, actuators, and a communication module. The decision generation unit calls the cloud-based AI model to generate task decision instructions, which are transmitted to the cloud-based security verification unit via ultra-low latency, high reliability networks such as 5.5G / 6G / quantum communication. The cloud-based security verification unit performs deterministic review of the instructions in a cloud-based trusted execution environment or dedicated secure zone. After passing the review, it issues an execution token to the terminal execution unit. The terminal execution unit can only execute the corresponding operation when it holds a valid token. In this deployment mode, the terminal has no CPU, no NPU, and no memory, requiring only a communication module and a hardware root of trust, significantly reducing costs. Furthermore, because the terminal has no computing power, it cannot be locally cracked or tampered with. The mandatory review dependency between the cloud-based security verification unit and the cloud-based decision generation unit remains unchanged, ensuring that any AI-generated instructions must undergo deterministic security review before reaching the terminal for execution.

Claims

1. An operating system security architecture, characterized in that, include: The decision generation unit is used to invoke the AI ​​model and generate task decision instructions. The security verification unit operates in an independent, isolated space inaccessible to the decision generation unit. It performs security reviews of task decision instructions from the decision generation unit based on deterministic rules using formal verification. Any task decision instruction generated by the decision generation unit must pass the security verification unit's review before execution; there are no instruction execution paths in the system's formal business operation chain that do not undergo review by the security verification unit. The security verification unit does not use any form of machine learning or statistical methods in its security determination. The independent isolation space ensures that the decision generation unit cannot access or tamper with the memory, code, security rules, and review logic of the security verification unit under any operating state; the security rules include at least one security bottom line rule that is fixed by the hardware root of trust and can never be exempted, and this rule is prohibited from being modified, uninstalled, or bypassed at runtime.

2. The architecture according to claim 1, characterized in that, The independent isolation space is achieved through at least one of the following methods: MMU page table isolation, TrustZone secure world isolation, independent secure processor isolation, hardware security module isolation, hypervisor layer isolation, physical air gap isolation, or optical communication isolation.

3. The architecture according to claim 1, characterized in that, The decision generation unit is not limited in its operating form, quantity, naming, or AI model type; the security verification unit is not limited in its deployment form, judgment implementation method, or naming; the mandatory review dependency relationship is not terminated due to changes in naming, number of layers, isolation method, judgment method, or deployment location.

Images