JAVA application control method and management platform

Abstract

The present application provides a Java application control method and a management platform. The method comprises: receiving an image inputted by a user, the image comprising bytecode corresponding to a Java application and a runtime dependency file of the Java application, the bytecode corresponding to the Java application being obtained by means of compiling a source code corresponding to the Java application; on the basis of an available Java local interface in the bytecode corresponding to the Java application, identifying an available system call set of the Java application in the runtime dependency file, the available Java local interface being a Java local interface that can be used when the Java application runs in a target container; and when the Java application runs in the target container, controlling a system call actually used by the Java application to be within the available system call set. The method can efficiently and accurately limit system calls that an application can use, without affecting the service of the application.

Description

A Java application control method and management platform

[0001] This application claims priority to Chinese Patent Application No. 202411986064.3, filed on December 27, 2024, entitled "A Java Application Control Method and Management Platform", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of computer science, and in particular to a Java application control method and management platform. Background Technology

[0003] Compared to virtual machines (VMs), containers are lightweight virtual instances, offering flexibility and ease of deployment. Therefore, containers have become widely used virtual instances in the cloud technology field. However, containers share the same kernel as the host machine, which means that applications within containers may exploit kernel vulnerabilities to perform privilege escalation, escape, and other actions, thereby affecting the security of the host machine and other containers within it.

[0004] Applications within containers access the host kernel using system calls (Syscalls). Restricting the system calls an application can use controls its access to the host kernel, effectively preventing privilege escalation and escape attempts. In related technologies, container security policies (Seccomp) are configured to restrict the system calls available to applications. However, configuring container security policies is cumbersome and may incorrectly restrict the system calls an application might use, impacting the application's business functionality. Summary of the Invention

[0005] This application provides a Java application control method and management platform that can efficiently and accurately restrict the system calls that an application can use without affecting the application's business functions.

[0006] Firstly, a Java application control method executable by a management platform is provided. The management platform can be connected to infrastructure, or the management platform can be located within the infrastructure. The infrastructure may include at least one data center, each of which deploys multiple hosts, each of which is used to deploy containers. In this method, a user can input an image to the management platform, which can receive the input image. The image may include bytecode corresponding to a Java application and runtime dependency files of the Java application. The bytecode corresponding to the Java application is compiled from the source code corresponding to the Java application, and the Java application is used to run in a target container within the infrastructure. The target container is one or more containers within the infrastructure. In this method, the management platform can identify the Java native interfaces that the Java application can use when running in the target container from the bytecode corresponding to the Java application, thus obtaining the usable Java native interfaces of the Java application. Then, based on the usable Java native interfaces of the Java application, the management platform can identify the set of usable system calls of the Java application in the runtime dependency files; wherein there is a call path between the system calls in the set of usable system calls and the usable Java native interfaces. After identifying the set of system calls that a Java application can use, the management platform can control the actual system calls used by the Java application within the set of available system calls when the Java application is running in the target container.

[0007] The Java native interface that can be used can be one or more Java native interfaces. The set of system calls that can be used includes one or more system calls that a Java application can use while running in a container.

[0008] This method leverages the Java native interfaces available in the Java application's bytecode to identify the set of system calls that the Java application can use while running in a container. It accurately identifies the system calls that the Java application can use, avoiding excessive restrictions on the actual system calls used by the Java application at runtime, thus preventing impact on business operations. Furthermore, this method is derived through analysis of bytecode and runtime dependency files, belonging to static analysis. By pre-running the Java application, the set of usable system calls can be obtained, improving the completeness of the usable system call set. Moreover, there is no window period; the set of usable system calls can be obtained before business deployment.

[0009] This method restricts the system calls used by Java applications to a specific range, preventing attacks on the host kernel. Furthermore, it obtains the necessary system calls without requiring the Java application to run, saving time and performance overhead. Additionally, it identifies system calls corresponding to Java native interfaces that the Java application might use, thus avoiding erroneous restrictions on system call usage and ensuring the functionality of the Java application.

[0010] In one possible implementation, the image may include multiple applications. The method also includes using static analysis of the programs to identify the Java application among the multiple applications.

[0011] Among these, the Java application is a potential main business process of the target container. Static analysis can be used to identify the potential main business process from among these multiple applications, thereby identifying the Java application itself. There can be multiple potential main business processes; that is, when the container actually runs, the main business process that actually runs can be one of these multiple potential main business processes. Through static program analysis, all potential main business processes can be identified, thus ensuring the integrity of the set of usable system calls.

[0012] In one possible implementation, the bytecode corresponding to the Java application includes the Java application's entry point function, and a call path exists between the Java native interface and the entry point function.

[0013] By determining whether there is a call path between a Java native interface and its entry function, it is possible to identify whether a Java application might use that Java native interface. This allows for the accurate identification of Java native interfaces that can be used by a Java application, thereby ensuring the accuracy of the set of system calls that can be used.

[0014] In one possible implementation, the method further includes: receiving user input about the runtime environment of the target container; controlling the system calls used by the Java application implementation within the set of available system calls, including: obtaining the names of the system calls in the set of available system calls in the target container based on the runtime environment; and controlling the system calls actually used by the Java application within the set of available system calls based on the names.

[0015] In this implementation, the names of system calls from the available system call set can be obtained. Based on these names, the actual system calls used by the Java application can be more easily controlled. For example, based on these names, container security policies can be configured, thereby allowing control over the actual system calls used by the Java application.

[0016] In one possible implementation, the bytecode corresponding to the Java application includes the bytecode of the Java application itself and the bytecode of the Java application's dependent libraries.

[0017] In this implementation, the set of available system calls can be identified based on the available Java native interfaces in the bytecode of the Java application itself and the available Java native interfaces in the bytecode of the Java application's dependent libraries, thereby ensuring the integrity of the set of available system calls.

[0018] In one possible implementation, runtime dependencies include the Java Virtual Machine and / or the Java Software Development Kit.

[0019] In this implementation, usable system calls in the Java Virtual Machine and / or Java Software Development Kit can be identified, ensuring the integrity of the set of usable system calls.

[0020] Secondly, a management platform is provided, which is connected to or located within an infrastructure, including at least one data center. Each data center has multiple hosts deployed, and each host is used to deploy containers. The management platform includes: a receiving module for receiving an image input by a user, the image including bytecode corresponding to a Java application and runtime dependency files of the Java application; wherein the bytecode corresponding to the Java application is compiled from the source code corresponding to the Java application, and the Java application is used to run in a target container in the infrastructure; an identification module for identifying the set of usable system calls of the Java application in the runtime dependency files based on the usable Java native interfaces in the bytecode corresponding to the Java application; wherein the usable Java native interfaces are Java native interfaces that the Java application can use when running in the target container, and there is a call path between the system calls in the set of usable system calls and the usable Java native interfaces; and a control module for controlling the system calls actually used by the Java application within the set of usable system calls when the Java application is running in the target container.

[0021] In one possible implementation, the image includes multiple applications; the identification module is also used to: identify the Java application among the multiple applications using static program analysis.

[0022] In one possible implementation, the bytecode corresponding to the Java application includes the Java application's entry point function, and a call path exists between the Java native interface and the entry point function.

[0023] In one possible implementation, the receiving module is further configured to: receive the runtime environment of the target container input by the user; the control module is further configured to: obtain the names of system calls in the target container from the set of available system calls based on the runtime environment; and control the system calls actually used by the Java application within the set of available system calls based on the names.

[0024] In one possible implementation, the bytecode corresponding to the Java application includes the bytecode of the Java application itself and the bytecode of the Java application's dependent libraries.

