PLC program control method and device based on eBPF, PLC system and storage medium

Abstract

The invention provides a PLC program control method and device based on an eBPF, a PLC system and a storage medium, the method comprises the steps that eBPF byte codes of a target program from an IDE and used for downloading and configuration files corresponding to the eBPF byte codes are obtained, the eBPF byte codes are obtained by compiling the target program through the IDE, and the configuration files correspond to the eBPF byte codes; the target program comprises at least one of a PLC program, a PLC program library and a bus protocol plug-in; compiling the eBPF byte code into a target machine code according to a target framework operated by Runtime; and according to a target Hook point which is declared in the configuration file and corresponds to the target machine code, mounting the target machine code to the corresponding target Hook point. According to the method and the device, a plurality of technical problems caused by too many PLC equipment programs in the prior art are solved.

Description

Technical Field

[0001] This application relates to the field of PLC technology, and in particular to a PLC program control method and apparatus, PLC system and storage medium based on eBPF. Background Technology

[0002] A traditional PLC (Programmable Logic Controller) generally consists of two parts: an IDE (Integrated Development Environment) and a Runtime (the stage and environment in which the PLC control program actually runs on its operating system or execution engine). The IDE generates executable binary files from code written in electrical engineering languages. In addition to its own framework, the Runtime should also include as many current industrial bus protocols as possible (such as ModBus, CANOpen, etc.).

[0003] However, the diversity of electrical engineering languages ​​leads to a diversity of compilation toolchains, resulting in problems such as excessively large IDE installation packages, slow startup, and complex functionality. At the same time, the numerous industrial bus protocols currently available result in a large runtime framework, making fault localization difficult.

[0004] Therefore, the aforementioned problems exist in related technologies due to excessive PLC device programs. Summary of the Invention

[0005] This application provides a PLC program control method and apparatus, PLC system and storage medium based on eBPF, to at least solve at least one technical problem in the related art caused by too many programs in PLC devices.

[0006] According to one aspect of the embodiments of this application, a PLC program control method based on eBPF is provided, applied to a PLC device, comprising: Obtain the eBPF bytecode of the target program for download from the IDE and the configuration configuration file corresponding to the eBPF bytecode. The eBPF bytecode is obtained by the IDE compiling the target program. The target program includes at least one of the following: PLC program, PLC program library and bus protocol plugin. The eBPF bytecode is compiled into target machine code according to the target architecture of the Runtime. According to the target Hook point declared in the configuration file and corresponding to the target machine code, the target machine code is mounted to the corresponding target Hook point.

[0007] Optionally, as described above, obtaining the eBPF bytecode from the IDE for downloading the target program includes: Obtain the eBPF bytecode; The function depth and instruction validity of the eBPF bytecode are checked by a static code security checker. If the eBPF bytecode meets the preset first requirement based on the function depth and instruction validity, it is determined that the eBPF bytecode can be downloaded.

[0008] Optionally, as described above, obtaining the configuration file corresponding to the eBPF bytecode from the IDE includes: Obtain the configuration file; The static code security checker examines the runtime access control policy of the access point table in the configuration file. If the check result of the runtime access control policy meets the preset second requirement, the configuration file is determined to have passed the security check.

[0009] Optionally, as described above, compiling the eBPF bytecode into target machine code according to the target architecture running the runtime includes: According to the target architecture, the eBPF bytecode is compiled by just-in-time compilation to obtain the target machine code corresponding to the target architecture.

[0010] Optionally, as described above, before compiling the eBPF bytecode into target machine code according to the target architecture running the runtime, the method further includes: If it is determined that the eBPF bytecode is in the memory whitelist, the target machine code is determined to correspond to the first access permission, wherein the first access permission is used to indicate that the program after the eBPF bytecode is executed can only access the data in the dedicated eBPF Map memory pool. Determine the permissions of the auxiliary functions corresponding to the eBPF bytecode, wherein the permissions of the auxiliary functions are used to indicate the functions that the program can use after the eBPF bytecode is executed.

[0011] Optionally, as described above, after compiling the eBPF bytecode into target machine code according to the target architecture running the runtime, the method further includes: If the target machine code is a PLC program or a bus protocol plugin, the target machine code is cached in the business program area; If the target machine code is a third-party system library, the target machine code is cached in the function library program area.

[0012] Optionally, as described above, before attaching the target machine code to the corresponding target hook point according to the target hook point declared in the configuration file, the method further includes: Identify the target Hook point on the critical path to which the target machine code needs to be attached, and the target functional interface symbol corresponding to the target Hook point; Bind the target machine code to the target function interface symbol.

