A method, apparatus, device, and storage medium for loading a dynamic library.

Abstract

This disclosure provides a method, apparatus, device, and storage medium for loading dynamic libraries. The method includes: receiving a loading request for a target executable file; verifying the target executable file; if the target executable file passes verification, loading the target executable file into memory; reading the dynamic linker from the target executable file in memory; verifying the dynamic linker; if the dynamic linker passes verification, loading the dynamic linker into memory; and controlling the dynamic linker to start in memory. The dynamic linker is used to verify a hijacked dynamic library; if the hijacked dynamic library passes verification, loading the hijacked dynamic library into memory; the target executable file is used to call the hijacked dynamic library to verify the original dynamic library; and when the original dynamic library passes verification, it calls the hijacked dynamic library to load the original dynamic library into memory. Therefore, the embodiments of this disclosure can effectively prevent dynamic library escape.

Description

Technical Field

[0001] This disclosure relates to the field of data processing, and in particular to a method, apparatus, device, and storage medium for loading dynamic libraries. Background Technology

[0002] With the increasing complexity of software, especially with the widespread application of containerization technology, preventing dynamic library escape has become particularly important.

[0003] In related technologies, tenants can customize the search path of dynamic libraries by configuring ldconfig (dynamic linker runtime binding configuration) or setting the LD_LIBRARY_PATH (dynamic linker search path) environment variable to meet the needs of custom executable files.

[0004] However, custom configurations of dynamic libraries can cause executables to bypass the original hijacking dynamic libraries. For example, if the original hijacking dynamic library is a resource-limited hijacking dynamic library, the custom configuration of the dynamic library will prevent the resource-limited hijacking dynamic library from hijacking the application interfaces called in the executable file, causing the dynamic library to escape. Therefore, how to prevent dynamic library escape has become a technical problem that urgently needs to be solved. Summary of the Invention

[0005] To address the aforementioned technical problems, this disclosure provides a method, apparatus, device, and storage medium for loading dynamic libraries.

[0006] Firstly, this disclosure provides a method for loading a dynamic library, the method comprising:

[0007] Receive a loading request for a target executable file, verify the target executable file, and if the target executable file passes the verification, load the target executable file into memory;

[0008] The dynamic linker in the target executable file in the memory is read and verified. If the dynamic linker passes the verification, the dynamic linker is loaded into memory.

[0009] The dynamic linker is controlled to start in the memory; wherein, the dynamic linker is used to find the hijacking dynamic library corresponding to the target executable file, and to verify the hijacking dynamic library. If the hijacking dynamic library passes the verification, the hijacking dynamic library is loaded into the memory. The dynamic linker is also controlled to start in the memory. The dynamic linker is used to refuse to load the original dynamic library, which is a dynamic library that the target executable file depends on at runtime. The target executable file is used to call the hijacking dynamic library to verify the original dynamic library, and when the original dynamic library passes the verification, it calls the hijacking dynamic library to load the original dynamic library into the memory.

[0010] In one optional implementation, the hijacking dynamic library includes an interface symbol value for the resource allocation function to be called by the target executable file. The target executable file is used to call the hijacking dynamic library to obtain the interface symbol value. The hijacking dynamic library is used to call the resource allocation function to allocate resources based on the interface symbol value when the sum of the amount of resources to be allocated corresponding to the resource allocation function and the amount of currently used resources of the container corresponding to the target executable file does not exceed the preset resource limit of the container.

[0011] In one optional implementation, the hijacking dynamic library does not include the interface symbol value of the resource allocation function to be called by the target executable file. The target executable file is used to call the hijacking dynamic library to obtain the interface symbol value of the resource allocation function from the original dynamic library. The hijacking dynamic library is used to call the resource allocation function to allocate resources based on the interface symbol value when the sum of the amount of resources to be allocated corresponding to the resource allocation function and the amount of currently used resources of the container corresponding to the target executable file does not exceed the preset resource limit of the container.

[0012] In one optional implementation, receiving a load request for a target executable file and verifying the target executable file includes:

[0013] Receive a load request for a target executable file, and verify the preset signature of the target executable file based on a preset first private key.

[0014] In one optional implementation, reading the dynamic linker from the target executable file in the memory and verifying the dynamic linker includes:

[0015] The dynamic linker in the target executable file in the memory is read, and the preset signature of the dynamic linker is verified based on the preset second private key.

[0016] In one optional implementation, the dynamic linker is provided with a preset third private key, which is used to verify the preset signature of the hijacked dynamic library.

[0017] In one optional implementation, the hijacking dynamic library is provided with a preset fourth private key, which is used to verify the preset signature of the original dynamic library.

[0018] Secondly, this disclosure provides a dynamic library loading device, the device comprising:

[0019] The receiving module is used to receive a loading request for a target executable file, verify the target executable file, and if the target executable file passes the verification, load the target executable file into memory.