[0025] In one possible implementation, runtime dependencies include the Java Virtual Machine and / or the Java Software Development Kit.

[0026] Thirdly, a computing device cluster is provided, including at least one computing device, each computing device including a processor and a memory; the processor of the at least one computing device is used to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster performs the method provided in the first aspect.

[0027] Fourthly, a computer-readable storage medium is provided, including computer program instructions that, when executed by a cluster of computing devices, execute the method provided in the first aspect.

[0028] Fifthly, a computer program product containing instructions is provided, which, when executed by a cluster of computer devices, causes the cluster of computer devices to perform the method provided in the first aspect.

[0029] The beneficial effects of the second to fifth aspects can be referred to the introduction of the beneficial effects of the first aspect above, and will not be repeated here. Attached Figure Description

[0030] Figure 1 is a schematic diagram of a system architecture provided in an embodiment of this application;

[0031] Figure 2 is a schematic diagram of a management platform provided in an embodiment of this application;

[0032] Figure 3 is a schematic diagram of a Java application accessing the kernel in a container according to an embodiment of this application;

[0033] Figure 4 is a schematic diagram of a system call that a Java application can use, provided in an embodiment of this application;

[0034] Figure 5 is a schematic diagram of a management platform provided in an embodiment of this application;

[0035] Figure 6 is a schematic diagram illustrating the identification of a runnable Java application according to an embodiment of this application;

[0036] Figure 7 is a schematic diagram of the runtime dependency files of a Java application provided in an embodiment of this application;

[0037] Figure 8 is a schematic diagram illustrating the extraction of a Java dependency library according to an embodiment of this application;

[0038] Figure 9 is a schematic diagram illustrating an identification method for using Java native interfaces, provided in an embodiment of this application.

[0039] Figure 10 is a schematic diagram of a function call graph provided in an embodiment of this application;

[0040] Figure 11 is a schematic diagram of the data structure of a function call graph provided in an embodiment of this application;

[0041] Figure 12 is a schematic diagram of system call identification provided in an embodiment of this application.

[0042] Figure 13 is a schematic diagram of the data structure of a function call graph provided in an embodiment of this application;

[0043] Figure 14 is a schematic diagram of function identification provided in an embodiment of this application;

[0044] Figure 15 is a schematic diagram of function recognition provided in an embodiment of this application;

[0045] Figure 16 is a flowchart of a Java application control method provided in an embodiment of this application;

[0046] Figure 17 is a schematic diagram of the structure of a management platform provided in an embodiment of this application;

[0047] Figure 18 is a schematic diagram of the structure of a computing device provided in an embodiment of this application;

[0048] Figure 19 is a schematic diagram of the structure of a computing device cluster provided in an embodiment of this application;

[0049] Figure 20 is a schematic diagram of the structure of a computing device cluster provided in an embodiment of this application. Detailed Implementation

[0050] The solutions provided in the embodiments of this application will now be described with reference to the accompanying drawings. In the embodiments of this application, "multiple" refers to two or more objects, and "various types" refers to two or more types. Terms such as "first," "second," etc., are only used to distinguish similar objects and are not necessarily used to describe a specific order or number of objects.

[0051] To facilitate understanding of the solutions provided in the embodiments of this application, the technical terms that may be involved in the embodiments of this application will be introduced first.

[0052] Cloud technology refers to a managed service that unifies a series of resources such as hardware, software, and networks within a wide area network or local area network to enable data computing, storage, processing, and sharing.

[0053] Infrastructure refers to facilities that can provide resources such as computing resources, storage resources, and / or network resources. An infrastructure may include at least one data center, and each data center includes multiple hosts.

[0054] A host is a computing device that can act as a host for deploying containers. In some embodiments, a host can also be a physical computing device, such as a server or a bare metal server. In some embodiments, a host can be a virtual computing device, such as a virtual machine (VM) or an elastic cloud server (ECS). In cloud technology, infrastructure can be referred to as cloud infrastructure.

[0055] Management platform: A platform provided by the resource provider for user interaction. Users can register accounts on the management platform and rent resources within the infrastructure managed by the platform. Users can deploy containers within the infrastructure through the management platform, and the rented resources support the operation of the application. In cloud technology, the management platform can be called a cloud management platform.

[0056] Containers: A type of virtual computing instance, belonging to kernel virtualization technology, used to isolate processes and resources. Containers and virtual machines have similar resource isolation and allocation methods. However, compared to virtual machines, containers virtualize the operating system rather than the hardware, making them more portable and efficient.

[0057] Bytecode, also known as a bytecode file, is a binary file containing an executable program, consisting of a sequence of operation (op) code / data pairs. Bytecode is an intermediate binary file compiled from source code and is more abstract than machine code.

[0058] A Java application is an application developed using Java. A Java application corresponds to one or more services, and a container provides these services by running the Java application.

[0059] A mirror image is a file format that can contain multiple files. An image file can be understood as an "extract" from a CD / DVD. A container image includes multiple applications and the runtime dependencies of each application. A container can load applications and their runtime dependencies from an image. Specifically, the Java application in the image is the application's bytecode. For example, an image might include a Java archive file for a Java application, and the Java archive file for that Java application might contain the application's bytecode.

[0060] Java archive (JAR) files, also known as JAR packages, are a software package file format that includes the bytecode of a Java application, related metadata, and resource files (text, images, etc.). The bytecode of a Java application consists of the bytecode of its classes. Loading a Java archive file enables the Java application to start. A Java archive file can contain multiple sub-packages, and each sub-package can contain one or more classes.

[0061] Runtime dependencies refer to the files required for a Java application to function correctly, such as the Java Development Kit (JDK) and the Java Runtime Environment (JRE). The runtime dependencies of a Java application in an image are typically developed using binary, C, or C++ languages.

[0062] Dependency libraries are code libraries required for a Java application to function properly. The code in dependency libraries provides the necessary functionality and support for Java's operation. Java application dependency libraries are also included in the image, where they can be in bytecode form. For example, an image package contains Java archive files of the Java application's dependency libraries, and these archive files include the bytecode of the dependency libraries.

[0063] The Java Virtual Machine (JVM) is the language runtime used to execute Java code. Designed to achieve the "compile once, run anywhere" characteristic, Java code is compiled into bytecode during compilation—a format that is easy to distribute but cannot be directly executed. The JVM is responsible for interpreting or compiling and executing this bytecode, and for providing support for operations such as class loading and garbage collection.

[0064] Java class: The basic building block of Java code, used to describe Java objects. It contains a series of fields that define data and methods that define operations. It is a template for Java objects.

[0065] A Java object is a data structure that contains a series of data fields and a series of methods for manipulating that data. Each Java object is a concrete instance of a corresponding Java class.

[0066] Java Native Interface (JNI): An interface provided by the JVM for Java language code to call native code (also known as machine language code, which is assembly code that runs directly on the processor) written and compiled in languages ​​such as C / C++.

[0067] Available Java native interfaces: also known as reachable Java native interfaces, these are the Java native interfaces that a Java application can use at runtime, i.e., the Java native interfaces that a Java application can reach. The Java native interfaces that a Java application actually uses at runtime are a subset of the available Java native interfaces for that Java application.

[0068] Program static analysis, also known as static analysis, is a code analysis technique that scans program code without running the code, using techniques such as lexical analysis, syntax analysis, control flow analysis, and data flow analysis, to verify whether the code meets the criteria for standardization, security, reliability, and maintainability.

[0069] Dynamic program analysis refers to using analysis tools to load and run a program. As the program runs, the analyst can interrupt the target's instruction flow at any time to observe the relevant calculation results and the current device status.

