A container consumable resource discovery method based on engineering kernel tuning practice

Abstract

A container consumable resource discovery method based on engineering kernel tuning practice, aiming at the risk of resource depletion caused by container sharing host kernel, the kernel tuning parameters widely used in engineering practice are collected and mapped to specific kernel global resource variables; then combined with static analysis technology, the resources that can be reached by system call in non-privileged container environment, not isolated by namespace and can be continuously depleted are screened out, and verified in real container environment; compared with the traditional full code analysis method, the invention is aimed at high-risk real resources in the production environment, which excludes low-probability trigger items and paths that need privileges to access, significantly improves the accuracy and engineering applicability of risk identification, and provides quantifiable and verifiable basis for risk assessment, monitoring and reinforcement of container platform and stability guarantee.

Description

Technical Field

[0001] This invention belongs to the field of engineering kernel tuning technology, specifically involving a method for discovering container exhaustible resources based on engineering kernel tuning practices. Background Technology

[0002] With the popularization of cloud computing and microservice architecture, container technology has been widely used in server clusters and cloud platform environments. Containers adopt operating system-level virtualization mechanisms, and their operation is highly dependent on the host kernel, and they share various system resources in the kernel space with other containers on the same node [Hossein Aqasizade, Ehsan Ataie, Mostafa Bastam. 2024. Experimental Assessment of Containers Running on Top of Virtual Machines. arXiv:2401.07539. https: / / doi.org / 10.48550 / arXiv.2401.07539]. While this model significantly improves resource utilization, deployment efficiency, and operational flexibility, it also allows processes within containers to directly influence the usage status of host kernel resources to a certain extent, thereby introducing new stability and security risks at the kernel level [Omar Jarkas, Ryan Ko, Naipeng Dong, and RedowanMahmud. 2025. A Container Security Survey: Exploits, Attacks, and Defenses. ACM Comput. Surv. 57, 7, Article 170 (July 2025), 36 pages. https: / / doi.org / 10.1145 / 3715001].

[0003] In the Linux operating system, the kernel maintains a large number of system resources with global attributes, including but not limited to state tables and buffers in the network protocol stack, file descriptors and their global limits, kernel objects related to processes and threads, and resource pools maintained by various kernel subsystems (such as the connection tracking table nf_conntrack). These resources are usually managed uniformly by the kernel, and their capacity limits, allocation strategies, and reclamation behaviors are not fixed but are directly controlled by a series of kernel parameters. In engineering practice, these parameters are mainly configured through the sysctl interface and exposed as files in the / proc / sys / directory [The Linux Kernel Documentation. Documentation for / proc / sys — the Linux Kernel documentation. https: / / www.kernel.org / doc / html / latest / admin-guide / sysctl / ] and related paths, becoming the most commonly used and centralized entry point for kernel tuning.

[0004] From an engineering perspective, a significant portion of Linux kernel parameter tuning involves addressing the limits of consumable kernel resources. For example, insufficient configuration of file descriptor-related parameters can lead to "Too many open files" errors; improper network connection parameters can cause TCP connection establishment failures and connection tracking table exhaustion [W. Shen et al., "Towards Understanding and Defeating Abstract ResourceAttacks for Container Platforms," ​​in IEEE Transactions on Dependable and Secure Computing, vol. 22, no. 1, pp. 474-490, Jan.-Feb. 2025, doi: 10.1109 / TDSC.2024.3403920]. To avoid these issues, engineering practice typically involves increasing parameters such as fs.file-max, net.core.somaxconn, net.ipv4.tcp_max_syn_backlog, and net.netfilter.nf_conntrack_max to strengthen the available limits of these resources. This type of tuning behavior essentially redefines the availability boundaries of some global resources in the kernel.