[0020] The reading module is used to read the dynamic linker in the target executable file in the memory, verify the dynamic linker, and if the dynamic linker passes the verification, load the dynamic linker into memory.

[0021] A control module is used to control the dynamic linker to start in the memory; wherein, the dynamic linker is used to find the hijacking dynamic library corresponding to the target executable file, and verify the hijacking dynamic library. If the hijacking dynamic library passes the verification, the hijacking dynamic library is loaded into the memory. The dynamic linker is also used to control the target executable file to start in the memory. The dynamic linker is used to refuse to load the original dynamic library, which is a dynamic library that the target executable file depends on at runtime. The target executable file is used to call the hijacking dynamic library to verify the original dynamic library, and if the original dynamic library passes the verification, it calls the hijacking dynamic library to load the original dynamic library into the memory.

[0022] Thirdly, this disclosure provides a computer-readable storage medium storing instructions that, when executed on a terminal device, cause the terminal device to implement the above-described method.

[0023] Fourthly, this disclosure provides a dynamic library loading device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the above-described method.

[0024] Fifthly, this disclosure provides a computer program product comprising a computer program / instruction that, when executed by a processor, implements the method described above.

[0025] The technical solution provided in this disclosure has at least the following advantages compared with the prior art:

[0026] This disclosure provides a method for loading a dynamic library. The method receives a loading request for a target executable file, verifies the target executable file, and if the verification passes, loads the target executable file into memory. It then reads the dynamic linker from the target executable file in memory, verifies the dynamic linker, and if the verification passes, loads the dynamic linker into memory and controls its startup in memory. Specifically, the dynamic linker is used to locate and verify the hijacking dynamic library corresponding to the target executable file. If the hijacking dynamic library verification passes, it loads the hijacking dynamic library into memory and controls the startup of the target executable file in memory. The dynamic linker is also used to refuse to load the original dynamic library, which is a dynamic library that the target executable file depends on at runtime. The target executable file uses the hijacking dynamic library to verify the original dynamic library, and if the original dynamic library verification passes, it calls the hijacking dynamic library to load the original dynamic library into memory. As can be seen, the multi-level verification method of this disclosure, from the operating system kernel to the dynamic linker, from the dynamic linker to the hijacked dynamic library, and from the hijacked dynamic library to the original dynamic library, can effectively prevent dynamic library escape. Attached Figure Description

[0027] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure.

[0028] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, those skilled in the art can obtain other drawings based on these drawings without creative effort.

[0029] Figure 1 A flowchart illustrating the executable file loading and execution process provided in this embodiment of the disclosure;

[0030] Figure 2 A flowchart illustrating a method for loading a dynamic library as provided in this embodiment of the disclosure;

[0031] Figure 3 A flowchart illustrating another method for loading a dynamic library as provided in this embodiment of the disclosure;

[0032] Figure 4 A flowchart illustrating yet another method for loading a dynamic library as provided in this embodiment of the disclosure;

[0033] Figure 5A schematic diagram of a dynamic library loading device provided in an embodiment of this disclosure;

[0034] Figure 6 This is a schematic diagram of the structure of a dynamic library loading device provided in an embodiment of the present disclosure. Detailed Implementation

[0035] To better understand the above-mentioned objectives, features, and advantages of this disclosure, the solutions disclosed herein will be further described below. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0036] Numerous specific details are set forth in the following description in order to provide a full understanding of this disclosure, but this disclosure may also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only some, and not all, of the embodiments of this disclosure.

[0037] In cloud computing scenarios, resources exist in the form of resource pools and are allocated and scheduled on demand according to reasonable strategies. These resources include, but are not limited to, central processing unit (CPU) resources, memory resources, disk resources, and other input / output (I / O) peripheral resources. Common resource quota schemes include Linux kernel control groups, file system quota capabilities, and dynamic library function hijacking. Cloud providers allocate equivalent resources to provide services based on the tenant's actual purchase.

[0038] Operating systems and container images contain a large number of executable files and dynamic libraries. These dynamic libraries provide a unified application programming interface for applications and can interact with the operating system kernel and hardware devices.

[0039] For a more detailed description of the loading and execution process of executable files, please refer to [reference needed]. Figure 1 This is a flowchart illustrating the executable file loading and running process provided in an embodiment of this disclosure, as shown below. Figure 1 As shown, at the beginning of executable file execution, the operating system kernel first loads the executable file into memory. After the executable file is loaded into memory, the operating system kernel continues to load the dynamic linker specified by the executable file into memory and jumps to the dynamic linker to start execution (that is, the operating system kernel gives control to the dynamic linker). The dynamic linker loads the dynamic libraries into memory according to the dynamic library table that the executable file depends on, and then jumps to the entry point of the executable file to execute (that is, the dynamic linker gives control to the executable file). Thus, the loading and running of the executable file is completed. The loading and running process of the executable file is the same in the container.