[0013] Optionally, as described above, the runtime environment includes: Protocol adaptation modules for compatibility with different bus protocol plugins; A data acquisition and output module that performs data acquisition and output through a connection with the protocol adaptation module, wherein the data acquisition and output module is also used to input the acquired data into a security sandbox for algorithm calculation; The configuration file is generated based on the device configuration information and the PLC program configuration. The device configuration information includes: bus protocol, configuration information corresponding to each bus protocol, and access point table. The PLC program configuration includes hook points corresponding to machine codes.

[0014] According to another aspect of the embodiments of this application, a PLC program control method based on eBPF is also provided, applied to an IDE terminal, including: Obtain the target program to be downloaded to the target PLC device, wherein the target program includes at least one of the following: PLC program, PLC program library and bus protocol plugin; The target program is compiled into eBPF bytecode, and a configuration file corresponding to the eBPF bytecode is obtained. Download the eBPF bytecode and the configuration file to the target PLC device.

[0015] According to another aspect of the embodiments of this application, an eBPF-based PLC device is also provided, comprising: The acquisition module is used to acquire the eBPF bytecode of the target program for download from the IDE and the configuration configuration file corresponding to the eBPF bytecode. The eBPF bytecode is obtained by the IDE compiling the target program. The target program includes at least one of the following: PLC program, PLC program library and bus protocol plugin. The compilation module is used to compile the eBPF bytecode into target machine code according to the target architecture of the Runtime. The mounting module is used to mount the target machine code to the corresponding target hook point according to the target hook point declared in the configuration configuration file and corresponding to the target machine code; The execution module is used to run the target machine code.

[0016] According to another aspect of the embodiments of this application, a computing device is also provided, comprising: The acquisition module is used to acquire the target program that needs to be downloaded to the target PLC device, wherein the target program includes at least one of the following: PLC program, PLC program library and bus protocol plugin; The compilation module is used to compile the target program into eBPF bytecode and obtain a configuration file corresponding to the eBPF bytecode. The download module is used to download the eBPF bytecode and the configuration file to the target PLC device.

[0017] According to another aspect of the embodiments of this application, a PLC system is also provided, including the PLC device as described in the foregoing embodiments and the computing device as described in the foregoing embodiments.

[0018] According to another aspect of the embodiments of this application, an electronic device is also provided, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; wherein the memory is used to store a computer program; and the processor is used to execute the method steps of any of the above embodiments by running the computer program stored in the memory.

[0019] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored therein, wherein the computer program is configured to execute the method steps of any of the above embodiments when running.

[0020] In this embodiment, the provided method for controlling a PLC program based on eBPF applied to the device side employs the following approach: Obtaining the eBPF bytecode of the target program from the IDE for downloading, along with a configuration file corresponding to the eBPF bytecode. The eBPF bytecode is compiled by the IDE from the target program, which includes at least one of the following: a PLC program, a PLC program library, and a bus protocol plugin. The method compiles the eBPF bytecode into target machine code according to the target architecture of the Runtime. Then, according to the target Hook points declared in the configuration file corresponding to the target machine code, the method mounts the target machine code to the corresponding target Hook points. Since only the target machine code of the target program that needs to be installed under the target architecture needs to be mounted and run, it eliminates the need to install unnecessary programs or machine code for other architectures. This effectively reduces the size of the IDE installation package and the Runtime framework in the PLC device, thereby solving the technical problem caused by excessive PLC device programs in related technologies. Attached Figure Description

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

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

[0023] Figure 1 This is a flowchart illustrating an optional eBPF-based PLC program control method for PLC devices according to an embodiment of this application. Figure 2 This is a flowchart illustrating an optional eBPF-based PLC program control method applied to an IDE terminal according to an embodiment of this application. Figure 3 This is a structural block diagram of another optional PLC device according to an embodiment of this application; Figure 4 This is a structural block diagram of another optional computing device according to an embodiment of this application; Figure 5 This is a structural block diagram of a system architecture consisting of the Runtime and PLCIDE of an optional PLC program based on the eBPF architecture, according to an embodiment of this application. Figure 6This is a structural block diagram of an optional electronic device according to an embodiment of this application. Detailed Implementation

[0024] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0025] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0026] First, some nouns or terms that appear in the description of the embodiments of this application shall be interpreted as follows: 1. eBPF is a virtual machine within the Linux kernel. When certain events (called hooks) occur, the kernel invokes eBPF programs. Examples of such hooks include system calls, network events, etc. The most popular toolchain for writing and debugging eBPF programs is called the BPF Compiler Collection (BCC), which is based on LLVM and CLang.

[0027] 2. Verification: Every eBPF program must undergo verification before being loaded into the kernel to ensure the security of the eBPF program.

