A kernel security policy zero-downtime hot update method and device

Abstract

The present application relates to a kind of kernel security policy zero downtime hot updating method and device, belong to access control technical field, solve the problem that there is air window period in the policy updating period in prior art, memory policy and configuration file state are inconsistent, policy switching process non-atomicity leads to unpredictable problem of access control check behavior.Method includes: response user layer process to the opening operation of device file, allocation shared memory and map to user layer;Response process synchronization submitted update request, read request parameter and update data from shared memory to build new structure, by RCU mechanism, pointer is atomically switched from old structure to new structure;Switch before and in the middle based on old structure to carry out access control check, all old release occupancy space after completion, update is completed;After switching, based on new structure to carry out access control check.The present application realizes air window period reduction, policy in memory is complete and effective, and policy data used for access control check is complete and effective.

Description

Technical Field

[0001] This invention relates to the field of access control technology, and in particular to a method and apparatus for zero-downtime hot update of kernel security policies. Background Technology

[0002] In the field of operating system security, dynamic updates of security policies are a key capability to ensure the continuous secure operation of a system. When a security policy needs to be adjusted (such as adding policy rules, modifying access control rules, or updating policy constraints), the modified policy configuration data from the user layer needs to be loaded into the kernel to replace the currently effective policy, so that the new policy immediately affects the system's access control behavior.

[0003] The current mainstream methods for updating kernel security policies mainly include the following: 1. Security Module Overloading Method The kernel updates policies by unloading the current security module and then reloading the security module containing the new policy. This method has the following drawbacks: (1) During the policy update, the security module is in an unloaded state, and there is a security window in the system. During this period, all access control checks are bypassed, and attackers can use this window to make unauthorized access. (2) The process of unloading and loading security modules involves the destruction and reconstruction of kernel data structures, which consumes a lot of system resources and takes a long time; (3) For scenarios where strategies need to be updated frequently, repeatedly unloading and loading security modules seriously affects system availability.

[0004] 2. Trigger loading method Policy updates are performed by writing trigger commands to specific device files or interfaces, which then prompt the kernel to reread the user-level configuration file. This method has the following drawbacks: (1) During the policy update process, the kernel needs to clear the old policy data and then load the new policy data. There is a time gap between clearing and loading, and the system lacks effective access control protection during this gap. (2) The policy update uses non-atomic operations (a non-atomic operation is an operation that can be interrupted, split or interleaved). If an error occurs during the update process and some policies fail to load, the memory policy may be inconsistent with the configuration file. (3) The access control check behavior during policy loading is unpredictable—it may reference old policy data that has been released or new policy data that has not been fully initialized, which poses a security risk.

[0005] 3. Security Policy Compilation and Loading Method The security policy compilation and loading method, after modifying the policy through the policy configuration tool, requires a policy compilation process to generate policy binary data, which is then loaded into the kernel policy library to complete the policy update. During the kernel policy library update phase, some methods use the RCU (Read-Copy-Update) mechanism to switch policy data, but its overall update process still has the following shortcomings: (1) Policy updates require compilation and linking processes, resulting in long update chains and high time consumption; During policy updates, the access decision cache in the kernel needs to be gradually invalidated and refilled. During this period, some access decisions need to be backtracked to the policy library, which increases the inspection latency. In addition, there is a time difference between the invalidation of cache entries and the RCU policy switch, which may result in the cache still retaining access decision results based on the old policy. The security policy compilation and loading method adopts a whole replacement approach, which transmits the policy binary data from the user layer to the kernel through sockets or files. The transmission process involves data copying overhead. Moreover, the policy update process is not an atomic operation—the policy data is transmitted in fragments and the access decision cache gradually expires, which leads to intermediate states during policy switching and poses a risk of state inconsistency.

[0006] In summary, the main shortcomings of the existing technology can be summarized as follows: there is a security window during policy updates, the memory policy and the configuration file state are inconsistent, and the non-atomic nature of the policy switching process leads to unpredictable access control check behavior. Summary of the Invention

[0007] Based on the above analysis, the embodiments of the present invention aim to provide a method and apparatus for zero-downtime hot update of kernel security policies to solve the problems in the prior art.

[0008] On one hand, embodiments of the present invention provide a method for zero-downtime hot update of kernel security policies, including: Create and register a device file, which provides a communication interface between user-level processes and the kernel; In response to a user-level process opening the device file, a separate shared memory is allocated to the process and mapped to the user layer; In response to a security policy update request submitted synchronously by a user-level process, request parameters and policy request data are read from the shared memory. A new security policy structure is constructed based on the request parameters and policy request data to store the new security policy data. The security policy pointer is atomically switched from pointing to the old security policy structure to pointing to the new security policy structure via the RCU mechanism. Before and during the atomic switch, access control checks are performed on resource access requests initiated by user-level processes to the kernel based on the old security policy structure. After the atomic switch, access control checks are performed on resource access requests initiated by user-level processes to the kernel based on the new security policy structure. Once all access control checks based on the old security policy structure are completed, the space occupied by the old security policy structure is released, and the security policy update is complete.

[0009] Furthermore, the shared memory includes a shared memory control header, a request buffer, and a response buffer; The shared memory control header includes multiple fields, including at least: a verification identifier field, a kernel ready status flag field, a process identifier field, a shared memory creation timestamp field, a request status and response status field, and other preset fields; The request parameters for the security policy update request are stored in other preset fields; The request buffer is used to store policy request data; The response buffer is used to store the security policy information requested in the query.

[0010] Furthermore, the mapping to the user layer also includes: The starting address of the shared memory is mapped to a shared memory control header, and the fields in the shared memory control header are initialized by assigning values. The verification identifier field and the kernel ready status flag field of the initialized data are verified. If the verification fails, the initialization fails. If the verification passes, the user layer fills the shared memory control header and the request buffer according to the security policy update request.

[0011] Furthermore, the request parameters include the operation type and the request data length; Read request parameters and policy request data from the shared memory, and construct a new security policy structure based on the request parameters and policy request data to store the new security policy data, including: The validity of the operation type and the length of the request data are verified. If both verifications pass, the corresponding policy processing function is called according to the operation type to read the policy request data from the shared memory, the new security policy data is determined based on the policy request data, and the new security policy data is stored in the new security policy structure. If any verification fails, the error information is written to the shared memory control header.