[0070] Source code: also known as source program, refers to an uncompiled text file written according to certain programming language specifications. It is a series of human-readable computer language instructions.

[0071] A function is a reusable block of code that performs a specific task. A function associated with a specific object is called a method. Furthermore, in Java, functions are associated with objects; that is, functions in Java are methods.

[0072] Entry point function: This is the starting point for application execution. It is responsible for receiving external data and initiating the application's execution flow. In other words, the entry point function is a function that must be executed during application runtime, and it is the first function executed.

[0073] Call path: This refers to the path from the caller to the callee. This path can include one or more code blocks (such as functions), which the caller invokes sequentially to reach the callee. The caller and callee can be code blocks; for example, the caller might be a function, and the callee might be another function.

[0074] System call (Syscall): A system call is an interface provided by the operating system to applications, allowing applications to request services from the operating system kernel, such as file operations, process control, and communication.

[0075] Available system calls: also known as reachable system calls, refer to system calls that a Java application may use at runtime, i.e., system calls that are reachable by the Java application at runtime. The system calls that a Java application actually uses at runtime are a subset of the available system calls for that Java application.

[0076] Immediate value: A term in computer science that refers to a value or operand that is encoded into an instruction and whose value is fixed.

[0077] Runtime environment: This refers to information about the host machine where the container resides, such as the host's instruction set architecture and kernel version. System calls with the same call number may have different names in different runtime environments.

[0078] Container security policy (Seccomp) refers to a series of measures taken when using container technology to prevent applications within containers from attacking the host kernel (such as privilege escalation and escape). Container security policy includes a whitelist, which lists system calls that applications can use. During application runtime, if a system call that an application intends to use is not on the whitelist, the application is prohibited from using that system call. The whitelist records the names of the system calls; therefore, configuring container security policies requires specifying the names of these system calls.

[0079] By restricting the system calls used by applications within containers, attacks on the host kernel can be effectively prevented. Container security policies can be used to restrict system calls used by applications within containers. Therefore, the efficient and accurate configuration of container security policies has a significant impact on container deployment and operation.

[0080] One approach involves manually configuring container security policies. This requires a high level of expertise and is very manpower-intensive. Another approach utilizes dynamic application analysis to identify system calls used by the application within the container and configures container security policies based on these identified systems. This approach requires the application to run for a period of time, resulting in significant time and resource overhead. Furthermore, dynamic application analysis cannot identify all system calls the application might use, leading to an incomplete whitelist in the container security policy, which could potentially impact the application's normal business operations during runtime.

[0081] This application provides a Java application control method. In this method, a management platform can obtain the bytecode corresponding to the Java application and the runtime dependency files of the Java application from the image. Then, the management platform can identify the Java native interfaces that the Java application can use when running in a container from the bytecode corresponding to the Java application, thus obtaining the usable Java native interfaces of the Java application. Furthermore, based on the usable Java native interfaces of the Java application, the management platform identifies the usable system calls of the Java application from the runtime dependency files of the Java application. When the Java application runs in a container, the management platform can control the system calls used by the Java application to be within the range of usable system calls. In this way, the system calls used by the Java application can be restricted to a corresponding range, preventing attacks on the host kernel by the Java application. Moreover, this method obtains the corresponding system calls without running the Java application, saving time and performance overhead. Additionally, this method can identify the system calls corresponding to the Java native interfaces that the Java application may use, thereby avoiding erroneous restrictions on the use of system calls by the Java application and ensuring the business functionality of the Java application.

[0082] Next, the Java application control method provided in the embodiments of this application will be introduced.

[0083] Figure 1 illustrates a system architecture that can be used to implement the method. This system architecture may include a management platform 100 and infrastructure 200. The management platform 100 may be a cloud management platform, and the infrastructure 200 may be cloud infrastructure. In some embodiments, the management platform 100 may be located outside of and connected to the infrastructure 200. In some embodiments, the management platform 100 may be located within the infrastructure 200, for example, within one or more data centers of the infrastructure 200.

[0084] As shown in Figure 1, infrastructure 200 may include at least one data center, such as data center 210 and / or data center 220. Each data center in infrastructure 200 may deploy multiple hosts; for example, data center 210 may deploy hosts 211, 212, etc. These hosts can be used to deploy containers; for example, host 211 can be used to deploy container 300.

[0085] Users can deploy containers in infrastructure 200 through management platform 100 and run relevant applications in the containers to perform their business operations. These applications can be Java applications.

[0086] To prevent Java applications running in containers from attacking the kernel of the host machine hosting the container, it's necessary to restrict the system calls used by the Java applications while running in the container. Management platform 100 can analyze the bytecode and runtime dependencies of the Java applications in the image to identify the system calls that the Java applications can use while running in the container. Then, when the Java application runs in the container, it controls the actual system calls used by the Java application to be within the identified range. In this way, the system calls used by the Java application while running in the container can be restricted.

[0087] To achieve the above functions, as shown in Figure 2, the management platform 100 can have a receiving module 110, an identification module 120, and a control module 130. The receiving module 110 can receive images input by users. For example, the receiving module 110 can interface with a business development pipeline, allowing business developers to input images into the receiving module 110 as users. The identification module 120 can identify system calls that the Java application 310 might use when running in the container 300 from the image, obtaining the identification result. The control module 130 can control the operation of the Java application 310 in the container 300 based on the identification result, ensuring that the system calls actually used by the Java application 310 are within the identified system calls. For example, the control module 130 can generate a container security policy based on the identification result and control the operation of the Java application 310 in the container 300 based on this container security policy.

[0088] The identification module 120 can utilize the relevant mechanisms of Java runtime system calls to identify system calls that Java application 310 may use during runtime. This mechanism is as follows.

[0089] The image contains the bytecode corresponding to the Java application, which is compiled from the source code of the Java application. This bytecode can be the Java application's own bytecode and / or the bytecode of its dependent libraries. During Java application runtime, the Java Virtual Machine (JVM) is responsible for executing the bytecode. As shown in Figure 3, for functions with frequent calls in the bytecode, the JVM can compile them into native code. The JVM can call less frequently called functions in interpreted mode to save on compilation and optimization costs, achieving a more balanced execution efficiency. The runtime dependencies of a Java application (such as the JVM, JDK, etc.) are typically binary files developed in C or C++. These runtime dependencies provide native libraries and function interfaces. Native libraries and function interfaces include native functions. The native code generated by the JVM compiling or interpreting the Java application's bytecode uses system calls to interact with the host kernel and implement low-level functionality by calling native functions in the runtime dependencies. Specifically, the native code generated by the JVM compiling or interpreting the Java application's bytecode uses Java native interfaces to call native functions in the runtime dependencies.

[0090] Taking the code shown in Figure 4 as an example, the `write` function in the bytecode of the Java application calls `writeBytes` defined in the `FileOutputStream` class. `writeBytes` is a Java native interface. This Java native interface `writeBytes` corresponds to the `java_java_io_FileOutputStream_writeBytes` function in the JDK. The Java application can call the `java_java_io_FileOutputStream_writeBytes` function through this Java native interface. By calling `java_java_io_FileOutputStream_writeBytes`, the Java application can call the `writeByte` and `handleWrite` functions. Calling `writeByte` and `handleWrite` allows the Java application to access the `write` function in `unistd`. The Java application can then use the `write` system call by calling the `write` function in `unistd`. `unistd` belongs to the POSIX system call set, which is used by Linux systems.

[0091] Based on the above mechanism, the identification module 120 can identify the Java native interface from the bytecode corresponding to the Java application 310 in the image. Then, based on the identified Java native interface, it can identify system calls in the runtime dependency files of the Java application 310 and obtain the identification result.

