A Multi-Layer Sandbox-Based Full Lifecycle Protection System and Method for Vehicle Components

Abstract

This invention discloses a multi-layered sandbox-based full lifecycle protection system and method for vehicle components, belonging to the field of vehicle security protection technology. The system includes: acquiring the vehicle component generation code, component type tags, target operating scenario identifiers, and preset security level parameters; generating compliant component code through taint propagation analysis and security disinfection; allocating independent operating containers to the compliant component code to construct a multi-layered isolation environment; dynamically generating dynamic permission configuration policies based on driving status; monitoring the operating status in real time; determining the anomaly level using a Naive Bayes classifier; and performing self-healing operations until the component's lifecycle ends. This invention achieves full-process security protection for vehicle components from deployment to destruction, improving the vehicle system's resistance to attacks and anomalies, and ensuring vehicle operation safety.

Description

Technical Field

[0001] This invention belongs to the field of vehicle safety protection technology, specifically a vehicle component full life cycle protection system and method based on multi-layer sandbox. Background Technology

[0002] In-vehicle software components cover a variety of categories, including navigation, entertainment, and control. These components come from diverse sources and have varying code quality, leading to a significant increase in security risks. Current in-vehicle component protection often employs single isolation or static permission control, resulting in coarse-grained protection, poor flexibility, and difficulty in adapting to heterogeneous in-vehicle computing environments and dynamic operating scenarios.

[0003] Existing technologies have certain shortcomings: First, they lack targeted security testing and disinfection before code deployment, making it easy for external inputs to spread through taints and cause vulnerabilities such as memory corruption; second, the isolation mechanism is too simplistic, making it difficult to achieve deep isolation between components' views, processes, and networks, which can easily lead to unauthorized access across components; third, the permission policies are static and fixed, unable to be dynamically adjusted according to the vehicle's driving status, which can easily lead to misoperation in high-risk scenarios; fourth, the anomaly monitoring dimensions are limited, and the self-healing capability is weak, making it difficult to quickly handle issues such as memory anomalies and resource abuse; fifth, the protection strategies are fixed and cannot be iterated and strengthened with component operation, which poses security risks in the long run.

[0004] Therefore, there is an urgent need for a protection solution that covers the entire lifecycle of vehicle components, has multi-layer isolation, dynamic permissions, real-time self-healing and progressive hardening capabilities, and ensures the safe operation of vehicle systems. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention proposes a multi-layered sandbox-based full lifecycle protection system and method for vehicle-mounted components. The system acquires the generated code, component type tags, target operating scenario identifiers, and preset security level parameters of the vehicle-mounted components. After taint propagation analysis and security disinfection, compliant component code is generated. An independent operating container is then allocated to the compliant component code, constructing a multi-layered isolation environment. Dynamic permission configuration policies are generated based on driving status. The operating status is monitored in real time, and anomaly levels are determined using a Naive Bayes classifier. Self-healing operations are then performed until the component's lifecycle ends. This invention achieves full-process security protection for vehicle-mounted components from deployment to destruction, enhancing the vehicle system's resistance to attacks and anomalies, and ensuring vehicle operational safety.

[0006] To achieve the above objectives, the present invention provides the following technical solution:

[0007] A multi-layered sandbox-based approach to the full lifecycle protection of automotive components includes:

[0008] S1: Obtain the generated code, component type label, target running scenario identifier, and preset security level parameters of the vehicle component to be deployed, and perform vehicle safety disinfection on the generated code according to the security level parameters and component type label, and output compliant component code;

[0009] S2: Allocate independent running containers for the compliant component code, build a multi-layered isolation environment, and output isolated running instances;

[0010] S3: Generate dynamic permission configuration policies based on isolated running instances, target running scenario identifiers, component type tags, and real-time acquired vehicle driving status data;

[0011] S4: Perform vehicle capability interface rate limiting and external data source hierarchical access control on the isolated running instance according to the dynamic permission configuration policy, and output the permission-controlled instance;

[0012] S5: Real-time monitoring of the permission-controlled instance, obtaining real-time running status data, determining the abnormality level based on the real-time running status data, executing the corresponding self-healing isolation operation, and outputting the repaired component instance;

[0013] S6: Return the repaired component instance to S2 and execute it in a loop until the lifecycle of the vehicle component ends.

[0014] Specifically, the step of performing vehicle safety disinfection on the generated code based on safety level parameters and component type labels, and outputting compliant component code, includes:

[0015] Based on the taint propagation depth threshold included in the security level parameters, and according to the communication or display component indicated by the component type label, the intermediate representation directed graph of the generated code is obtained; the nodes of the intermediate representation directed graph are basic blocks, and the edges are the control transfer relationships between basic blocks.

[0016] The symbolic execution method is used to mark the external network data receiving function node in the generated code as a taint source node and the vehicle control command generating function node as a taint sink node. Following the reachable path in the directed graph represented by the middle, the process traverses from the taint source node towards the taint sink node. For each edge traversed, the number of edges traversed on the current path is recorded as the current taint propagation depth. The correspondence between the current taint propagation depth and each node on the current path is stored as a taint-marked tuple. All taint-marked tuples of visited nodes together constitute a taint-marked set. Each taint-marked tuple contains a node identifier and the corresponding taint propagation depth value.

[0017] Continue traversing along the reachable path until the taint sink node is reached. Each time a new node is reached, update the taint propagation depth value in the taint label tuple and output a labeled directed graph carrying the taint propagation path and the taint propagation depth value corresponding to each node.

[0018] Specifically, the step of performing vehicle safety disinfection on the generated code based on security level parameters and component type labels, and outputting compliant component code, further includes:

[0019] When there is a path from any taint source node to any taint sink node in the labeled directed graph, and the taint propagation depth value in the taint label tuple at the end of the path exceeds the taint propagation depth threshold, the security sterilizer is invoked to locate the memory copy basic block on the taint propagation path that has not performed input length verification.

[0020] Based on the component type label, a boundary-checked safe function is found from the preset safe function replacement mapping table that is functionally equivalent to the unsafe function in the memory copy basic block. The unsafe function call in the memory copy basic block is replaced with the boundary-checked safe function to generate compliant component code.

[0021] Specifically, allocating independent running containers for the compliant component code includes:

[0022] Based on the resource requirement list of compliant component code, and according to the real-time data stream processing component or non-real-time log recording component indicated by the component type label, a snapshot of the physical resource distribution of the vehicle heterogeneous computing platform is obtained; the physical resource distribution snapshot includes the current operating frequency status of each physical processor core in the vehicle heterogeneous computing platform and the number of free physical page frames on each memory access node.

[0023] When the component type label indicates a real-time data stream processing component, a dedicated physical computing core is allocated to the compliant component code, and the set of continuous physical page frames on the local memory node corresponding to the physical computing core is locked as a dedicated memory region. At the same time, the interrupt response attribute of the physical computing core is set to only handle direct memory access requests from the dedicated memory region.

[0024] When the component type label indicates a non-real-time logging component, a shared logical computing core and a virtual memory area of ​​standard page size are allocated to the compliant component code, and the scheduling strategy of the logical computing core is set to a time-slice round-robin scheduling strategy.

[0025] Write the allocated physical computing core number or logical computing core number and the starting address of the dedicated memory region or the base address of the virtual memory region into the container isolation namespace, and output the unique namespace identifier of the independently running container.

[0026] Specifically, the construction of a multi-layered isolation environment and the output of isolated running instances include:

[0027] Based on the unique namespace identifier of the independently running container, and according to the graphical interface layout file carried in the code of the compliant component, the layer stack management interface of the vehicle graphics synthesis server is obtained.

[0028] Call the private layer creation function in the layer stack management interface to create an isolated layer bound to an independent frame buffer for the standalone running container, and set the visibility control bit of the isolated layer to allow the image data in the independent frame buffer to be passed to the physical display controller only when the standalone running container is in the foreground active state;

[0029] Obtain the isolation work pool application interface in the vehicle operating system coroutine scheduler, apply for a coroutine work pool identifier carrying a lock-free message queue for the independent running container, and set the transmission type restriction of the lock-free message queue to only allow the transmission of data payloads with value semantics, and prohibit the transmission of reference type data pointing to the internal control structure of other coroutine work pools;

[0030] When the compliant component code contains a web page rendering component tag, an independent browser rendering process is started, an isolated network namespace and virtual Ethernet device are allocated to the browser rendering process, and a filtering callback function based on a Uniform Resource Locator (URL) domain suffix whitelist is registered on the network protocol stack output path of the virtual Ethernet device.

[0031] The layer number of the isolated layer, the coroutine worker pool identifier, and the process identifier of the browser rendering process are encapsulated together into an isolated context descriptor for the isolated running instance and then output.

[0032] Specifically, the steps of S3 include:

[0033] Based on the isolation context descriptor of the isolated running instance, and according to the vehicle stationary power supply scenario or vehicle road driving scenario indicated by the target running scenario identifier, the vehicle longitudinal acceleration integral value in the real-time vehicle driving status data is obtained.

[0034] Based on the target running scenario identifier, the basic permission mask row vector is read from the pre-stored scenario permission matrix; each binary bit of the basic permission mask row vector corresponds to a vehicle capability interface or an external data source.

[0035] Based on the navigation map component or audio / video entertainment component indicated by the component type label, a dynamic risk-weighted correction method is used to correct the basic permission mask row vector to obtain the corrected permission mask row vector.

[0036] Each valid binary bit in the corrected permission mask row vector is organized into a list of permission entries according to the interface identifier and data source name, and the dynamic permission configuration policy is output.

[0037] Specifically, the step of modifying the basic permission mask row vector to obtain the modified permission mask row vector includes:

[0038] When the component type label is a navigation map component and the vehicle longitudinal acceleration integral value exceeds the preset driving start acceleration threshold, the binary bit of the corresponding map incremental data download interface in the basic permission mask row vector is changed from allowed to denied, and the binary bit of the corresponding real-time traffic event broadcast interface is changed from allowed to pending explicit user confirmation.

[0039] When the component type label is an audio-visual entertainment component and the vehicle longitudinal acceleration integral value exceeds the preset driving start acceleration threshold, the binary bit of the corresponding video frame decoding output interface in the basic permission mask row vector is changed from allowed to denied, and the binary bit of the corresponding audio stream decoding output interface is changed from unlimited to output power limited mode.

[0040] Specifically, the specific steps of S4 include:

[0041] Based on the list of permission entries in the dynamic permission configuration policy, and based on the coroutine worker pool identifier of the isolated running instance, obtain the token bucket group base address in the vehicle interface gateway process and the mandatory access control tag library of the external data source.

[0042] Based on the maximum number of calls configured for each vehicle capability interface in the permission entry list, a cyclic time slot token matrix is ​​initialized for the coroutine worker pool identifier at the token bucket group base address; each row of the cyclic time slot token matrix corresponds to a vehicle capability interface, each column corresponds to a time slot, and the initial number of tokens in each time slot is calculated and replenished according to the ratio of the maximum number of calls to the total number of time slots.

[0043] Specifically, the steps of S4 further include:

[0044] When the isolated running instance initiates a call request to the vehicle capability interface through a coroutine in the coroutine worker pool, the target interface identifier and the current system clock tick count in the call request are extracted. The mapping column index of the current system clock tick count in the cyclic time slot token matrix is ​​calculated. The remaining number of tokens in the time slot corresponding to the target interface identifier in the cyclic time slot token matrix at the mapping column index is checked. If the remaining number of tokens is greater than zero, one token is consumed and the call request is forwarded to the vehicle capability interface. If the remaining number of tokens is equal to zero, the call request is marked as a rate-limited pass request and temporarily stored in the delayed processing queue.

[0045] The system queries the mandatory access control tag library to obtain the sensitivity level tag of the external data source and the authorization level tag of the isolated running instance. When the level value of the authorization level tag is greater than or equal to the level value of the sensitivity level tag, the isolated running instance is allowed to read the data from the corresponding external data source and the read data is recorded as a hierarchical access data stream; otherwise, reading is refused.

[0046] All call requests marked as rate-limited requests are retrieved from the delayed processing queue, merged with the hierarchical access data stream, and the merged data is arranged in timestamp order as a record of the running behavior of the permission-controlled instance and output.

[0047] Specifically, the access-controlled instance is monitored in real time to obtain real-time operational status data, and the anomaly level is determined based on the real-time operational status data, including:

[0048] Based on the runtime behavior records of the permission-controlled instance, and based on the unique namespace identifier of the independent running container corresponding to the permission-controlled instance, the hardware event counter of the vehicle operating system performance monitoring unit and the callback functions registered on the kernel exception notification chain are obtained.

[0049] The hardware event counter is configured to track the number of instruction execution cycles, the number of last-level cache access misses, and the number of address translation backstop misses. Values ​​are read from the register of the hardware event counter at a preset sampling period to obtain the microarchitecture state vector of the permission-controlled instance.

[0050] The callback function registered on the kernel exception notification chain captures the memory access out-of-bounds signal or illegal opcode signal generated by the permission-controlled instance. When the memory access out-of-bounds signal or the illegal opcode signal is captured, the crash event flag is set to true.

[0051] When the number of instruction execution cycles exceeds the preset lower limit threshold for instruction throughput, a computing resource anomaly flag is generated and set to true.

[0052] When the number of missing accesses to the last-level cache exceeds the preset cache jitter detection threshold, a memory access mode exception flag is generated and set to true.

[0053] When the number of address translation back buffer misses exceeds the preset address space fragmentation threshold, an address translation exception flag is generated and set to true.

[0054] Specifically, the method of real-time monitoring of the access-controlled instance, obtaining real-time operational status data, and determining the anomaly level based on the real-time operational status data also includes:

[0055] The crash event flag, computing resource anomaly flag, memory access mode anomaly flag, and address translation anomaly flag are input into the Naive Bayes classifier. The Naive Bayes classifier contains a category node representing the overall anomaly level and four feature nodes corresponding to the four flags. The conditional probability distribution of each feature node under a given category node value is obtained through pre-statistics. The actual values ​​of the four observed flags are substituted into the Naive Bayes classifier to calculate the posterior probability of each category. The anomaly level category with the highest posterior probability is output as the final anomaly level.

[0056] A multi-layered sandbox-based full lifecycle protection system for vehicle components includes:

[0057] The component disinfection module is used to obtain the generated code, component type label, target running scenario identifier and preset security level parameters of the vehicle components to be deployed. Based on the taint propagation depth threshold and component type label, it marks the taint source node and taint sink node through symbolic execution, traverses the taint propagation path and generates an labeled directed graph, locates the unsafe memory copy basic block and replaces it with a security function with boundary checks, and outputs compliant component code.

[0058] The isolation environment building module is used to allocate independent running containers for different types of components, create isolation layers, lock-free message queue coroutine worker pools and container isolation namespaces, and output isolated running instances;

[0059] The permission configuration module is used to generate dynamic permission configuration policies through dynamic risk weighting and correction, implement hierarchical access to external data sources through a mandatory access control tag library, and output permission-controlled instances.

[0060] The anomaly level determination module, based on the running behavior records of the permission-controlled instance and the namespace identifier of the independent running container, configures the hardware event counter to obtain the microarchitecture state vector, generates multiple anomaly labels and inputs them into the Naive Bayes classifier, and calculates the posterior probability to determine the anomaly level.

[0061] The self-healing isolation module is used to perform self-healing operations based on the anomaly level and the microarchitecture state vector, and output the repaired component instance.

[0062] Compared with the prior art, the beneficial effects of the present invention are:

[0063] 1. This invention proposes a multi-layered sandbox-based method for full lifecycle protection of automotive components. By analyzing taint propagation, it locates and repairs insecure code such as memory copying, blocking vulnerability risks caused by external inputs from the source. At the same time, it constructs a multi-layered isolation environment for views, coroutines, and web page rendering to achieve deep isolation during component runtime, effectively preventing cross-component unauthorized access and attack propagation, and improving the basic operational security of automotive components.

[0064] 2. This invention proposes a multi-layered sandbox-based full lifecycle protection method for vehicle components. It combines dynamic generation of permission strategies based on vehicle driving status, adopts interface rate limiting and hierarchical access control of data sources, adapts to the security requirements of different scenarios such as stationary and moving vehicles, and avoids the limitations of static permission control. Furthermore, it accurately determines the anomaly level through hardware microarchitecture monitoring and a Naive Bayes classifier, and performs targeted self-healing operations such as heat migration and forced recycling to quickly handle various operational anomalies and enhance the dynamic risk resistance and fault recovery capabilities of the vehicle system.

[0065] 3. This invention proposes a multi-layered sandbox-based full lifecycle protection method for vehicle components. It adopts a cyclical iteration and progressive sandbox hardening mechanism, gradually strengthening access control and introducing nested virtualization isolation as the component runs, thereby achieving continuous upgrades in protection capabilities. It covers the entire lifecycle of vehicle components from deployment, operation, monitoring to destruction, solving the problems of one-sided protection, rigid strategies, and lack of iterative hardening capabilities in existing technologies, and comprehensively ensuring the long-term stable and safe operation of vehicle components. Attached Figure Description

[0066] Figure 1 This is a schematic diagram of the full life-cycle protection method for vehicle-mounted components based on a multi-layer sandbox according to the present invention;

[0067] Figure 2 This is a flowchart illustrating the principle of the multi-layer sandbox-based full lifecycle protection method for vehicle components according to the present invention.

[0068] Figure 3 This is a diagram of the full lifecycle protection system architecture for vehicle components based on a multi-layer sandbox, as described in this invention. Detailed Implementation

[0069] Example 1:

[0070] Please see Figure 1 and Figure 2 The present invention provides an embodiment of a method for full lifecycle protection of vehicle components based on a multi-layer sandbox, comprising the following steps:

[0071] S1: Obtain the generated code, component type label, target running scenario identifier, and preset security level parameters of the vehicle component to be deployed, and perform vehicle safety disinfection on the generated code according to the security level parameters and component type label, and output compliant component code;

[0072] Furthermore, before deploying components, the vehicle system first retrieves the original generated code of the components to be deployed from the vehicle component development platform. This generated code includes the component's functional implementation logic, interface call instructions, and data interaction rules. Simultaneously, it reads the component type tags preset during the component development phase. These tags clearly indicate whether the component belongs to a communication, display, real-time data stream processing, or non-real-time log recording category. Subsequently, it obtains the vehicle's current target operating scenario identifier to distinguish different operating scenarios such as stationary power supply, road driving, low-speed congestion, or high-speed cruising. Finally, it retrieves the preset security level parameters from the vehicle security protection system. These security level parameters are divided into three levels—low, medium, and high—based on the component's functional importance, data sensitivity, and operating permission level. Different levels correspond to different taint propagation depth thresholds and security verification standards.

[0073] The process of performing vehicle safety disinfection on the generated code based on safety level parameters and component type tags, and outputting compliant component code, includes:

[0074] S1.1: Based on the taint propagation depth threshold included in the security level parameters, and according to the communication or display component indicated by the component type label, obtain the intermediate representation directed graph of the generated code; the nodes of the intermediate representation directed graph are basic blocks, and the edges are the control transfer relationships between basic blocks;

[0075] Furthermore, the specific steps of S1.1 include:

[0076] (1) Perform lexical analysis and syntax analysis on the generated code of the vehicle-mounted components to be deployed. The lexical analysis converts the character sequence of the generated code into a token sequence, and the syntax analysis constructs the token sequence into an abstract syntax tree according to the syntax rules of the programming language. Each node of the abstract syntax tree represents a syntax structure in the code, including function definition nodes, variable declaration nodes, assignment statement nodes, conditional branch nodes and function call nodes.

[0077] Furthermore, the official syntax specification file of the programming language used by the vehicle component generation code is read, and all reserved word strings enclosed in quotation marks are extracted from the specification file. Each reserved word string is stored as an element in the keyword character combination list. All single-character and multi-character symbols defined as operators are extracted from the specification file, and each operator symbol is stored as an element in the operator character set. All single-character symbols defined as delimiters are extracted from the specification file, and each delimiter symbol is stored as an element in the delimiter character set.

[0078] Furthermore, the lexical analysis process reads each character in the generated code sequentially according to the predefined list of keyword character combinations, operator character sets, and delimiter character sets in the programming language specification. Whenever the read character sequence completely matches any item in the keyword character combination list, a token is output. This token consists of the matched keyword type identifier and the starting position number of the keyword in the generated code. When the read character belongs to the operator character set or the delimiter character set, a token is output. This token consists of the type identifier of the operator or delimiter and the position number of the character. When the read characters are letters and the consecutively read letters or numbers form a continuous sequence, the entire continuous sequence is treated as an identifier, and a token is output. This token consists of the identifier type identifier and the string value of the identifier. When the read characters are numbers and the consecutively read numbers form a continuous sequence, all tokens are arranged according to their order of appearance in the generated code to obtain a token sequence.

[0079] Furthermore, the parsing process operates according to the context-free grammar rule set of the programming language, where each rule contains a non-terminal symbol and a production body consisting of multiple terminal or non-terminal symbols. The parsing process begins with the initial nonterminal symbol. A stack structure is used to store the currently deduced grammatical components. Each symbol in the symbol sequence is read sequentially, and its type is matched against the expected terminal symbol type at the top of the stack. When a match is successful, the symbol is consumed from the symbol sequence, and the terminal symbol at the top of the stack is popped. When the top of the stack is a nonterminal symbol, the rule with the nonterminal symbol as its left-hand side is searched from the context-free grammar rule set, and the right-hand side of the rule is pushed onto the stack in reverse order. When a continuous sequence of symbols is reduced to a grammatical unit according to the rule, an abstract syntax tree node is created. The type of this node is identified by the grammatical structure type corresponding to the grammatical unit, and the list of child nodes of this node contains the nodes corresponding to the reduced symbols or sub-grammatical units. The above process is repeated until all symbols are consumed and only the node corresponding to the initial nonterminal symbol remains in the stack. The construction of the abstract syntax tree is then complete. The root node of the abstract syntax tree is the node corresponding to the initial nonterminal symbol, and the remaining nodes include function definition nodes, variable declaration nodes, assignment statement nodes, conditional branch nodes, and function call nodes.

[0080] (2) Traverse from the root node of the abstract syntax tree, identifying boundary nodes used to divide basic blocks during the traversal. Boundary nodes include conditional jump statement nodes, unconditional jump statement nodes, and function call statement nodes. Whenever a boundary node is encountered, it is used as the termination node of the current basic block. All consecutively executed statement nodes from the previous boundary node to the current boundary node are grouped into the same basic block. The statement nodes within this basic block are arranged in the order they appear in the abstract syntax tree. The starting node of the basic block is the first statement node after the previous boundary node. When the current boundary node is a... When a conditional jump statement node is encountered, the two statement nodes pointed to by the two branch targets of that conditional jump statement node are used as the starting nodes of two new basic blocks. When the current boundary node is an unconditional jump statement node, the statement node pointed to by the jump target of that unconditional jump statement node is used as the starting node of a new basic block. When the current boundary node is a function call statement node, the entry statement node of the called function is used as the starting node of a new basic block. When there are no more untraversed nodes in the abstract syntax tree, all continuously executed statement nodes from the last boundary node to the end node of the abstract syntax tree are included in the last basic block.

[0081] (3) For each basic block of the output, extract the jump target information in the termination node of the basic block and construct directed edges between basic blocks, including: when the termination node is a conditional jump statement node, draw two directed edges from the basic block where the termination node is located. The first directed edge points to the target basic block pointed to by the true branch target in the conditional jump statement node, and the second directed edge points to the target basic block pointed to by the false branch target in the conditional jump statement node; when the termination node is an unconditional jump statement node, draw a directed edge from the basic block where the termination node is located. The directed edge points to the target basic block pointed to by the jump target in the unconditional jump statement node; when the termination node is a function call statement node, draw a directed edge from the basic block where the termination node is located. The directed edge points to the entry basic block of the called function, and at the same time, establish a directed edge between the basic block where the return statement node of the called function is located and the successor basic block of the function call statement node; when the termination node is a return statement node, no directed edges are drawn from the basic block where the termination node is located.

[0082] (4) Take all the output basic blocks as a set of nodes and all the directed edges as a set of edges, and combine them into an intermediate representation directed graph. The intermediate representation directed graph contains a unique entry basic block node and at least one exit basic block node, as well as all directed paths from the entry basic block node to each exit basic block node. Each directed path consists of multiple consecutively connected directed edges. The entry basic block node is the basic block where the first executable statement corresponding to the root node of the abstract syntax tree is located, and the exit basic block node is the basic block with the return statement node as the terminating node or the basic block without any outgoing edges.

[0083] Furthermore, in the process of constructing the aforementioned intermediate directed graph, the threshold value for taint propagation depth is pre-set to 5. This threshold value represents the upper limit of the number of directed edges contained in the directed path from the taint source node to the taint sink node. The communication components indicated by the component type label include the Controller Area Network (CAN) bus communication component and the Ethernet communication component. The display components indicated by the component type label include the instrument panel display component and the central control screen display component. When the component type label indicates a communication component, the external network data receiving function node is tracked as the taint source node during the taint analysis process. When the component type label indicates a display component, the user input processing function node is tracked as the taint source node during the taint analysis process.

[0084] S1.2: Using symbolic execution, the external network data receiving function node in the generated code is marked as a taint source node, and the vehicle control command generating function node is marked as a taint sink node. Following the reachable path in the directed graph represented by the middle, the process traverses from the taint source node towards the taint sink node. For each edge traversed, the number of edges traversed on the current path is recorded as the current taint propagation depth. The correspondence between the current taint propagation depth and each node on the current path is stored as a taint-marked tuple. All taint-marked tuples of visited nodes together constitute a taint-marked set. Each taint-marked tuple contains a node identifier and the taint propagation depth value of that node.

[0085] Furthermore, the specific steps in S1.2 include:

[0086] (1) Traverse all function call nodes in the middle of the directed graph and perform a string-complete match between the called function name of each function call node and the pre-established list of external network data receiving function names. The list of external network data receiving function names includes the following four function names: socket receiving function, user datagram protocol data packet receiving function, transmission control protocol stream reading function, and controller area network bus frame receiving function. When the called function name is completely consistent with any function name in the list of external network data receiving function names, mark the function call node as a taint source node and write a taint source identifier in the attribute field of the node. The taint source identifier takes the value 1, indicating that the node is the starting point of taint propagation.

[0087] Furthermore, the process of constructing the list of external network data receiving function names includes: reading the interface definition file of the vehicle communication middleware, which declares the function prototypes of all external network data receiving interfaces according to the interface description language specification; searching for receiving semantic keywords in the function prototype declarations from the interface definition file, which include receiving, reading, polling, and data arrival; when a function prototype declaration containing receiving semantic keywords is found, extracting the function name from the function prototype declaration and storing the function name as an element in the list of external network data receiving function names; repeating the above search and extraction process until the interface definition file is completely scanned, and outputting the list of external network data receiving function names.

[0088] (2) Traverse all function call nodes in the middle of the directed graph, and perform a string-complete match between the called function name of each function call node and the pre-established list of vehicle control command generation function names. The list of vehicle control command generation function names includes the following three function names: brake pedal opening setting function, steering wheel angle setting function, and drive torque request function. When the called function name is completely consistent with any function name in the list of vehicle control command generation function names, mark the function call node as a taint sink node, and write a taint sink identifier in the attribute field of the taint sink node. The taint sink identifier takes the value 2, indicating that the node is the termination point of taint propagation.

[0089] Furthermore, the process of constructing the vehicle control command generation function name list includes: reading the application programming interface specification file of the vehicle controller, which declares the generation function prototypes of all vehicle motion control commands according to the interface description language specification; searching for control command semantic keywords in the function prototype declarations from the application programming interface specification file, including set, write, request, and enable; when a function prototype declaration containing control command semantic keywords is found, further checking the return value type of the function prototype declaration; if the return value type is a status code type indicating success or failure of the operation, extracting the function name from the function prototype declaration; storing the extracted brake pedal opening setting function name, steering wheel angle setting function name, and drive torque request function name as three elements into the vehicle control command generation function name list; repeating the above search, check, and extraction process until the application programming interface specification file is completely scanned, and outputting the vehicle control command generation function name list.

[0090] (3) Create a first-in-first-out work queue. Each element in the work queue is a node identifier to be visited and its cumulative propagation depth value when it arrives at the node. Push the node identifiers of all marked taint source nodes and the initial cumulative propagation depth value 0 into the work queue as the first batch of elements. At the same time, create an visited node record table. The visited node record table is used to store the node identifiers that have been processed to prevent repeated traversal. The visited node record table is initially empty.