[0012] Furthermore, it also includes: Set the VMA flag for the shared memory to prevent the shared memory from being dumped or expanded.

[0013] Furthermore, the security policy structure stores security policy data, security policy version information, and access control results, and the access control results are stored in the security policy structure in the form of a cache table; The cache table of the old security policy structure stores valid access control results, while the cache table of the new security policy structure is empty. When the new access control check fails to find the access control result in the cache table from the new security policy structure, it needs to query the security policy data in the new security policy structure to perform the access control check and fill the cache table with the access control check result.

[0014] Furthermore, it also includes: In response to the security policy query request initiated by the user-level process, when there is no data in the response buffer of the shared memory, the user-level process is added to the waiting queue and the execution status of the user-level process is set to an interruptible sleep state. After writing the current security policy data into the response buffer, the user-level process in the waiting queue is woken up, causing the user-level process to return from the security policy query request.

[0015] Furthermore, it also includes: The number of concurrent user-level processes is counted using atomic counters; the atomic counter is incremented by 1 when a user-level process opens a device file and decremented by 1 when a user-level process closes a device file. The shared memory is released when the user-level process closes the device file.

[0016] On the other hand, embodiments of the present invention provide a method for zero-downtime hot update of kernel security policies, including: The kernel creates and registers device files, which provide a communication interface between user-level processes and the kernel. The user-level process opens the device file; In response to a user-level process's open operation on the device file, the kernel allocates independent shared memory for the process and maps it to the user layer; The user-level process writes the request parameters and policy request data into the shared memory and simultaneously submits a security policy update request. In response to a security policy update request submitted synchronously by a user-level process, the kernel reads the request parameters and policy request data from the shared memory, constructs a new security policy structure based on the request parameters and policy request data to store the new security policy data, and atomically switches the security policy pointer from pointing to the old security policy structure to pointing to the new security policy structure through the RCU mechanism. User-level processes send resource access requests to the kernel; Before and during the atomic switch, the kernel performs access control checks on the resource access requests based on the old security policy structure. After the atomic switch, the kernel performs access control checks on the resource access requests based on the new security policy structure. Once all access control checks based on the old security policy structure are completed, the kernel releases the space occupied by the old security policy structure, and the security policy update is complete.

[0017] On the other hand, embodiments of the present invention provide a kernel security policy zero-downtime hot update device, applied to the kernel, comprising: The device module is used to create and register device files, which provide a communication interface between user-level processes and the kernel; in response to a user-level process opening the device file, it allocates independent shared memory for the process and maps it to the user layer. The request processing module is used to respond to security policy update requests synchronously submitted by user-level processes. It reads request parameters and policy request data from the shared memory, constructs a new security policy structure based on these parameters and data to store the new security policy data, and atomically switches the security policy pointer from pointing to the old security policy structure to pointing to the new one via the RCU mechanism. Before and during the atomic switch, access control checks are performed on resource access requests initiated by user-level processes to the kernel based on the old security policy structure. After the atomic switch, access control checks are performed on resource access requests initiated by user-level processes to the kernel based on the new security policy structure. Once all access control checks based on the old security policy structure are completed, the space occupied by the old security policy structure is released, and the security policy update is complete.

[0018] Compared with the prior art, the present invention can achieve at least one of the following beneficial effects: 1) Existing methods require clearing the old policy before loading the new policy during policy updates, resulting in a lack of effective access control protection during this interval. This invention allocates independent shared memory for the user layer and the kernel. The new security policy is placed in the shared memory, while the old security policy stored in the kernel is not deleted during the update process. This ensures that access control checks remain available during policy updates, effectively reducing the security window.

[0019] 2) Existing methods may encounter issues where errors during policy updates cause partial policy loading failures, potentially leading to inconsistencies between policies stored in memory and those recorded in user-level configuration files. This invention addresses this by using the RCU mechanism to atomically switch the security policy pointer from pointing to the old security policy structure to pointing to the new security policy structure, achieving atomic switching of policy data and ensuring the integrity and validity of policies in memory.

[0020] 3) Existing methods use non-atomic switching during policy switching, which can lead to access control check threads referencing old policy data that has been released or new policy data that has not been fully initialized, resulting in unpredictable access control check behavior. By using the RCU mechanism to atomically switch the security policy pointer from pointing to the old security policy structure to pointing to the new security policy structure, atomic switching of policy data is achieved, ensuring that the policy data referenced by the access control check thread remains intact and valid.

[0021] In this invention, the above-described technical solutions can be combined with each other to achieve more preferred combinations. Other features and advantages of this invention will be set forth in the following description, and some advantages may become apparent from the description or be learned by practicing the invention. The objects and other advantages of this invention can be realized and obtained from what is particularly pointed out in the description and drawings. Attached Figure Description

[0022] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts. Figure 1 This is a schematic diagram of a kernel security strategy zero-downtime hot update method provided in an embodiment of the present invention; Figure 2 This invention provides a schematic diagram of a shared memory mapping principle, illustrating the partition layout structure of shared memory and the mechanism for zero-copy data transfer between the user layer and the kernel through shared memory. Figure 3 This is a schematic diagram illustrating shared memory initialization and data filling / updating provided in an embodiment of the present invention. Figure 4 This is a schematic diagram illustrating the process of filling in error information in shared memory, as provided in an embodiment of the present invention. Figure 5 A timing diagram for RCU atomic policy switching provided in this embodiment of the invention illustrates the interaction process between the policy update thread and the access control check thread. Figure 6 This is a schematic diagram of a kernel security strategy zero-downtime hot update system architecture provided in an embodiment of the present invention, showing the main components of the user layer and the kernel and their data flow relationships. Detailed Implementation

[0023] Preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, which form part of this application and are used together with the embodiments of the present invention to illustrate the principles of the present invention, but are not intended to limit the scope of the present invention.

[0024] Terminology Definition 1. RCU (Read-Copy-Update) mechanism: A synchronization mechanism provided by the operating system kernel that allows multiple read ends to concurrently access a shared data structure while write ends can update the data structure, and read ends do not need to acquire locks. Key RCU operations involved in this invention include: (a) RCU atomic pointer update operation: The policy pointer is switched from the old policy atom to the new policy. Internally, a memory barrier instruction is used to ensure that the new policy data is fully visible before the pointer switch. (b) RCU protected pointer read operation: safely read the current policy pointer within the critical section of the RCU read end; (c) RCU grace period synchronization wait operation: wait for all read ends that have entered the critical section of the RCU read end to exit; (d) RCU Read End Critical Section: The code region marked by the entry and exit operations. RCU protected data read in this region will not be released before the end of the critical section.