[0028] 3. Just-In-Time (JIT) compilation is used to translate generic eBPF bytecode into a machine-dependent instruction set, thereby greatly accelerating the execution of BPF programs: compared to an interpreter, they can reduce the overhead per instruction. Typically, instructions can be mapped 1:1 to the native instructions of the underlying architecture.

[0029] 3. Hook Overview: BPF programs (i.e., hook point programs) are all event-driven. They run when the kernel or application passes through a certain hook point. These hook points are predefined and include system calls, function entry / exit, kernel tracepoints, network events, etc.

[0030] The eBPF-based PLC program control method of this application embodiment can be executed by a server, a terminal, or both. Specifically, the terminal can execute the eBPF-based PLC program control method of this application embodiment, or it can be executed by a client installed on it.

[0031] Taking the PLC program control method based on eBPF in this embodiment, executed by a PLC device, as an example, Figure 1 An eBPF-based PLC program control method for PLC devices, provided in this application embodiment, includes the following steps: Step S102: Obtain the eBPF bytecode of the target program for download from the IDE and the configuration configuration file corresponding to the eBPF bytecode. The eBPF bytecode is obtained by the IDE compiling the target program. The target program includes at least one of the following: PLC program, PLC program library and bus protocol plugin.

[0032] The eBPF-based PLC program control method in this embodiment can be applied to scenarios where programs are downloaded to PLC devices in a PLC system (i.e., a system including PLC devices and IDE terminals).

[0033] Specifically, the eBPF bytecode of the target program can be generated by compiling the PLC program, PLC program library, and bus protocol plugin on the IDE side. Optionally, the IDE side can obtain the target program to be downloaded to the target PLC device. In addition, developers can generate the target program for downloading to the target PLC device on the IDE side.

[0034] The target program is compiled into eBPF bytecode, and a configuration file corresponding to the eBPF bytecode is obtained. In other words, after generating the target program, this embodiment aims to slim down the PLC IDE and avoid the need to pre-compile the downloaded files during the PLC program compilation stage on the PLC device. It adopts a cross-compilation toolchain that removes architecture-related dependencies, uniformly compiling the target program into eBPF bytecode, thus achieving "compile once, use anywhere". Optionally, the clang compiler can be used to perform syntax analysis on ST programs, LD programs, FBD programs, and C / C++ programs to obtain an abstract syntax tree corresponding to the target program. This abstract syntax tree is then transformed to generate LLVM IR (Compiler Infrastructure Intermediate Representation, i.e., a platform-independent, strongly typed low-level intermediate language in LLVM used to represent program logic), and finally, the LLVM IR is converted into eBPF bytecode. This configuration file can be a metadata description file designed by the user in the IDE and used to guide how the eBPF bytecode is loaded and mounted.

[0035] Download the eBPF bytecode and configuration file to the target PLC device. Specifically, after obtaining the eBPF bytecode and configuration file, the IDE can communicate with the target PLC device to package the eBPF bytecode compiled from the user program and the configuration file together, and then download the eBPF bytecode to the target PLC device through the project.

[0036] Step S104: Compile the eBPF bytecode into target machine code according to the target architecture of the Runtime.

[0037] Specifically, eBPF bytecode is a hardware-independent intermediate code. To run eBPF bytecode in the runtime, it can be compiled according to the current target architecture (e.g., x86_64, ARM64, RISC-V, etc.) to obtain target machine code suitable for the target architecture. Target machine code is code that can be run directly on the target architecture.

[0038] Step S106: According to the target Hook point declared in the configuration configuration file and corresponding to the target machine code, mount the target machine code to the corresponding target Hook point.

[0039] Specifically, the Runtime framework program can start algorithm tasks and bus tasks according to the configuration configuration file, and dynamically attach the target machine code to the target hook point (i.e., the execution anchor point) according to the target hook point declared in the configuration configuration file that corresponds to the target machine code. Furthermore, hook points include, but are not limited to: algorithm lifecycle: START (initialization), RUN (periodic execution), END (cleanup); bus operation events: START, STOP, READ, WRITE, IOCTL.

[0040] After mounting is complete, wait for the event to be triggered, and then run the target machine code after starting the task.

[0041] In this embodiment, the method involves obtaining the eBPF bytecode of the target program for download from the IDE, along with the corresponding configuration file. The eBPF bytecode is obtained after the IDE converts the target program. The eBPF bytecode is compiled into target machine code according to the target architecture of the runtime. The target machine code is then mounted to the corresponding target hook point declared in the configuration file. This approach allows for the mounting and execution of only the target machine code of the program to be installed under the target architecture, eliminating the need to install unnecessary programs or machine code for other architectures. This effectively reduces the size of the IDE installation package and the runtime framework in the PLC device, thus solving the technical problem of excessive PLC device programs in related technologies.