[0092] In some embodiments, as shown in Figure 5, a user can input an image and a runtime environment into the management platform 100. The management platform 100 can receive the image and the runtime environment. The image is related to container 300. This image can be used to deploy container 300 on host 211, and image 300 includes information related to applications running in container 300, such as bytecode for Java applications and runtime dependency files for Java applications. The image can include multiple applications. These multiple applications can include at least one Java application, such as Java application 310. These multiple applications can also include applications in other languages, such as Python applications. The image can include bytecode for Java applications and runtime dependency files for Java applications. The runtime environment refers to the information of the host where container 300 resides, i.e., the information of host 2100.

[0093] The identification module 120 can obtain the image from the receiving module 110 and identify runnable Java applications from the image. Here, a runnable Java application refers to a Java application that may run in container 300. Typically, the runnable Java application of a container is the main business process within that container. If the main business process of a container is a Java application, then that Java application is the runnable application of that container. If the main business process of a container is a shell script, then the runnable Java application of that container is the Java application contained in all branches of that shell script.

[0094] The identification module 120 can use static program analysis technology to identify all runnable Java applications in the image of container 300, thus obtaining Java application 310. In other words, Java application 310 is all the runnable applications in container 300. Specifically, when the main business process of container 300 is a Java application, that Java application is used as Java application 310. When the main business process of the container is a shell script, Java application 310 is the Java applications contained in the various branches of the shell script.

[0095] In some embodiments, the identification module 120 may identify the Java application 310 in the image using static program analysis technology in the following ways.

[0096] First, the identification module 120 can utilize static program analysis technology to construct the Dockerfile and filesystem of container 300. Specifically, it can analyze the historical commit information of the container 300 image's manifest file to obtain the identifier (ID) of each layer, the corresponding Dockerfile commands, and the linear dependencies between file layers. Based on the identifier (ID) of each layer, the corresponding Dockerfile commands, and the linear dependencies between file layers, the original Dockerfile of container 300 is reconstructed. By sequentially decompressing the image layers, the filesystem actually used by container 300 during runtime can be obtained.

[0097] Next, based on the Dockerfile and file system of container 300, all runnable Java applications in container 300 are extracted. The CMD and ENDPOINT instructions in the Dockerfile specify the startup program and parameters for container 300. By analyzing the CMD and ENDPOINT instructions, the main business process of container 300 can be determined.

[0098] If the main business process is a Java process, then the startup parameters, i.e., the Java application's JAR file, are extracted to obtain the bytecode of Java application 310. If the main business process of container 300 is a Java process, and the Java process's startup parameters include the -cp or -classpath command, then Java application 310 defines the user classpath, and classes under this path will be loaded by the Application ClassLoader.

[0099] If the main business process is a shell script, the shell script is analyzed to extract the binary executable files it calls. A schematic diagram of the analysis is shown in Figure 6. Furthermore, the encoding language is automatically detected, therefore, there is no need to manually mark the language of the main business process in container 300. The header of the extracted binary executable file can be analyzed to obtain the executable's dependency libraries, which are then extracted from the file system of container 300. This process is repeated recursively until all executable files and their dependency libraries in container 300 are extracted. The Java application within all executable files is used as Java application 310.

[0100] Thus, the runnable application of container 300, namely Java application 310, can be obtained. The identification module 120 can extract the JAR package of Java application 310 from this image, and obtain the bytecode of Java application 310 from this JAR package. The bytecode of Java application 310 belongs to the bytecode corresponding to Java application 310.

[0101] The identification module 120 can also use static program analysis technology to identify the runtime dependency files and Java dependency libraries of the Java application 310 in the image.

[0102] The identification module 120 utilizes static program analysis techniques to extract the runtime dependencies (such as JDK, JRE, etc.) and classpath of the Java application from the constructed file system. The runtime dependencies include a series of dependency library files, as shown in Figure 7. These dependency library files contain low-level functions implemented in C or C++. The native code of the Java application typically does not directly depend on these dependency library files, but loads them on demand using the `dlopen` command to provide different functionalities for the Java application. The identification module 120 can locate the path pointed to by the `JAVA_HOME` environment variable and extract the dependency library files from the runtime dependencies. In a container, environment variables can be configured via the `env` directive in the Dockerfile, and the identification module 120 can obtain the extraction path of the dependency library files through the Dockerfile.

[0103] The bytecode corresponding to the Java application includes the Java application's own bytecode and the bytecode of the Java dependency libraries. The class files of these Java dependency libraries are located outside the Java application's JAR file. To ensure the integrity of using Java native interfaces, the identification module 120 extracts the Java dependency libraries of the Java application from the image. For example, the extraction method can be as shown in Figure 8. When the Java Launcher starts the Java Virtual Machine, each class loader loads classes sequentially from different paths. The loading process of the Java class loader can be simulated to extract the bytecode of the dependency libraries from the same class path. Specifically, the identification module 120 can extract the Java dependency library's JAR file, which contains the bytecode of the Java dependency libraries. Thus, the identification module 120 can obtain the bytecode of the Java dependency libraries of the Java application 310.

[0104] Referring again to Figure 5, the identification module 120 can identify the Java native interfaces that can be used in the Java application 310 from the bytecode corresponding to the Java application 310. The identified Java native interfaces can be one or more Java native interfaces.

[0105] In some embodiments, as shown in FIG5, the identification module 120 can construct a function call graph of the Java application 310, and use the constructed function call graph to identify the Java native interfaces that the Java application 310 can use. For example, as shown in FIG9, the identification module 120 can construct a function call graph based on the bytecode corresponding to the Java application 310, and use the function call graph to identify the Java native interfaces that the Java application 310 can use. The Java native interfaces that the Java application 310 can use refer to the Java native interfaces that the Java application 310 can use when running in the container 300.

[0106] The identification module 120 can identify all usable Java native interfaces in the bytecode corresponding to the Java application 310. In some embodiments, the bytecode corresponding to the Java application 310 may have multiple Java native interfaces, among which the Java native interfaces that have a call path with the entry function of the Java application 310 are the usable Java native interfaces of the Java application 310. For example, the identification module 120 can identify all usable Java native interfaces of the application 310 in the following manner.

[0107] The identification module 120 can analyze the bytecode corresponding to the Java application 310 using static program analysis techniques, and construct a function call graph of the Java application 310 based on the analysis results. The function call graph of the Java application 310 consists of functions in the bytecode corresponding to the Java application 310 and the call paths between functions.

[0108] The identification module 120 can start from the entry function (e.g., the main function) of the Java application 310, identify all functions in the bytecode corresponding to the Java application 310, and analyze the call relationships between functions. Functions are mapped to nodes in the function call graph, and the call relationships between functions are mapped to connecting edges between nodes. In this way, a function call graph of the Java application 310 can be drawn. For example, the function call graph can be as shown in Figure 10.

[0109] In Figure 10, A, B, C, D, E, F, G, and H represent different functions in the bytecode, and the lines connecting them represent their calling relationships. If two functions have a calling relationship, it means there is a call path between them. If two functions are connected by at least one other function, and adjacent functions within that other function have a calling relationship, and the two functions and that at least one other function also have a calling relationship, then there is a call path between the two functions. Here, function A is the entry point function of Java application 310, function G corresponds to the Java native interface g, and function H corresponds to the Java native interface h. The existence of a call path between function G and function A (the entry point function of Java application 310) indicates that there is a call path between the Java native interface g and the entry point function of Java application 310. Therefore, the Java native interface g is a usable Java native interface of Java application 310. The absence of a call path between function H and function A indicates that there is no call path between the Java native interface h and the entry point function of Java application 310. Therefore, the Java native interface h is not a usable Java native interface of Java application 310.