[0025] 2. Shared memory: A virtual contiguous memory region allocated by the kernel through a dedicated memory allocation interface is mapped to the address space of user processes through a memory mapping mechanism, enabling zero-copy data transfer between the user layer and the kernel.

[0026] 3. Device file: The device file interface used in the operating system for interaction between the user layer and the kernel module; in this invention, it is used as the interaction channel for policy configuration data.

[0027] 4. Synchronous command submission: A synchronous call mechanism in which the user layer submits policy operation requests to the kernel through the control command interface. The kernel does not return until the request is processed and the response data is ready when the command returns.

[0028] 5. Policy pointer: A pointer to the currently effective policy data structure, protected by the RCU mechanism to ensure the atomicity of policy switching.

[0029] 6. State Machine Protocol: The transition rules between the request and response phases in the shared memory control header, used to ensure the timing consistency of data access between the user layer and the kernel.

[0030] 7. Zero-copy: Data is transferred between the user layer and the kernel without memory copying. Instead, shared memory mapping enables both parties to directly access the same physical memory.

[0031] 8. Poll mechanism: An I / O event notification mechanism provided by the operating system kernel, allowing user processes to asynchronously detect changes in the response status in shared memory without blocking. In this invention, it is used as an auxiliary means to synchronously submit commands, for user processes to asynchronously wait for the kernel to complete its processing response.

[0032] 9. mmap: A memory mapping system call provided by the operating system, which maps file or device memory to the virtual address space of a user process, allowing the process to directly access device memory through a memory pointer. In this invention, it is used to map the shared memory corresponding to a device file to the address space of a user process.

[0033] 10. VMA (Virtual Memory Area): A data structure in the operating system that describes a contiguous virtual address space of a process. In this invention, the VMA flag is set to prevent shared memory from being dumped to the kernel dump file or extended through system calls, thereby enhancing the security of shared memory.

[0034] To address the problems existing in the prior art, this invention provides a method and apparatus for zero-downtime hot update of kernel security policies. It achieves zero-copy policy data transfer between the user layer and the kernel by allocating shared memory through a dedicated memory allocation interface in the kernel and mapping it to the user layer via a memory mapping interface. The kernel processes requests synchronously by submitting commands, and after processing the request, the kernel writes the result to the shared memory response buffer and wakes up the waiting queue. The atomic switching of policy pointers is achieved through the RCU mechanism, ensuring that access control checks remain available and behavior is predictable during policy updates.

[0035] First Embodiment A specific embodiment of the present invention discloses a method for zero-downtime hot update of kernel security policies, such as... Figure 1 As shown, applied to the kernel, the method includes: S110: Create and register a device file, which provides a communication interface between user-level processes and the kernel.

[0036] In practice, during kernel initialization, devices are registered and device files (such as / dev / policy_shm) are created. / dev / policy_shm is a shared memory device file for policies, serving as the communication interface between user-level processes and the kernel. User-level policy configuration tools establish a channel by opening the device file, transferring security policy data from the user level to the kernel, where the kernel stores and applies the policies.

[0037] S120: In response to the user-level process's open operation on the device file, allocate independent shared memory for the process and map it to the user level.

[0038] In specific implementation, such as Figure 2 As shown, when a user-level process opens a device file (such as / dev / policy_shm) using a policy configuration tool, the kernel allocates a contiguous block of shared memory to that process via a dedicated memory allocation interface. When the policy configuration tool performs an mmap (memory mapping) call on the device file, the kernel mmap callback function maps the shared memory to the virtual address space of the user-level process through the memory mapping interface. The memory mapping interface automatically handles cases where physical pages are not contiguous, establishing a user-space page table mapping for each physical page corresponding to the kernel virtual address. The memory allocated by the dedicated memory allocation interface has the characteristics of page boundary alignment and automatically sets user-space access permission flags, allowing it to be safely mapped to user space through the memory mapping interface. Simultaneously, a memory region protection flag (VMA) is set for the shared memory to control the behavior attributes of the virtual memory region in the kernel, including access permissions, sharing semantics, memory management policies, and expansion behavior, preventing the shared memory from being dumped or expanded.

[0039] In some embodiments, such as Figure 2 As shown, the shared memory uses a partitioned layout structure, including a shared memory control header, a request buffer, and a response buffer. The shared memory control header area occupies a fixed memory page, while the sizes of the request and response buffers can be configured according to the actual policy scale.

[0040] In practice, after allocating shared memory, the kernel maps the starting address of that region to a shared memory control header. This header, stored at the beginning of the shared memory, manages request-response interactions between the user layer and the kernel, containing metadata information for both requests and responses. Then, the fields in the shared memory control header are initialized. Specifically, the shared memory control header includes multiple fields, which at least include: 1. Verification Identifier Field: Initialize and write a fixed magic number (e.g., 0x12345678) to verify the validity of shared memory, that is, to verify that the shared memory has been correctly initialized and prevent incorrect mapping; 2. Kernel Ready Status Flags Field: Sets the kernel ready status flags, initialized to 1, indicating that the shared memory is available for use by the user layer, ensuring that requests are submitted only after initialization is complete; 3. Process Identifier Field: Records the process ID for opening the device; 4. Shared memory creation timestamp field: Records the creation time of the shared memory; 5. Request status field: Implement a state machine: Idle → Pending → Processing → Idle, to prevent concurrent submissions from the same process; initialize the request status to Idle; 6. Response Status Field: The user layer uses poll to wait for the response phase to become ready, realizing synchronous / asynchronous notification; the response status is initialized to idle. 7. Preset Other Fields: Initialize to zero. Preset other fields may include: operation type (the kernel uses this to distribute requests to the corresponding policy handling function), request data length (used for boundary checks), sequence number (a pairing identifier between request and response, facilitating debugging and problem tracing), operation result (the kernel returns a success / error code, used by the user layer to determine whether the operation was successful), response data length (used to read valid data), error message length, and error message (an error description when the operation fails). This information will be filled in after subsequent security policy update requests are initiated and processed, which will be explained in detail later.