[0040] The operating system kernel provides interfaces to applications through dynamic libraries. These interfaces can be used to allocate device memory, execute programs on the device to use its computing resources, and so on. Hardware manufacturers provide dynamic libraries that applications can call. For example, NVIDIA's CUDA (Compute Unified Device Architecture) / NVML (NVIDIA Management Library) dynamic libraries provide interfaces for NVIDIA graphics processing units (GPUs).

[0041] In cloud scenarios, a large number of container groups (Pods) run within a Kubernetes cluster, and each Pod typically does not consume the full amount of device resources. This means that during the Pod startup process, Kubernetes needs to allocate device resource quotas to the Pod based on resource allocation conditions.

[0042] The resource quota-based solution using dynamic libraries relies on dynamic library hijacking. In a containerized environment, the hijacked dynamic library is mounted to the container's dynamic library lookup path during container startup. When an executable that depends on the hijacked dynamic library is executed, the hijacked dynamic library is loaded. This hijacked dynamic library implements all the application programming interfaces (APIs) of the original dynamic library, including resource limiting algorithms and hooks to these APIs. When these APIs are invoked, the system first checks if the hijacked dynamic library has already loaded the APIs from the original dynamic library. If not, it loads the symbol values ​​of these APIs and assigns them to the hook functions of the hijacked dynamic library. Then, based on the current process or container's hardware resource usage, the quota algorithm is invoked. If the specified resource limit is exceeded, no new resources are allocated; otherwise, allocation is successful.

[0043] This dynamic library hijacking scheme can be applied to limit the resources of NVIDIA graphics processors in Kubernetes clusters. For example, if an NVIDIA graphics processor has 8GB of video memory, by hijacking the cuMemAlloc library function, the allocated memory can be counted, thereby implementing a memory allocation limit. In this way, resources can be allocated to users based on their actual payment situation.

[0044] Based on the above description, by hijacking dynamic libraries, the original dynamic library functions can be modified to achieve resource quota functionality. In this process, the dynamic library is loaded into memory by the dynamic linker. For example, the dynamic linker / loader of the GNU C standard library, ld.so (usually / lib64 / ld-linux-x86-64.so.2 on x86_64 architecture), will find the matching dynamic library in the dynamic linker's search path LD_LIBRARY_PATH based on the executable file's dependencies and load it into memory.

[0045] In summary, tenants can customize the dynamic library search path by configuring ldconfig (dynamic linker runtime binding configuration) or by setting the LD_LIBRARY_PATH environment variable, such as... Figure 2 As shown, this allows the application to use any dynamic library that can be loaded normally, thus preventing the resource quota hijacking dynamic library from hijacking the application interface called in the executable file, resulting in dynamic library escape. In real-world applications, if a tenant specifies that a dynamic library can use the full amount of resources when using a Pod, then the tenant will spend less money to use more resources. Therefore, how to prevent dynamic library escape has become a technical problem that urgently needs to be solved.

[0046] To prevent dynamic libraries from escaping, this disclosure provides a method for loading dynamic libraries.

[0047] Specifically, the system receives a load request for a target executable file, verifies the target executable file, loads it into memory if the verification passes, reads the dynamic linker from the target executable file in memory, verifies the dynamic linker, loads it into memory if the verification passes, and controls the startup of the dynamic linker in memory. The dynamic linker is used to locate the hijacking dynamic library corresponding to the target executable file, verify the hijacking dynamic library, load the hijacking dynamic library into memory if the verification passes, and control the startup of the target executable file in memory. The dynamic linker is also used to refuse to load the original dynamic library, which is the dynamic library that the target executable file depends on at runtime. The target executable file calls the hijacking dynamic library to verify the original dynamic library, and if the original dynamic library passes verification, calls the hijacking dynamic library to load the original dynamic library into memory. The embodiments disclosed herein employ a multi-level verification method, from the operating system kernel to the dynamic linker, from the dynamic linker to the hijacked dynamic library, and from the hijacked dynamic library to the original dynamic library, which can effectively prevent dynamic library escape.

[0048] Based on this, the present disclosure provides a method for loading a dynamic library, referencing... Figure 3The flowchart illustrates another method for loading a dynamic library provided in this disclosure, the method comprising:

[0049] S301: Receive a loading request for the target executable file, verify the target executable file, and if the target executable file passes the verification, load the target executable file into memory.

[0050] The dynamic library loading method provided in this disclosure can be applied to the operating system kernel. The operating system can be a UNIX system or a Windows operating system, and this disclosure does not limit it in any way.

[0051] Accordingly, the target executable file has a different file format for different operating systems. For example, the UNIX system corresponds to the UNIX ELF (Executable and Linkable Format) format, and the Windows operating system corresponds to the Windows PE (Portable Executable) format.

[0052] Taking the container orchestration engine Kubernetes as an example, the target executable file can be an application running in any container in the Kubernetes environment.