[0091] (4) When the work queue is not empty, take an element from the head of the work queue. The element contains the current node identifier and the current cumulative propagation depth value. Check whether the current node identifier already exists in the visited node record table. If it already exists, skip the element and do not process it. Continue to process the next element in the work queue. If it does not exist, store the current node identifier and its corresponding current cumulative propagation depth value as a taint tag tuple in the taint tag set. The first component of the taint tag tuple is the node identifier, and the second component is the taint propagation depth value of the node.

[0092] (5) After storing the taint tag tuple into the taint tag set, check whether the node attribute field corresponding to the current node identifier contains the taint sink identifier. If it contains the taint sink identifier, it means that a taint propagation path from the taint source node to the current node has ended, and the successor node of the node will no longer be added to the work queue.

[0093] (6) If there is no taint sink identifier, then all directed edges starting from the current node are obtained from the middle of the directed graph. Each directed edge points to a successor node. For each directed edge, the new cumulative propagation depth value reaching the successor node is calculated. The new cumulative propagation depth value is calculated by adding 1 to the current cumulative propagation depth value, and pushing the node identifier of each successor node and the calculated new cumulative propagation depth value into the work queue from the tail of the work queue.

[0094] (7) Repeat (4) to (6) until the work queue becomes empty. At this point, all nodes reachable from the taint source node have been processed.

[0095] (8) Output a set of taint tags, which contains multiple taint tag tuples. Each taint tag tuple records the identifier of a node and the number of shortest directed edges that can be traversed from any taint source node to that node. The number of shortest directed edges is equal to the taint propagation depth of that node.

[0096] S1.3: Continue traversing along the reachable path until the taint sink node is reached. Each time a new node is reached, update the taint propagation depth value in the taint label tuple of that node, and output a labeled directed graph carrying the taint propagation path and the taint propagation depth value corresponding to each node.

[0097] Furthermore, the specific steps in S1.3 include:

[0098] (1) Create a new output directed graph. The node set and edge set of the output directed graph are exactly the same as those of the original intermediate representation directed graph. Traverse each node in the original intermediate representation directed graph and obtain the node identifier of the node. Use the node identifier as the key to search for the corresponding taint tag tuple in the taint tag set. If the search is successful, read the taint propagation depth value from the taint tag tuple and write the value into the taint depth label field of the corresponding node in the output directed graph. If the search fails, it means that the node is unreachable from any taint source node. Write the value -1 into the taint depth label field of the corresponding node in the output directed graph. The value -1 indicates that the node has no taint propagation depth value, and the labeled directed graph is obtained.

[0099] (2) The generated labeled directed graph is associated with each taint propagation path recorded. Each taint propagation path is represented by a sequence of consecutive node identifiers from the taint source node to the taint sink node. The directed edge between each pair of adjacent node identifiers in the consecutive node identifier sequence is marked as a taint propagation edge. All taint propagation edges are traversed, and a taint propagation edge identifier is written into the corresponding directed edge attribute field in the labeled directed graph. The value of the taint propagation edge identifier is 1, indicating that the directed edge is located on at least one taint propagation path.

[0100] (3) Output the labeled directed graph after processing. Each node in the labeled directed graph contains a taint depth label field. Each node attribute field contains a taint source identifier or a taint sink identifier or neither. Each directed edge contains a taint propagation edge identifier field.

[0101] S1.4: When there is a path from any taint source node to any taint sink node in the labeled directed graph, and the taint propagation depth value in the taint label tuple at the end of the path exceeds the taint propagation depth threshold, call the safety sterilizer to locate the memory copy basic block on the taint propagation path that has not performed input length verification.

[0102] Furthermore, the specific steps in S1.4 include:

[0103] (1) Starting from the entry node of the labeled directed graph, perform a depth-first search along the direction of the directed edges. During the depth-first search, when a node is encountered, check whether the attribute field of the node contains a taint source identifier. When a node containing a taint source identifier is encountered, record the node as the starting node of the current path and start recording the node sequence on the path. Continue to traverse along the directed edges. When a node is passed, append the node to the end of the current node sequence. When a node containing a taint sink identifier is encountered, record the node as the ending node of the current path and save the current node sequence as a complete taint propagation path. Continue until all paths from the taint source node to the taint sink node in the labeled directed graph have been found.

[0104] (2) Read the endpoint node of one of the paths from the labeled directed graph, access the taint depth label field of the endpoint node, obtain the value stored in the field, and record the value as the endpoint depth value of the path.

[0105] (3) When the depth value of the path endpoint is less than or equal to the stain propagation depth threshold of 5, the stain propagation path is determined to be a safe path and no disinfection is required. The path is skipped and the next path is checked. When the depth value of the path endpoint is greater than 5, the stain propagation path is determined to be a risk path.

[0106] (4) For a taint propagation path that is determined to be a risk path, the safety sterilizer is invoked to perform a positioning operation. The safety sterilizer first obtains the complete node sequence on the risk path. The node sequence is arranged in order from the taint source node to the taint sink node and includes every intermediate node on the path.

[0107] (5) Traverse the node sequence on the risk path. For each node in the node sequence, obtain the intermediate representation code of the basic block corresponding to the node, scan the statement sequence in the intermediate representation code, and look for the characteristic pattern of memory copy operation during the scan. The characteristic pattern includes the following two types: the first type is that the name of the called function in the function call statement is the name of the memory copy function, which includes string copy function and memory region copy function; the second type is that the loop structure contains an assignment operation sequence that reads bytes from the source address and writes them to the destination address.

[0108] (6) When a memory copy operation is located in the basic block corresponding to any node, check whether there is an input length verification statement before the memory copy operation. The characteristic pattern of the input length verification statement is: the conditional expression of the conditional statement contains an operation to calculate the length of the copy source data, and the memory copy operation is performed in the true branch of the conditional statement, and the operation of skipping memory copy or returning an error is performed in the false branch. The specific checking method is: scan upwards line by line from the position of the memory copy operation statement to find the nearest basic block containing the conditional statement. If the conditional expression of the found conditional statement calculates the data length and compares it with the buffer size variable, and the memory copy operation is located in the true branch of the conditional statement, then it is determined that the memory copy operation has performed input length verification. If no conditional statement that meets the conditions is found in the above scanning process, or the memory copy operation is not in the true branch of the conditional statement, then it is determined that the memory copy operation has not performed input length verification.

[0109] (7) When it is determined that any memory copy operation has not performed input length verification, the node identifier where the memory copy operation is located and the statement position offset of the memory copy operation in the basic block are recorded. The statement position offset represents the number of statements between the memory copy operation statement and the start position of the basic block.

[0110] (8) Output the location information of all memory copy basic blocks that have not performed input length verification as the location result. The location result contains a list, and each entry in the list contains three fields: the first field is the path identifier of the risk path, the second field is the node identifier, and the third field is the statement position offset of the memory copy operation in the basic block.

[0111] S1.5: Based on the component type label, find a boundary-checked safe function from the preset safe function replacement mapping table that is functionally equivalent to the unsafe function in the memory copy basic block, and replace the unsafe function call in the memory copy basic block with the boundary-checked safe function to generate compliant component code.

[0112] Furthermore, the specific steps in S1.5 include:

[0113] (1) Read the location information of each memory copy basic block that has not performed input length verification from the location results of S1.4. Each location information includes the path identifier of the risk path, the node identifier, and the statement position offset of the unsafe function call in the basic block. Locate the target node in the labeled directed graph according to the node identifier, and then locate the specific statement in the basic block corresponding to the node according to the statement position offset. Extract the name of the unsafe function called and the actual parameter list of the function call from the statement. The unsafe function name includes the string copy function name and the memory region copy function name. The string copy function name is the string copy function. The memory region copy function name is the memory copy function. The actual parameter list includes the source address parameter, the destination address parameter, and the length parameter.

[0114] (2) Read the current value of the component type label. The current value of the component type label is either a communication component or a display component. The communication components include the controller local area network bus communication component and the Ethernet communication component. The display components include the instrument panel display component and the central control screen display component. Record the current value as the current component type label value.

[0115] (3) Load the preset security function replacement mapping table. The security function replacement mapping table is a key-value pair collection stored in the security configuration storage area of ​​the vehicle system and loaded in read-only mode. Each entry of the security function replacement mapping table contains four fields: the first field is the source function name field, the second field is the component type matching field, the third field is the target function name field, and the fourth field is the boundary check parameter position field.

[0116] Furthermore, during the construction of the safe function replacement mapping table, an offline training method is used to determine the specific values ​​of each field in the mapping table. This offline training method includes: collecting a list of standard unsafe functions used in vehicle software development; for each unsafe function, testing multiple safe function variants with boundary checks on the target vehicle platform; measuring the execution time cost of each safe function variant under real-time constraints, with the measurement unit being microseconds; setting an upper limit of 50 microseconds for execution time cost; selecting safe function variants with execution time costs not exceeding 50 microseconds and functionally equivalent as target functions; writing this correspondence into the safe function replacement mapping table; and determining the values ​​of the boundary check parameter position field in the safe function replacement mapping table through static code analysis, which extracts the target buffer size information from variable declarations.

[0117] (4) Use the extracted unsafe function name as the matching key of the source function name field and the read current component type label value as the matching key of the component type matching field. Perform an exact search in the safe function replacement mapping table. When there is an entry in the safe function replacement mapping table whose source function name field value is completely consistent with the unsafe function name and whose component type matching field value is completely consistent with the current component type label value, output the entry as the matching entry.

[0118] (5) Read the value of the target function name field from the output matching entries. This value is the function name of the boundary-checked safe function. The boundary-checked safe function includes a string copy function with length limit and a memory copy function with target buffer size parameter. The string copy function with length limit is named as a safe string copy function. Before copying, the safe string copy function compares the source string length with the target buffer size minus 1 to get the minimum value. The memory copy function with target buffer size parameter is named as a safe memory copy function. Before copying, the safe memory copy function compares the copy length with the target buffer size. At the same time, read the value of the boundary check parameter position field from the matching entries. This value indicates which parameter corresponds to the data length in the unsafe function call and which parameter corresponds to the target buffer size in the safe function call.

[0119] (6) Based on the read target function name and the extracted actual parameter list, construct a new function call statement. The construction rules are as follows: When the unsafe function name is a string copy function and the current component type label value is a communication component, use the safe string copy function as the target function name, use the source address parameter in the unsafe function call as the first actual parameter of the safe string copy function, use the destination address parameter in the unsafe function call as the second actual parameter of the safe string copy function, and use the predefined size value of the buffer pointed to by the destination address parameter as the third actual parameter of the safe string copy function. The predefined size value is obtained from the variable type declaration information. If the variable is of type character array, then the array length minus 1 is taken as the value of the third actual parameter; when the unsafe function name is a memory copy function and the current component type label is a display component, the safe memory copy function is taken as the target function name, the destination address parameter in the unsafe function call is taken as the first actual parameter of the safe memory copy function, the source address parameter in the unsafe function call is taken as the second actual parameter of the safe memory copy function, the length parameter in the unsafe function call is taken as the third actual parameter of the safe memory copy function, and the predefined size value of the buffer pointed to by the destination address parameter is taken as the fourth actual parameter of the safe memory copy function.

[0120] (7) Locate the specific statement position determined by the node identifier and statement position offset, delete the original unsafe function call statement at that position, insert the constructed safe function call statement at the same position, and keep the order and content of the remaining statements in the basic block unchanged;

[0121] (8) Repeat steps (1) to (7) until all memory copy basic blocks that have not undergone input length verification have been processed. Each time a memory copy basic block is processed, a local replacement operation is performed on the original generated code segment where the basic block is located. The scope of the local replacement operation is limited to the basic block.

[0122] (9) Collect all generated code snippets that have undergone replacement operations, merge them with other code snippets that have not undergone any replacement operations according to the original code organization structure, keep the original function boundaries, basic block boundaries and control flow relationships unchanged during the merging, and output the merged complete code as compliant component code.

[0123] S2: Allocate independent running containers for the compliant component code, build a multi-layered isolation environment, and output isolated running instances;

[0124] Assigning a separate running container to the compliant component code, including:

[0125] S2.1: Based on the resource requirement list of compliant component code, and according to the real-time data stream processing component or non-real-time log recording component indicated by the component type label, obtain a snapshot of the physical resource distribution of the vehicle heterogeneous computing platform; the physical resource distribution snapshot includes the current operating frequency status of each physical processor core in the vehicle heterogeneous computing platform and the number of free physical page frames on each memory access node;

[0126] It should be noted that during the compilation and packaging phase, the compliant component code generates a resource requirement description file, which is stored in key-value pair format; the component type label is assigned by the vehicle system manager and stored in the component metadata during component deployment; the vehicle heterogeneous computing platform includes high-performance computing cores and low-power computing cores.

[0127] Furthermore, the specific steps of S2.1 include:

[0128] (1) Read the resource requirement description file and extract the maximum allowed memory usage, the maximum allowed CPU utilization, the number of required physical processor cores, and the flag bit for whether exclusive processor cores are required. The flag bit is either true or false. Combine all the extracted field values ​​into a resource requirement structure.

[0129] (2) Read the string value of the component type tag from the component metadata, and match the string value with the predefined component type enumeration value. The predefined component type enumeration value includes real-time data stream processing components and non-real-time logging components. When the string value matches the real-time data stream processing component, mark the current component type as real-time type. When the string value matches the non-real-time logging component, mark the current component type as non-real-time type.

[0130] (3) By reading the processor device node file maintained by the operating system kernel, the total number of all physical processor cores in the system is obtained. This total number is recorded as the total number of physical cores. Each physical processor core is traversed to obtain the unique identifier number of each core. This number is an integer between zero and the total number of physical cores minus 1.

[0131] (4) Collect the current operating frequency status of each physical processor core, specifically: for each physical processor core, read its corresponding system power management interface file, which is located in the processor device directory of the system and the file name is current frequency; read an integer value from the system power management interface file, which represents the current operating frequency of the physical processor core, and divide the read frequency value by 1000; at the same time, read the highest operating frequency value and the lowest operating frequency value supported by the physical processor core, which are read from the highest frequency file and the lowest frequency file in the same directory respectively; and combine the unique identifier number, current operating frequency value, highest operating frequency value and lowest operating frequency value of each physical processor core into a processor core status record;