[0041] The request buffer stores policy request data, while the response buffer stores the security policy information requested.

[0042] In some embodiments, the mapping to the user layer also includes: The verification identifier field and the kernel ready status flag field of the initialization assignment are verified. If the verification fails, the initialization fails. If the verification passes, the user layer fills the shared memory control header and the request buffer according to the security policy update request.

[0043] Specifically, the validity of the shared memory control header is verified as follows: 1. Magic number check: Checks whether the magic number field in the control header is equal to a predefined constant value to confirm that the shared memory has been correctly initialized and has not been corrupted.

[0044] 2. Kernel Ready Flag Verification: Check whether the kernel ready flag has been set to ensure that the kernel has completed the initialization of shared memory and can respond to requests normally.

[0045] In some embodiments, it also includes: The kernel uses atomic counters to count the number of concurrent user-level processes to limit the maximum number of concurrent processes. Specifically, when a user-level process opens a device file, the atomic counter is incremented by 1, and an error is returned if the current count has reached the limit. When a user-level process closes a device file, the atomic counter is decremented by 1, and the shared memory is released to prevent memory resources from being exhausted.

[0046] S130: In response to a security policy update request submitted synchronously by a user-level process, request parameters and policy request data are read from the shared memory. A new security policy structure is constructed based on the request parameters and policy request data to store the new security policy data. The security policy pointer is atomically switched from pointing to the old security policy structure to pointing to the new security policy structure via the RCU mechanism. Before and during the atomic switch, access control checks are performed on resource access requests initiated by user-level processes to the kernel based on the old security policy structure. After the atomic switch, access control checks are performed on resource access requests initiated by user-level processes to the kernel based on the new security policy structure. After all access control checks based on the old security policy structure are completed, the space occupied by the old security policy structure is released, and the security policy update is completed.

[0047] In practice, after mapping is complete, user-level processes and the kernel exchange data through the same shared memory, eliminating the need for data copying. The user-level policy configuration tool can directly fill the request parameters into the shared memory control header via the user virtual address and write the policy request data to the request buffer. After filling in the request parameters and policy request data, the user layer uses the policy configuration tool to send a synchronous commit command to the kernel through the synchronous commit command interface, notifying the kernel to process the request, such as... Figure 2 As shown, the synchronous commit command is a synchronous call. The kernel will not return to the user layer until processing is complete. That is, after calling the synchronous commit command, the user-level process will enter a waiting queue and block until the kernel completes request processing and fills the response data. Only then will the call return (i.e., the synchronous commit command returns to the user layer), waking up the processes waiting for poll. User processes can also asynchronously detect subsequent changes in the response status in shared memory through the poll mechanism. The synchronous commit command itself does not directly contain the request parameters in the shared memory header area or the policy update request data in the request buffer. The purpose of this command is to notify the kernel: the data in shared memory is ready, please begin processing.

[0048] The request parameters include the operation type and the request data length; the kernel distributes the request to the corresponding policy processing function based on different operation types. Setting the request data length is used for boundary checks. Request parameters may also include a sequence number.

[0049] The policy update request data includes the specific content of the security policy to be updated, such as the policy rule name or other configuration information. Its data format corresponds to the operation type, and is constructed and written to the request buffer by the user-level policy configuration tool based on the actual policy change request data.

[0050] At this time, the information in the shared memory is as follows: Figure 3As shown, the shared memory control header (4KB) contains the following information: Magic number of the verification identifier field: 0x12345678, Kernel ready flag: 1, Request phase: Pending, Response phase: Idle, Operation type: 1 (assuming 1 represents "Add policy rule"), Request data length: 64, Sequence number: 12345, Operation result: 0, Response data length: 0, Error message length: 0, Error message: (empty). The request buffer (8MB) contains policy request data (64 bytes) {Policy ID: 5, Policy name: p1, Path: " / var / log", Permission bits: rwx}. The response buffer (64MB) contains policy request data (64 bytes) {Policy ID: 5, Policy name: p1, Path: " / var / log", Permission bits: rwx} (This is a query operation, hence the content; a detailed explanation of query operations will follow).

[0051] In some embodiments, reading request parameters and policy request data from the shared memory, and constructing a new security policy structure based on the request parameters and policy request data to store the new security policy data includes: The validity of the operation type and the length of the request data are verified. If both verifications pass, the corresponding policy processing function is called according to the operation type to read the policy request data from the shared memory, the new security policy data is determined based on the policy request data, and the new security policy data is stored in the new security policy structure. If any verification fails, the error information is written to the shared memory control header.

[0052] In practice, the operation type and request data length are validated: 1. Validate the operation type: Determine whether the operation type is within the predefined valid enumeration range (e.g., less than the maximum operation type value). If it is, it is valid; otherwise, it is invalid.

[0053] 2. Verify the length of the request data: Determine whether the length of the request data is greater than 0 and does not exceed the maximum capacity of the request buffer. If so, it is valid; otherwise, it is invalid.

[0054] Verification passed: The operation type is valid and the requested data length is legal. The kernel will continue with subsequent processing.

[0055] Verification failed: If any condition is not met, the verification fails. The kernel writes the error message to the error message field of the shared memory control header, sets the operation result to the corresponding error code, marks the response phase as ready and wakes up the waiting process, then synchronously submits the command and returns. The user layer can read the error message. At this time, the information in shared memory is as follows: Figure 4As shown, the magic number of the verification identifier field is 0x12345678, the kernel ready flag is 1, the request phase is idle, the response phase is ready, the operation type is 99 (invalid value entered by the user), the request data length is 64 (hypothetically), the sequence number is 12345, the operation result is -1 (ERR_INVALID_OP), the response data length is 0, the error message length is 25, and the error message is "Invalid operation type". The request buffer (8MB) remains unchanged and is not read by the kernel. The response buffer (64MB) is empty because it is not a query operation.

[0056] The technical advantages of using a shared memory mapping mechanism are as follows: (1) Zero-copy data transfer: The user layer directly writes the policy update request data to the shared memory request buffer, and the kernel reads directly from the request buffer. The response data is transferred in the same way. This avoids the overhead of copying user layer data to the kernel buffer through the kernel data copy function in the traditional method, reducing data transfer latency and memory usage.