[0053] It should be noted that the embodiments disclosed herein do not impose any limitations on the container orchestration engine.

[0054] Specifically, the operating system kernel can verify the target executable file in the following ways.

[0055] In one optional implementation, a loading request for a target executable file is received, and a preset signature of the target executable file is verified based on a preset first private key.

[0056] In this embodiment of the disclosure, the operating system kernel is configured with a preset first private key, which is used to verify the preset signature of the target executable file. If the preset signature of the target executable file can be verified by the preset first private key, it indicates that the target executable file has passed the verification.

[0057] In another alternative implementation, the target executable file can also be verified using a hash check.

[0058] In this embodiment of the disclosure, the operating system kernel can compare the hash value of the target executable file with a preset hash value by calculating the hash value of the target executable file. If the comparison is successful, it indicates that the target executable file has passed verification.

[0059] It should be noted that the above is only an example, and the embodiments disclosed herein do not limit the method by which the operating system kernel verifies the target executable file.

[0060] In this embodiment of the disclosure, after the target executable file passes verification, the operating system kernel first reads the header information of the target executable file, including the format, entry point, location and size of the code segment and data segment of the target executable file. Then, the operating system kernel allocates space in memory for each segment (such as the code segment and data segment) of the target executable file, so that the code segment and data segment of the target executable file can be loaded into the allocated space in memory.

[0061] In this embodiment of the disclosure, if the target executable file fails verification, loading is refused.

[0062] S302: Read the dynamic linker from the target executable file in memory, verify the dynamic linker, and if the dynamic linker passes the verification, load the dynamic linker into memory.

[0063] The dynamic linker, also known as the dynamic link library loader, is used to parse and load the target executable file to determine the dynamic libraries within it.

[0064] Specifically, the operating system kernel can verify the dynamic linker in the following ways.

[0065] In one alternative implementation, the dynamic linker in the target executable file in memory is read, and the preset signature of the dynamic linker is verified based on a preset second private key.

[0066] The preset second private key can be the same as the preset first private key mentioned above, meaning that the operating system kernel can set the same private key to verify the target executable file and dynamic linker.

[0067] In this embodiment of the disclosure, the operating system kernel is configured with a preset second private key, which is used to verify the signature preset by the dynamic linker. If the signature preset by the dynamic linker can be verified by the preset second private key, it indicates that the dynamic linker verification is successful.

[0068] If the verification fails, loading is refused, and the previously loaded target executable is released.

[0069] It should be noted that the operating system kernel can also verify the dynamic linker through hash verification. For details, please refer to the description of the operating system kernel's verification of the target executable file. This disclosure does not limit the operating system kernel's verification method for the dynamic linker.

[0070] S303: Controls the dynamic linker to start in memory.

[0071] The dynamic linker is used to find the hijacking dynamic library corresponding to the target executable file and verify the hijacking dynamic library. If the hijacking dynamic library passes the verification, it is loaded into memory, and the target executable file is controlled to start in memory. The dynamic linker is used to refuse to load the original dynamic library, which is the dynamic library that the target executable file depends on at runtime. The target executable file uses the hijacking dynamic library to verify the original dynamic library, and if the original dynamic library passes the verification, it calls the hijacking dynamic library to load the original dynamic library into memory.

[0072] In this embodiment of the disclosure, the operating system kernel controls the dynamic linker to start in memory, that is, the operating system kernel gives control to the dynamic linker.

[0073] In this embodiment of the disclosure, during the operation of the dynamic linker, the header information of the executable file is parsed. If the hijacking dynamic library corresponding to the target executable file is found, the dynamic linker can verify the hijacking dynamic library.

[0074] In one optional implementation, the dynamic linker is provided with a preset third private key, which is used to verify the preset signature of the hijacked dynamic library.

[0075] In this embodiment of the disclosure, the dynamic linker can verify the hijacked dynamic library through digital signature. Specifically, the dynamic linker can verify the preset signature of the hijacked dynamic library through a built-in preset third private key. If the preset signature of the hijacked dynamic library is successfully verified, it indicates that the hijacked dynamic library has passed the verification.

[0076] If the hijacked dynamic library verification passes, the dynamic linker loads the hijacked dynamic library into memory; if the hijacked dynamic library verification fails, the loaded target executable program and dynamic linker are released.

[0077] It should be noted that the dynamic linker can also verify the hijacked dynamic library through hash verification. For specific implementation methods, please refer to the description of the operating system kernel's verification of the target executable file. This disclosure does not limit the dynamic linker's verification method for the hijacked dynamic library.

[0078] To prevent tenants from tampering with the original dynamic library, the dynamic linker can be configured to refuse to load the original dynamic library.

[0079] In this embodiment of the disclosure, after the hijacking dynamic library is verified and loaded into memory by the dynamic linker, the target executable file is started in memory. In other words, the dynamic linker gives control to the target executable file.