[0110] Java applications exhibit polymorphism, which can lead to dynamic binding issues. To address this, and to avoid detailed pointer analysis, the identification module 120 records all polymorphic relationships between classes during bytecode analysis. When a parent class / interface function call occurs, it associates all subclass / implementation class overridden functions and performs saturation estimation on dynamic binding to ensure the integrity of the function call graph.

[0111] There are various tools available for static program analysis and function call graph construction, such as Soot, Tai-E, SecBrella, SonarJava, and native image generators. The identification module 120 can use any of these tools to perform static program analysis and function call graph construction on the bytecode. For example, the identification module 120 can be configured to use a native image generator for static program analysis and function call graph construction, resulting in the function call graph shown in Figure 11.

[0112] In some embodiments, the usable native interfaces of Java application 310 can be obtained by excluding unusable Java native interfaces from the bytecode corresponding to Java application 310. In this embodiment, the identification module 120 can be configured to obtain all class files corresponding to the bytecode of Java application 310. Furthermore, if class files require bytecode enhancement, the bytecode can be supplemented or modified. Additionally, the native image generator may not be able to recognize classes used through reflection; this can be supplemented through configuration files.

[0113] In some embodiments, Java applications typically follow a specific process when using Java native interfaces. Generally, a Java application can obtain the address of a native function, create a native frame, push it onto the stack, and then invoke the Java native interface. Therefore, in the function call graph, the function containing the Java native interface has a relatively obvious characteristic. The identification module 120 can start from the Java application's entry function, traverse the reachable call paths, identify and obtain the Java native interfaces in the leaf nodes of the function call tree, and thus identify those that can use Java native interfaces.

[0114] Referring again to Figure 5, after identifying the Java native interfaces that Java application 310 can use, the identification module 120 can identify the system calls that Java application 310 can use in its runtime dependency files based on these interfaces. The identified system calls can be one or more system calls, and there is a call path between any of these system calls and at least one Java native interface among the available Java native interfaces.

[0115] Next, we will introduce a scheme for identifying available system calls in a Java application 310. This scheme identifies at least one available system call, which constitutes a set of available system calls.

[0116] In some embodiments, runtime dependency files may include binary dependency libraries, which may include C++ functions. Java native interfaces can be converted into C++ functions within the binary dependency libraries. To ensure correct linking between bytecode and functions in the binary dependency libraries, the function names of Java native interfaces follow certain rules. Typically, the function name consists of the prefix `java_`, the fully qualified class name, and the function name. Different function names are separated by underscores. For overloaded Java native interfaces, double underscores are used followed by an encoded parameter signature. Based on this, the identification module 120 can identify functions that can be converted from native interfaces into functions in the binary dependency libraries, thus obtaining the functions used by the Java application at runtime in the runtime dependency files.

[0117] In some embodiments, when the Java application 310 runs in the container 300, the system calls available to the Java application 310 can be divided into two categories. The first type of system call is initiated by the Java Virtual Machine (JVM) and includes bytecode compilation, bytecode interpretation, scheduling the execution of the Java application 310, garbage collection, etc. The second type of system call is initiated by the Java application 310 itself. After the bytecode corresponding to the Java application 310 is compiled or interpreted into native code, the Java application 310 can call system calls in the runtime dependency files through Java native interfaces. For the first type of system calls, the identification module 120 can perform binary analysis on the JVM as a binary executable file to identify the available first-type system calls of the Java application 310. For the second type of system calls, the identification module 120 can identify the usable functions of the Java application 310 in the runtime dependency files based on the identified usable Java native interfaces of the Java application 310, and use binary analysis to identify the usable second-type system calls of the Java application 310 within the usable functions of the Java application 310. In other words, binary analysis is required to identify both the first and second types of usable system calls. The following section will introduce binary analysis.

[0118] Runtime dependency files may be developed in high-level languages ​​such as C or C++. The development methods of high-level languages ​​often obscure the details of the interaction between runtime dependency files and the kernel, and there is a lack of clear mapping between low-level operations such as system calls and runtime dependency files developed in high-level languages. For example, the "hello world" business logic developed in C involves 25 system calls such as mmap, fstat, and access. This information is difficult to obtain directly from runtime dependency files developed in high-level languages; therefore, binary analysis is required. In summary, identifying system calls from runtime dependency files developed in C or C++ presents three challenges. Firstly, runtime dependency files can be compiled into binary code; the runtime dependency files mentioned below refer to the binary code compiled from runtime dependency files.

[0119] The first of these three challenges is identifying system calls within the assembly code after disassembling the dependent files. This requires identifying the assembly statements of system calls initiated by the Java Virtual Machine or Java application 310, as well as reading values ​​from specific registers. Since the call number of a system call may be passed multiple times before being recorded in the target register, simple analysis methods based on regular expressions are insufficient for system call identification. In some embodiments, as shown in Figure 5, the identification module 120 can employ data flow backtracking analysis to address this issue.

[0120] The second of the three challenges is excluding unusable system calls from Java application 310. Unusable system calls are those outside the usable system calls of Java application 310. When a Java application runs in a container, it doesn't use all system calls from its runtime dependencies. For example, runtime dependencies may include multiple dependency libraries, such as libc, through linking. These dependency libraries contain unusable system calls from Java application 310. To avoid over-licensing, unusable system calls need to be excluded. In some embodiments, as shown in Figure 5, the identification module 120 can perform reachability analysis on system calls to identify unusable system calls, and then identify usable system calls.

[0121] The third challenge is identifying system calls used through indirect calls. Indirect calls are difficult to analyze statically, making it challenging to accurately identify system calls used indirectly. An indirect call refers to using a system call by manipulating the destination address (i.e., the address of the called function) stored in a general-purpose register or memory through a calling instruction (such as `call` or `jmp`). Due to the poor precision of point-to-analysis, statically inferring the target address of function pointers is difficult, while dynamic inference lacks completeness. Therefore, accurately identifying system calls used through indirect calls is challenging.

[0122] To address the three challenges mentioned above, the following solutions were designed.

[0123] To address the first challenge mentioned above, the identification module 120 can perform data flow analysis during function calls within the assembly code. Specifically, the identification module 120 can identify and cache instructions in functions within dependent files. After identifying an instruction (syscall) that uses a system call, it can backtrack along the instruction stack to find the target register of that call instruction. Backtracking refers to searching upwards along the instruction flow for an immediate value. When the assignment statement in the target register is not an immediate value, the target register is changed, and backtracking along the instruction stack is performed to obtain the assignment statement in the new target register. This process is recursively repeated until the call number of the system call or the starting address of the function is found. For example, as shown in Figure 12, following the direction of the instruction flow, the instruction that uses a system call points to the eax register (i.e., the target register of this instruction is eax), and the assignment statement for the eax register is obtained. This assignment statement can be set to the r13d register, and r13d can be used as the new target register to obtain the assignment statement for r13d. The assignment statement for r13d can be set to call number 0xca. Thus, we can obtain the call number of the system call used by this instruction, which is 0xca, thereby identifying that the system call represented by 0xca belongs to the usable system call of Java application 310.

[0124] To address the second challenge mentioned above, the identification module 120 can construct a function call graph. Using this graph, it can identify system calls of the Java application 310 that can be called using Java native interfaces, thus obtaining the available system calls of the Java application 310. In some embodiments, the function call graph shown in Figure 10 can be constructed based on runtime dependency files. Here, I, J, K, M, and N represent different functions. Java native interface g can call function M through function I and function J. Java native interface h can call function M through function J and function N through function K. Java native interface g is a usable Java native interface of the Java application 310, while Java native interface h is not. Function M includes system call m, and function N includes system call n. Since the usable Java native interfaces of the Java application 310 can call function M, the usable Java native interfaces of the Java application 310 can use system call m in function M; therefore, system call m belongs to the usable system calls of the Java application 310. System call n, however, does not belong to the usable system calls of the Java application 310.