[0057] (2) Data Consistency Guarantee: Only one copy of the data exists in shared memory, and the kernel can read it as soon as the user layer finishes writing. The request and response phases in the shared memory control header provide a clear state machine protocol, ensuring that the timing of data access by the user layer and the kernel is consistent. The state transition rules for the request status field and the response status field are as follows: After the user layer writes policy request data into shared memory, the request status field is changed from the idle state to the pending state; after the kernel reads the security policy update request, the request status field is changed from the pending state to the processing state; after the kernel completes the processing of the security policy update request, the response status field is changed from the idle state to the ready state, and the request status field is restored from the processing state to the idle state, indicating that the next request can be accepted; before the user layer initiates the next request, the response status field is restored from the ready state to the idle state. The synchronous submission command is a synchronous call, and the response data is ready when the command returns, so there is no timing race problem.

[0058] (3) Security: Access permissions for shared memory are controlled by device file permissions. By configuring device file access permissions (e.g., setting them to root-only read and write), access to shared memory by unauthorized users can be restricted. The dedicated memory allocation interface automatically sets the VMA access permission flag for allocated memory to prevent uninitialized kernel data from leaking into user space. At the same time, the maximum number of concurrent processes is limited by atomic counters to prevent memory resource exhaustion.

[0059] In practice, after successful verification, the kernel calls the corresponding policy processing function (i.e., performs request dispatch and processing) based on the operation type. The policy processing function reads policy request data from the shared memory request buffer and parses it into kernel data structures, executes specific policy operations (such as adding policy rules or modifying policy constraints), and then determines the new security policy data based on the data corresponding to these kernel data structures, storing the new security policy data in the new security policy structure. Each process has an independent I / O mutex to prevent multiple threads within the same process from concurrently calling synchronous submission commands, ensuring that requests from the same process are processed in order. During operation, the RCU mechanism protects policy data from concurrent access interference, allowing the access control check thread (running in the kernel) to still read policy data normally during policy updates. Different processes can concurrently submit policy operation requests through their own independent shared memory, and the kernel's policy processing function is responsible for ensuring the correctness of the policy data structure updates.

[0060] In practice, the corresponding strategy processing function is called according to the operation type, including: 1. When the operation type is "Policy rule addition", the policy rule addition processing function is called. This function parses the policy rule to be added (such as path, permission bits, etc.) from the request buffer and inserts it into the current security policy data.

[0061] 2. When the operation type is "policy rule deletion", the policy rule deletion processing function is called to remove the corresponding rule from the current security policy data according to the rule identifier in the request buffer.

[0062] This includes reading policy request data from the shared memory request buffer and parsing it into kernel data structures, including: The strategy processing function determines the predefined format of the request data based on the operation type, reads the data field by field from the request buffer according to the format, and performs necessary validity checks (such as field range, string length, etc.).

[0063] For example: For policy rule operations: fields include rule identifier, object path, permission mask, rule priority, etc. For policy constraint operations: fields include constraint type, threshold, list of constrained objects, etc.

[0064] Executing specific policy operations (such as adding policy rules, modifying policy constraints, etc.) includes: Add a new policy rule: The operation object is a specific access control rule (such as a subject, object, and permission triple). The policy processing function parses the components of the rule (such as subject identifier, object path, allow / deny permission bits, etc.) from the request buffer, inserts them into the current security policy structure (such as a rule linked list or rule hash table), and triggers a policy version number update so that the new rule takes effect for subsequent access control checks.

[0065] Modifying policy constraints: The operation targets the policy's constraints (such as time limits, quantity limits, separation of duties rules, etc.). The policy processing function parses the constraint type and constraint parameters from the request buffer and updates the constraint fields in the current security policy structure.

[0066] In some embodiments, the security policy structure stores security policy data (i.e., security policy rules), security policy version information, and access control results (i.e., caching a valid access control result so that when the access is initiated again without updating the policy, the access control result can be obtained quickly). The access control results are stored in the security policy structure in the form of a cache table. The cache table of the old security policy structure stores valid access control results, while the cache table of the new security policy structure is empty. When the new access control check fails to find the access control result in the cache table from the new security policy structure, it needs to query the security policy rules in the new security policy structure to perform access control checks and fill the cache table with the access control check results.

[0067] It is important to note that the access control result, as a member of the security policy structure, is protected by the RCU mechanism along with the policy data structure. After the security policy pointer atomically switches, the new access control check thread obtains the security policy pointer through an RCU protected pointer read operation, simultaneously acquiring the empty cache table in the new policy. The initial new access control check will proceed in the following order: 1. Cache table 2. Security policy rules. If no access control result is found in the cache table from the new security policy structure B (i.e., there is no access control check result corresponding to the access behavior in the cache table), the policy rules in the new security policy structure B must be queried and the cache table populated. This process is normal cache warm-up behavior and does not affect the correctness of the access control check. Since the cache table in the old policy is released with a delay along with the old policy by the RCU, check threads still in the critical section of the old policy's RCU read end can still use the old cache normally. When all old read ends exit, the old policy and its cache table are released together, eliminating the problem of cache inconsistency with the policy. This design, which incorporates the cache table as part of the policy structure and performs an atomic RCU switch along with the policy, avoids the complexity and consistency risks associated with an independent cache invalidation mechanism.

[0068] In practice, the pointer to the currently effective security policy is stored in the security policy state structure, which also stores the kernel's running state, including the full policy structure. This security policy pointer is protected by the RCU mechanism.

[0069] In practice, for operations involving updating the policy data structure (which includes all policy operations such as adding new policy rules and modifying policy constraints), the policy processing function completes the atomic switching of policies through the RCU mechanism: constructing a new security policy structure, calling the RCU atomic pointer update operation to atomically switch the policy pointer, calling the RCU grace period synchronization wait operation to wait for the old reader to exit, and releasing the old policy memory.

[0070] Specifically, RCU is a synchronization mechanism provided by the operating system kernel that allows multiple read ends to concurrently access a shared data structure while write ends update that data structure, and read ends do not need to acquire locks. This invention utilizes the RCU mechanism to achieve atomic switching of security policies, ensuring that access control checks remain available during policy updates.

[0071] The timing process of RCU atomic policy switching is as follows: Figure 5 As shown, the specific process is as follows: 1. The policy update thread constructs a new security policy structure B in the kernel. During the construction process, the old security policy structure A remains the currently effective policy, and all access control check threads still reference the old security policy structure A, so the system access control function is unaffected.