[0042] As an optional embodiment, the method described above can be used to obtain the eBPF bytecode of the target program from the IDE for downloading by following these steps: Obtain the eBPF bytecode; specifically, after downloading the eBPF bytecode to the PLC device's Runtime environment on the IDE, the Linux kernel can automatically verify the eBPF bytecode. The Runtime can be used to trigger the loading process.

[0043] The function depth and instruction validity of the eBPF bytecode are checked by a static code security checker. If the eBPF bytecode meets the preset first requirement based on the function depth and instruction validity, it is determined that the eBPF bytecode can be downloaded.

[0044] Specifically, the kernel eBPF Verifier (i.e., static code security checker) can perform rigorous static analysis on the function depth and instruction legality of eBPF bytecode. Only if the first requirement is met will the eBPF bytecode be allowed to be JIT compiled and mounted to the specified target hook point for execution. This stage can be the first stage, checking the depth and instructions of the function (i.e., eBPF bytecode): by using depth-first traversal to check if it is a directed acyclic graph (DAG), that is, to determine whether the eBPF bytecode will get stuck in an infinite loop; checking each bytecode instruction (i.e., eBPF bytecode), and according to the instruction class, checking its register read / write attributes, whether memory access is out of bounds, and whether BPF_CALL (i.e., helper functions) conform to the interface protocol, etc.

[0045] As an optional embodiment, the method described above involves obtaining a configuration file from the IDE that corresponds to the eBPF bytecode, including: Obtain the configuration file; The static code security checker examines the runtime access control policy of the access point table in the configuration file. If the check result of the runtime access control policy meets the preset second requirement, the configuration file is deemed to have passed the security check. Specifically, this step can be a second-stage inspection of the eBPF bytecode: that is, customized security inspection of the eBPF bytecode based on the PLC semantic context; after the eBPF bytecode passes the first-stage inspection, the Runtime framework, in conjunction with the process point table (I / O variable table) defined in the configuration configuration file, performs domain-specific security checks on the access behavior of the eBPF bytecode, including: point table read / write permission check: verifying whether the eBPF program only accesses its authorized variables (such as HMI read-only, control logic writable); security state consistency check: ensuring that the eBPF bytecode does not perform unsafe operations when the system is in a safe state (such as emergency stop, maintenance mode); forced state intervention identification: detecting whether the eBPF bytecode bypasses the "variable forced" state to ensure the priority of manual intervention; blocking and real-time risk assessment: analyzing whether the eBPF bytecode may cause task timeouts or scheduling delays due to complex calculations or map access. Furthermore, this second type of detection relies on the binding relationship between eBPF bytecode and PLC variable symbols (usually declared via BTF or configuration metadata), which is completed by the user-mode runtime in collaboration with the kernel before loading or during runtime.

[0046] As an optional embodiment, the method described above can be implemented by compiling eBPF bytecode into target machine code according to the target architecture running at runtime through the following steps: According to the target architecture, the eBPF bytecode is compiled using just-in-time (JIT) compilation to obtain the target machine code corresponding to the target architecture. Specifically, JIT compilation can be a JIT compiler, which compiles the intermediate code (i.e., eBPF bytecode) obtained from the target program into the corresponding target machine code applicable to the target architecture before execution and caches it. This allows the target machine code to be executed directly, thus solving the problem of needing to parse intermediate code for each execution.

[0047] As an optional embodiment, the method described above, before compiling the eBPF bytecode into target machine code according to the target architecture running the runtime, further includes: If the eBPF bytecode is determined to be in the memory whitelist, the target machine code is determined to correspond to the first access permission. The first access permission is used to instruct the program after the eBPF bytecode is executed to only access data in the dedicated eBPF Map memory pool. In other words, under normal circumstances, the eBPF bytecode is in the memory whitelist and is therefore controlled by the memory whitelist. Consequently, when the eBPF bytecode is compiled into the target machine code and executed, it can only access data in the eBPF Map memory pool, thus avoiding the occurrence of machine code access exceeding permissions.

[0048] Determining the permissions of helper functions corresponding to the eBPF bytecode is crucial. Helper function permissions indicate the functions that the program can use after the eBPF bytecode runs. Specifically, to prevent system crashes or security vulnerabilities caused by improper calls to kernel functions, eBPF bytecode can only call helper functions provided by the kernel according to its permissions. Helper functions are a set of runtime-provided functions that can be used after the eBPF bytecode runs. These functions help programs perform specific tasks, such as accessing kernel data structures, performing network operations, and handling memory. Using these helper functions can greatly simplify the writing of eBPF bytecode and improve program efficiency and security, thereby effectively ensuring system security.