[0125] In some embodiments, a function call graph can be constructed in the following manner.

[0126] Within each file in the runtime dependency files, direct call instructions (such as `call` statements, conditional jump statements across function boundaries, and unconditional jump statements across function boundaries) can be recorded. A function call graph can be constructed using these recorded direct call instructions. For cross-file calls, different files can be connected by calls pointing to symbols in the procedure linkage table (PLT). This allows for the construction of a context-insensitive function call graph across files. The files can be binary files.

[0127] In some embodiments, as shown in Table 1, the call relationships between functions can be categorized into direct call statements, function boundary condition jump statements, function boundary unconditional jump statements, and indirect call statements. Direct call statements can be identified using the `call` command. Function boundary condition jump statements or function boundary unconditional jump statements can be identified using one or more of the following statements: `jmp`, `je`, `jne`, `jg`, `jge`, `jl`, `jle`, `ja`, `jae`, `jb`, `jbe`, and `jo`. Indirect jump statements can be identified using address-taken techniques.

[0128] Table 1

[0129] The entry function in the function call graph constructed above can be identified. In some embodiments, relevant documentation defines the entry function; for example, the e_entry field in the header of the System V ABI document's executable and linkable format (ELF) defines the entry function for each file. Additionally, special sections reserved by the system related to file initialization and termination processing (.init, .fini, .preinit_array, .init_array, .fini_array) are automatically executed after the dynamic linker loads dependent libraries, and functions in these sections are also marked as reachable functions as initialization functions. In some embodiments, functions of the Java application 310 that can use Java native interfaces are identified, and these identified functions are used as entry functions.

[0130] Starting from the entry function, the system calls that each function can initiate are identified along the function call graph. By summarizing the system calls that can be initiated by the functions of Java application 310 that can use Java native interfaces, the functions of Java application 310 that can use system calls can be identified, and thus the system calls that Java application 310 can use can be identified.

[0131] In one example, as shown in Figure 13, the function call graph's data structure consists of a dictionary containing all functions and an initial set of functions. The function's data structure includes the function's start and end addresses, a list of callers and callees, and a set of system calls that can be initiated within the function.

[0132] In one example, identifying each function along the function call graph is shown in Figure 14. Function P can be designated as the entry point function; for instance, function P is one or more functions of Java application 310 that can use Java native interfaces. Function P can call function Q, function P can also call function R through function Q, and function P can also call function X through functions Q and R. System call p in function P, system call q in function Q, system call r in function R, and system call x in function X are all usable system calls of Java application 310. Function P does not call functions S and T; therefore, system call s in function S and system call t in function T are not usable system calls of Java application 310.

[0133] To address the third challenge mentioned above, the identification module 120 can employ address-taken technology to perform saturation estimation of the functions callable by the Java application 310 that can access Java native interfaces, thus ensuring the integrity of the function call graph. Registers (e.g., general-purpose registers) and memory only store addresses during indirect calls (the address can be the address of a function or the address of data; data can also be an address). Therefore, when a caller calls a callee, it needs to calculate the address of the callee. The address calculation method in this mechanism can be used to calculate the address of the function called by the function in which the Java application 310 resides.

[0134] In some embodiments, the address calculation result may be the address of a function (e.g., the starting address of the function), in which case the function is the call target of the function containing the Java application 310. The function represented by this address can be added to the address retrieval set, and the address can be recorded.

[0135] In some embodiments, the address calculation result may be the address of a symbol (e.g., the starting address of the symbol), where the function pointed to by the symbol is the call target of the function in the Java application 310. Here, a symbol refers to an identifier or name, and is associated with a memory address or value. A symbol can be a variable name, function name, or label name, etc.

[0136] The above embodiments enable partial saturation estimation. These embodiments do not require identifying detailed calculations of registers and memory in the binary control flow and can quickly extract indirect calls involving symbolic offset calculations.

[0137] In some embodiments, the address calculation result may be the address of a data segment (e.g., the .data or .rodata segment) (e.g., the starting address of the data). If the data segment stores the address of the called function, it can be considered as a jump using the data segment. If the data segment stores the address of another data segment, which in turn stores the address of the called function, it can be considered as two jumps using the data segment, and so on, until the function is found. Thus, whenever the calculation result is the address of a data segment, the address of each data segment to which the jump is made is recursively checked according to the aforementioned reasoning.

[0138] In one example, referring to Figure 15, the address calculation result can be set to 0x123456. If 0x123456 is the address of the called function, then the called function can be directly obtained from 0x123456. If 0x123456 is the address of a data segment that stores the address 0x456789, then the called function can be obtained from 0x123456 and 0x456789. If 0x456789 is the address of another data segment that stores the address 0x666777, then the called function can be obtained from 0x123456, 0x456789, and 0x666777.

[0139] Therefore, the caller and callee of indirect calls can be connected in the function call graph, thus constructing a function call graph that can cover indirect calls.

[0140] The function call graph constructed using the above scheme is a tightly saturated estimate of the actual function call graph, possessing high integrity, and the construction method is simple and quick.

[0141] The identification module 120 can identify the functions that can be called by the functions of the Java application 310 that can use Java native interfaces through the function call graph. The system calls in these callable functions belong to the system calls that can be used by the Java application 310. In this way, the system calls that can be used by the Java application 310 can be obtained.

[0142] Using the methods or approaches described above, at least one usable system call of Java application 310 can be identified, and this at least one usable system call constitutes the set of usable system calls of Java application 310. In other words, the set of usable system calls of Java application 310 includes at least one usable system call.

[0143] Returning to Figure 5, when the Java application 310 runs in the container 310, the control module 130 can control the system calls actually used by the Java application 310 within the set of system calls that Java 310 can use. In other words, the control module 130 can ensure that the system calls actually used by the Java application 310 during runtime do not exceed the set of usable system calls identified by the identification module 120.

[0144] In some embodiments, the control module 130 can configure a container security policy based on the set of usable system calls identified by the identification module 120, and control the use of system calls by the Java application 310 at runtime based on the container security policy. For example, the control module 130 can use the usable system calls identified by the identification module 120 as a whitelist for the container security policy, ensuring that the system calls actually used by the Java application 310 at runtime are within this whitelist.

[0145] In some embodiments, the identification module 120 identifies the call number of a usable system call. However, the call number is inconvenient for the control module 130 to control the system calls used by the Java application 310, and the configuration of the container security policy requires the name of the system call. In this case, the control module 130 can obtain the runtime environment of the container 300 from the receiving module 110. Based on this runtime environment, the name of the system call represented by the call number in the container 300 can be obtained, thus obtaining the names of system calls in the set of usable system calls. For example, the runtime environment includes the kernel version and instruction set of the host where the container 300 resides. The control module 130 constructs a container system call information knowledge base based on the kernel code for that kernel version and instruction set. The container system call information knowledge base has a mapping relationship between the call number and the name of the system call. Based on the call number of the usable system call and the container system call information knowledge base, the call number of the usable system call can be obtained. Therefore, the call numbers of system calls in the set of usable system calls can be obtained.

[0146] Then, the control module 130 can use the names of system calls in the set of available system calls to control the system calls actually used by the Java application 310 to be within the set of system calls available to Java 310. For example, the control module 130 can configure a container security policy based on the names of the available system calls. The container security policy can be used to control the system calls actually used by the Java application 310 to be within the set of system calls available to Java 310.