[0132] (5) Collect memory access node information of the vehicle-mounted heterogeneous computing platform. The vehicle-mounted heterogeneous computing platform adopts a non-unified memory access architecture, which divides physical memory into multiple memory access nodes. Each memory access node is physically adjacent to one or more physical processor cores. By reading the memory node device directory maintained by the operating system kernel, the total number of all memory access nodes in the system is obtained. This number is recorded as the total number of memory nodes. Each memory access node is traversed to obtain the unique identifier number of each node. This number is an integer between zero and the total number of memory nodes minus 1.

[0133] (6) For each memory access node, read its corresponding system memory information interface file. The system memory information interface file is located in the memory node device directory and the file name is memory information. Search for the line that starts with the string "free" in the system memory information interface file. The value in the line represents the number of free physical page frames on the memory access node. The size of a physical page frame is 4096 bytes. Record this value as the current number of free physical page frames. At the same time, read the total number of memory page frames on the memory access node. This value is extracted from the same file with the string "total number" as the key. Combine the unique identifier number of each memory access node, the current number of free physical page frames and the total number of memory page frames to form a memory node status record.

[0134] (7) For each physical processor core, read its corresponding memory node affinity interface file. The memory node affinity interface file is located in the processor device directory and the file name is memory node affinity mask. Read a bit mask value from the file. Each binary bit of the bit mask value corresponds to a memory access node. When the value of any binary bit is 1, it means that the physical processor core and the memory access node are physically adjacent and the access latency is the lowest. Store the correspondence between the unique identifier of each physical processor core and the number of its adjacent memory access node as an affinity entry. After traversing all physical processor cores and collecting all affinity entries, all affinity entries are summarized to form a complete mapping set. This mapping set is used to record the physical proximity correspondence between the processor core and the memory node and is defined as a physical distance relationship table.

[0135] (8) Combine the collected processor core status record list, memory node status record list and the constructed physical distance relationship table into a data structure, which is a snapshot of physical resource distribution;

[0136] (9) When the current component type is marked as real-time, select physical processor cores with a current operating frequency greater than or equal to 2000MHz from the processor core status array; when the current component type is marked as non-real-time, select physical processor cores with a current operating frequency less than or equal to 1200MHz from the processor core status array; finally output the filtered physical resource distribution snapshot.

[0137] S2.2: When the component type label indicates a real-time data stream processing component, allocate a dedicated physical computing core to the compliant component code, lock the set of continuous physical page frames on the local memory node corresponding to the dedicated physical computing core as a dedicated memory region, and set the interrupt response attribute of the dedicated physical computing core to only handle direct memory access requests from the dedicated memory region.

[0138] Furthermore, the specific steps of S2.2 include:

[0139] (1) Read the component type tag field from the component metadata and compare the string value of the component type tag field with the real-time data stream processing component type identifier; the content of the real-time data stream processing component type identifier is a single string composed of the lowercase English letters "real-time data stream processing component";

[0140] (2) When the comparison results are consistent, select all physical processor cores with a current operating frequency value greater than or equal to 2000MHz from the processor core status array of the physical resource distribution snapshot, select the physical processor core with the highest current operating frequency value from the selection results as the exclusive physical computing core, and record the unique identifier number of the core.

[0141] (3) Obtain the process identifier of the process where the current compliant component code is located, construct a 64-bit processor core mask, in which only the binary bit corresponding to the unique identifier number of the recorded exclusive physical computing core is set to the value 1, and the remaining bits are set to the value 0, and then lock the specified process on the exclusive physical computing core.

[0142] (4) From the affinity mapping table of the physical resource distribution snapshot, use the unique identifier of the recorded exclusive physical computing core as the key to search, obtain the list of memory access node numbers adjacent to it, and select the first memory access node number in the list of memory access node numbers as the unique identifier of the local memory node.

[0143] (5) From the memory node status array of the physical resource distribution snapshot, use the obtained local memory node number as the index to read the list of free physical page frame start addresses on the memory node. The size of each physical page frame is fixed at 4096 bytes.

[0144] (6) Read the maximum allowed memory usage value from the resource requirement structure, multiply the value by 1024 to convert it to bytes, divide it by 4096 and round up to get the number of consecutive physical page frames required to meet the resource requirements.

[0145] (7) Traverse the list of free physical page frame starting addresses, and find a sequence of physical page frames that are consecutive and have a number greater than or equal to the required number of consecutive physical page frames. The criterion for consecutive arrangement is: the starting physical address of the next physical page frame is equal to the starting physical address of the previous physical page frame plus 4096. After finding it, record the starting physical address of the consecutive sequence.

[0146] (8) Call the memory locking system call provided by the operating system kernel to lock the found physical page frame sequence as a dedicated memory region, prevent the dedicated memory region from being swapped to external storage devices, and record the starting physical address and byte length of the dedicated memory region;

[0147] (9) Read the register base address file in the system processor device directory, obtain the base address of the interrupt response attribute register. The base address of the interrupt response attribute register is offset by 16 bytes from the base address. Construct a configuration value. The configuration value sets bit 0 to the value 1 to allow external device interrupts, sets bits 1, 2 and 3 to the value 0 to disable other types of interrupts, and sets the specified bits from bits 4 to 31 to the value 1. The specified bits correspond to the memory address range where the starting physical address of the recorded physical page frame sequence is located, so that the processor core only allows direct memory access requests from the dedicated memory area to trigger the interrupt handler. Then write the configuration value into the interrupt response attribute register.

[0148] (10) Read the current affinity mask register of the processor core, confirm that the binary bit corresponding to the unique identifier of the exclusive physical computing core is 1 and the rest bits are 0. At the same time, read the interrupt response attribute register, confirm that the value of its direct memory access filter mask bit field is consistent with the written configuration value. After verification, record the unique identifier of the exclusive physical computing core, the starting physical address of the exclusive memory region and the byte length into the container configuration structure and output it.

[0149] S2.3: When the component type label indicates a non-real-time logging component, allocate a shared logical computing core and a virtual memory area of ​​standard page size to the compliant component code, and set the scheduling strategy of the shared logical computing core to a time-slice round-robin scheduling strategy.

[0150] Furthermore, the specific steps in S2.3 include:

[0151] (1) Read the component type tag field from the component metadata and compare the string value of the field with the standard type name of the non-real-time logging component written to the system configuration database by the vehicle operating system component manager when the component is registered. The standard type name is a fixed string, and its specific content is a single string composed of the lowercase English letters "non-real-time logging component".

[0152] (2) When the comparison results are consistent, select all physical processor cores with a current operating frequency value less than or equal to 1200MHz from the processor core status array of the physical resource distribution snapshot, sort the selected physical processor cores according to the current operating frequency value from smallest to largest, and record the sorted core unique identifier number list.

[0153] (3) Read the process scheduling statistics file maintained by the operating system kernel, extract the number of processes currently running on each physical processor core and the length of the ready queue from the process scheduling statistics file, combine the unique identifier of each physical processor core, the number of processes currently running and the length of the ready queue into a core load record, and all core load records constitute a core load record list.

[0154] (4) Traverse the core unique identifier list. For each physical processor core in the core unique identifier list, find the number of currently running processes and the length of the ready queue corresponding to the physical processor core in the core load record list. Add the two values ​​to get the comprehensive load value of the physical processor core. Select the physical processor core with the smallest comprehensive load value from the entire core unique identifier list as the target physical core to carry the logic computing core, and record the unique identifier of the target physical core.

[0155] (5) Call the processor core topology configuration interface provided by the operating system kernel. The function name of this interface is Create Shared Processor Core. This interface receives two parameters: the first parameter is the unique identifier of the target physical core output in (4), and the second parameter is the core type flag. The value of the core type flag is 0, which means that a shared type processor core is created. This core and other shared cores share the same physical processor core execution time. After executing this interface, the operating system kernel returns a unique identifier of the shared processor core. This number is an integer that starts from zero and increments, which is used to uniquely identify the newly created shared processor core.

[0156] (6) Call the address space management interface provided by the operating system kernel. The function name of the address space management interface is Create Anonymous Memory Map. The address space management interface receives three parameters: the first parameter is the desired virtual starting address, which takes the value 0, indicating that the operating system kernel will automatically select the starting address; the second parameter is the size of the virtual memory region, which is read from the resource requirement structure as the maximum allowed memory usage value, multiplied by 1024 to convert it into a byte value, and then rounded up according to the standard page size of 4096 bytes before being used as the value of the parameter; the third parameter is the memory access permission flag, which sets bit 0 to the value 1 to allow reading, bit 1 to the value 1 to allow writing, and bit 2 to the value 0 to disallow execution; after executing the interface, the operating system kernel allocates a continuous virtual address range from the process's virtual address space and returns the starting virtual address of the virtual address range;

[0157] (7) Call the physical page frame allocation policy interface provided by the operating system kernel. The function name of the physical page frame allocation policy interface is Delayed Page Allocation. The physical page frame allocation policy interface receives three parameters: the first parameter is the starting virtual address of the virtual memory region returned by (6), the second parameter is the size of the virtual memory region determined in (6), and the third parameter is the allocation policy flag. The value of the allocation policy flag is 1, which means that the on-demand page allocation policy is adopted. After executing the interface, the operating system kernel marks the virtual memory region as a delayed allocation state, that is, it does not allocate physical page frames immediately, but allocates physical page frames only when the virtual address in the region is accessed for the first time.

[0158] (8) Call the thread scheduling parameter configuration interface provided by the operating system kernel. The function name of the thread scheduling parameter configuration interface is Set scheduling policy. The thread scheduling parameter configuration interface receives three parameters: the first parameter is the unique identifier number of the shared processor core returned in (5), the second parameter is the scheduling policy identifier, the value of the scheduling policy identifier is 2, which indicates the time slice round-robin scheduling policy, and the third parameter is the pointer to the scheduling parameter structure. Construct a scheduling parameter structure, fill the time slice length value of 10ms into the first field of the structure, fill the priority value of 0 into the second field of the structure, the priority value of 0 indicates the lowest priority. After executing the interface, the scheduling policy of the shared processor core is set to the time slice round-robin scheduling policy.

[0159] S2.4: Write the allocated physical computing core number or logical computing core number and the starting address of the dedicated memory region or the base address of the virtual memory region into the container isolation namespace, and output the unique namespace identifier of the independently running container.

[0160] Furthermore, the specific steps in S2.4 include:

[0161] (1) Read the resource allocation type flag from the container configuration structure. The resource allocation type flag is stored at the zero-byte offset of the starting address of the structure, occupying 4 bytes. When the value of the flag is equal to 1, it indicates that a dedicated physical computing core and a dedicated memory area have been allocated for the real-time data stream processing component. At this time, the dedicated physical computing core number is read from the offset of 4 bytes in the container configuration structure, and the starting address of the dedicated memory area is read from the offset of 8 bytes. When the value of the flag is equal to 2, it indicates that a shared logical computing core and a virtual memory area have been allocated for the non-real-time log recording component. At this time, the shared logical computing core number is read from the offset of 4 bytes in the container configuration structure, and the base address of the virtual memory area is read from the offset of 8 bytes.

[0162] (2) Call the namespace creation interface provided by the operating system kernel. The function name of this interface is Create Container Namespace. This interface accepts a 32-bit unsigned integer as a parameter. The value is 16, which indicates that a container namespace type specifically for the isolation of vehicle component resources is being created. After executing this interface, the operating system kernel creates a namespace kernel object internally and returns a file descriptor associated with the object. The file descriptor is an integer greater than or equal to zero. The returned file descriptor is recorded as the namespace file descriptor.

[0163] (3) Construct a path string using the namespace file descriptor as an index: the namespace directory, container subdirectory, decimal string of namespace file descriptor, and runtime parameters are connected in sequence with the path concatenation separator " / ". Use the constructed string as the control interface file path, specifically described as [namespace directory / container subdirectory / decimal string of namespace file descriptor / runtime parameters];

[0164] (4) Call the standard file open function with the constructed control interface file path as the first parameter and the read / write mode flag as the second parameter. The read / write mode flag is set to 2, which means that the file is opened in read and write mode. After successful execution, the function returns a new file descriptor, which is called the control interface file descriptor. If the opening fails, an error code is returned.

[0165] (5) Determine the core number value to be written based on the read resource allocation type flag. When the flag is 1, the value to be written is the exclusive physical computing core number; when the flag is 2, the value to be written is the shared logical computing core number. Convert the core number value to a decimal string and call the standard file writing function to write the following content to the opened control interface file: first write the string core number, then write the equal sign character, then write the decimal string of the core number, and finally write the newline character. After writing, the operating system kernel binds the core number to the processor set in the namespace.

[0166] (6) Determine the memory address value to be written based on the read resource allocation type flag. When the flag is 1, the value to be written is the starting address of the dedicated memory region, which is a 64-bit physical address. When the flag is 2, the value to be written is the base address of the virtual memory region, which is a 64-bit virtual address. Convert the memory address value to a hexadecimal string, adding the prefix string 0X to the beginning of the string during the conversion; call the standard file write function to write the following content to the control interface file: first write the string memory base address, then write the equals sign character, then write the hexadecimal format memory address string, and finally write the newline character; after writing, the operating system kernel records the memory address in the memory isolation mapping table of the namespace;

[0167] (7) Read the memory region size value from the offset of 16 bytes in the container configuration structure. When the resource allocation type flag is 1, the value is equal to the required page frame number multiplied by 4096. When the resource allocation type flag is 2, the value is equal to the maximum allowed memory usage value rounded up to 4096. Convert the memory region size value to a decimal string. Call the standard file write function to write the following content to the control interface file: first write the string memory size, then write the equal sign character, then write the decimal string of the memory region size, and finally write the newline character. After writing, the operating system kernel records the memory region size in the resource limit field of the namespace.

[0168] (8) Call the standard file closing function, pass the returned control interface file descriptor as a parameter, and after the closing operation is performed, the operating system kernel refreshes all data to be written to the namespace kernel object and releases the system resources occupied by the control interface file descriptor;

[0169] (9) Using the returned namespace file descriptor as an index, call the kernel object location interface, which returns the virtual address of the namespace kernel object in the kernel address space. This address is a 64-bit value, denoted as the kernel object address.

[0170] (10) Initialize the hash value to 5381. Process the obtained kernel object address in order from low byte to high byte. Perform an XOR operation on each byte with the current hash value. Then multiply the XOR result by 167. After processing all 8 bytes, read the creation timestamp of the namespace kernel object from the system clock. Perform a bitwise XOR operation on the creation timestamp and the current hash value to obtain the original hash value.