[0049] As an optional embodiment, the method described above, after compiling the eBPF bytecode into target machine code according to the target architecture running the runtime, further includes: When the target machine code is a PLC program or a bus protocol plugin, it is cached in the application program area. Specifically, machine code can be categorized as a PLC program, a bus protocol plugin, or a third-party system library. In this embodiment, if the target machine code is determined to be either a PLC program or a bus protocol plugin, it is cached in the application program area. Later, when mounting the target machine code as a PLC program or a bus protocol plugin, the cached target machine code can be retrieved from the application program area.

[0050] If the target machine code is a third-party system library, it is cached in the function library program area. In other words, if the target machine code is determined to be a third-party system library, it is cached in the function library program area. Then, when mounting the target machine code as a third-party system library later, the cached target machine code can be read from that function library program area.

[0051] Since different applications may use the same third-party library programs, this embodiment adopts a method of caching different types of programs in different program areas. That is, the PLC program or bus protocol plug-in is cached in the business program area, and the third-party library program is placed in the function library program area. Since the third-party library program does not change for a long time, it can be maintained in the function library program area. When downloading the third-party library program of other applications later, only the incremental version needs to be downloaded. The PLC program or bus protocol plug-in is cached in full in the business program area. By distinguishing the program areas, different maintenance methods can be used for different download strategies, which is more targeted.

[0052] As an optional embodiment, the method described above, before mounting the target machine code to the corresponding target Hook point as declared in the configuration file, the method further includes the following steps: determining the target Hook point that the target machine code needs to be mounted to on the critical path and the target function interface symbol corresponding to the target Hook point; binding the target machine code to the target function interface symbol. Specifically, during the runtime framework startup process, the algorithm tasks and protocol bus tasks are first parsed and initialized according to the configuration configuration file. Then, the preset target hook points on the critical execution path are determined (including START, RUN, END of the algorithm logic lifecycle, and START, STOP, READ, WRITE, IOCTL of the protocol bus operation). Specifically: for algorithm logic tasks, the runtime identifies the extension points required for each stage of its lifecycle and extracts the target function interface symbols (such as user_init_Hook, diag_filter_run) associated with events such as START, RUN, and END from the configuration. For protocol bus tasks, the runtime parses its data interaction flow according to the communication type (such as Modbus, CANopen) and matches the target function interface symbols (such as modbus_pre_read_validator, can_tx_encryptor) corresponding to operations such as READ and WRITE. Finally, the runtime binds the loaded and verified target machine code to the call entry point represented by the above target function interface symbols to complete the logic mounting. This embodiment achieves non-intrusive observation, auditing, filtering, and enhanced control of control behavior, data flow, and communication processes by pre-setting these standardized hook points on the critical paths of the runtime framework and algorithm / protocol implementation, and dynamically binding external extension code. Thus, the original core logic can be flexibly injected with diagnostic, security, or optimization functions without modification.

[0053] like Figure 5 As shown, the runtime environment, that is, the minimum runtime environment on the device side, can include: Protocol adaptation modules are used to adapt to different bus protocol plugins; that is, protocol adaptation modules are used to convert data corresponding to different bus protocols into data of a unified protocol.

[0054] The data acquisition and output module, which connects with the protocol adaptation module, performs data acquisition and output. It also inputs the acquired data into a security sandbox for algorithmic computation. Specifically, after receiving a task, the data corresponding to the task can be passed into the data input buffer, then into the I area (i.e., the input area, located within the eBPF map). The processed result after algorithmic computation is input into the Q area (i.e., the output area, located within the eBPF map). The processed result is then sent to the protocol adaptation module via the data output buffer and the task, whereby the module converts the processed result into data for the corresponding interface protocol.

[0055] A configuration file is generated based on device configuration information and PLC program configuration. The device configuration information includes: bus protocols, configuration information corresponding to each bus protocol, and an access point table. The PLC program configuration includes hook points corresponding to machine code. In other words, this configuration file can be a JSON file, which may include, but is not limited to, information such as bus protocols, configuration information corresponding to each bus protocol, and an access point table. The PLC program configuration may also include hook points corresponding to machine code. Furthermore, it may include configuration information for different protocols, the PLC program's execution cycle, and trigger conditions.

[0056] like Figure 2 As shown, according to another aspect of the embodiments of this application, a PLC program control method based on eBPF applied to an IDE terminal is also provided, including the following steps: Step S202: Obtain the target program to be downloaded to the target PLC device. The target program includes at least one of the following: a PLC program, a PLC program library, and a bus protocol plugin.

[0057] Step S204: Compile the target program into eBPF bytecode and obtain the configuration file corresponding to the eBPF bytecode; Step S206: Download the eBPF bytecode and configuration file to the target PLC device.