[0080] During the execution of the target executable file, the target executable file can verify the original dynamic library by calling the hijacked dynamic library. When the original dynamic library is verified, the target executable file can call the hijacked dynamic library to load the original dynamic library into memory.

[0081] In one optional implementation, the hijacked dynamic library is equipped with a preset fourth private key, which is used to verify the preset signature of the original dynamic library.

[0082] In this embodiment of the disclosure, the hijacked dynamic library can verify the preset signature of the original dynamic library by using a built-in preset fourth private key. If the preset signature of the original dynamic library passes the verification, the original dynamic library is loaded into memory. If the preset signature of the original dynamic library fails the verification, loading is refused, and the loaded target executable file, dynamic linker, and hijacked dynamic library are released.

[0083] It should be noted that hijacking dynamic libraries can also verify the original dynamic library through hash verification or dynamic library whitelisting. For specific implementation methods, please refer to the description of the operating system kernel's verification of the target executable file.

[0084] refer to Figure 4 This is another flowchart of a dynamic library loading process provided in this embodiment of the disclosure, such as... Figure 4 As shown, in practical applications, taking the preset first private key and preset second private key as private key 1, the preset third private key as private key 2, the preset fourth private key as private key 3, the preset signature of the target executable file and the preset signature of the dynamic linker as signature 1, the preset signature of the hijacked dynamic library as signature 2, and the preset signature of the original dynamic library as signature 3 as an example, private key 1 can be set in the operating system kernel, and signature 1 can be set in the target executable file and the dynamic linker. Here, signature 1 is generated by private key 1. That is to say, when the signature set in the target executable file is signature 1, the target executable file can be verified by the private key 1 set in the operating system kernel. When the signature set in the dynamic linker is signature 1, the dynamic linker can be verified by the private key 1 set in the operating system kernel.

[0085] Private key 2 is set in the dynamic linker, and signature 2 is set in both the base dynamic library and the hijacking dynamic library. Signature 2 is generated by private key 2. In other words, when the signature set in the hijacking dynamic library is signature 2, the hijacking dynamic library can be verified by the private key 2 set in the dynamic linker. Similarly, when the signature set in the base dynamic library is signature 2, the base dynamic library can be verified by the private key 2 set in the dynamic linker.

[0086] The hijacked dynamic library sets private key 3, and the original dynamic library sets signature 3. Signature 3 is generated by private key 3. That is to say, when the original dynamic library sets signature 3, the original dynamic library can be verified by the hijacked dynamic library's private key 3. However, when the original dynamic library sets signature 3, it cannot be verified by the dynamic linker's private key 2, so it is refused to be loaded by the dynamic linker.

[0087] Through the above methods: the operating system kernel refuses to load unsigned or unverified target executable files and dynamic linkers; the dynamic linker refuses to load unsigned or unverified dynamic libraries (such as unsigned hijacked dynamic libraries or base dynamic libraries); and the hijacked dynamic library refuses to load unsigned or unverified original dynamic libraries.

[0088] It should be noted that the software installed in the container group is provided uniformly by the container group provider, and the software installed and compiled needs to be certified and signed.

[0089] After the target executable file, dynamic linker, hijacking dynamic library, and original dynamic library are all loaded into memory, when the hijacking dynamic library includes the interface symbol value of the resource allocation function to be called by the target executable file, the target executable file calls the hijacking dynamic library to obtain the interface symbol value. The hijacking dynamic library then calls the resource allocation function to allocate resources based on the interface symbol value when the sum of the amount of resources to be allocated corresponding to the resource allocation function and the amount of currently used resources of the container corresponding to the target executable file does not exceed the container's preset resource limit.

[0090] In this embodiment of the disclosure, if the hijacking dynamic library includes the interface symbol value of the resource allocation function to be called by the target customer consultation file, it indicates that the target executable file has called the hijacking dynamic library to obtain the interface symbol value of the resource allocation function from the original dynamic library.

[0091] Furthermore, the target executable file directly obtains the interface symbol value by calling the hijacking dynamic library. The hijacking dynamic library can then use a resource limiting algorithm to determine whether the sum of the amount of resources to be allocated by the resource allocation function and the amount of resources currently used by the container corresponding to the target executable file exceeds the container's preset resource limit. If the sum does not exceed the container's preset resource limit, the hijacking dynamic library can call the resource allocation function based on the interface symbol value to allocate resources. If the sum exceeds the container's preset resource limit, a resource overdraft warning will be displayed.

[0092] In one optional implementation, the hijacking dynamic library does not include the interface symbol value of the resource allocation function to be called by the target executable file. The target executable file is used to call the hijacking dynamic library to obtain the interface symbol value of the resource allocation function from the original dynamic library. The hijacking dynamic library is used to call the resource allocation function to allocate resources based on the interface symbol value when the sum of the amount of resources to be allocated corresponding to the resource allocation function and the amount of currently used resources of the container corresponding to the target executable file does not exceed the preset resource limit of the container.