[0171] (11) Convert the original hash value into a string according to hexadecimal encoding, add the type prefix string "container-namespace" to the front of the converted hexadecimal string, and then concatenate the type prefix string with the hexadecimal string using the hyphen character "-". After concatenation, a complete unique namespace identifier string is obtained. Store the unique namespace identifier string in the identifier field of the namespace kernel object.

[0172] (12) Return the generated unique namespace identifier string as the function return value to the caller. At the same time, open the container deployment log file in the system log directory, first write the current timestamp, then write the horizontal tab character "\t" as the field separator, then write the unique namespace identifier string, write the \t separator again, then write the component type label string, and add a newline character "\n" at the end, and finally close the log file.

[0173] The construction of a multi-layered isolation environment and the output of isolated running instances include:

[0174] S2.5: Based on the unique namespace identifier of the independently running container, and according to the graphical interface layout file carried in the compliant component code, obtain the layer stack management interface of the vehicle graphics synthesis server.

[0175] Furthermore, the specific steps of S2.5 include:

[0176] (1) Read the unique namespace identifier corresponding to the independent running container. The unique namespace identifier is a globally unique identity credential assigned by the vehicle system to each independent running container. It is extracted directly from the container resource configuration information.

[0177] (2) Read the graphical interface layout file carried in the compliant component code. The graphical interface layout file is generated during the component development stage and contains configuration information such as the size, position, hierarchy, and display mode of the component's graphical interface. It is located and read directly from the resource directory of the compliant component code.

[0178] (3) Start the interface request initialization process of the vehicle graphics synthesis server. During initialization, the interface request timeout parameter needs to be configured. In this embodiment, it is set to 3000ms to limit the maximum waiting time of the interface request and avoid blocking the vehicle system for a long time during the request process.

[0179] (4) Construct an identity verification data packet for the interface request. The identity verification data packet contains the unique namespace identifier of the independent running container and the basic verification information of the graphical interface layout file.

[0180] (5) The completed identity verification data packet is sent to the vehicle-mounted graphics synthesis server. After receiving the data packet, the server first extracts the unique namespace identifier of the independent running container and performs a legality verification on the unique namespace identifier. The verification is completed by comparing the list of legal container identifiers stored in the system to confirm that the identifier is real, valid and has not been tampered with.

[0181] (6) After the identity verification is passed, the vehicle-mounted graphics synthesis server further parses the basic verification information of the graphical interface layout file in the data packet, checks the file format, configuration item integrity and data legality, and confirms that the graphical interface layout file conforms to the vehicle-mounted graphics display specification.

[0182] (7) After completing the dual verification, the vehicle-mounted graphics synthesis server retrieves the internal interface resource pool and locates the layer stack management interface that matches the current compliant component's graphical interface requirements based on the interface size parameters in the graphical interface layout file, ensuring that the interface capabilities are fully adapted to the component requirements.

[0183] (8) After the retrieval is completed, the vehicle-mounted graphics synthesis server will organize the access handles, call permission information and interface function descriptions of the successfully matched layer stack management interfaces to form complete interface return data;

[0184] (9) The vehicle system receives the interface return data returned by the vehicle graphics compositing server, extracts the core layer stack management interface information from it, completes the interface acquisition operation, and finally obtains the vehicle graphics compositing server layer stack management interface that can be used for layer creation.

[0185] S2.6: Call the private layer creation function in the layer stack management interface to create an isolated layer bound to an independent frame buffer for the independent running container, and set the visibility control bit of the isolated layer to allow the image data in the independent frame buffer to be passed to the physical display controller only when the independent running container is in the foreground active state;

[0186] Furthermore, the specific steps in S2.6 include:

[0187] (1) Obtain the layer stack management interface of the vehicle-mounted graphics compositing server;

[0188] (2) Locate the private layer creation function encapsulated inside the layer stack management interface. The private layer creation function is a function implementation function exclusive to the layer stack management interface. The location process directly matches the function identification features preset inside the interface.

[0189] (3) Configure basic running parameters for the private layer creation function. Among them, the container identity binding parameter is directly associated with the unique namespace identifier of the previously determined independent running container, and the frame buffer binding mode parameter is set to independent binding mode according to the vehicle graphics isolation display standard to ensure that the currently created layer only uses its own storage area and does not generate resource sharing.

[0190] (4) After the private layer creation function call takes effect, the vehicle graphics synthesis server starts the creation of the isolated layer. First, it allocates a dedicated independent frame buffer to the independent running container. The resolution parameter of the independent frame buffer is set to 1920×1080 pixels according to the standard of the vehicle central control display device, and the buffer data bit width parameter is set to 32 bits to ensure the storage accuracy and display effect of the image data. After the allocation is completed, the independent frame buffer is forcibly bound to the newly created layer to form an isolated layer bound to the independent frame buffer.

[0191] (5) After the isolation layer is created, enter the visibility control bit configuration. The visibility control bit is the core identifier for controlling the output permission of the layer image data. When configuring, the trigger condition parameter of the visibility control bit is fixed to the foreground activation matching condition. This condition limits the control bit to the effective state only when the independent running container is in the foreground active state.

[0192] (6) Establish a real-time linkage mechanism between the visibility control bit and the operating status of the independent operating container. The linkage detection cycle parameter is fixed at 10ms according to the vehicle real-time display standard to ensure that the control bit can respond in time when the container status changes. After the linkage mechanism takes effect, the visibility control bit will continuously monitor the operating status of the independent operating container.

[0193] (7) When the independent running container is detected to be in the foreground active state, the visibility control bit automatically switches to the active state, allowing the image data stored in the independent frame buffer to be transmitted to the physical display controller. When the independent running container is detected to be not in the foreground active state, the visibility control bit automatically remains in the inactive state, blocking the transmission path of the image data in the independent frame buffer to the physical display controller.

[0194] (8) After completing all configuration and binding operations, the vehicle graphics synthesis server returns the information of successfully created isolation layer. The isolation layer has been bound to the independent frame buffer of the independent running container and the condition configuration of the visibility control bit has been completed. Finally, all operations are completed to create an isolation layer with display isolation and status linkage capabilities for the independent running container.

[0195] S2.7: Obtain the isolation work pool application interface in the vehicle operating system coroutine scheduler, apply for a coroutine work pool identifier carrying a lock-free message queue for the independent running container, and set the transmission type of the lock-free message queue to only allow the transmission of data payloads with value semantics, and prohibit the transmission of reference type data pointing to the internal control structure of other coroutine work pools;

[0196] Furthermore, the specific steps in S2.7 include:

[0197] (1) Obtain the isolation work pool application interface in the vehicle operating system coroutine scheduler. The isolation work pool application interface is a standard functional interface provided by the vehicle operating system for container resource isolation. It is located and extracted directly from the operating system kernel service registration list.

[0198] (2) Initiate a coroutine work pool creation request based on the isolated work pool application interface, and bind the unique namespace identifier of the independently running container before initiating the request;

[0199] (3) Call the resource allocation function of the isolated work pool application interface to apply for a dedicated coroutine work pool identifier for the independently running container. The coroutine work pool identifier is uniformly allocated by the vehicle operating system coroutine scheduler.

[0200] (4) After completing the allocation of the coroutine work pool identifier, the lock-free message queue is bound to the allocated coroutine work pool identifier to form a coroutine work pool identifier carrying the lock-free message queue. The vehicle operating system coroutine scheduler integrates the lock-free message queue by default when creating the coroutine work pool. The maximum number of cached messages in the lock-free message queue is set to 1024 according to the vehicle high real-time operation standard to limit the message storage capacity and avoid queue overflow affecting the operating efficiency.

[0201] (5) Set the data transmission type restriction parameter of the lockless message queue to the value semantic data exclusive transmission mode. The value semantic data exclusive transmission mode restricts the lockless message queue to only support the transmission of value semantic data payload. The value semantic data payload includes basic data type and independent data copy, and can complete the transmission without relying on external memory address.

[0202] (6) Configure the lock-free message queue to prohibit transmission rules, specifically: set the reference type data interception function to the enabled state, and the prohibition transmission rule explicitly prohibits the lock-free message queue from transmitting reference type data that points to the internal control structure of other coroutine work pools. Reference type data includes memory address pointers, internal structure handles and cross-pool resource indexes. After being enabled, the queue will automatically identify and block the transmission request of this type of data.

[0203] (7) After configuration, the vehicle operating system coroutine scheduler verifies the transmission type restriction rules of the lockless message queue, verifies the integrity and validity of the rule configuration, confirms that value semantic data can be transmitted normally, the reference type data transmission path is completely blocked, and obtains a coroutine work pool identifier carrying the lockless message queue exclusively allocated to the independent running container. The coroutine work pool corresponding to the coroutine work pool identifier has completed the transmission type restriction settings of the lockless message queue, only allowing the transmission of value semantic data load, and prohibiting the transmission of reference type data pointing to the internal control structure of other coroutine work pools.

[0204] S2.8: When the compliant component code contains a web page rendering component tag, start an independent browser rendering process, allocate an isolated network namespace and virtual Ethernet device to the browser rendering process, and register a filtering callback function based on a Uniform Resource Locator (URL) domain suffix whitelist on the network protocol stack output path of the virtual Ethernet device.

[0205] Furthermore, the specific steps in S2.8 include:

[0206] (1) Perform a complete tag scan and identification on the compliant component code, and confirm whether the compliant component code contains web page rendering component tags during the scanning process;

[0207] (2) When the identification results determine that the compliant component code contains the web page rendering component tag, start an independent browser rendering process in accordance with the vehicle operating system process isolation management specifications;

[0208] (3) Allocate an isolated network namespace to the started browser rendering process. This network namespace is uniformly allocated by the vehicle operating system network management module and has an independent network protocol stack and network resource management capabilities. No numerical parameters need to be set.

[0209] (4) After completing the allocation of the isolated network namespace, create and bind a virtual Ethernet device to the network namespace. The virtual Ethernet device serves as a dedicated network communication carrier for the browser rendering process. Its transmission queue length parameter is fixed at 256 data packet units according to the vehicle high-stability communication standard to ensure the smoothness of network data transmission and keep it fixed throughout the process. After the virtual Ethernet device is created, it is bound to the isolated network namespace one by one.

[0210] (5) Register a filtering callback function on the network protocol stack output path of the completed virtual Ethernet device. The execution priority parameter of the filtering callback function is fixed to the highest priority according to the vehicle network security management standard to ensure that all network data output to the outside will be verified by the function first. The registered filtering callback function adopts a whitelist filtering mechanism based on the Uniform Resource Locator domain name suffix. The maximum configurable number of suffix entries in the whitelist is set to 128 to limit the storage capacity of legal domain name suffixes. Only the secure domain name suffixes certified by the vehicle system are included in the whitelist. The filtering callback function will perform domain name suffix matching verification on all network requests output through the virtual Ethernet device.

[0211] (6) After the filter callback function is registered and takes effect, the vehicle operating system network management module performs integrity verification on the network configuration filtering rules and the status of the filter callback function of the virtual Ethernet device. No additional parameters are set during the verification process, only confirming that the network isolation configuration and filtering mechanism are in normal working condition.

[0212] S2.9: Combine the layer number of the isolation layer, the coroutine worker pool identifier, and the process identifier of the browser rendering process in sequence, and add the configured 16-bit checksum data to form the isolation context descriptor of the isolated running instance. The isolation context descriptor uniquely corresponds to the current standalone running container and is used to mark all isolated running resources of the standalone running container.

[0213] S3: Generate dynamic permission configuration policies based on isolated running instances, target running scenario identifiers, component type tags, and real-time acquired vehicle driving status data;

[0214] The specific steps of S3 include:

[0215] S3.1: Based on the isolation context descriptor of the isolated running instance, and according to the vehicle stationary power supply scenario or vehicle road driving scenario indicated by the target running scenario identifier, obtain the vehicle longitudinal acceleration integral value in the real-time vehicle driving state data.

[0216] Furthermore, the specific steps in S3.1 include:

[0217] (1) Read the isolation context descriptor and target running scenario identifier corresponding to the isolated running instance;

[0218] (2) Based on the specific scenario type indicated by the target operation scenario identifier, perform differentiated data collection and filtering, including: if the target operation scenario identifier indicates a vehicle stationary power supply scenario, then only collect driving status data when the vehicle is in the parking power supply state; if the target operation scenario identifier indicates a vehicle road driving scenario, then collect all driving status data when the vehicle is in the dynamic driving process. In this embodiment, the collection frequency is set to 50 times per second.

[0219] (3) Under the given scenario constraints, real-time vehicle driving status data is obtained from the vehicle body sensor network, and the longitudinal acceleration value of the vehicle is extracted from the vehicle driving status data.

[0220] (4) Perform time domain integration on the collected vehicle longitudinal acceleration values ​​according to the integration time window of 100ms, convert the change of acceleration with time into an integral result that can characterize the vehicle motion state, and generate the corresponding vehicle longitudinal acceleration integral value.

[0221] S3.2: Read the basic permission mask row vector from the pre-stored scene permission matrix according to the target running scene identifier; each binary bit of the basic permission mask row vector corresponds to a vehicle capability interface or an external data source;

[0222] Furthermore, the scenario permission matrix is ​​the core data structure for the vehicle system to achieve scenario-based permission control. The construction work is completed in one go during the vehicle system's factory deployment phase. During construction, the matrix row and column size parameters are configured. In this embodiment, it is set to 8 rows and 64 columns. The matrix rows are used to store the complete permission policies corresponding to different vehicle operation scenarios. The scenarios currently officially enabled by the system only include two types: vehicle stationary power supply scenario and vehicle road driving scenario, occupying the first two rows of the matrix. The remaining 6 rows are reserved for expansion rows, used to add extended operation scenarios such as low-speed crawling, high-speed cruise, and automatic parking. The columns of the matrix correspond to vehicle capability interfaces or external data sources. In accordance with the vehicle safety management and control specifications, the permission status of each column is configured for the matrix rows corresponding to the vehicle stationary power supply scenario and the vehicle road driving scenario. The permission status includes two basic types: allow and deny. After configuration, a complete scenario permission matrix is ​​formed. The constructed scenario permission matrix is ​​then stored in the internal security configuration storage area of ​​the vehicle system.