[0058] Specifically, the specific implementation of the above steps can be referred to the relevant implementation of steps S102 to S106 in the foregoing embodiments, and will not be repeated here.

[0059] As an optional application example of this application, a method for applying such as Figure 5 The system architecture shown is comprised of the PLC program's runtime and the PLC IDE, based on the eBPF architecture. 1) The PLC IDE uses a compiler to convert ST programs, LD programs, FBD programs, etc. into C language programs (e.g., C programs and C / C++ library programs).

[0060] 2) The PLC IDE uses the Clang compiler to perform syntax analysis on the C language program, obtain the abstract syntax tree corresponding to the source code (i.e., ST program, LD program, FBD program), transform the abstract syntax tree to generate LLVM IR, and then transform it into eBPF bytecode through LLVM IR.

[0061] 3) Install the eBPF bytecode / PLC configuration file from the PLC IDE into the PLC device's runtime environment and verify it.

[0062] 4) The eBPF Verifier is a static code security checker that ensures eBPF bytecode will not corrupt the runtime or affect its stability. The security check of eBPF bytecode is mainly divided into two stages: In the first phase, the existing eBPF framework is enhanced with tests to check the depth and instructions of the functions (i.e., eBPF bytecode). This is done using depth-first traversal to check if the graph is a directed acyclic graph (DAG). Each bytecode instruction (i.e., eBPF bytecode) is examined, and based on the instruction class, its register read / write attributes, memory accesses (whether they are out of bounds), and whether the BPF_CALL conforms to the interface protocol are checked.

[0063] The second stage involves customized testing of the PLC program, including checking read / write permissions for the access point table, setting the security state of the point table, the interface for mandatory state judgment when inserting point table entries, and checking blocking delays.

[0064] 5) eBPF JIT Compiler: In related technologies, interpreting and executing bytecode is a process that simulates the CPU executing machine code. At runtime, instructions need to be translated into machine code one by one before execution, so it is much less efficient than the execution of machine code.

[0065] In this application example, JIT (Just-In-Time) Compiler is used to address the inefficiency of virtual machines running intermediate code. JIT compilation first compiles the intermediate code (i.e., eBPF bytecode) into corresponding machine code and caches it before execution, allowing the machine code to be executed directly at runtime. This solves the problem of needing to parse intermediate code on every execution.

[0066] 6) Security Sandbox: a) Implement memory whitelist control for eBPF bytecode, ensuring it can only access data in the dedicated eBPF Map memory pool.

[0067] (b) Access control is applied to eBPF bytecode, allowing only restricted use of helper functions. Helper functions are a set of runtime-provided functions available within eBPF bytecode. These functions help programs perform specific tasks, such as accessing kernel data structures, performing network operations, and handling memory. Using these helper functions greatly simplifies eBPF bytecode writing and improves program efficiency and security. This is primarily for system security. To prevent improper calls to kernel functions from causing system crashes or security vulnerabilities, eBPF bytecode can only call kernel-provided eBPF helper functions.

[0068] 7) PLC program loading and binding: The compiled machine code of the program that has passed the security check is stored in two areas: the function library program area and the business program area.

[0069] The runtime framework program starts algorithm tasks and bus tasks according to the configuration file. It also attaches the specified hook point programs according to the configured functional interface symbols. a) Hook points of the algorithm logic (i.e., the algorithm task): START, RUN, END; b) Hook points of the protocol bus (i.e., bus task); START, STOP, READ, WRITE, IOCTL.

[0070] By embedding key points in the Runtime framework and algorithm logic / business protocol, non-intrusive observation and control of system behavior is achieved.

[0071] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0072] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM (Read-Only Memory) / RAM (Random Access Memory), magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0073] According to another aspect of the embodiments of this application, an eBPF-based PLC device is also provided for implementing the above-described eBPF-based PLC program control method applied to a PLC device. Figure 3 This is a structural block diagram of an optional eBPF-based PLC device according to an embodiment of this application, such as... Figure 3 As shown, the device may include: The acquisition module 31 is used to acquire the eBPF bytecode of the target program for download from the IDE and the configuration configuration file corresponding to the eBPF bytecode. The eBPF bytecode is obtained by the IDE after converting the target program. Compilation module 32 is used to compile eBPF bytecode into target machine code according to the target architecture of the Runtime; Mounting module 33 is used to mount the target machine code to the corresponding target hook point according to the target hook point declared in the configuration configuration file and corresponding to the target machine code.

[0074] It should be noted that the acquisition module 31 in this embodiment can be used to perform the above step S102, the compilation module 32 in this embodiment can be used to perform the above step S104, and the mounting module 33 in this embodiment can be used to perform the above step S106.

[0075] In addition to the modules described above, the apparatus in this embodiment may also include modules that execute any method in any of the embodiments of the eBPF-based PLC program control method applied to a PLC device.