[0072] 2. After the new security policy structure B is constructed, the policy update thread calls the RCU atomic pointer update operation function to atomically switch the security policy pointer in the security policy state structure from pointing to the old security policy structure A to pointing to the new security policy structure B. Internally, the RCU atomic pointer update operation uses memory barrier instructions to ensure that all fields of the new policy data structure are visible to other CPUs before the pointer switch, guaranteeing the atomicity and visibility of the pointer switch.

[0073] 3. Before and during the switch of the security policy pointer, the old access control check thread that has entered the critical section of the RCU read end reads the security policy pointer in the security policy status structure through the RCU protected pointer read operation. At this time, the security policy pointer still points to the old security policy structure A and references the currently effective security policy data in the old security policy structure A.

[0074] During this transition, the old and new policies coexist, but each checking thread is able to reference a complete and valid policy, without referencing partially updated policy data.

[0075] 4. After the security policy pointer is switched, when a newly initiated access control check thread enters the RCU read-end critical section and reads the security policy pointer in the security policy status structure through the RCU protected pointer read operation, the security policy pointer points to the new security policy structure B, and then references the currently effective security policy data in the new security policy structure B.

[0076] 5. The policy update thread calls the RCU grace period synchronization wait operation function, waiting for all threads that have entered the RCU read-side critical section and are performing access control checks using the old security policy structure A to exit the critical section (i.e., calling the RCU read-side critical section exit operation). During this waiting period, the access control check function continues to operate normally without any interruption.

[0077] 6. Once all old access control check threads have finished executing, perform the RCU read-end critical section exit operation (i.e., old read end exits the critical section).

[0078] 7. The policy update thread receives the return of the RCU grace period synchronization wait operation function (indicating that the old data is no longer in use and can be released; it does not return specific content that needs to be called by subsequent operations). At this time, no thread in the system is referencing the old security policy structure A.

[0079] 8. The policy update thread calls the memory release operation to release the memory occupied by the old security policy structure A, and the policy update is complete. At this point, only the security policy structure B remains, and the security policy pointer points to the security policy structure B.

[0080] The technical advantages of using the RCU atomic strategy switching mechanism are as follows: (1) Zero-downtime update: During the policy update process, the access control check thread does not need to lock and wait, and can perform access control check operations concurrently. There is no security window in the system.

[0081] (2) Atomicity switching: The security policy pointer is atomically switched through the RCU atomic pointer update operation. Combined with the memory barrier instruction, the new policy data is fully visible before the pointer is switched, thus ensuring the atomicity of the policy switch.

[0082] (3) Data integrity guarantee: During the transition period, the old and new policies coexist. Each checking thread references a complete and valid policy data structure and will not reference partially updated policy data.

[0083] In practice, after the request is processed, the kernel writes the operation result (including: operation status code (success or predefined error code, such as invalid operation type, request data length exceeded, memory allocation failure, policy verification failed, etc.) and error description information (filling in the error message string when the operation fails) into the shared memory control header.

[0084] For query operations, the result also includes the response data length (indicating the number of bytes of valid data in the response buffer), which is also written to the shared memory control header. If query data (which refers to policy configuration information, such as the list of currently effective policy rules and policy constraints) is required, the response data is written to the response buffer, the response phase is marked as ready, and the request phase is restored to idle. If the user process previously waited for a response asynchronously via the poll mechanism, the kernel wakes up the process after the response is ready, the process returns from the poll call, and the synchronous commit command is returned to the user layer. The policy configuration tool reads the operation result from the shared memory control header, and reads the query data from the response buffer if needed.

[0085] After the operation is completed, the policy configuration tool can directly fill in the new operation type and request parameters in the shared memory control header to initiate the next policy operation.

[0086] In some embodiments, it also includes: In response to the security policy query request initiated by the user-level process, when there is no data in the response buffer of the shared memory, the user-level process is added to the waiting queue and the execution status of the user-level process is set to an interruptible sleep state. After writing the current security policy data into the response buffer, the user-level process in the waiting queue is woken up, causing the user-level process to return from the security policy query request.

[0087] In practice, the corresponding strategy processing function is called according to the operation type, and the following are also included: When the operation type is "policy query", the policy query processing function is called to retrieve the results from the current security policy data according to the query conditions in the request buffer and write the results to the response buffer.

[0088] In practice, the kernel maintains a wait queue head for each shared memory device file. When a process calls the poll system call and there is currently no ready response, the kernel places the process into the wait queue corresponding to that device file and puts it into an interruptible sleep state. Since each process shares memory independently, the wait queue typically only contains the current process that called poll (because different processes have their own shared memory instances and do not share the same wait queue). After the kernel completes request processing and marks the response stage as ready, the kernel wakes up the processes waiting in the wait queue through the poll mechanism. Then, the process returns from the security policy query request, synchronously submits the command back to the user layer, and reads the current security policy data from the response buffer.

[0089] Compared with existing technologies, the kernel security policy zero-downtime hot update method provided in this embodiment can achieve the following beneficial effects: 1) Existing methods require clearing the old policy before loading the new one during policy updates, resulting in a lack of effective access control protection during this gap. This invention addresses this issue by allocating shared memory through a kernel-dedicated memory allocation interface and mapping the shared memory to the virtual address space of user processes via a memory mapping interface. This allocates independent shared memory for the user layer and the kernel. The new security policy is placed in the shared memory, while the old security policy, stored in the kernel, is not deleted during the update process. This ensures that access control checks remain available during policy updates, effectively reducing the security window.

[0090] Meanwhile, compared with the socket transmission method of the existing overall replacement policy update method, the present invention adopts shared memory, with the user layer directly writing to the shared memory and the kernel directly reading it, eliminating data copy overhead and message fragmentation problems, realizing zero-copy policy data transfer between user space and kernel, reducing data transfer latency and memory consumption, while ensuring the timing consistency of data access between user space and kernel.

[0091] 2) Existing methods may encounter issues where errors during policy updates cause partial policy loading failures, potentially leading to inconsistencies between policies stored in memory and those recorded in user-level configuration files. This invention addresses this by using the RCU mechanism to atomically switch the security policy pointer from pointing to the old security policy structure to pointing to the new security policy structure, achieving atomic switching of policy data and ensuring the integrity and validity of policies in memory.