[0223] Furthermore, the target operating scenario identifier is input into the matching logic of the scenario permission matrix, and the corresponding matching operation between the scenario type and the matrix row vector is performed. If the target operating scenario identifier indicates a vehicle stationary power supply scenario, the corresponding permission storage row for the vehicle stationary power supply scenario in the scenario permission matrix is ​​located. If the target operating scenario identifier indicates a vehicle road driving scenario, the corresponding permission storage row for the vehicle road driving scenario in the scenario permission matrix is ​​located. The matching process strictly follows the one-to-one correspondence rule between scenarios and matrix rows. After the location is completed, the complete 64-bit column data of the row is read. Considering that the vehicle security chip and interface gateway only support 32-bit permission register operations, and that the first 32 columns of the matrix are the standard permissions for mass-produced vehicles and the last 32 columns are reserved for extended permissions, only the effective permission bits of the first 32 columns are extracted and encapsulated into a basic permission mask row vector. This basic permission mask row vector is a fixed-length data structure preset by the vehicle system. Its total number of bits is fixed at 32 bits according to the total number of vehicle capability interfaces and external data sources. Each bit of data independently corresponds to a system permission.

[0224] S3.3: Based on the navigation map component or audio / video entertainment component indicated by the component type label, a dynamic risk-weighted correction method is used to correct the basic permission mask row vector to obtain the corrected permission mask row vector, specifically including:

[0225] When the component type label is a navigation map component and the vehicle's longitudinal acceleration integral value exceeds a preset driving start acceleration threshold, it is determined that the vehicle has switched from a stationary state to a driving state. At this time, it is necessary to perform a first permission tightening adjustment on the basic permission mask row vector, including: locating the binary bit corresponding to the map incremental data download interface in the basic permission mask row vector, changing the permission status corresponding to the binary bit from allowed to denied; and simultaneously locating the binary bit corresponding to the real-time traffic event broadcast interface in the basic permission mask row vector, changing the permission status corresponding to the binary bit from allowed to pending explicit user confirmation. In this embodiment, the driving start acceleration threshold is set to 0.5 m / s². 2 ;

[0226] When the component type label is audio and video entertainment component and the vehicle longitudinal acceleration integral value exceeds the driving start acceleration threshold, it is also determined that the vehicle has switched from a stationary state to a driving state. The second permission tightening adjustment is performed on the basic permission mask row vector, including: locating the binary bit of the corresponding video frame decoding output interface in the basic permission mask row vector, changing the permission status of the binary bit from allowed to denied, and locating the binary bit of the corresponding audio stream decoding output interface in the basic permission mask row vector, changing the permission status of the binary bit from unrestricted to output power limiting mode.

[0227] After tightening and adjusting permissions, the corrected permission mask row vector is obtained. The corrected permission mask row vector is traversed to identify all valid binary bits. The interface identifier and data source name corresponding to each valid binary bit are matched and associated one by one. The data are arranged in an orderly manner according to the vehicle permission management data organization specification to generate a permission entry list. The valid binary bits refer to the binary bits where the permission status has changed or remains unchanged. Each item in the permission entry list clearly contains the interface identifier, data source name and corresponding permission status.

[0228] S4: Perform vehicle capability interface rate limiting and external data source hierarchical access control on the isolated running instance according to the dynamic permission configuration policy, and output the permission-controlled instance;

[0229] The specific steps of S4 include:

[0230] S4.1: Based on the list of permission entries in the dynamic permission configuration policy and the coroutine worker pool identifier of the isolated running instance, obtain the token bucket group base address in the vehicle interface gateway process and the mandatory access control tag library of the external data source.

[0231] Furthermore, the specific steps of S4.1 include:

[0232] (1) Read the dynamic permission configuration policy and extract the permission entry list from the dynamic permission configuration policy. The permission entry list contains the permission status information of each vehicle capability interface and the external data source.

[0233] (2) Read the isolation context descriptor corresponding to the isolated running instance, and extract the coroutine work pool identifier from the isolation context descriptor. The coroutine work pool identifier is a globally unique identifier assigned by the vehicle operating system coroutine scheduler to the exclusive coroutine work pool.

[0234] (3) Use the permission entry list and coroutine work pool identifier to initiate a resource request to the vehicle interface gateway process. Before the request, establish a communication connection with the gateway process. The connection uses the vehicle internal process communication standard and the communication port is fixed at 8080 to ensure a stable and reliable connection.

[0235] (4) After the communication connection is established, the list of permission entries and the coroutine work pool identifier are sent to the vehicle interface gateway process as request parameters to request the token bucket group base address. The token bucket group is used to control the calling frequency of each vehicle capability interface. After receiving the request, the vehicle interface gateway process performs parameter validity verification.

[0236] (5) After the parameter verification is passed, the vehicle interface gateway process searches the internal resource management area, locates the storage start position of the token bucket group according to the coroutine work pool identifier, and reads the base address of the token bucket group after the location is completed. The base address of the token bucket group is the starting physical address of the token bucket group in the memory of the vehicle interface gateway process.

[0237] (6) After obtaining the token bucket group base address, retrieve the mandatory access control tag library of the external data source. The mandatory access control tag library of the external data source is a set of external data source permission management data that is fixed in the vehicle system before leaving the factory. It is stored in the internal security area and can be read directly. It contains the sensitivity level tags of all external data sources and the authorization level tags of all isolated running instances.

[0238] (7) After the retrieval is completed, the token bucket group base address and the mandatory access control tag library of the external data source are verified for integrity. After the verification is passed, the obtained token bucket group base address in the vehicle interface gateway process and the mandatory access control tag library of the external data source are used as the output results of this process for vehicle capability interface rate limiting and external data source hierarchical access control operations.

[0239] S4.2: Based on the maximum number of calls configured for each vehicle capability interface in the permission entry list, initialize a cyclic time slot token matrix for the coroutine worker pool identifier at the token bucket group base address; each row of the cyclic time slot token matrix corresponds to a vehicle capability interface, and each column corresponds to a time slot. The initial number of tokens in each time slot is calculated and replenished according to the ratio of the maximum number of calls to the total number of time slots. In this embodiment, the maximum number of calls is set to 100 times, and the total number of time slots is set to 10, which is used to evenly divide the unit rate limiting cycle into 10 time slots of equal length.

[0240] S4.3: When the isolated running instance initiates a call request to the vehicle capability interface through a coroutine in the coroutine worker pool, the target interface identifier and the current system clock tick count in the call request are extracted. The mapping column index of the current system clock tick count in the cyclic time slot token matrix is ​​calculated. The remaining number of tokens in the time slot corresponding to the target interface identifier in the cyclic time slot token matrix at the mapping column index is checked. If the remaining number of tokens is greater than zero, one token is consumed and the call request is forwarded to the vehicle capability interface. If the remaining number of tokens is equal to zero, the call request is temporarily stored in the delayed processing queue.

[0241] Furthermore, the specific steps of S4.3 include:

[0242] (1) Listen to the coroutine work pool corresponding to the isolated running instance. When a coroutine in the coroutine work pool initiates a call request for the vehicle capability interface, extract the target interface identifier from the request data packet of the call request. The target interface identifier is used to uniquely identify the vehicle capability interface currently being called.

[0243] (2) Extract the current system clock tick count from the request data packet. The system clock tick count is generated in real time by the vehicle operating system kernel and is used to accurately mark the time point when the request was initiated. The extraction process reads directly from the kernel clock register.

[0244] (3) Configure the time slot tick span parameter. In this embodiment, it is set to the number of ticks corresponding to 100ms, which is used to define the clock tick range corresponding to a single time slot;

[0245] (4) Divide the system clock tick count by the time slot tick span parameter to obtain the quotient and remainder. Take the modulo of the quotient with the total number of time slots, 10. The result is the index of the mapping column of the current request in the cyclic time slot token matrix.

[0246] (5) After obtaining the mapping column index, locate the corresponding row in the loop time slot token matrix according to the temporarily stored target interface identifier. The row corresponds to the vehicle capability interface currently being called.

[0247] (6) Locate the corresponding column in the corresponding row based on the mapping column index. This column corresponds to the time slot to which the current request belongs, and read the remaining number of tokens stored at this position;

[0248] (7) Check the remaining token quantity. In the first case, the remaining token quantity is greater than 0. At this time, the token consumption and request forwarding operation is performed. First, the remaining token quantity in the time slot is reduced by 1 to complete the consumption of one token. Then, the complete interface call request is forwarded to the corresponding vehicle capability interface. In the second case, the remaining token quantity is equal to 0. At this time, the request temporary storage operation is performed. The current interface call request is marked as a rate-limited pass request. Then, according to the vehicle request caching specification, the rate-limited pass request is temporarily stored in the delayed processing queue and processed after the subsequent time slot tokens are replenished.

[0249] (8) After completing the processing of the two cases, end the current interface call request, continue to return to the listening state, and wait for the next interface call request.

[0250] S4.4: Query the mandatory access control tag library to obtain the sensitivity level tag of the external data source and the authorization level tag of the isolated running instance. When the level value of the authorization level tag is greater than or equal to the level value of the sensitivity level tag, allow the isolated running instance to read the data from the external data source and record the read data as a hierarchical access data stream; otherwise, refuse to read.

[0251] Furthermore, the specific steps of S4.4 include:

[0252] (1) Read the mandatory access control tag library of external data sources, which includes the sensitivity level tags corresponding to all external data sources and the authorization level tags corresponding to all isolated running instances;

[0253] (2) Receive external data source read requests initiated by isolated running instances, and extract the unique identifier of the external data source from the data packet of the external data source read request;

[0254] (3) Based on the unique identifier of the external data source, the corresponding sensitivity level label is retrieved in the mandatory access control label library of the external data source according to the binding relationship between the identifier and the label. After the retrieval is completed, the level value corresponding to the sensitivity level label is read. The level value is fixedly divided into level 1 to level 5 according to the vehicle data classification standard. Level 1 is public data and level 5 is the most sensitive data. The larger the value, the higher the sensitivity of the data.

[0255] (4) Extract the unique identifier of the isolated running instance from the data packet, and then search the authorization level label corresponding to the identifier in the mandatory access control label library of the external data source. Read the level value corresponding to the authorization level label. Similarly, it is divided into five levels, with the larger the value representing the higher the access permission.

[0256] (5) When the authorization level value is greater than or equal to the sensitivity level value, it is determined that the isolated running instance has the legal access rights to the external data source. At this time, the isolated running instance is allowed to read the data of the target external data source. The data reading process is executed in accordance with the vehicle data transmission protocol. After the reading is completed, the acquired data is marked as hierarchical access through the data stream, and the data source, access time, instance identity and other related information are recorded.

[0257] (6) When the authorization level value is less than the sensitivity level value, it is determined that the isolated running instance does not have sufficient permissions and is not qualified to access the external data source. At this time, the read request is directly rejected, the insufficient permission prompt message is returned, and no data read operation is performed to avoid sensitive data leakage.

[0258] S4.5: Take all call requests marked as rate-limited requests from the delayed processing queue, merge them with the hierarchical access data stream, arrange the merged data in timestamp order as a record of the running behavior of the permission-controlled instance, and output it.

[0259] S5: Real-time monitoring of the permission-controlled instance, obtaining real-time running status data, determining the abnormality level based on the real-time running status data, executing the corresponding self-healing isolation operation, and outputting the repaired component instance;

[0260] Real-time monitoring of the access-controlled instances is performed to obtain real-time operational status data. Based on this data, an anomaly level is determined, including:

[0261] S5.1: Based on the runtime behavior records of the permission-controlled instance, and based on the unique namespace identifier of the independent running container corresponding to the permission-controlled instance, obtain the hardware event counter of the vehicle operating system performance monitoring unit and the callback function registered on the kernel exception notification chain;

[0262] Furthermore, the specific steps in S5.1 include:

[0263] (1) Read the running behavior records of the controlled instance, including the interface call behavior, process running status, memory usage and thread scheduling behavior of the corresponding isolated running container. The sampling frequency of data collection is set to 100 times per second according to the vehicle performance monitoring standard.

[0264] (2) The unique namespace identifier of the standalone running container corresponding to the read-permission controlled instance;

[0265] (3) Based on the unique namespace identifier of the independent running container, a precise matching and retrieval is performed in the resource registry of the vehicle operating system performance monitoring unit. Specifically, the resource registry of the performance monitoring unit pre-stores the binding relationship between hardware monitoring resources and abnormal callback resources corresponding to all isolated running containers. The retrieval process completes one-to-one precise matching through the unique namespace identifier and filters out the monitoring resource set exclusive to the current permission-controlled instance.

[0266] (4) Read the hardware event counter corresponding to the vehicle operating system performance monitoring unit from the selected set of dedicated monitoring resources. The hardware event counter is a hardware monitoring unit configured at the kernel level for isolated running container performance statistics. It is used to count hardware scheduling events, instruction execution events and resource occupation events during container operation. The reading process relies on the set 32-bit cache retrieval length parameter to complete accurate positioning, directly call the valid hardware event counter resource, and complete the acquisition of hardware monitoring resources.

[0267] (5) Based on the matching result of the unique namespace identifier, retrieve the callback function that the currently independently running container has completed registration in the registered resource list of the kernel exception notification chain. The kernel exception notification chain is the exception reporting mechanism preset by the kernel of the vehicle operating system. All isolated running containers will complete the registration and binding of their exclusive callback functions during the initialization phase and obtain the callback function of the exception notification corresponding to the currently controlled instance.

[0268] S5.2: Configure the hardware event counter to track the number of instruction execution cycles, the number of last-level cache access misses, and the number of address translation backstop misses. Read the values ​​from the register of the hardware event counter at a preset sampling period to obtain the microarchitecture state vector of the permission-controlled instance.

[0269] Furthermore, the specific steps in S5.2 include:

[0270] (1) Call the hardware event counter of the vehicle operating system performance monitoring unit, and use the hardware event counter as the only hardware resource carrier for this function configuration. The entire configuration operation is executed on the dedicated hardware event counter corresponding to the current permission-controlled instance.

[0271] (2) Configure the hardware event counter for monitoring events, and enable the tracking functions of three types of fixed monitoring indicators in sequence. The first type of configuration is the instruction execution cycle number tracking function, which is used to count the total number of instruction execution cycles completed by the hardware processor during the operation of the permission-controlled instance; the second type of configuration is the last-level cache access miss number tracking function, which is used to count the total number of times the processor's last-level cache failed to read data during the operation of the permission-controlled instance; the third type of configuration is the address translation back buffer miss number tracking function, which is used to count the total number of times the virtual address translation physical address cache failed to match during the operation of the permission-controlled instance. The three types of monitoring events are fixed configuration items.

[0272] (3) Initialize the hardware sampling scheduling parameters. The sampling period parameter is fixed at 10ms according to the vehicle microarchitecture monitoring standard.