[0076] like Figure 4 As shown, according to another aspect of the embodiments of this application, a computing device is also provided, comprising: The acquisition module 41 is used to acquire the target program to be downloaded to the target PLC device, wherein the target program includes at least one of the following: PLC program, PLC program library and bus protocol plugin; The compilation module 42 is used to compile the target program into eBPF bytecode and obtain the configuration file corresponding to the eBPF bytecode. Download module 43 is used to download the eBPF bytecode and configuration configuration file to the target PLC device.

[0077] It should be noted that the acquisition module 41 in this embodiment can be used to perform the above step S202, the compilation module 42 in this embodiment can be used to perform the above step S204, and the download module 43 in this embodiment can be used to perform the above step S206.

[0078] In addition to the modules described above, the apparatus in this embodiment may also include modules that execute any of the methods described in any of the foregoing embodiments of the eBPF-based PLC program control method applied to the IDE terminal.

[0079] It should be noted that the examples and application scenarios implemented by the above modules and corresponding steps are the same, but are not limited to the content disclosed in the above embodiments. It should be noted that the above modules, as part of the device, can operate in ways such as... Figure 1 The method shown can be implemented in either software or hardware within a hardware environment, where the hardware environment includes a network environment.

[0080] According to another aspect of the embodiments of this application, a PLC system is also provided, including the PLC device as described in the foregoing embodiments and the computing device as described in the foregoing embodiments.

[0081] According to another aspect of the embodiments of this application, an electronic device is also provided for implementing the above-described eBPF-based PLC program control method applied to a PLC device and the eBPF-based PLC program control method applied to an IDE terminal. The electronic device may be a server, a terminal, or a combination thereof.

[0082] According to another embodiment of this application, an electronic device is also provided, comprising: Figure 6 As shown, the electronic device may include: a processor 1501, a communication interface 1502, a memory 1503, and a communication bus 1504, wherein the processor 1501, the communication interface 1502, and the memory 1503 communicate with each other through the communication bus 1504.

[0083] Memory 1503 is used to store computer programs; When processor 1501 executes the program stored in memory 1503, it performs the following steps: Step S102: Obtain the eBPF bytecode of the target program for download from the IDE and the configuration configuration file corresponding to the eBPF bytecode. The eBPF bytecode is obtained by the IDE compiling the target program. The target program includes at least one of the following: PLC program, PLC program library and bus protocol plugin.

[0084] Step S104: Compile the eBPF bytecode into target machine code according to the target architecture of the Runtime.

[0085] Step S106: According to the target Hook point declared in the configuration configuration file and corresponding to the target machine code, mount the target machine code to the corresponding target Hook point.

[0086] Step S202: Obtain the target program to be downloaded to the target PLC device. The target program includes at least one of the following: PLC program, PLC program library, and bus protocol plugin.

[0087] Step S204: Compile the target program into eBPF bytecode and obtain the configuration file corresponding to the eBPF bytecode.

[0088] Step S206: Download the eBPF bytecode and configuration file to the target PLC device.

[0089] Optionally, in this embodiment, the communication bus can be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. This communication bus can be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is used to represent it in the figure, but this does not mean that there is only one bus or one type of bus. The communication interface is used for communication between the aforementioned electronic device and other devices.

[0090] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0091] As an example, the memory 1503 described above may include, but is not limited to, the acquisition module 31, compilation module 32, mounting module 33, acquisition module 41, compilation module 42, and download module 43 from the PLC device and computing device described above. Furthermore, it may include, but is not limited to, other module units from the PLC device and computing device described above, which will not be elaborated upon in this example.

[0092] The processor mentioned above can be a general-purpose processor, including but not limited to: CPU (Central Processing Unit), NP (Network Processor), etc.; it can also be DSP (Digital Signal Processor), ASIC (Application Specific Integrated Circuit), FPGA (Field-Programmable Gate Array) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0093] This application also provides a computer-readable storage medium, which includes a stored program, wherein the program executes the method steps of the above method embodiments when it runs.

[0094] Optionally, in this embodiment, the storage medium may include, but is not limited to, various media capable of storing program code, such as USB flash drives, ROMs, RAMs, portable hard drives, magnetic disks, or optical disks.

[0095] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0096] If the integrated units in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in the aforementioned computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause one or more computer devices (which may be personal computers, servers, or network devices, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0097] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0098] In the several embodiments provided in this application, it should be understood that the disclosed client can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between units or modules, and may be electrical or other forms.

[0099] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of the solution provided in this embodiment, depending on actual needs.