[0092] 3) Interaction based on synchronous command submission and state machine mechanism: The existing compile-loaded policy update method is an asynchronous process for policy loading. After the user layer triggers policy reloading, it cannot synchronously obtain the kernel processing result. This invention simplifies the interaction design between user space and kernel by synchronously submitting commands and synchronizing the request-response protocol. When the command returns, the result is ready, and the user layer can directly read the operation result and error information, effectively avoiding the timing competition problem between user space and kernel.

[0093] 4) Incremental policy operations reduce update overhead: Existing RCU-based security policy update methods using compile-and-load architecture employ a holistic policy replacement approach. Each update requires reloading the complete policy binary data into the kernel; even modifying a single policy rule necessitates transmitting and replacing the entire policy library. This invention supports incremental policy operations (adding, deleting, modifying, etc., of single policy rules). Different operations are distinguished by an operation type field, and only the changed parts are transmitted and updated, significantly reducing data transmission volume and update time, making it more suitable for applications requiring frequent policy updates.

[0094] 6) Existing methods use non-atomic switching during policy switching, which can lead to access control check threads referencing old policy data that has been released or new policy data that has not been fully initialized, resulting in unpredictable access control check behavior. This invention uses the RCU mechanism to atomically switch the security policy pointer from pointing to the old security policy structure to pointing to the new security policy structure, achieving atomic switching of policy data. Access control results are included as members of the policy data structure, protected and atomically switched along with the policy by the RCU mechanism. This ensures that the policy data referenced by the access control check thread remains intact and valid during policy updates, and that its behavior is predictable. Although existing compile-loaded policy update methods also use the RCU mechanism, this invention combines shared memory zero-copy and incremental policy operations to achieve end-to-end zero-downtime hot policy updates, while existing methods' overall replacement method and socket transmission still suffer from update delays and intermediate states.

[0095] 7) Independent shared memory per process, supporting multi-process concurrency: Existing compile-loaded policy update methods use global communication channels, and multiple processes operating on policies simultaneously require a user-level serialization mechanism. This invention allocates independent shared memory to each process, limits the maximum number of concurrent processes through atomic counters, and the kernel ensures the in-order processing of requests within the same process through independent I / O mutexes for each process. Different processes can submit policy operation requests concurrently without user-level involvement in concurrency control, simplifying policy management in multi-process scenarios.

[0096] Third Embodiment A specific embodiment of the present invention discloses a kernel security policy zero-downtime hot update device, applied to the kernel, comprising: The device module is used to create and register device files, which provide a communication interface between user-level processes and the kernel; in response to a user-level process opening the device file, it allocates independent shared memory for the process and maps it to the user layer. The request processing module is used to respond to security policy update requests synchronously submitted by user-level processes. It reads request parameters and policy request data from the shared memory, constructs a new security policy structure based on these parameters and data to store the new security policy data, and atomically switches the security policy pointer from pointing to the old security policy structure to pointing to the new one via the RCU mechanism. Before and during the atomic switch, access control checks are performed on resource access requests initiated by user-level processes to the kernel based on the old security policy structure. After the atomic switch, access control checks are performed on resource access requests initiated by user-level processes to the kernel based on the new security policy structure. Once all access control checks based on the old security policy structure are completed, the space occupied by the old security policy structure is released, and the security policy update is complete.

[0097] In practical implementation, this invention provides a kernel security policy zero-downtime hot update system. The system architecture is divided into two parts: a user layer and a kernel layer (i.e., the kernel layer). Figure 6 As shown. The system adopts a design where each process shares memory independently, supporting concurrent access by multiple processes.

[0098] The user layer includes a policy configuration tool, shared memory, and a synchronous commit command interface. After the policy configuration tool opens the device file, the kernel uses the mmap system call to map shared memory into the user process's virtual address space. It then fills in the shared memory control header and the request parameters from the request data within the header, writes the policy request data to the request buffer, and finally submits the request synchronously via the synchronous commit command interface. The synchronous commit command is a synchronous call; the kernel returns immediately after processing. The policy configuration tool can directly read the corresponding operation result from the shared memory control header and the queried response data from the response buffer.

[0099] The kernel includes a device module, a per-process context management module, and a request processing module (including a synchronous commit command processing module, a request dispatch processing module, and an RCU atomic policy switching module). When a user-level process opens a device file, the device module is triggered to allocate independent shared memory for each process through a dedicated memory allocation interface. The per-process context management module limits the maximum number of concurrent processes through an atomic counter. When a process opens a device file, the atomic counter is incremented by 1. If the current count has reached the limit, an error is returned. When a process closes a device file, the atomic counter is decremented by 1, and the shared memory of that process is released to prevent memory exhaustion. The synchronous commit command processing module supports synchronous commit commands. After a user process submits a request through this synchronous commit command interface, the kernel processes the request synchronously through the synchronous commit command processing module, dispatches the request according to the operation type, and the request dispatch processing module calls the corresponding policy processing function to process the request. After processing, the result is written to the shared memory response buffer with zero copy, and processes waiting in the waiting queue through the poll mechanism are woken up. The policy update operation is implemented by the RCU atomic policy switching module, which atomically switches the policy pointer from the old security policy structure to the new security policy structure. The security policy running state and the RCU-protected policy pointer are included in the security policy state structure.

[0100] The first embodiment and the system embodiment corresponding to the above method are based on the same principle, and their related parts can be referenced from each other and can achieve the same technical effect. For the specific implementation process, please refer to the first embodiment mentioned above, which will not be repeated here.

[0101] Second Embodiment A specific embodiment of the present invention discloses a method for zero-downtime hot update of kernel security policies, comprising: The kernel creates and registers device files, which provide a communication interface between user-level processes and the kernel. The user-level process opens the device file; In response to a user-level process's open operation on the device file, the kernel allocates independent shared memory for the process and maps it to the user layer; The user-level process writes the request parameters and policy request data into the shared memory and simultaneously submits a security policy update request. In response to a security policy update request submitted synchronously by a user-level process, the kernel reads the request parameters and policy request data from the shared memory, constructs a new security policy structure based on the request parameters and policy request data to store the new security policy data, and atomically switches the security policy pointer from pointing to the old security policy structure to pointing to the new security policy structure through the RCU mechanism. User-level processes send resource access requests to the kernel; Before and during the atomic switch, the kernel performs access control checks on the resource access requests based on the old security policy structure. After the atomic switch, the kernel performs access control checks on the resource access requests based on the new security policy structure. Once all access control checks based on the old security policy structure are completed, the kernel releases the space occupied by the old security policy structure, and the security policy update is complete.