[0005] In a containerized environment, the aforementioned kernel parameter configurations are not limited to a single container but apply uniformly to all containers on the same host machine. While processes within a container, as ordinary user-space processes, do not have the authority to directly modify kernel parameters, they can, within their legal permissions, repeatedly request and consume corresponding kernel resources by continuously triggering specific system call paths or kernel behaviors [Nanzi Yang, Wenbo Shen, Jinku Li, et al. 2021. Demons in the Shared Kernel: Abstract Resource Attacks Against OS-level Virtualization. In Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security (CCS '21), pp. 764–778]. When the reachability and exhaustibility of these resources lack systematic identification, their consumption behavior may be amplified across multiple containers, thereby affecting the normal operation of the host machine and other containers on the same node, leading to security risks such as decreased stability or even denial of service.

[0006] Therefore, from an engineering practice perspective, the widely existing set of kernel tuning parameters not only reflects the resource bottlenecks that the system is likely to encounter in actual operation, but also implicitly characterizes which kernel resources are capable of being continuously accessed and exhausted under the container shared kernel model. This reality provides a clear technical motivation and application foundation for the systematic identification and analysis of exhaustible kernel resources in container environments, starting from engineering kernel tuning practices.

[0007] Existing technical solutions: Yang et al. [Nanzi Yang, Wenbo Shen, Jinku Li, et al. 2021. Demons in the Shared Kernel: Abstract Resource Attacks Against OS-level Virtualization. In Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security (CCS '21), pp. 764–778] proposed the concept of abstract resources from the operating system kernel implementation level. They pointed out that under the Linux kernel-shared operating model, in addition to sharing physical resources such as CPU and memory, containers also share a large number of global states and internal data structures maintained by the kernel code. This work takes LinuxIR code as the analysis object, obtains a set of abstract resources through static analysis of resource allocation and reference relationships in the kernel, and verifies the feasibility of DOS attacks within containers through attack experiments. Building upon the work described above, subsequent research [W. Shenet al., "Towards Understanding and Defeating Abstract Resource Attacks for Container Platforms," ​​in IEEE Transactions on Dependable and SecureComputing, vol. 22, no. 1, pp. 474-490, Jan.-Feb. 2025, doi: 10.1109 / TDSC.2024.3403920] (2024) proposed a dynamic monitoring and constraint framework. Its core idea is to track resource allocation behavior in real time at the kernel level, dynamically associate resource consumption with specific container instances, and identify abnormal occupancy patterns based on this.

[0008] Existing technologies mainly rely on static analysis of kernel source code to identify potential resource points, without fully considering actual business operating environments and engineering practices. There are a large number of global variables and kernel objects in the kernel, many of which are rarely triggered in production environments or have a very small impact on system stability. Existing technologies cannot effectively distinguish between critical and secondary resources, and the scope of analysis is too broad. At the same time, the system analysis does not consider the impact of different container permissions on resource access in the application, which makes it difficult for some analysis results to reflect the real risks under non-privileged containers. Summary of the Invention

[0009] To overcome the shortcomings of the existing technologies, this invention provides a container exhaustible resource discovery method based on engineering kernel tuning practices. Starting from engineering operation and maintenance experience and kernel tuning practices, the method systematically collects and filters kernel resource configurations that are widely adjusted in actual production environments and are highly related to system stability as the analysis entry point. Based on this, combined with kernel static analysis, the method systematically identifies the reachability, exhaustibility, and permission constraints of relevant resources in a containerized environment. This allows the discovery of kernel resources that ordinary container processes can continuously reach and may exhaust under common deployment strategies, thereby affecting the host machine and the operation of other containers on the same node. This provides an engineering-verifiable basis for resource risk assessment and system hardening in container environments.

[0010] To achieve the above objectives, the technical solution adopted by the present invention is as follows: A method for discovering exhaustible resources in containers based on engineering kernel tuning practices is used to identify kernel resources that can be exhausted by non-privileged container processes and affect system stability in a containerized environment with a shared kernel, starting from kernel parameters adjusted in actual operation and maintenance to improve system stability; the method includes the following steps: Step 1: Collect and clean the knowledge information on engineering kernel tuning practices from cloud vendor operation and maintenance documents, technical community articles and engineering tuning guides to obtain kernel parameters that need to be adjusted due to system stability risks and have the nature of resource boundary hardening. Extract the set of kernel parameters that conform to the sysctl dot-matrix format as a candidate set of exhaustible resources. Step 2: Establish the mapping relationship between the sysctl point parameter in the candidate set of exhaustible resources and the Linux kernel global resource variable entities, and obtain the set of kernel global resource variable entities controlled by the parameter; Step 3: Perform multi-dimensional static analysis and filtering on the kernel global resource variable entity set.

[0011] Step 1 specifically includes: A set of query keywords with semantic similarity to "Linux kernel tuning" is preset, and web crawling technology is used to search and collect articles from relevant technical communities to obtain the original HTML documents; The original HTML document is cleaned in a structured manner, separating the main text from the code blocks and removing noise information; Kernel parameters in a document are identified using matching rules, which include the dotted fraction format of sysctl parameters and the directory path format. The extracted kernel parameters are standardized and uniformly converted into sysctl dotted format to form an initial candidate set of exhaustible resources.

[0012] In step 2, based on the complete path information of the sysctl dotted parameters in the candidate set, and combined with the directory hierarchy of ctl_table in the Linux kernel, the corresponding configuration item is located level by level to obtain the specific ctl_table structure, and its data pointer field is parsed to obtain the data object actually associated with the parameter. This object is then used as the Linux kernel global resource variable entity controlled by the parameter, thereby forming a set of kernel global resource variable entities.

[0013] The complete path information for the sysctl dot-matrix parameter is obtained using the following method: For each sysctl point parameter in the candidate set of exhaustible resources, perform path parsing to obtain its complete directory hierarchy information; The ctl_table structure is obtained using the following method: Combining the static definition information of the ctl_table structure in the Linux kernel and its directory hierarchy, the corresponding directory entries and leaf configuration entries are located level by level according to the complete path of the sysctl dotted parameters to determine the target ctl_table configuration entry and obtain the ctl_table structure; The actual data object associated with the parameter is obtained through the following method: Parse the data pointer field of the target configuration item to obtain the kernel data object that is actually associated with the parameter.

[0014] Step 3 specifically includes the following four stages, used to output the final set of resources that satisfy the conditions of "exhaustible", "system call reachable", "non-privileged container triggerable", and "non-namespace isolated": Phase 1: Determining Exhaustibility Based on LLVM IR, data flow analysis is performed on resource variables. Starting from the target resource variable, the def-use chain is traced to all instructions that use the variable to determine whether the variable simultaneously possesses growth semantics and comparison semantics. Growth semantics: If a variable or its derived fields participate in growth operations (such as add, inc, atomicrmw, etc.), it indicates that the variable may continue to accumulate during the execution process. Comparison semantics: If a variable or its derived fields are involved in a comparison operation (such as icmp, fcmp), and the comparison result is used in a conditional jump (br) control branch, it indicates that the variable has an upper limit or quota control. If a variable satisfies both of the above semantics, it is determined that it has the exhaustibility condition and is retained as an exhaustible kernel resource variable; otherwise, it is determined as an inexhaustible resource and is removed. Phase Two: System Call Reachability Analysis Starting with the resource operation functions associated with the aforementioned exhaustible resource variables, we enumerate all reachable call paths from the system call entry point to the target function based on the global call graph; we filter out resources that do not have valid call paths to ensure that the remaining resources can be triggered by user-mode system calls. Phase 3: Access Control and Isolation Checks For each intermediate function on a reachable call path, perform the following comprehensive checks to eliminate restricted resources: Namespace isolation analysis: Identify comparison instructions in resource modification functions and analyze whether their operands involve Linux namespace types; if so, traverse the control flow graph (CFG) branch paths to check for write operations on resource variables; if write operations exist and are controlled by namespace variables, then the resource is determined to be namespace isolated and removed. rlimit limit check: Identifies whether there are instructions within a function that read variables from fields of the struct rlimit or struct rlimit64 structure and participate in comparison; if the comparison result affects resource modification, it is determined that an rlimit limit exists, the resource is considered to be subject to per-user restrictions, and it is removed; Capability filtering: Identify whether there are calls to privilege checking functions (such as capable, has_capability, etc.) in the path; extract the capability parameter of the request; if the parameter does not belong to the container's default set of capabilities, use control flow graph (CFG) pruning techniques to simulate reachability under unprivileged paths; if the path is blocked, determine that the resource requires privileges to trigger and remove it. Phase Four: Output Results After the above three layers of filtering, the final list of exhaustible kernel resources that simultaneously meet the conditions of "exhaustable", "reachable by system call", "triggerable without privilege" and "non-namespace isolated" is output.

[0015] The container exhaustible resource discovery method based on engineering kernel tuning practices further includes: conducting resource consumption attack experiments on the resources in the final exhaustible kernel resource list in a container orchestration environment to verify their impact on the availability of other container services on the same node. The experimental verification specifically includes: Deploy attacker and victim containers in a controlled Kubernetes environment; For each type of exhaustible kernel resource obtained in step 3, design a corresponding resource consumption program (POC). The attacker continuously executes the resource-consuming procedure POC within the attacker's container to trigger resource consumption behavior; Simultaneously monitor the changes in the running status of the host machine and the victim container. If the victim container's related functions fail, become blocked, or experience a decline in performance indicators, or if the host machine exhibits observable anomalies such as abnormal logs, abnormal service exits, or resource allocation failures, then the resource is confirmed to be a container-exhaustible resource with actual risks.

[0016] A container exhaustible resource discovery system based on engineering kernel tuning practices includes: The kernel tuning practice knowledge acquisition module is responsible for collecting and cleaning commonly used kernel optimization practice documents, and outputting a candidate set of exhaustible resources in sysctl dot-matrix format. The data conversion module is used to map the exhaustible resource candidate set into a set of kernel global resource variable entities that are actually controlled by the parameter; The analysis module is used to analyze the exhaustibility and reachability of kernel resources and container triggering conditions, filter out resources that are isolated by mechanisms such as ulimit and namespace, cannot be triggered by non-privileged containers, or are unreachable by syscalls, and output the final resource set; The verification module is used to verify the impact of analysis results on other containers on the same host in a standard container orchestration environment, and to confirm the impact of the identified resources on system stability and service availability in a real container environment.

[0017] An electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the container exhaustible resource discovery method based on engineering kernel tuning practices.

[0018] A computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the container exhaustible resource discovery method based on engineering kernel tuning practices.

[0019] Compared with the prior art, the beneficial effects of the present invention are as follows: 1) This invention does not start from the full kernel source code to find a needle in a haystack, but uses the parameter set in the practice of kernel tuning in engineering as the analysis entry point, and limits the candidate space of kernel resource analysis accordingly. From the methodological level, it avoids indiscriminate scanning of the full kernel resources, and from the source, it narrows the candidate range to resource objects that are actually accessible and triggerable in engineering, avoiding noise and inoperability caused by an overly broad analysis target.

[0020] 2) This invention takes the actual running permissions of non-privileged containers as the premise of analysis. Based on the system call reachability analysis, it further identifies the permission gating conditions in the call path and systematically removes resource consumption paths that can only be triggered in privileged containers or host processes, so that the output results focus on the real exhaustible risks under the default container deployment strategy.

[0021] 3) This invention not only outputs analysis results of potentially exhaustible resources, but also verifies their impact on other containers on the same host in a standard container orchestration environment, ensuring that the findings have engineering verifiability and practical reference value.

[0022] In summary, existing technologies mostly perform full static extraction starting from the kernel implementation, resulting in a wide coverage of abstract resources. However, a significant portion of these resources have a low probability of triggering in real-world business scenarios and a weak impact on stability. This invention takes an engineering optimization approach, with candidate options naturally satisfying prior conditions that have been repeatedly discussed / adjusted in engineering and are strongly correlated with failure risks. This makes the final identification results more applicable and risk-oriented in production environments.

[0023] In a containerized environment, this invention further narrows the analysis target from theoretically reachable resource points to resource points that can be actually triggered by non-privileged containers and have an external impact, filtering out paths that depend on privileged prerequisites, and the output set of exhaustible resources more closely resembles the real container environment. Attached Figure Description

[0024] Figure 1 A diagram of the container architecture; Figure 2 This is a diagram of a traditional virtual machine architecture. Figure 3 This is a diagram of the overall architecture of the present invention; Figure 4 The tool identifies depletable resources and provides experimental results. Detailed Implementation

[0025] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments.

[0026] Appendix Figure 1 Container architecture diagram attached. Figure 2 The diagram illustrates the virtual machine architecture, showing that unlike traditional virtual machines which are based on hardware virtualization and each has its own independent kernel, the overall structure of this invention is as follows: Figure 3As shown, it consists of four modules: ① Engineering kernel tuning practice knowledge collection module, responsible for collecting and cleaning commonly used kernel optimization practice documents, and outputting a candidate set of exhaustible resources in sysctl dot-matrix format; ② Data conversion module, which maps the candidate set of exhaustible resources into the actual set of kernel global resource variable entities controlled by the parameter; ③ Analysis module: analyzes the exhaustibility and reachability of kernel resources and container triggering conditions, and filters resources isolated by mechanisms such as ulimit and namespace, resources that cannot be triggered by non-privileged containers, and resources that are unreachable by syscall; ④ Verification module: confirms whether the collected resources will affect the stability and service availability of the system in the container environment.

[0027] Explanation of the principle: The first part, the Engineering Kernel Tuning Practice Knowledge Acquisition Module, is used to obtain candidate resources from an engineering practice perspective. It collects data from cloud vendor operation and maintenance documents, technical community articles, and engineering tuning guidelines using a pre-defined keyword set as input sources. Next, the original HTML documents undergo structured cleaning, separating the main text from code blocks, removing irrelevant noise, and uniformly converting them into a structured format for storage. Based on this, kernel parameters appearing in the documents are automatically extracted. Matching rules are established for common dotted-part formats and directory path formats for sysctl parameters, and the extraction results are standardized. Finally, a set of kernel parameters conforming to the sysctl dotted-part format is output as the initial candidate set of exhaustible resources.

[0028] The second part, the data conversion module, establishes the correspondence between engineering tuning parameters and kernel resource entities. Taking the sysctl dotted parameters output in the first step as input, it extracts their last-level fields to form a set of parameter keywords. Combining this with the static information of the ctl_table structure in the Linux kernel, it locates the configuration items in the kernel that match the parameter keywords, further parses the associated data pointers, and maps them to the actual kernel global resource variables controlled by the parameters. This completes the conversion from engineering tuning parameters to kernel resource entities, and the mapped global resource variables are used as the output of this module.

[0029] The third part, the container reachability and exhaustibility analysis module, further filters the aforementioned kernel resources. Taking the global resource variable set output from the second part as input, it first performs semantic analysis on each resource variable in LLVM IR, tracing its data flow and comparison statements within kernel functions. If a variable participates in a comparison statement, it is determined to have quota / cap semantics and is considered a candidate for exhaustible resources. Next, starting with the resource operation functions associated with these candidate resources, it enumerates all reachable call paths from the system call entry point to the target function based on the global call graph, filtering resources unreachable by syscalls. Then, for intermediate functions on each reachable call path, it identifies comparison instructions in resource modification functions and analyzes whether their operands involve Linux Namespace types. If so, it traverses the control flow graph branch paths, checking for write operations on resource variables. If a write operation exists and is controlled by a Namespace variable, the resource is determined to be Namespace isolated and removed. Finally, it identifies whether functions on each call path read variables from structrlimit or struct rlimit64 structure fields and participate in comparison instructions. If the comparison result affects resource modification, rlimit is determined to exist. The system restricts resources by identifying those subject to per-user restrictions and removing them; it also identifies whether there are calls to privilege check functions in the path; it extracts the capability parameter of the request, and if the parameter does not belong to the container's default capability set, it uses control flow graph pruning techniques to simulate reachability under unprivileged paths; if the path is blocked, it determines that the resource requires privilege to trigger and removes it; and it outputs the final set of resources that meet the criteria of "exhaustive + syscall reachable + unprivileged triggerable + non-namespace isolated".

[0030] Finally, the experimental verification validated the analysis results at the engineering level. The verification module built attacker and victim containers in a controlled Kubernetes environment, designed corresponding resource consumption programs (POCs) for the selected kernel resources, continuously triggered resource consumption behavior in the attacker container, and synchronously observed the changes in the running status of the host machine and the victim container, thereby verifying the impact of the identified resources on system stability and service availability in a real container environment.

[0031] Through the collaborative work of the above modules, this invention achieves systematic identification and verification of exhaustible kernel resources in container environments, starting from engineering kernel tuning practices. Ultimately, it successfully discovered multiple types of exhaustible kernel resources in containers, such as PID idr, pty_count, and inode. After an attacker's container executes the corresponding POC, it can significantly impact the functional availability of the victim's container on the same host machine, as shown in Figure 4.Specifically, the PID (Process Identifier) ​​resource is used to allocate and manage process identifiers in the kernel. When this resource is exhausted, new process creation requests in the victim container cannot obtain new PIDs, causing repeated fork operations to fail and the success rate of new process creation to drop to 0%. The dirty ratio resource, associated with the dirty page ratio control resource, is used to adjust the proportion of memory occupied by dirty pages in the system and affects the page cache write-back process. When this resource is maliciously occupied, the I / O performance of the victim container drops by more than 90%, the write operation rate is significantly reduced, and normal I / O functions are severely affected. The random entropy resource is used to maintain the entropy reserve of the kernel random number pool. When this resource is insufficient, the / dev / random read operation in the victim container is blocked, and the acquisition of high-quality random numbers is blocked. The inode resource is used to maintain the metadata information of file and directory objects in the file system. When this resource is exhausted, file or directory creation operations in the victim container fail, further affecting the normal operation of services that depend on the file system. The nr_files resource is used to limit the number of file objects that can be allocated system-wide. When this resource is exhausted, file creation or file opening operations in the victim container fail. pty_count The `netns_ct->count` resource is used to record the number of pseudo-terminals occupied in the system. When this resource is full, new SSH connection establishments are rejected. The `netns_ct->count` resource is used to maintain the number of connection tracking entries in the network namespace. When this resource is heavily consumed, the network latency of the victim container increases significantly, accompanied by increased packet loss, and `dmesg` continuously outputs "table full, dropping packet" log information. The `aio_nr` resource is used to count the number of currently allocated asynchronous I / O requests in the system. When this resource is exhausted, AIO request requests within the container fail, causing applications that rely on asynchronous I / O to be unable to request new asynchronous I / O, resulting in performance degradation. The `tcp_mem` resource controls the memory range available for the TCP protocol stack. When this resource is consumed to the high threshold, the TCP transmission rate of other containers on the same host and the host machine decreases significantly; in experiments, the wget download speed decreased by approximately 90%. The `udp_mem` resource controls the memory range available for the UDP protocol stack. When this resource is continuously consumed, other containers on the same host machine receive UDP... The packet loss rate during data transmission reaches approximately 90%.

[0032] The experimental results above demonstrate that, on the one hand, the present invention can automatically identify real, depletable kernel resources that can be triggered by containers from engineering practice; on the other hand, it can verify the significant impact of these resources on the availability of victim container services, network communication capabilities, file system operation capabilities, and system stability after being maliciously consumed by the attacked container. This illustrates the effectiveness and practical value of the present invention in the discovery of kernel resource risks in container environments.

Claims

1. A method for discovering exhaustible resources in containers based on engineering kernel tuning practices, used to identify kernel resources that can be exhausted by non-privileged container processes and affect system stability in a containerized environment with a shared kernel; characterized in that, Includes the following steps: Step 1: Collect and clean the knowledge information on engineering kernel tuning practices from cloud vendor operation and maintenance documents, technical community articles and engineering tuning guides to obtain kernel parameters that need to be adjusted due to system stability risks and have the nature of resource boundary hardening. Extract the set of kernel parameters that conform to the sysctl dot-matrix format as a candidate set of exhaustible resources. Step 2: Establish the mapping relationship between the sysctl point parameter in the candidate set of exhaustible resources and the Linux kernel global resource variable entities, and obtain the set of kernel global resource variable entities controlled by the parameter; Step 3: Perform multi-dimensional static analysis and filtering on the kernel global resource variable entity set, and output the final resource set that meets the four conditions of "exhaustible", "reachable by system call", "triggerable by non-privileged container" and "non-namespace isolated".

2. The method according to claim 1, characterized in that, Step 1 specifically includes: A set of pre-defined query keywords with semantic similarity to "Linux kernel tuning" is used, and web crawling technology is used to search and collect articles from relevant technical communities to obtain the original HTML documents; The original HTML document is cleaned in a structured manner, separating the main text from the code blocks and removing noise information; Kernel parameters in a document are identified using matching rules, which include the dotted fraction format of sysctl parameters and the directory path format. The extracted kernel parameters are standardized and uniformly converted into sysctl dotted format to form an initial candidate set of exhaustible resources.

3. The method according to claim 1, characterized in that, In step 2, based on the complete path information of the sysctl dotted parameters in the candidate set, and combined with the directory hierarchy of ctl_table in the Linux kernel, the corresponding configuration item is located level by level to obtain the specific ctl_table structure, and its data pointer field is parsed to obtain the data object actually associated with the parameter. This object is then used as the Linux kernel global resource variable entity controlled by the parameter, thereby forming a set of kernel global resource variable entities.

4. The method according to claim 1 or 3, characterized in that, The complete path information for the sysctl dot-matrix parameter is obtained using the following method: For each sysctl point parameter in the candidate set of exhaustible resources, perform path parsing to obtain its complete directory hierarchy information; The ctl_table structure is obtained using the following method: Combining the static definition information of the ctl_table structure in the Linux kernel and its directory hierarchy, the corresponding directory entries and leaf configuration entries are located level by level according to the complete path of the sysctl dotted parameters to determine the target ctl_table configuration entry and obtain the ctl_table structure; The actual data object associated with the parameter is obtained through the following method: Parse the data pointer field of the target configuration item to obtain the kernel data object that is actually associated with the parameter.

5. The method according to claim 1, characterized in that, Step 3 specifically includes the following four stages: Phase 1: Determining Exhaustibility Based on LLVM IR, data flow analysis is performed on resource variables. Starting from the target resource variable, all instructions that use the variable are traced along its def-use chain. It is determined whether the variable has both growth semantics and comparison semantics. If so, it is determined that it has the exhaustibility condition and is retained as an exhaustible kernel resource variable; otherwise, it is determined as an inexhaustible resource and is removed. Phase Two: System Call Reachability Analysis Starting with the resource operation functions associated with the aforementioned exhaustible resource variables, enumerate all reachable call paths from the system call entry point to the target function based on the global call graph; Filter out resources that do not have a valid call path, and ensure that the remaining resources can be triggered through user-space system calls; Phase 3: Access Control and Isolation Checks For each intermediate function on a reachable call path, perform the following comprehensive checks to eliminate restricted resources: Namespace isolation analysis: Identify comparison instructions in resource modification functions and analyze whether their operands involve Linux namespace types; if so, traverse the control flow graph branch paths to check for write operations on resource variables; if write operations exist and are controlled by namespace variables, then the resource is determined to be isolated by namespace and is removed. rlimit limit check: Identifies whether there are instructions within a function that read variables from fields of the struct rlimit or struct rlimit64 structure and participate in comparison; if the comparison result affects resource modification, it is determined that an rlimit limit exists, the resource is considered to be subject to per-user restrictions, and it is removed; Privilege check filtering: Identify whether there are calls to privilege check functions in the path; extract the capability parameter of the request, and if the parameter does not belong to the container's default capability set, use control flow graph pruning techniques to simulate reachability under unprivileged paths; If the path is blocked, the resource is determined to require privileges to trigger and is therefore removed. Phase Four: Output Results After the above three layers of filtering, the final list of exhaustible kernel resources is output, which simultaneously satisfies the conditions of "exhaustive", "system call reachable", "non-privileged triggerable", and "non-namespace isolated".

6. The method according to claim 5, characterized in that, The growth semantics: If a variable or its derived field participates in a growth operation, it indicates that the variable may continue to accumulate during the execution process; The comparison semantics: If a variable or its derived field participates in a comparison operation, and the comparison result is used for a conditional jump control branch, it indicates that the variable has an upper limit or quota control.

7. The method according to claim 1, characterized in that, Also includes: For the resources in the final list of exhaustible kernel resources, a resource consumption attack experiment was conducted in a container orchestration environment to verify its impact on the availability of other container services on the same node. The experimental verification specifically includes: Deploy attacker and victim containers in a controlled Kubernetes environment; For each type of exhaustible kernel resource obtained in step 3, design a corresponding resource consumption program (POC). The attacker continuously executes the resource-consuming procedure POC within the attacker's container to trigger resource consumption behavior; Simultaneously monitor the changes in the operating status of the host machine and the victim container. If the victim container's related functions fail, become blocked, or its performance indicators decline, or if the host machine exhibits observable anomalies, then the resource is confirmed as a container-depletable resource with actual risk.

8. A container exhaustible resource discovery system based on engineering kernel tuning practices, used to implement the method according to any one of claims 1 to 7, characterized in that, include: The kernel tuning practice knowledge acquisition module is responsible for collecting and cleaning commonly used kernel optimization practice documents, and outputting a candidate set of exhaustible resources in sysctl dot-matrix format. The data conversion module is used to map the exhaustible resource candidate set into a set of kernel global resource variable entities that are actually controlled by the parameter; The analysis module is used to analyze the exhaustibility and reachability of kernel resources and container triggering conditions, filter out resources that are isolated by mechanisms such as ulimit and namespace, cannot be triggered by non-privileged containers, or are unreachable by syscalls, and output the final resource set; The verification module is used to verify the impact of analysis results on other containers on the same host in a standard container orchestration environment, and to confirm the impact of the identified resources on system stability and service availability in a real container environment.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 7.

Images