[0273] (4) Based on a 10ms sampling period, a periodic register read scheduling logic is constructed. The system continuously triggers the register read operation of the hardware event counter at equal time intervals. Each round of scheduling directly accesses the underlying register space corresponding to the hardware event counter to accurately read the cumulative value of the instruction execution cycle number, the cumulative value of the last-level cache access miss, and the cumulative value of the address translation back buffer miss within the current cycle.

[0274] (5) The original values ​​of the three types of hardware counts obtained in each sampling period are normalized, the invalid interference values ​​in the register reading process are removed, and the real and valid hardware statistics are retained to ensure that each set of collected data corresponds to the real hardware running status of the permission-controlled instance.

[0275] (6) The number of instruction execution cycles, the number of last-level cache access misses, and the number of address translation back buffer misses collected in the same sampling period are ordered according to the dimensions to form a complete and unified microarchitecture state vector. All data dimensions of this state vector come from the real-time sampling results of the hardware event counter and are used to characterize the hardware microarchitecture running state of the current permission-controlled instance.

[0276] S5.3: Capture the memory access out-of-bounds signal or illegal opcode signal generated by the permission-controlled instance through the callback function registered on the kernel exception notification chain. When the memory access out-of-bounds signal or the illegal opcode signal is captured, set the crash event flag to true.

[0277] Furthermore, the specific steps in S5.3 include:

[0278] (1) Enable the dedicated callback function on the kernel exception notification chain that has been successfully obtained, and only listen for and process kernel exception signals generated by the privilege-controlled instance;

[0279] (2) Configure the kernel abnormal signal listening mask parameter. The kernel abnormal signal listening mask parameter is set to 655 according to the vehicle kernel abnormal monitoring standard. It is used to precisely limit the range of listening signals of the callback function, so that the callback function only responds to two types of abnormal signals: memory access out of bounds signal and illegal opcode signal, and shields ordinary abnormal signals and interference signals of the system.

[0280] (3) Relying on the kernel-level monitoring mechanism of the kernel exception notification chain, the system monitors hardware and program exceptions generated during the operation of the privilege-controlled instance in real time. If the instance engages in illegal memory read or cross-domain memory access during the operation of the privilege-controlled instance, the system kernel will actively throw a memory access out-of-bounds signal. If the instance executes an erroneous instruction or illegal instruction code that the processor cannot recognize, the system kernel will actively throw an illegal opcode signal.

[0281] (4) The callback function receives the abnormal signal data pushed by the kernel in real time, and performs precise matching and verification of the signal type by combining the preset 655 listening mask parameter to determine whether the currently captured signal is a memory access out-of-bounds signal or an illegal opcode signal.

[0282] (5) When the callback function confirms that it has successfully captured the memory access out-of-bounds signal or the illegal opcode signal through mask matching, it immediately configures the state of the system's preset crash event flag and switches the original default false state to the true state.

[0283] (6) After the flag bit setting is completed, the state solidification operation is performed to lock the true state of the current crash event flag bit, so as to avoid the flag bit state from frequently flipping due to instantaneous signal jitter. At the same time, the current abnormal signal type and the flag bit change time are recorded to form a complete abnormal trigger record, ensuring that the abnormal event is traceable and verifiable.

[0284] (7) If the callback function fails to capture the two types of target exception signals, the default false state of the crash event flag will remain unchanged, and the exception listening and signal matching will be continuously executed in a loop to always maintain the ability to monitor the abnormal operation of the privilege-controlled instance.

[0285] S5.4: When the number of instruction execution cycles exceeds the preset lower limit threshold for instruction throughput, generate a computing resource anomaly flag and set it to true.

[0286] Furthermore, the specific steps in S5.4 include:

[0287] (1) Read the microarchitecture state vector of the previously sampled permission-controlled instance, and extract the statistical value of the instruction execution cycle number corresponding to the current sampling cycle from the microarchitecture state vector;

[0288] (2) Initialize the lower limit threshold of instruction throughput. In this embodiment, the lower limit threshold of instruction throughput is set to 12,000 cycles every 10 milliseconds to determine whether the instruction throughput of the isolated running instance is in the normal operating range.

[0289] (3) Compare the number of instruction execution cycles collected in real time with the lower limit threshold of instruction throughput;

[0290] (4) When the number of instruction execution cycles in the current sampling period is detected to be greater than the lower limit threshold of instruction throughput, it is determined that the instruction throughput scale of the current permission-controlled instance exceeds the normal control range and there is abnormal operation behavior of computing resource occupation.

[0291] (5) Retrieve the computing resource exception flag from the system resource status flag register, modify the default initial false state of the computing resource exception flag and set it to true state to mark the current instance as having a computing resource exception problem;

[0292] (6) Synchronously record the sampling time, instruction execution cycle number and flag change status corresponding to this over-limit, so as to ensure that the abnormal judgment behavior is traceable and auditable; if the instruction execution cycle number is less than or equal to the instruction throughput lower limit threshold, the false state of the computing resource abnormal flag remains unchanged, no abnormal flag is generated, and the value judgment of the next sampling cycle is continuously waited for.

[0293] S5.5: When the number of last-level cache access misses exceeds the preset cache jitter detection threshold, a memory access mode exception flag is generated and set to true.

[0294] Furthermore, the specific steps of S5.5 include:

[0295] (1) Read the microarchitecture state vector of the permission-controlled instance, and extract the value of the number of last-level cache access misses corresponding to the current 10ms sampling period from the microarchitecture state vector. This value is the real hardware operation data statistically analyzed in real time by the vehicle operating system performance monitoring unit, which represents the cache access anomaly of the permission-controlled instance in a single sampling period.

[0296] (2) Initialize the cache jitter detection threshold. In this embodiment, the cache jitter detection threshold is set to 250 times every 10 milliseconds to determine whether the permission-controlled instance has abnormal cache jitter behavior with frequent cache invalidation, thus eliminating the problem of ambiguous description.

[0297] (3) Compare the number of missing accesses to the last-level cache collected in real time with the cache jitter detection threshold;

[0298] (4) When the number of missing accesses to the last-level cache in the current sampling period is found to be greater than the cache jitter detection threshold, it is determined that the memory access behavior of the current permission-controlled instance is disordered and frequently triggers cache failure, indicating a typical memory access pattern abnormality and cache jitter problem.

[0299] (5) Retrieve the preset memory access mode exception flag in the system kernel status register, modify the default false state of the flag to the true state, and complete the marking and solidification of the exception state.

[0300] (6) Automatically record the number of missing accesses to the last-level cache, the threshold comparison results, and the status of flag changes in the current sampling period to ensure that abnormal events are traceable throughout the process. If the number of missing accesses to the last-level cache does not exceed the preset cache jitter detection threshold, the false status of the memory access mode abnormal flag will remain unchanged, and the system will continue to enter the monitoring and judgment process of the next sampling period.

[0301] S5.6: When the number of address translation back buffer misses exceeds the preset address space fragmentation threshold, an address translation exception flag is generated and set to true.

[0302] Furthermore, the specific steps in S5.6 include:

[0303] (1) Read the microarchitecture state vector of the permission-controlled instance generated by the hardware event counter according to the 10ms sampling period, extract the address translation back buffer miss number corresponding to the current sampling period from the microarchitecture state vector. The address translation back buffer miss number is the real statistical data of the vehicle processor memory address translation process, which is used to reflect the cache hit status of the virtual address and physical address mapping of the permission-controlled instance.

[0304] (2) Initialize the address space fragmentation threshold. In this embodiment, the address space fragmentation threshold is set to 180 times every 10 milliseconds to determine whether there are abnormal problems such as frequent failures or address space fragmentation in the address mapping of the permission-controlled instance.

[0305] (3) Compare the number of address translation backup buffer misses extracted in real time with the address space fragmentation threshold;

[0306] (4) When the number of address translation back buffer misses in the current sampling period is greater than the preset address space fragmentation threshold, it is determined that the address mapping cache frequently fails during the operation of the permission-controlled instance, indicating hardware operation problems such as address space fragmentation and address translation abnormalities.

[0307] (5) Retrieve the preset address translation exception flag in the kernel status register of the vehicle system, modify the initial default false state of the flag and set it to true state to complete the marking of the address translation exception state for this time;

[0308] (6) Automatically record the specific number of address translation backup buffer misses, threshold comparison results, and abnormal flag change status of the current sampling period to ensure that abnormal monitoring behavior is traceable and verifiable. If the current number of address translation backup buffer misses does not exceed the address space fragmentation threshold, the false state of the address translation abnormal flag remains unchanged, and the system continues to wait for the cyclic monitoring and judgment of the next sampling period.

[0309] S5.7: The crash event flag, computing resource anomaly flag, memory access mode anomaly flag, and address translation anomaly flag are input into the Naive Bayes classifier. The Naive Bayes classifier includes a category node representing the overall anomaly level and four feature nodes corresponding to the four flags. The conditional probability distribution of each feature node under a given category node value is obtained through pre-statistics. The actual values ​​of the four observed flags are substituted into the Naive Bayes classifier to calculate the posterior probability of each category. The anomaly level category with the highest posterior probability is output as the final anomaly level. The Naive Bayes classifier is prior art in this field and is not an inventive solution of this application. It will not be described in detail here.

[0310] Furthermore, the execution of the corresponding self-healing isolation operation and the output of the repaired component instance include:

[0311] (1) Based on the determined anomaly level and microarchitecture state vector, obtain the process control block of the permission-controlled instance and the resource control group file interface of the independently running container;

[0312] (2) When the anomaly level is low and the number of last-level cache access misses in the microarchitecture state vector is greater than the cache jitter detection threshold and less than the preset multiple upper limit of the cache jitter detection threshold, in this embodiment the multiple upper limit is set to 1.8 times, and the virtual address region hot migration self-healing operation is adopted: call the virtual memory region management structure in the process control block, remap the virtual memory region with the highest access frequency of the permission-controlled instance to an idle address translation back buffer slot, and read the current address translation prefetch depth parameter, and modify the address translation prefetch depth parameter from the default level to the depth enhancement level;

[0313] (3) When the anomaly level is medium or high, namespace forced reclamation self-healing operation is adopted: write process termination instruction to the control group file of the independent running container through the resource control group file interface, forcibly reclaim all physical computing core binding relationships and physical page frames in the exclusive memory area occupied by the independent running container, and store the component type label of the permission-controlled instance and the hash signature of the current running behavior record into the hash set of the global isolation blacklist, and attach a limited lifespan to the hash set entries;

[0314] (4) When the exception level is a crash level exception, after the namespace forced reclamation self-healing operation is completed, the kernel crash dump interface is called to save the general register values ​​and kernel state function call stack at the time of the crash to the persistent storage medium.

[0315] (5) Re-instantiate the original image file of the permission-controlled instance that is in a terminated state after performing self-healing operation into a new independent running container. The new independent running container reuses the unique namespace identifier of the original independent running container but has a new process identifier. Output the re-instantiated component as the repaired component instance, and output the improved address translation prefetch depth parameter or the newly added isolation blacklist hash set entry as the updated protection policy.

[0316] S6: Return the repaired component instance to S2 and execute it in a loop until the lifecycle of the vehicle component ends.

[0317] Further, in step S6, the repaired component instance is returned to step S2 for repeated execution until the lifecycle of the vehicle component ends, including:

[0318] (1) Based on the output of the repaired component instance and the updated protection strategy, and based on the unique namespace identifier of the independent running container, obtain a loop execution counter stored in the metadata area of ​​the independent running container. The loop execution counter is initialized to the initial value of zero when S2 is executed for the first time. After each complete process from S2 to S6 is completed, an increment operation is automatically performed with an increment step of 1.

[0319] (2) A progressive sandbox reinforcement method triggered by a cyclic count is adopted. After each cyclic execution of the counter increments, the current count value is read and compared with the preset first reinforcement trigger threshold and second reinforcement trigger threshold. The first reinforcement trigger threshold is less than the second reinforcement trigger threshold. In this embodiment, the first reinforcement trigger threshold is set to 15 times and the second reinforcement trigger threshold is set to 30 times.

[0320] (3) When the current count value is greater than or equal to the first hardening trigger threshold and the current count value is less than the second hardening trigger threshold, on the basis of the multi-layer isolation environment of view isolation, coroutine isolation and WebView strong sandbox already constructed in S2, an additional forced access control layer based on system call hijacking is enabled. The forced access control layer intercepts the file read and write system calls and inter-process communication system calls initiated by the repaired component instance at the kernel system call entry point, and performs string pattern matching between the target path of these system calls and an access allowed list that gradually shrinks with the number of loops. The system call is allowed to be executed only when the match is successful; otherwise, a permission denial error is returned.

[0321] (4) When the current count value is greater than or equal to the second hardening trigger threshold, on the basis of enabling the forced access control layer based on system call hijacking, a nested virtualization reconstruction operation is further triggered. The nested virtualization reconstruction operation first saves the current memory working set of the repaired component instance to a temporary storage area, then destroys the current independent running container and its multi-layer isolation environment, and finally reconstructs the independent running container and the multi-layer isolation environment inside a newly created lightweight virtual machine monitor. The newly created lightweight virtual machine monitor has an independent guest physical address space and is isolated from the host operating system physical address space.

[0322] (5) Continuously monitor the current value of the loop execution counter. When a component destruction notification is received from the vehicle operating system or the unique namespace identifier of the independent running container is forcibly released by the kernel, the component life cycle is determined to be over, the loop execution from S2 to S6 is stopped, and the final value of the loop execution counter is written into the component running file record in the non-volatile storage device.

[0323] Example 2:

[0324] Please see Figure 3 Another embodiment of the present invention provides: a multi-layer sandbox-based vehicle component full lifecycle protection system, comprising:

[0325] The component disinfection module 10 is used to obtain the generated code, component type label, target running scenario identifier and preset security level parameters of the vehicle component to be deployed. Based on the taint propagation depth threshold and component type label, it marks the taint source node and taint sink node through symbolic execution, traverses the taint propagation path and generates an labeled directed graph, locates the unsafe memory copy basic block and replaces it with a safe function with boundary checks, and finally outputs compliant component code to achieve code security purification before deployment.

[0326] The isolation environment construction module 20, based on the compliant component code resource requirements, component type tags, and snapshots of the physical resource distribution of the vehicle heterogeneous computing platform, allocates exclusive or shared computing cores and memory areas for different types of components, generates independent running containers, and combines graphical interface layout files, coroutine scheduler interfaces, and web page rendering tags to create isolation layers, lock-free message queue coroutine work pools, and container isolation namespaces, outputs isolated running instances, and constructs a multi-layered isolated running environment;