[0102] Electronic device example: One specific implementation of this application discloses an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the steps of the kernel security policy zero-downtime hot update method in the method embodiment.

[0103] Examples of readable storage media: One specific implementation of this application discloses a non-transitory computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the kernel security policy zero-downtime hot update method in the method embodiment.

[0104] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware, and the program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.

[0105] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

Claims

1. A kernel security strategy for zero-downtime hot update, applied to the kernel, characterized in that, include: Create and register a device file, which provides a communication interface between user-level processes and the kernel; In response to a user-level process opening the device file, a separate shared memory is allocated to the process and mapped to the user layer; In response to a security policy update request submitted synchronously by a user-level process, request parameters and policy request data are read from the shared memory. A new security policy structure is constructed based on the request parameters and policy request data to store the new security policy data. The security policy pointer is atomically switched from pointing to the old security policy structure to pointing to the new security policy structure through the RCU mechanism. Before and during the atomic switch, access control checks are performed on resource access requests initiated by user-level processes to the kernel based on the old security policy structure. After the atomic switch, access control checks are performed on resource access requests initiated by user-level processes to the kernel based on the new security policy structure; once all access control checks based on the old security policy structure are completed, the space occupied by the old security policy structure is released, and the security policy update is complete.

2. The kernel security policy zero-downtime hot update method according to claim 1, characterized in that, The shared memory includes a shared memory control header, a request buffer, and a response buffer; The shared memory control header includes multiple fields, including at least: a verification identifier field, a kernel ready status flag field, a process identifier field, a shared memory creation timestamp field, a request status and response status field, and other preset fields; The request parameters for the security policy update request are stored in other preset fields; The request buffer is used to store policy request data; The response buffer is used to store the security policy information requested in the query.

3. The kernel security policy zero-downtime hot update method according to claim 2, characterized in that, Before mapping to the user layer, it also includes: The starting address of the shared memory is mapped to a shared memory control header, and the fields in the shared memory control header are initialized by assigning values. The verification identifier field and the kernel ready status flag field of the initialized data are verified. If the verification fails, the initialization fails. If the verification passes, the user layer fills the shared memory control header and the request buffer according to the security policy update request.

4. The kernel security policy zero-downtime hot update method according to claim 2, characterized in that, The request parameters include the operation type and the request data length; Read request parameters and policy request data from the shared memory, and construct a new security policy structure based on the request parameters and policy request data to store the new security policy data, including: The validity of the operation type and the length of the request data are verified. If both verifications pass, the corresponding policy processing function is called according to the operation type to read the policy request data from the shared memory, the new security policy data is determined based on the policy request data, and the new security policy data is stored in the new security policy structure. If any verification fails, the error information is written to the shared memory control header.

5. The kernel security policy zero-downtime hot update method according to claim 1, characterized in that, Also includes: Set the VMA flag for the shared memory to prevent the shared memory from being dumped or expanded.

6. The kernel security policy zero-downtime hot update method according to claim 1, characterized in that, The security policy structure stores security policy data, security policy version information, and access control results. The access control results are stored in the security policy structure in the form of a cache table. The cache table of the old security policy structure stores valid access control results, while the cache table of the new security policy structure is empty. When the new access control check fails to find the access control result in the cache table from the new security policy structure, it needs to query the security policy data in the new security policy structure to perform the access control check and fill the cache table with the access control check result.

7. The kernel security policy zero-downtime hot update method according to claim 2, characterized in that, Also includes: In response to the security policy query request initiated by the user-level process, when there is no data in the response buffer of the shared memory, the user-level process is added to the waiting queue and the execution status of the user-level process is set to an interruptible sleep state. After writing the current security policy data into the response buffer, the user-level process in the waiting queue is woken up, causing the user-level process to return from the security policy query request.

8. The kernel security policy zero-downtime hot update method according to claim 1, characterized in that, Also includes: The number of concurrent user-level processes is counted using atomic counters; the atomic counter is incremented by 1 when a user-level process opens a device file and decremented by 1 when a user-level process closes a device file. The shared memory is released when the user-level process closes the device file.

9. A kernel security strategy zero-downtime hot update method, characterized in that, include: The kernel creates and registers device files, which provide a communication interface between user-level processes and the kernel. The user-level process opens the device file; In response to a user-level process's open operation on the device file, the kernel allocates independent shared memory for the process and maps it to the user layer; The user-level process writes the request parameters and policy request data into the shared memory and simultaneously submits a security policy update request. In response to a security policy update request submitted synchronously by a user-level process, the kernel reads the request parameters and policy request data from the shared memory, constructs a new security policy structure based on the request parameters and policy request data to store the new security policy data, and atomically switches the security policy pointer from pointing to the old security policy structure to pointing to the new security policy structure through the RCU mechanism. User-level processes send resource access requests to the kernel; Before and during the atomic switch, the kernel performs access control checks on the resource access requests based on the old security policy structure. After the atomic switch, the kernel performs access control checks on the resource access requests based on the new security policy structure; after all access control checks based on the old security policy structure are completed, the kernel releases the space occupied by the old security policy structure, and the security policy update is complete.

10. A kernel security strategy zero-downtime hot update device, applied to the kernel, characterized in that, include: The device module is used to create and register device files, which provide a communication interface between user-level processes and the kernel. In response to a user-level process opening the device file, a separate shared memory is allocated to the process and mapped to the user layer; The request processing module is used to respond to security policy update requests submitted synchronously by user-level processes. It reads request parameters and policy request data from the shared memory, constructs a new security policy structure based on the request parameters and policy request data to store the new security policy data, and atomically switches the security policy pointer from pointing to the old security policy structure to pointing to the new security policy structure through the RCU mechanism. Before and during the atomic switch, access control checks are performed on resource access requests initiated by user-level processes to the kernel based on the old security policy structure. After the atomic switch, access control checks are performed on resource access requests initiated by user-level processes to the kernel based on the new security policy structure; once all access control checks based on the old security policy structure are completed, the space occupied by the old security policy structure is released, and the security policy update is complete.

Images