[0100] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0101] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A PLC program control method based on eBPF, characterized in that, Applied to PLC equipment, including: Obtain the eBPF bytecode of the target program for download from the IDE and the configuration configuration file corresponding to the eBPF bytecode. The eBPF bytecode is obtained by the IDE compiling the target program. The target program includes at least one of the following: PLC program, PLC program library and bus protocol plugin. The eBPF bytecode is compiled into target machine code according to the target architecture of the Runtime. According to the target Hook point declared in the configuration file and corresponding to the target machine code, the target machine code is mounted to the corresponding target Hook point.

2. The method according to claim 1, characterized in that, The process of obtaining the eBPF bytecode from the IDE for downloading the target program includes: Obtain the eBPF bytecode; The function depth and instruction validity of the eBPF bytecode are checked by a static code security checker. If the eBPF bytecode meets the preset first requirement based on the function depth and instruction validity, it is determined that the eBPF bytecode can be downloaded.

3. The method according to claim 1, characterized in that, The step of obtaining the configuration configuration file corresponding to the eBPF bytecode from the IDE includes: Obtain the configuration file; The static code security checker examines the runtime access control policy of the access point table in the configuration file. If the check result of the runtime access control policy meets the preset second requirement, the configuration file is determined to have passed the security check.

4. The method according to claim 1, characterized in that, The process of compiling the eBPF bytecode into target machine code according to the target architecture running the runtime includes: According to the target architecture, the eBPF bytecode is compiled by just-in-time compilation to obtain the target machine code corresponding to the target architecture.

5. The method according to claim 1, characterized in that, Before compiling the eBPF bytecode into target machine code according to the target architecture running the runtime, the method further includes: If it is determined that the eBPF bytecode is in the memory whitelist, the target machine code is determined to correspond to the first access permission, wherein the first access permission is used to indicate that the program after the eBPF bytecode is executed can only access the data in the dedicated eBPF Map memory pool. Determine the permissions of the auxiliary functions corresponding to the eBPF bytecode, wherein the permissions of the auxiliary functions are used to indicate the functions that the program can use after the eBPF bytecode is executed.

6. The method according to claim 1, characterized in that, After compiling the eBPF bytecode into target machine code according to the target architecture of the Runtime, the method further includes: If the target machine code is a PLC program or a bus protocol plugin, the target machine code is cached in the business program area; If the target machine code is a third-party system library, the target machine code is cached in the function library program area.

7. The method according to any one of claims 1 to 6, characterized in that, Before attaching the target machine code to the corresponding target hook point as declared in the configuration file, the method further includes: Identify the target Hook point on the critical path to which the target machine code needs to be attached, and the target functional interface symbol corresponding to the target Hook point; Bind the target machine code to the target function interface symbol.

8. The method according to claim 1, characterized in that, The runtime environment includes: Protocol adaptation modules for compatibility with different bus protocol plugins; A data acquisition and output module that performs data acquisition and output through a connection with the protocol adaptation module, wherein the data acquisition and output module is also used to input the acquired data into a security sandbox for algorithm calculation; The configuration file is generated based on the device configuration information and the PLC program configuration. The device configuration information includes: bus protocol, configuration information corresponding to each bus protocol, and access point table. The PLC program configuration includes hook points corresponding to machine codes.

9. A PLC program control method based on eBPF, characterized in that, Applied to the IDE, including: Obtain the target program to be downloaded to the target PLC device, wherein the target program includes at least one of the following: PLC program, PLC program library and bus protocol plugin; The target program is compiled into eBPF bytecode, and a configuration file corresponding to the eBPF bytecode is obtained. Download the eBPF bytecode and the configuration file to the target PLC device.

10. A PLC device based on eBPF, characterized in that, include: The acquisition module is used to acquire the eBPF bytecode of the target program for download from the IDE and the configuration configuration file corresponding to the eBPF bytecode. The eBPF bytecode is obtained by the IDE compiling the target program. The target program includes at least one of the following: PLC program, PLC program library and bus protocol plugin. The compilation module is used to compile the eBPF bytecode into target machine code according to the target architecture of the Runtime. The mounting module is used to mount the target machine code to the corresponding target hook point according to the target hook point declared in the configuration configuration file.

11. A computing device, characterized in that, include: The acquisition module is used to acquire the target program that needs to be downloaded to the target PLC device, wherein the target program includes at least one of the following: PLC program, PLC program library and bus protocol plugin; The compilation module is used to compile the target program into eBPF bytecode and obtain a configuration file corresponding to the eBPF bytecode. The download module is used to download the eBPF bytecode and the configuration file to the target PLC device.

12. A PLC system, characterized in that, It includes the PLC device as described in claim 10 and the computing device as described in claim 11.

13. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, wherein the computer program is configured to perform the method described in any one of claims 1 to 8 or 9 when run on a processor.

Images