[0327] The permission configuration module 30 reads the scene permission matrix based on the isolated running instance context, target running scene identifier, component type label and real-time vehicle driving status data, and generates a dynamic permission configuration strategy through dynamic risk weighting correction. It uses the time slot rotation rate limiting method to control the frequency of vehicle capability interface calls, and realizes hierarchical access to external data sources through the forced access control label library. It outputs permission-controlled instances to achieve dynamic permission management.

[0328] The anomaly level determination module 40, based on the running behavior records of the permission-controlled instance and the namespace identifier of the independent running container, configures the hardware event counter to obtain the microarchitecture state vector, captures the crash signal through the kernel anomaly notification chain, generates multiple anomaly flags and inputs them into the Naive Bayes classifier, and calculates the posterior probability to determine the anomaly level.

[0329] The self-healing isolation module 50 performs self-healing operations such as virtual address region hot migration, namespace forced reclamation, and kernel crash dumping based on the anomaly level and microarchitecture state vector, and outputs the repaired component instance; and based on a loop execution counter, it adopts a progressive sandbox hardening method, gradually enabling reinforcement mechanisms such as system call hijacking and nested virtualization reconstruction as the number of runs increases, and provides loop protection until the end of the component's life cycle.

[0330] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments under the guidance of the present invention without departing from the spirit and scope of the present invention. All of these variations are within the protection scope of the present invention.

Claims

1. A method for full lifecycle protection of vehicle-mounted components based on a multi-layer sandbox, characterized in that, include: S1: Obtain the generated code, component type label, target running scenario identifier, and preset security level parameters of the vehicle component to be deployed, and perform vehicle safety disinfection on the generated code according to the security level parameters and component type label, and output compliant component code; S2: Allocate independent running containers for the compliant component code, build a multi-layered isolation environment, and output isolated running instances; S3: Generate dynamic permission configuration policies based on isolated running instances, target running scenario identifiers, component type tags, and real-time acquired vehicle driving status data; S4: Perform vehicle capability interface rate limiting and external data source hierarchical access control on the isolated running instance according to the dynamic permission configuration policy, and output the permission-controlled instance; S5: Real-time monitoring of the permission-controlled instance, obtaining real-time running status data, determining the abnormality level based on the real-time running status data, executing the corresponding self-healing isolation operation, and outputting the repaired component instance; S6: Return the repaired component instance to S2 and execute it in a loop until the lifecycle of the vehicle component ends.

2. The method for full lifecycle protection of vehicle-mounted components based on a multi-layer sandbox as described in claim 1, characterized in that, The process of performing vehicle safety disinfection on the generated code based on safety level parameters and component type tags, and outputting compliant component code, includes: Based on the taint propagation depth threshold included in the security level parameters, and according to the communication or display component indicated by the component type label, the intermediate representation directed graph of the generated code is obtained; the nodes of the intermediate representation directed graph are basic blocks, and the edges are the control transfer relationships between basic blocks. The symbolic execution method is used to mark the external network data receiving function node in the generated code as a taint source node and the vehicle control command generating function node as a taint sink node. Following the reachable path in the directed graph represented by the middle, the process traverses from the taint source node towards the taint sink node. For each edge traversed, the number of edges traversed on the current path is recorded as the current taint propagation depth. The correspondence between the current taint propagation depth and each node on the current path is stored as a taint-marked tuple. All taint-marked tuples of visited nodes together constitute a taint-marked set. Each taint-marked tuple contains a node identifier and the corresponding taint propagation depth value. Continue traversing along the reachable path until the taint sink node is reached. Each time a new node is reached, update the taint propagation depth value in the taint label tuple and output a labeled directed graph carrying the taint propagation path and the taint propagation depth value corresponding to each node.

3. The method for full lifecycle protection of vehicle-mounted components based on a multi-layer sandbox as described in claim 2, characterized in that, The process of performing vehicle safety disinfection on the generated code based on safety level parameters and component type labels, and outputting compliant component code, also includes: When there is a path from any taint source node to any taint sink node in the labeled directed graph, and the taint propagation depth value in the taint label tuple at the end of the path exceeds the taint propagation depth threshold, the security sterilizer is invoked to locate the memory copy basic block on the taint propagation path that has not performed input length verification. Based on the component type label, a boundary-checked safe function is found from the preset safe function replacement mapping table that is functionally equivalent to the unsafe function in the memory copy basic block. The unsafe function call in the memory copy basic block is replaced with the boundary-checked safe function to generate compliant component code.

4. The method for full lifecycle protection of vehicle-mounted components based on a multi-layer sandbox as described in claim 1, characterized in that, Assigning a separate running container to the compliant component code, including: Based on the resource requirement list of compliant component code, and according to the real-time data stream processing component or non-real-time log recording component indicated by the component type label, a snapshot of the physical resource distribution of the vehicle heterogeneous computing platform is obtained; the physical resource distribution snapshot includes the current operating frequency status of each physical processor core in the vehicle heterogeneous computing platform and the number of free physical page frames on each memory access node. When the component type label indicates a real-time data stream processing component, a dedicated physical computing core is allocated to the compliant component code, and the set of continuous physical page frames on the local memory node corresponding to the physical computing core is locked as a dedicated memory region. At the same time, the interrupt response attribute of the physical computing core is set to only handle direct memory access requests from the dedicated memory region. When the component type label indicates a non-real-time logging component, a shared logical computing core and a virtual memory area of ​​standard page size are allocated to the compliant component code, and the scheduling strategy of the logical computing core is set to a time-slice round-robin scheduling strategy. Write the allocated physical computing core number or logical computing core number and the starting address of the dedicated memory region or the base address of the virtual memory region into the container isolation namespace, and output the unique namespace identifier of the independently running container.

5. The method for full lifecycle protection of vehicle-mounted components based on a multi-layer sandbox as described in claim 1, characterized in that, The construction of a multi-layered isolation environment and the output of isolated running instances include: Based on the unique namespace identifier of the independently running container, and according to the graphical interface layout file carried in the code of the compliant component, the layer stack management interface of the vehicle graphics synthesis server is obtained. Call the private layer creation function in the layer stack management interface to create an isolated layer bound to an independent frame buffer for the standalone running container, and set the visibility control bit of the isolated layer to allow the image data in the independent frame buffer to be passed to the physical display controller only when the standalone running container is in the foreground active state; Obtain the isolation work pool application interface in the vehicle operating system coroutine scheduler, apply for a coroutine work pool identifier carrying a lock-free message queue for the independent running container, and set the transmission type restriction of the lock-free message queue to only allow the transmission of data payloads with value semantics, and prohibit the transmission of reference type data pointing to the internal control structure of other coroutine work pools; When the compliant component code contains a web page rendering component tag, an independent browser rendering process is started, an isolated network namespace and virtual Ethernet device are allocated to the browser rendering process, and a filtering callback function based on a Uniform Resource Locator (URL) domain suffix whitelist is registered on the network protocol stack output path of the virtual Ethernet device. The layer number of the isolated layer, the coroutine worker pool identifier, and the process identifier of the browser rendering process are encapsulated together into an isolated context descriptor for the isolated running instance and then output.

6. The method for full lifecycle protection of vehicle-mounted components based on a multi-layer sandbox as described in claim 1, characterized in that, The specific steps of S3 include: Based on the isolation context descriptor of the isolated running instance, and according to the vehicle stationary power supply scenario or vehicle road driving scenario indicated by the target running scenario identifier, the vehicle longitudinal acceleration integral value in the real-time vehicle driving status data is obtained. Based on the target running scenario identifier, the basic permission mask row vector is read from the pre-stored scenario permission matrix; each binary bit of the basic permission mask row vector corresponds to a vehicle capability interface or an external data source. Based on the navigation map component or audio / video entertainment component indicated by the component type label, a dynamic risk-weighted correction method is used to correct the basic permission mask row vector to obtain the corrected permission mask row vector. Each valid binary bit in the corrected permission mask row vector is organized into a list of permission entries according to the interface identifier and data source name, and the dynamic permission configuration policy is output.

7. The method for full lifecycle protection of vehicle-mounted components based on a multi-layer sandbox as described in claim 6, characterized in that, The step of modifying the basic permission mask row vector to obtain the modified permission mask row vector includes: When the component type label is a navigation map component and the vehicle longitudinal acceleration integral value exceeds the preset driving start acceleration threshold, the binary bit of the corresponding map incremental data download interface in the basic permission mask row vector is changed from allowed to denied, and the binary bit of the corresponding real-time traffic event broadcast interface is changed from allowed to pending explicit user confirmation. When the component type label is an audio-visual entertainment component and the vehicle longitudinal acceleration integral value exceeds the preset driving start acceleration threshold, the binary bit of the corresponding video frame decoding output interface in the basic permission mask row vector is changed from allowed to denied, and the binary bit of the corresponding audio stream decoding output interface is changed from unlimited to output power limited mode.

8. The method for full lifecycle protection of vehicle components based on multi-layer sandbox as described in claim 1, characterized in that, The specific steps of S4 include: Based on the list of permission entries in the dynamic permission configuration policy, and based on the coroutine worker pool identifier of the isolated running instance, obtain the token bucket group base address in the vehicle interface gateway process and the mandatory access control tag library of the external data source. Based on the maximum number of calls configured for each vehicle capability interface in the permission entry list, a cyclic time slot token matrix is ​​initialized for the coroutine worker pool identifier at the token bucket group base address; each row of the cyclic time slot token matrix corresponds to a vehicle capability interface, each column corresponds to a time slot, and the initial number of tokens in each time slot is calculated and replenished according to the ratio of the maximum number of calls to the total number of time slots.

9. The method for full lifecycle protection of vehicle components based on multi-layer sandboxes as described in claim 8, characterized in that, The specific steps of S4 also include: When the isolated running instance initiates a call request to the vehicle capability interface through a coroutine in the coroutine worker pool, the target interface identifier and the current system clock tick count in the call request are extracted. The mapping column index of the current system clock tick count in the cyclic time slot token matrix is ​​calculated. The remaining number of tokens in the time slot corresponding to the target interface identifier in the cyclic time slot token matrix at the mapping column index is checked. If the remaining number of tokens is greater than zero, one token is consumed and the call request is forwarded to the vehicle capability interface. If the remaining number of tokens is equal to zero, the call request is marked as a rate-limited pass request and temporarily stored in the delayed processing queue. The system queries the mandatory access control tag library to obtain the sensitivity level tag of the external data source and the authorization level tag of the isolated running instance. When the level value of the authorization level tag is greater than or equal to the level value of the sensitivity level tag, the isolated running instance is allowed to read the data from the corresponding external data source and the read data is recorded as a hierarchical access data stream; otherwise, reading is refused. All call requests marked as rate-limited requests are retrieved from the delayed processing queue, merged with the hierarchical access data stream, and the merged data is arranged in timestamp order as a record of the running behavior of the permission-controlled instance and output.

10. The method for full lifecycle protection of vehicle components based on a multi-layer sandbox as described in claim 1, characterized in that, Real-time monitoring of the access-controlled instances is performed to obtain real-time operational status data. Based on this data, an anomaly level is determined, including: Based on the runtime behavior records of the permission-controlled instance, and based on the unique namespace identifier of the independent running container corresponding to the permission-controlled instance, the hardware event counter of the vehicle operating system performance monitoring unit and the callback functions registered on the kernel exception notification chain are obtained. The hardware event counter is configured to track the number of instruction execution cycles, the number of last-level cache access misses, and the number of address translation backstop misses. Values ​​are read from the register of the hardware event counter at a preset sampling period to obtain the microarchitecture state vector of the permission-controlled instance. The callback function registered on the kernel exception notification chain captures the memory access out-of-bounds signal or illegal opcode signal generated by the permission-controlled instance. When the memory access out-of-bounds signal or the illegal opcode signal is captured, the crash event flag is set to true. When the number of instruction execution cycles exceeds the preset lower limit threshold for instruction throughput, a computing resource anomaly flag is generated and set to true. When the number of missing accesses to the last-level cache exceeds the preset cache jitter detection threshold, a memory access mode exception flag is generated and set to true. When the number of address translation back buffer misses exceeds the preset address space fragmentation threshold, an address translation exception flag is generated and set to true.

11. The method for full lifecycle protection of vehicle components based on a multi-layer sandbox as described in claim 10, characterized in that, Real-time monitoring of the access-controlled instance to obtain real-time operational status data, and determination of the anomaly level based on the real-time operational status data, further includes: The crash event flag, computing resource anomaly flag, memory access mode anomaly flag, and address translation anomaly flag are input into the Naive Bayes classifier. The Naive Bayes classifier contains a category node representing the overall anomaly level and four feature nodes corresponding to the four flags. The conditional probability distribution of each feature node under a given category node value is obtained through pre-statistics. The actual values ​​of the four observed flags are substituted into the Naive Bayes classifier to calculate the posterior probability of each category. The anomaly level category with the highest posterior probability is output as the final anomaly level.

12. A multi-layer sandbox-based vehicle component lifecycle protection system, used to implement the multi-layer sandbox-based vehicle component lifecycle protection method according to any one of claims 1-11, characterized in that, include: The component disinfection module is used to obtain the generated code, component type label, target running scenario identifier and preset security level parameters of the vehicle components to be deployed. Based on the taint propagation depth threshold and component type label, it marks the taint source node and taint sink node through symbolic execution, traverses the taint propagation path and generates an labeled directed graph, locates the unsafe memory copy basic block and replaces it with a security function with boundary checks, and outputs compliant component code. The isolation environment building module is used to allocate independent running containers to different types of components, create isolation layers, lock-free message queue coroutine worker pools and container isolation namespaces, and output isolated running instances; The permission configuration module is used to generate dynamic permission configuration policies through dynamic risk weighting and correction, implement hierarchical access to external data sources through a mandatory access control tag library, and output permission-controlled instances. The anomaly level determination module, based on the running behavior records of the permission-controlled instance and the namespace identifier of the independent running container, configures the hardware event counter to obtain the microarchitecture state vector, generates multiple anomaly labels and inputs them into the Naive Bayes classifier, and calculates the posterior probability to determine the anomaly level. The self-healing isolation module is used to perform self-healing operations based on the anomaly level and the microarchitecture state vector, and output the repaired component instance.

Images