[0147] Management platform 100 can restrict the system calls used by Java applications to a limited scope, preventing Java applications from attacking the host kernel. Furthermore, management platform 100 obtains the necessary system calls without requiring the Java application to run, saving time and performance overhead. Additionally, management platform 100 can identify system calls corresponding to Java native interfaces that Java applications may use, thereby avoiding erroneous restrictions on Java applications' use of system calls and ensuring the business functionality of Java applications.

[0148] Based on the above description, this application also provides a Java application control method. This method can be executed by the management platform 100. As shown in Figure 16, the method includes the following steps.

[0149] Step 1601: The management platform 100 receives the image input by the user. This image includes the bytecode corresponding to the Java application 310 and the runtime dependency files of the Java application 310. The bytecode corresponding to the Java application 310 is compiled from the source code corresponding to the Java application 310. The Java application 310 is used to run in the container 300 within the infrastructure 200. The container 300 can also be referred to as the target container. Related implementation methods can be found above and will not be repeated here.

[0150] In some embodiments, the bytecode corresponding to the Java application 310 may include the bytecode of the Java application 310 itself and the bytecode of the Java application 310's dependent libraries.

[0151] In some embodiments, the runtime dependencies of Java application 310 may include a Java Virtual Machine (JVM). In some embodiments, the runtime dependencies of Java application 310 may include a Java Software Development Kit (SDK). In some embodiments, the runtime dependencies of Java application 310 may include both a JVM and a Java SDK.

[0152] In some embodiments, the image may include multiple applications. For example, the multiple applications may include at least one Java application and at least one application coded in another language. The other language refers to a language other than Java, such as Python. For example, each of the multiple applications is a Java application. In this embodiment, the management platform 100 can use static program analysis to identify the Java application 310 among the multiple applications. Related implementation methods can be referred to the above description and will not be repeated here.

[0153] Step 1602: Based on the available Java native interfaces in the bytecode corresponding to the Java application 310, the management platform 110 identifies the set of available system calls for the Java application 310 in the runtime dependency files of the Java application 310. The available Java native interfaces are those that the Java application 310 can use when running in the container 300, and there is a call path between the system calls in the set of available system calls and the available Java native interfaces. Related implementation methods can be found in the above description and will not be repeated here.

[0154] In some embodiments, the bytecode corresponding to Java application 310 includes the Java application's entry function and multiple Java native interfaces. Before step 1602, the management platform 100 can identify usable Java native interfaces among the multiple Java native interfaces based on the entry function. There is a call path between the usable Java native interfaces and the entry function.

[0155] Step 1603: When the Java application 310 runs in the container 300, the management platform 100 controls the system calls actually used by the Java application 310 within the set of available system calls. Related implementation methods can be found above and will not be repeated here.

[0156] In some embodiments, the management platform 100 may also receive the runtime environment of the container 310. Then, based on this runtime environment, the management platform 100 can obtain the names of the system calls in the available call set within the container 310. Then, based on the names of the system calls in the available call set within the container 310, the management platform 100 can control the system calls actually used by the Java application to be within the available call set.

[0157] The Java application control method provided in this application can restrict the system calls used by Java applications to a corresponding range, thus preventing Java applications from attacking the host kernel. Furthermore, this method obtains the corresponding system calls without running the Java application, saving time and performance overhead. Additionally, this method can identify the system calls corresponding to Java native interfaces that the Java application may use, thereby avoiding erroneous restrictions on the Java application's use of system calls and ensuring the business functionality of the Java application.

[0158] Based on the above description, this application also provides a management platform 1700. The management platform 1700 is connected to or located within an infrastructure, the infrastructure including at least one data center, each of the at least one data center deploying multiple hosts, each of the multiple hosts being used to deploy containers. As shown in Figure 17, the management platform 1700 includes:

[0159] The receiving module 1710 is used to receive an image input by a user, the image including bytecode corresponding to a Java application and runtime dependency files of the Java application; wherein, the bytecode corresponding to the Java application is compiled from the source code corresponding to the Java application, and the Java application is used to run in a target container in the infrastructure;

[0160] The identification module 1720 is used to identify the set of available system calls of the Java application in the runtime dependency file based on the available Java native interfaces in the bytecode corresponding to the Java application; wherein, the available Java native interfaces are Java native interfaces that the Java application can use when running in the target container, and there is a call path between the system calls in the set of available system calls and the available Java native interfaces;

[0161] The control module 1730 is used to control the system calls actually used by the Java application within the set of available system calls when the Java application is running in the target container.

[0162] In some embodiments, the image includes multiple applications; the identification module 1720 is further configured to: identify the Java application among the multiple applications using static program analysis.

[0163] In some embodiments, the bytecode corresponding to the Java application includes the entry function of the Java application, and there is a call path between the Java native interface and the entry function.

[0164] In some embodiments, the receiving module 1710 is further configured to: receive the runtime environment of the target container input by the user; the control module 1730 is further configured to: obtain the names of system calls in the set of available system calls in the target container based on the runtime environment; and control the system calls actually used by the Java application to be within the set of available system calls based on the names.

[0165] In some embodiments, the bytecode corresponding to the Java application includes the bytecode of the Java application itself and the bytecode of the Java application's dependent libraries.

[0166] In some embodiments, the runtime dependencies include a Java Virtual Machine and / or a Java Software Development Kit.

[0167] The receiving module 1710, the identification module 1720, and the control module 1730 can all be implemented in software or in hardware. For example, the implementation of the receiving module 1710 will be described below. Similarly, the implementation of the identification module 1720 and the control module 1730 can refer to the implementation of the receiving module 1710.

[0168] As an example of a software functional unit, the receiving module 1710 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, or a container. Further, the aforementioned computing instance may be one or more. For example, the receiving module 1710 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed in the same region or in different regions. Further, the multiple hosts / virtual machines / containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including one or more geographically proximate data centers. Typically, a region may include multiple AZs.

[0169] Similarly, multiple hosts / virtual machines / containers used to run this code can be distributed within the same Virtual Private Cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Communication between two VPCs within the same region, as well as between VPCs in different regions, requires a communication gateway to be set up within each VPC to enable interconnection between VPCs.

[0170] As an example of a hardware functional unit, the receiving module 1710 may include at least one computing device, such as a server. Alternatively, the receiving module 1710 may also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be implemented using a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), or any combination thereof.

[0171] The multiple computing devices included in the receiving module 1710 can be distributed in the same region or in different regions. Similarly, the multiple computing devices included in the receiving module 1710 can be distributed in the same Availability Zone (AZ) or in different AZs. Likewise, the multiple computing devices included in the receiving module 1710 can be distributed in the same Virtual Private Cloud (VPC) or in multiple VPCs. These multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0172] It should be noted that, in other embodiments, the receiving module 1710 can be used to execute any step in the method shown in FIG. 16, the identification module 1720 can be used to execute any step in the method shown in FIG. 16, and the control module 1730 can be used to execute any step in the method shown in FIG. 16. The steps implemented by the receiving module 1710, the identification module 1720, and the control module 1730 can be specified as needed. By implementing different steps in the method shown in FIG. 16 through the receiving module 1710, the identification module 1720, the confirmation module 1730, and the control module 1730, all functions of the management platform 1700 can be realized.

[0173] This application also provides a computing device 1800. As shown in FIG18, the computing device 1800 includes: a bus 1802, a processor 1804, a memory 1806, and a communication interface 1808. The processor 1804, the memory 1806, and the communication interface 1808 communicate with each other via the bus 1802. The computing device 1800 may be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in the computing device 1800.