[0093] Among them, the preset resource limit refers to the maximum amount of system resources (such as memory, storage space, etc.) that can be used in the container where the target executable file is located.

[0094] In this embodiment of the disclosure, if the hijacking dynamic library does not include the interface symbol value of the resource allocation function to be called by the target executable file, the target executable file can obtain the interface symbol value of the resource allocation function from the original dynamic library by calling the hijacking dynamic library. Similarly, the hijacking dynamic library can determine whether the sum of the amount of resources to be allocated corresponding to the resource allocation function and the amount of resources currently used by the container corresponding to the target executable file exceeds the container's preset resource limit by calling the resource allocation function. If it does not exceed the container's preset resource limit, the hijacking dynamic library can call the resource allocation function to allocate resources based on the interface symbol value. If it exceeds the container's preset resource limit, a resource overdraft message will be displayed.

[0095] In related technologies, resource quotas can be implemented by hijacking dynamic libraries, which can provide hardware resource quota mechanisms for Kubernetes clusters. However, users can escape by customizing dynamic libraries, thereby using the resources of the entire device or even performing dangerous operations that affect the operation of the entire device. The embodiments disclosed in this disclosure can effectively prevent the above behaviors through the "verification chain" mechanism, without consuming additional resources or affecting performance.

[0096] In the dynamic library loading method provided in this embodiment, a loading request for a target executable file is received, the target executable file is verified, and if the target executable file passes verification, the target executable file is loaded into memory. The dynamic linker in the target executable file in memory is read, and the dynamic linker is verified. If the dynamic linker passes verification, the dynamic linker is loaded into memory, and the dynamic linker is started in memory. The dynamic linker is used to find the hijacking dynamic library corresponding to the target executable file, verify the hijacking dynamic library, and if the hijacking dynamic library passes verification, load the hijacking dynamic library into memory and control the target executable file to start in memory. The dynamic linker is also used to refuse to load the original dynamic library, which is a dynamic library that the target executable file depends on at runtime. The target executable file calls the hijacking dynamic library to verify the original dynamic library, and if the original dynamic library passes verification, it calls the hijacking dynamic library to load the original dynamic library into memory. As can be seen, the multi-level verification method of this disclosure, from the operating system kernel to the dynamic linker, from the dynamic linker to the hijacked dynamic library, and from the hijacked dynamic library to the original dynamic library, can effectively prevent dynamic library escape.

[0097] In practical applications, the loading process for a target executable file includes the following steps:

[0098] 1. The operating system kernel executes the target executable file through system calls;

[0099] 2. The operating system kernel loads the target executable file and verifies it. If the target executable file is successfully verified, the required data segments and code segments are loaded into memory. If the verification fails, loading is refused.

[0100] 3. The operating system kernel reads the dynamic linker specified in the target executable file and verifies the dynamic linker. If the verification is successful, the dynamic linker is loaded into memory; if it fails, the loading is rejected and the loaded target executable program is released.

[0101] 4. The operating system kernel hands over control to the dynamic linker / loader (usually the address of the _start symbol);

[0102] 5. The dynamic linker / loader searches for the dynamic libraries that the executable file depends on in the dynamic library search path, and verifies the hijacked dynamic library and the base dynamic library. If the verification is successful, the hijacked dynamic library and the base dynamic library are loaded into memory, and necessary ELF (Executable and Linkable Format Relocation) relocation operations are performed; if the verification fails, loading is refused, the loaded target executable program and dynamic linker are released, and the program exits.

[0103] 6. The dynamic linker / loader transfers control to the target executable file (usually the address of the _start symbol), and then enters the main function;

[0104] 7. The target executable file begins to run normally;

[0105] 8. When the target executable file calls the hijacked dynamic library, the hijacked dynamic library will load the original dynamic library. During the process of the hijacked dynamic library loading the original dynamic library, the hijacked dynamic library also needs to verify the original dynamic library. If the verification fails, the program will exit. If the verification succeeds, the hijacked dynamic library will load the original dynamic library into memory.

[0106] As can be seen, through the above steps, by adding verification mechanisms for the target executable program and dynamic linker in the operating system kernel to verify reliable and secure applications, adding verification mechanisms for dynamic libraries in the dynamic linker to verify reliable and secure dynamic libraries (such as hijacked dynamic libraries and basic dynamic libraries), and adding verification mechanisms in hijacked dynamic libraries to verify reliable and secure original dynamic libraries, a multi-level verification method is used from the operating system kernel to the dynamic linker, from the dynamic linker to the hijacked dynamic library, and from the hijacked dynamic library to the original dynamic library. This "verification chain" prevents dynamic libraries from being tampered with or loading incorrect dynamic libraries.

[0107] Additionally, it prevents tenants from customizing the dynamic library search path, thus preventing dynamic libraries from escaping.