[0174] Bus 1802 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, only one line is used in Figure 18, but this does not imply that there is only one bus or one type of bus. Bus 1802 can include pathways for transmitting information between various components of computing device 1800 (e.g., memory 1806, processor 1804, communication interface 1808).

[0175] Processor 1804 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0176] The memory 1806 may include volatile memory, such as random access memory (RAM). The memory 1806 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0177] The memory 1806 stores executable program code, and the processor 1804 executes this executable program code to implement the functions of the aforementioned receiving module 1710, identification module 1720, and control module 1730, thereby realizing the method shown in FIG16. That is, the memory 1806 stores instructions for executing the method shown in FIG16.

[0178] The communication interface 1808 uses transceiver modules, such as, but not limited to, network interface cards and transceivers, to enable communication between the computing device 1800 and other devices or communication networks.

[0179] This application also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0180] As shown in Figure 19, the computing device cluster includes at least one computing device 1800. The memory 1806 of one or more computing devices 1800 in the computing device cluster may store the same instructions for executing the method shown in Figure 16.

[0181] In some possible implementations, the memory 1806 of one or more computing devices 1800 in the computing device cluster may also store partial instructions for executing the method shown in FIG16. In other words, a combination of one or more computing devices 1800 can jointly execute the instructions for executing the method shown in FIG16.

[0182] It should be noted that the memory 1806 in different computing devices 1800 within the computing device cluster can store different instructions, which are used to execute certain functions of the management platform 1700. That is, the instructions stored in the memory 1806 of different computing devices 1800 can implement the functions of one or more modules among the receiving module 1710, the identification module 1720, and the control module 1730.

[0183] In some possible implementations, one or more computing devices in a computing device cluster can be connected via a network. This network can be a wide area network (WAN) or a local area network (LAN), etc. Figure 20 illustrates one possible implementation. As shown in Figure 20, two computing devices 1800A and 1800B are connected via a network. Specifically, they are connected to the network through communication interfaces in each computing device. In this type of possible implementation, the memory 1806 in computing device 1800A stores instructions for performing the functions of the receiving module 1710. Simultaneously, the memory 1806 in computing device 1800B stores instructions for performing the functions of the identification module 1720 and the control module 1730.

[0184] It should be understood that the functions of computing device 1800A shown in Figure 20 can also be performed by multiple computing devices 1800. Similarly, the functions of computing device 1800B can also be performed by multiple computing devices 1800.

[0185] This application also provides another computing device cluster. The connection relationship between the computing devices in this computing device cluster can be similarly referred to the connection method of the computing device clusters shown in Figures 19 and 20. The difference is that the memory 1806 of one or more computing devices 1800 in this computing device cluster can store the same instructions for executing the method shown in Figure 16.

[0186] In some possible implementations, the memory 1806 of one or more computing devices 1800 in the computing device cluster may also store partial instructions for executing the method shown in FIG16. In other words, a combination of one or more computing devices 1800 can jointly execute the instructions for executing the method shown in FIG16.

[0187] This application also provides a computer program product containing instructions. The computer program product may be a software or program product containing instructions, capable of running on a computing device or stored on any usable medium. When the computer program product is run on at least one computing device, it causes the at least one computing device to perform the method shown in FIG16.

[0188] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that a computing device can store, or a host migration device such as a data center that includes one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to perform the method shown in FIG16.

[0189] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of this application.

Claims

1. A Java application control method characterized by comprising: The method is applied to a management platform, which is connected to or located within an infrastructure, the infrastructure including at least one data center, each of the at least one data center deploying multiple hosts, each of the multiple hosts being used to deploy containers; the method includes: The system receives an image input by the user, the image including bytecode corresponding to a Java application and runtime dependency files of the Java application; wherein, the bytecode corresponding to the Java application is compiled from the source code corresponding to the Java application, and the Java application is used to run in the target container in the infrastructure; Based on the Java native interfaces available in the bytecode corresponding to the Java application, the set of available system calls for the Java application is identified in the runtime dependency file; wherein, the available Java native interfaces are Java native interfaces that the Java application can use when running in the target container, and there is a call path between the system calls in the set of available system calls and the available Java native interfaces; When the Java application runs in the target container, the system calls that control the Java application actually use are within the set of available system calls.

2. The method of claim 1, wherein, The image includes multiple applications; the method further includes: using static program analysis to identify the Java application among the multiple applications.

3. The method according to claim 1 or 2, characterized in that, The bytecode corresponding to the Java application includes the entry function of the Java application, and there is a call path between the Java native interface and the entry function.

4. The method according to any one of claims 1-3, characterized in that, The method further includes: receiving the runtime environment of the target container input by the user; The system calls used by the Java application implementation are within the set of available system calls, including: Based on the aforementioned operating environment, the names of the system calls in the set of available system calls are obtained within the target container; Based on the name, the system calls actually used by the Java application are controlled to be within the set of available system calls.

5. The method according to any one of claims 1-4, characterized in that, The bytecode corresponding to the Java application includes the bytecode of the Java application itself and the bytecode of the Java application's dependent libraries.

6. The method according to any one of claims 1-5, characterized in that, The runtime dependencies include the Java Virtual Machine and / or the Java Software Development Kit.

7. A management platform, characterized in that, The management platform is connected to or located within the infrastructure, which includes at least one data center, each of which deploys multiple hosts, each of which is used to deploy containers; the management platform includes: A receiving module is used to receive an image input by a user. The image includes bytecode corresponding to a Java application and runtime dependency files of the Java application. The bytecode corresponding to the Java application is compiled from the source code corresponding to the Java application, and the Java application is used to run in a target container in the infrastructure. The identification module is used to identify the set of available system calls of the Java application in the runtime dependency file based on the available Java native interfaces in the bytecode corresponding to the Java application; wherein, the available Java native interfaces are Java native interfaces that the Java application can use when running in the target container, and there is a call path between the system calls in the set of available system calls and the available Java native interfaces; The control module is used to control the system calls actually used by the Java application within the set of available system calls when the Java application is running in the target container.

8. The management platform according to claim 7, characterized in that, The image includes multiple applications; the identification module is also used to: identify the Java application among the multiple applications using static program analysis.

9. The management platform according to claim 7 or 8, characterized in that, The bytecode corresponding to the Java application includes the entry function of the Java application, and there is a call path between the Java native interface and the entry function.

10. The management platform according to any one of claims 7-9, characterized in that, The receiving module is also used to: receive the operating environment of the target container input by the user; The control module is also used for: Based on the aforementioned operating environment, the names of the system calls in the set of available system calls are obtained within the target container; Based on the name, the system calls actually used by the Java application are controlled to be within the set of available system calls.

11. The management platform according to any one of claims 7-10, characterized in that, The bytecode corresponding to the Java application includes the bytecode of the Java application itself and the bytecode of the Java application's dependent libraries.

12. The management platform according to any one of claims 7-11, characterized in that, The runtime dependencies include the Java Virtual Machine and / or the Java Software Development Kit.

13. A computing device cluster, characterized in that, It includes at least one computing device, each computing device including a processor and memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the cluster of computing devices to perform the method as described in any one of claims 1 to 6.

14. A computer-readable storage medium, characterized in that, It includes computer program instructions, which, when executed by a cluster of computing devices, perform the method as described in any one of claims 1 to 6.

15. A computer program product containing instructions, characterized in that, When the instruction is executed by a cluster of computer devices, the cluster of computer devices causes the cluster of computer devices to perform the method as described in any one of claims 1 to 6.

Images