[0108] Based on the above method embodiments, this disclosure also provides a dynamic library loading device, referencing... Figure 5 This is a schematic diagram of a dynamic library loading device provided in an embodiment of this disclosure. The device includes:

[0109] The receiving module 501 is used to receive a loading request for a target executable file, verify the target executable file, and if the target executable file passes the verification, load the target executable file into memory.

[0110] The reading module 502 is used to read the dynamic linker in the target executable file in the memory, verify the dynamic linker, and if the dynamic linker passes the verification, load the dynamic linker into the memory.

[0111] The control module 503 is used to control the dynamic linker to start in the memory; wherein, the dynamic linker is used to find the hijacking dynamic library corresponding to the target executable file, and verify the hijacking dynamic library. If the hijacking dynamic library passes the verification, the hijacking dynamic library is loaded into the memory, and the target executable file is controlled to start in the memory. The dynamic linker is used to refuse to load the original dynamic library, which is the dynamic library that the target executable file depends on at runtime. The target executable file is used to call the hijacking dynamic library to verify the original dynamic library, and when the original dynamic library passes the verification, it calls the hijacking dynamic library to load the original dynamic library into the memory.

[0112] In one optional implementation, the hijacking dynamic library includes an interface symbol value for the resource allocation function to be called by the target executable file. The target executable file is used to call the hijacking dynamic library to obtain the interface symbol value. The hijacking dynamic library is used to call the resource allocation function to allocate resources based on the interface symbol value when the sum of the amount of resources to be allocated corresponding to the resource allocation function and the amount of currently used resources of the container corresponding to the target executable file does not exceed the preset resource limit of the container.

[0113] In one optional implementation, the hijacking dynamic library does not include the interface symbol value of the resource allocation function to be called by the target executable file. The target executable file is used to call the hijacking dynamic library to obtain the interface symbol value of the resource allocation function from the original dynamic library. The hijacking dynamic library is used to call the resource allocation function to allocate resources based on the interface symbol value when the sum of the amount of resources to be allocated corresponding to the resource allocation function and the amount of currently used resources of the container corresponding to the target executable file does not exceed the preset resource limit of the container.

[0114] In one optional implementation, the receiving module 501 includes a receiving submodule and a first loading submodule;

[0115] The receiving submodule is used to receive a loading request for a target executable file and to verify the target executable file;

[0116] The first loading submodule is used to load the target executable file into memory when the target executable file passes verification;

[0117] In one optional implementation, the receiving submodule is specifically used for:

[0118] Receive a load request for a target executable file, and verify the preset signature of the target executable file based on a preset first private key.

[0119] In one optional implementation, the reading module 502 includes a reading submodule and a second loading submodule;

[0120] The reading submodule is used to read the dynamic linker in the target executable file in the memory and verify the dynamic linker;

[0121] The second loading submodule is used to load the dynamic linker into memory when the dynamic linker verification passes;

[0122] In one optional implementation, the reading submodule is specifically used for:

[0123] The dynamic linker in the target executable file in the memory is read, and the preset signature of the dynamic linker is verified based on the preset second private key.

[0124] In one optional implementation, the dynamic linker is provided with a preset third private key, which is used to verify the preset signature of the hijacked dynamic library.

[0125] In one optional implementation, the hijacking dynamic library is provided with a preset fourth private key, which is used to verify the preset signature of the original dynamic library.

[0126] The dynamic library loading device provided in this embodiment receives a loading request for a target executable file, verifies the target executable file, loads the target executable file into memory if the verification passes, reads the dynamic linker in the target executable file in memory, verifies the dynamic linker, loads the dynamic linker into memory if the verification passes, and controls the dynamic linker to start in memory. The dynamic linker is used to find the hijacking dynamic library corresponding to the target executable file, verify the hijacking dynamic library, load the hijacking dynamic library into memory if the verification passes, and control the target executable file to start in memory. The dynamic linker is also used to refuse to load the original dynamic library, which is a dynamic library that the target executable file depends on at runtime. The target executable file calls the hijacking dynamic library to verify the original dynamic library, and when the original dynamic library passes verification, calls the hijacking dynamic library to load the original dynamic library into memory. As can be seen, the multi-level verification method of this disclosure, from the operating system kernel to the dynamic linker, from the dynamic linker to the hijacked dynamic library, and from the hijacked dynamic library to the original dynamic library, can effectively prevent dynamic library escape.

[0127] In addition to the methods and apparatus described above, this disclosure also provides a computer-readable storage medium storing instructions that, when executed on a terminal device, cause the terminal device to implement the dynamic library loading method described in this disclosure.

[0128] This disclosure also provides a computer program product, which includes a computer program / instruction that, when executed by a processor, implements the dynamic library loading method described in this disclosure.

[0129] In addition, this disclosure also provides a dynamic library loading device, see [link to relevant documentation]. Figure 6 As shown, it may include:

[0130] The device includes a processor 601, a memory 602, an input device 603, and an output device 604. The number of processors 601 in the dynamic library loading device can be one or more. Figure 6 Taking a processor as an example. In some embodiments of this disclosure, the processor 601, memory 602, input device 603, and output device 604 can be connected via a bus or other means, wherein, Figure 6 Taking the example of a connection between China and Israel via a bus.

[0131] The memory 602 can be used to store software programs and modules. The processor 601 executes various functional applications and data processing of the dynamic library loading device by running the software programs and modules stored in the memory 602. The memory 602 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function, etc. In addition, the memory 602 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. The input device 603 can be used to receive input digital or character information, and generate signal inputs related to user settings and function control of the dynamic library loading device.

[0132] Specifically in this embodiment, the processor 601 loads the executable files corresponding to the processes of one or more applications into the memory 602 according to the following instructions, and the processor 601 runs the applications stored in the memory 602, thereby realizing the various functions of the dynamic library loading device.

[0133] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0134] The above description is merely a specific embodiment of this disclosure, enabling those skilled in the art to understand or implement it. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this disclosure. Therefore, this disclosure is not to be limited to the embodiments described herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for loading a dynamic library, characterized in that, The method includes: Receive a loading request for a target executable file, verify the target executable file, and if the target executable file passes the verification, load the target executable file into memory; The dynamic linker in the target executable file in the memory is read and verified. If the dynamic linker passes the verification, the dynamic linker is loaded into memory. The dynamic linker is controlled to start in the memory; wherein, the dynamic linker is used to find the hijacking dynamic library corresponding to the target executable file, and to verify the hijacking dynamic library. If the hijacking dynamic library passes the verification, the hijacking dynamic library is loaded into the memory. The dynamic linker is also controlled to start in the memory. The dynamic linker is used to refuse to load the original dynamic library, which is a dynamic library that the target executable file depends on at runtime. The target executable file is used to call the hijacking dynamic library to verify the original dynamic library, and when the original dynamic library passes the verification, it calls the hijacking dynamic library to load the original dynamic library into the memory.

2. The method according to claim 1, characterized in that, The hijacking dynamic library includes the interface symbol value of the resource allocation function to be called by the target executable file. The target executable file is used to call the hijacking dynamic library to obtain the interface symbol value. The hijacking dynamic library is used to call the resource allocation function to allocate resources based on the interface symbol value when the sum of the amount of resources to be allocated corresponding to the resource allocation function and the amount of currently used resources of the container corresponding to the target executable file does not exceed the preset resource limit of the container.

3. The method according to claim 1, characterized in that, The hijacking dynamic library does not include the interface symbol value of the resource allocation function to be called by the target executable file. The target executable file is used to call the hijacking dynamic library to obtain the interface symbol value of the resource allocation function from the original dynamic library. The hijacking dynamic library is used to call the resource allocation function to allocate resources based on the interface symbol value when the sum of the amount of resources to be allocated corresponding to the resource allocation function and the amount of currently used resources of the container corresponding to the target executable file does not exceed the preset resource limit of the container.

4. The method according to claim 1, characterized in that, The step of receiving a load request for a target executable file and verifying the target executable file includes: Receive a load request for a target executable file, and verify the preset signature of the target executable file based on a preset first private key.

5. The method according to claim 1, characterized in that, The step of reading the dynamic linker from the target executable file in the memory and verifying the dynamic linker includes: The dynamic linker in the target executable file in the memory is read, and the preset signature of the dynamic linker is verified based on the preset second private key.

6. The method according to claim 1, characterized in that, The dynamic linker is equipped with a preset third private key, which is used to verify the preset signature of the hijacked dynamic library.

7. The method according to claim 1, characterized in that, The hijacking dynamic library is equipped with a preset fourth private key, which is used to verify the preset signature of the original dynamic library.

8. A dynamic library loading device, characterized in that, The device includes: The receiving module is used to receive a loading request for a target executable file, verify the target executable file, and if the target executable file passes the verification, load the target executable file into memory. The reading module is used to read the dynamic linker in the target executable file in the memory, verify the dynamic linker, and if the dynamic linker passes the verification, load the dynamic linker into memory. A control module is used to control the dynamic linker to start in the memory; wherein, the dynamic linker is used to find the hijacking dynamic library corresponding to the target executable file, and verify the hijacking dynamic library. If the hijacking dynamic library passes the verification, the hijacking dynamic library is loaded into the memory. The dynamic linker is also used to control the target executable file to start in the memory. The dynamic linker is used to refuse to load the original dynamic library, which is a dynamic library that the target executable file depends on at runtime. The target executable file is used to call the hijacking dynamic library to verify the original dynamic library, and if the original dynamic library passes the verification, it calls the hijacking dynamic library to load the original dynamic library into the memory.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed on a terminal device, cause the terminal device to perform the method as described in any one of claims 1-7.

10. A dynamic library loading device, characterized in that, include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the method as claimed in any one of claims 1-7.

Images