CN113672273B

CN113672273B - Data processing method, system and equipment

Info

Publication number: CN113672273B
Application number: CN202111228418.4A
Authority: CN
Inventors: 陈善佩; 邓二伟; 吴一昊
Original assignee: Alibaba Cloud Computing Ltd
Current assignee: Alibaba Cloud Computing Ltd
Priority date: 2021-10-21
Filing date: 2021-10-21
Publication date: 2022-04-15
Anticipated expiration: 2041-10-21
Also published as: CN113672273A

Abstract

The embodiment of the application provides a data processing method, a data processing system and data processing equipment. Wherein the method comprises the following steps: when a target function, a function to be replaced in the kernel program and a safety check area are determined according to the hot upgrade data packet, entering a shutdown state; the safety check area comprises a plurality of functions on a calling path where the function to be replaced is located in the kernel program; checking the processes of the functions in the safety check area; and when the checking result is safe, executing replacement operation on the function to be replaced according to the target function. According to the technical scheme, all processes and stack frames do not need to be comprehensively checked any more, but functions with possible risks in the safety check area corresponding to the target function are checked, complexity of stack safety check is reduced, efficiency of stack safety check can be effectively improved, and user experience during thermal upgrading can be improved.

Description

Data processing method, system and equipment

Technical Field

The present application relates to the field of computer technologies, and in particular, to a data processing method, system, and device.

Background

With the development of the Linux application requirements, the user requirements are increasingly diversified, and further, the differentiation requirements of the user on the Linux application system are more and more obvious.

Hot patching (or hot repair, or hot repair patch) is a technique for modifying software defects of a device without affecting the operation of the device. The hot patching technology not only provides a means for timely modifying software errors in the running system, but also can reduce the loss of client income caused by version upgrading. The hot repair is an online repair service facing mobile equipment or a server, provides silent update and fine-grained repair capability for an online version of an application APP or an operating system, helps developers to repair online problems in real time, and releases a lightweight function quickly.

In the existing hot repair technology, in order to ensure that a replaced function does not exist on a stack of any process when the function is replaced, a stack security check method is used to check all stack frames of each process. If the replaced function (i.e., the upgraded/repaired function) exists on the process' stack, a failure is checked. Moreover, the existing stack security check process during hot repair is high in complexity, and if the current system load is high, time consumption is long.

Disclosure of Invention

In order to solve or improve the problems in the prior art, embodiments of the present application provide a data processing method, system, and device.

In a first aspect, in one embodiment of the present application, a data processing method is provided. The method comprises the following steps:

when a target function, a function to be replaced in the kernel program and a safety check area are determined according to the hot upgrade data packet, entering a shutdown state; the safety check area comprises a plurality of functions on a calling path where the function to be replaced is located in the kernel program;

checking the processes of the functions in the safety check area;

and when the checking result is safe, executing replacement operation on the function to be replaced according to the target function.

In a second aspect, in one embodiment of the present application, another data processing method is provided. The method comprises the following steps:

acquiring path information of a call path of a function to be replaced in a kernel program;

analyzing the path information to determine whether a security check area exists, wherein the security check area contains a plurality of functions on the call path;

outputting the analysis result of whether the safety check area exists or not to assist in generating a hot upgrade data packet for the function to be replaced.

In a third aspect, in one embodiment of the present application, a data processing system is provided. The system comprises:

the client device is used for acquiring the path information of the call path of the function to be replaced in the kernel program; analyzing the path information to determine whether a security check area exists, wherein the security check area contains a plurality of functions on the call path; acquiring a kernel program hot repair module aiming at the function to be replaced when the safety check area exists;

the server is used for acquiring the kernel program hot repair module and determining a target function, a function to be replaced in the kernel program and a safety check area according to the kernel program hot repair module; the safety check area comprises a plurality of functions on a calling path where the function to be replaced is located in the kernel program; entering a shutdown state; checking the processes of the functions in the safety check area; when the checking result is safe, carrying out replacement operation on the function to be replaced according to the target function; and recovering the kernel program to be in a working state, and completing the hot repair of the kernel program.

In a fourth aspect, in one embodiment of the present application, there is provided an electronic device comprising a memory and a processor; wherein,

the memory is used for storing programs;

the processor, coupled to the memory, is configured to execute the program stored in the memory, so as to implement the data processing method of the first aspect or the other data processing method of the second aspect.

According to the technical scheme provided by the embodiment of the application, when the Linux kernel program is upgraded in a hot mode, the replaced function is not called by any process. Specifically, when a target function, a function to be replaced in a kernel program and a safety check area are determined according to a hot upgrade data packet, a shutdown state is entered; the safety check area comprises a plurality of functions on a calling path where the function to be replaced is located in the kernel program. And checking the processes of the functions in the security check area. And when the checking result is safe, executing replacement operation on the function to be replaced according to the target function. By adopting the technical scheme, all processes and stack frames do not need to be comprehensively checked any more, but functions with possible risks in the safety inspection area corresponding to the function to be replaced are checked, so that the complexity of stack safety inspection is reduced, the efficiency of stack safety inspection can be effectively improved, and the user experience during thermal restoration can be further improved.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly described below, and it is obvious that the drawings in the following description are some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative efforts.

Fig. 1 is a schematic flow chart of a data processing method according to an embodiment of the present application;

fig. 2 is a schematic structural diagram of a call path provided in the embodiment of the present application;

FIG. 3 is a schematic diagram of a security inspection area according to an embodiment of the present application;

fig. 4 is a schematic flowchart of another data processing method according to an embodiment of the present application;

fig. 5 is a schematic flowchart of a method for determining a security inspection area according to an embodiment of the present application;

fig. 6 is a schematic flowchart of a security check policy provided in an embodiment of the present application;

FIG. 7 is a block diagram of a data processing system according to an embodiment of the present application;

fig. 8 is a schematic structural diagram of a client device according to an embodiment of the present application;

fig. 9 is a schematic structural diagram of a data processing apparatus according to an embodiment of the present application;

fig. 10 is a schematic structural diagram of a server device according to an embodiment of the present application;

fig. 11 is a schematic structural diagram of another data processing apparatus according to an embodiment of the present application.

Detailed Description

When an electronic device (e.g., a server, etc.) with a Linux system installed is maintained, in order to reduce the influence on the operation of the electronic device, a Linux kernel is usually maintained in a hot repair or hot upgrade manner. However, in the maintenance process, if the function to be repaired or upgraded is found to be in the process of being called, the repair or upgrade work for the function to be replaced is terminated. If the function to be replaced is not checked or the function to be replaced is forcibly replaced after the function is checked to be wrong, the Linux system may be wrong, the normal operation of the electronic equipment is influenced, and the adverse effect on the using process of the electronic equipment of the user is relatively large. Therefore, before performing a hot repair or hot upgrade, a stack security check is typically performed on all process stacks of the system. The existing hot repair methods include, for example, a kpatch _ trace _ address _ verify method, an klp _ check _ stack _ function method, and the like of a dynamic kernel patch mechanism. The two methods are similar, whether potential safety hazards exist is judged by checking stack frames of all processes of the system, if the function to be repaired or upgraded exists on the stack of the process, the check fails, and the function to be repaired or upgraded cannot be repaired or upgraded. When the two methods are used for security check, the complexity is usually high, because when the security check is performed, the security check is performed on all processes and corresponding stack frames, which means that the complexity of the check is the product of the number of processes and the depth of the stack. In some security check methods, the process needs to be completed in a stop _ machine state, and the check complexity is large, which may increase the downtime and affect the normal operation of the electronic device. Moreover, some special functions, such as __ schedule, cannot be replaced by the existing method. Therefore, a technical solution is needed to satisfy a fast and simple security check before a function (e.g., a Linux kernel function) is repaired or upgraded.

In order to make the technical solutions better understood by those skilled in the art, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application.

In some of the flows described in the specification, claims, and above-described figures of the present application, a number of operations are included that occur in a particular order, which operations may be performed out of order or in parallel as they occur herein. The sequence numbers of the operations, e.g., 101, 102, etc., are used merely to distinguish between the various operations, and do not represent any order of execution per se. Additionally, the flows may include more or fewer operations, and the operations may be performed sequentially or in parallel. It should be noted that, the descriptions of "first", "second", etc. in this document are used for distinguishing different messages, devices, modules, etc., and do not represent a sequential order, nor limit the types of "first" and "second" to be different. In addition, the embodiments described below are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

In the technical solution of the present application, hot repair of a function in a Linux kernel program is taken as an example for description. The functions in the Linux kernel program comprise:

in order to realize the rapid stack security check, the kernel program may be analyzed, and the analysis result and/or the recommendation information may be displayed to the developer, so that the developer may develop a hot upgrade data packet for a certain function in the kernel program according to the analysis result and/or the recommendation information. For example, the analysis result is that the function to be replaced (i.e., the function that needs hot upgrade and hot repair) meets the stack security protection condition, and the kernel program includes the security check area corresponding to the function to be replaced. Therefore, a developer can develop a corresponding kernel module (namely a data packet for a function to be replaced for hot upgrade and hot repair) based on an analysis result, so that after a device (such as a server) with the kernel program loads the kernel module, the device can adopt a lightweight security strategy to carry out hot upgrade and hot repair without checking process stacks of all processes of the system and then replacing the function. It should be noted that the hot-upgrade data packet may also be a hot-repair data packet, and the process of performing a replacement operation by using the hot-repair data packet is the same as the process of performing a replacement operation based on the hot-upgrade data packet. The following will be explained by way of specific examples.

Fig. 1 is a schematic flow chart of a data processing method according to an embodiment of the present application. In a practical application scenario, the execution subject of the method may be an electronic device (e.g., a computer, a server, etc.). The method specifically comprises the following steps:

101: when a target function, a function to be replaced in the kernel program and a safety check area are determined according to the hot upgrade data packet, entering a shutdown state; the safety check area comprises a plurality of functions on a calling path where the function to be replaced is located in the kernel program.

102: and checking the processes of the functions in the security check area.

103: and when the checking result is safe, executing replacement operation on the function to be replaced according to the target function.

In practical application, fig. 2 is a schematic structural diagram of a call path provided in the embodiment of the present application. The calling relations which accord with execution logic exist among the functions called in the process, and the complete calling path can be known according to the calling relations. For example, it can be seen from fig. 2 that the call path is a chain call path. One or more functions in the call path may be functions to be replaced in this embodiment. Fig. 2 shows a case where the function 3 is a function to be replaced. If a plurality of functions needing to be replaced exist, the functions to be replaced can be analyzed one by one correspondingly.

The function to be replaced may be various types of functions in the Linux kernel, such as an interface function, a function with a specific function (e.g., a scheduler function), and the like. For example, in a kernel function upgrade job, if the upgrade operation of the kernel scheduler needs to perform a replacement operation on a plurality of different interface functions, each interface function in the scheduler may be referred to as a function to be replaced. If the plurality of functions to be replaced are respectively in different calling paths, corresponding function calling information needs to be determined from the corresponding calling paths respectively. In order to increase the processing speed of kernel data, when determining the function to be replaced in the call path, if there are multiple functions to be replaced in the call path, the call relationship among the multiple functions to be replaced may be determined. If the calling relation does exist among the functions to be replaced, the functions to be replaced can be checked at the same time.

The security check area includes a plurality of functions including a function to be replaced in the kernel program. Specifically, based on the function call information, whether a scheduling function exists in the downstream functions of the function to be replaced is traversed along a call path. And when a scheduling function exists, taking the region from the node where the function to be replaced to the node where the scheduling function is located as the safety inspection region.

As described in step 102, the checking the processes of the functions in the security check area includes: 1021: and acquiring process descriptors of processes in which the functions are located in the security check area. 1022: and checking whether a function with set behaviors exists in the plurality of functions or not based on the process descriptors of the processes of the plurality of functions. 1023: if the function with the set behavior exists, the check result is no pass. 1024: and when the function with the set behavior does not exist, the checking result is pass.

After the Linux kernel starts the init program as the first process, the specific information of each function in the process stack can be known through the process descriptor. The state field of the process descriptor describes the current state of the process, each process being in one of a plurality of states, including: task _ running, the process is executable. Task _ interrupt: interruptible, process is blocked: waiting to be awakened. Task _ noninterruptile: not interruptible, no response to the received signal, etc. For example, the call path and the process state of the function to be replaced, the call relationship of each function in the process stack, and the like can be known through the process descriptor. For example, whether a setting mutex behavior exists is searched from the process descriptor corresponding to the security check area, for example, whether a setting owner or waiter behavior exists. If the setting behavior exists, the function in the security check area is called by the process, and the sleep function and/or the context switch is triggered, the check result is not passed, and the security replacement cannot be carried out. If the setting behavior does not exist, the checking result is passed, and the function to be replaced can be safely replaced. Based on the security check mode, only the functions in the security check area are checked in a targeted manner, so that the check efficiency is effectively improved, and the process of checking the security check area in a targeted manner can be understood as lightweight stack security check.

The mutex lock is used in multithread programming to prevent two threads from reading from and writing to the same common resource (e.g., a global variable) at the same time. In the scheme of the application, the function of the mutual exclusion lock can be just utilized to interfere the execution process, and convenience is provided for the replacement operation of the function to be replaced.

The following describes a method for determining a security check area with reference to the drawings. Fig. 3 is a schematic diagram of a security inspection area according to an embodiment of the present application. As can be seen from fig. 3, the safety check area of the function to be replaced is indicated in a dashed box. When the safety inspection area is determined, starting from a node where the function to be replaced is located, searching a preset function along the downstream of a path where the function to be replaced is located, and if at least one of the following functions is searched: a function of mutual exclusion lock, a function of triggering process to enter sleep state, and a function of triggering context switch are required to be acquired. The whole area of the function to be replaced, including the preset function, is taken as a safety check area.

There may be two ways to perform the lightweight stack security check on the security check area. The following are each specifically exemplified.

One way is to check the process running state of each node function in the security check area. If the mutual exclusion lock is in an occupied state, the checking result indicates that a function exists in the security checking area and is called by the process, the checking result indicates that the function does not pass, and the replacement processing of the function to be replaced is terminated; if the mutual exclusion lock is checked to be in an unoccupied state, the check result is passed, and the function to be replaced can be replaced.

For example, as shown in fig. 3, when the node function No. 5 in fig. 3 acquires a mutex B lock, and after checking the security check area, finds that there is a mutex lock mutex B lock, it will further check whether the lock is occupied, that is, specifically check whether there is any setting behavior for owner and waiter. If the setting behavior also exists, it indicates that the function exists in the security check area, which is called by the process (in other words, there is a process in the security check area), and a sleep function and/or a context switch has been triggered, and the security check area is not secure. The checking mode only needs to check a mutex lock or waitq, does not need to traverse all processes, and is very quick operation. The specific process is as follows:

retry:

stop_machine();

check_owner_waiter();

if(success)

continue;

else

goto retry;

starting the check and stopping the machine. Checking the states of winner and waiter, if the states are occupied, indicating that the checking result of the current security check area is unsafe, and terminating the replacement operation of the function to be replaced. On the contrary, if the checked (each function in the) security check area is in a security state, it indicates that the check is passed, and the replacement operation will be performed on the function to be replaced. Of course, the specific replacement operation mode needs to be determined according to the type of the function to be replaced.

Another way is to insert a Reference counting function (Reference counting) before and after the sleep function and/or the context switch in the security check region where the function to be replaced is located. Specifically, obtaining a reference count value corresponding to a first function in the plurality of functions in the security check area, wherein the first function is responsible for triggering a process to enter a sleep state or switching contexts; and determining whether the function to be replaced can be unloaded or not based on the reference count value. For example, if a first function (e.g., do _ wait _ for _ common, __ schedule) exists in the security check area and triggers a sleep state or context switch, and the number of times the first function is referred is not zero, then a node function exists in the security check area and is called by the process, and the replacement processing of the function to be replaced is terminated. Otherwise, if the value is zero, the function in the security check area is currently in a secure state, and the replacement operation may be performed on the function to be replaced.

Based on the above embodiment, before replacing the function to be replaced, stack security check needs to be performed on the process related to the function to be replaced. Specifically, a safety check area related to the function to be replaced is locked from the scheduling path, the process state of the safety check area is further analyzed, and then the corresponding function processing mode to be replaced is executed according to the analysis result.

In practical application, if the function to be replaced is to be replaced, a scheme of adopting security protection can be performed in addition to the above-mentioned manner of lightweight stack security check. Specifically, the method comprises the following steps: and when determining that the function to be replaced meets the stack safety protection condition according to the hot upgrade data packet, performing safety protection operation on the function to be replaced. And then, according to the target function, performing replacement operation on the function to be replaced which completes the protection operation.

It should be noted that the safety protection operations corresponding to different stack safety protection conditions are different. The following specifically exemplifies corresponding security protection measures adopted under different stack security protection conditions.

One of the situations is: and when a mutual exclusion lock exists on an upstream calling path of the function to be replaced, the function to be replaced conforms to the stack safety protection condition, and the mutual exclusion lock is utilized to perform safety protection operation on the function to be replaced.

Specifically, when the mutex is located upstream of the security check area, it is determined that a corresponding security protection operation is adopted when the hot fix corresponding to the function to be replaced is executed. From fig. 3, a dashed box can be seen for representing the safety check area, which ranges from the function to be replaced to the sleep function cutoff. Because it belongs to the safe area only if there is a sleep function in the downstream path of the function to be replaced (e.g., the interface function). If the process has executed to the node function 8 after the sleep function, it does not belong to the safe range of the function to be replaced. Because if the process enters the node function 7 and the node function 8 in fig. 3 after executing the node function where the sleep function 6 is located, it can be considered that the function to be replaced has no hidden danger of replacement, and it is not necessary to perform stack security check on the function.

Further, performing a security protection operation on the function to be replaced, including: and defining the mutual exclusion lock as an occupied state so as to prevent the process of the function to be replaced from triggering and calling the function to be replaced to generate the action of the stack frame corresponding to the function to be replaced.

For example, as shown in fig. 3, in the node function 2 in fig. 3, there is a mutexA lock in an occupied state, which indicates that the process corresponding to the current call path is interrupted or jumps to another process. Then, the node functions 3 to 8 behind the mutexA are temporarily not in progress, i.e., are in a secure state, and the function to be replaced (node function 3 in fig. 3) can be replaced with the target function.

In the whole calling path, the node function No. 3 and the sub-path thereof belong to the safety check area. In the parent node of node function No. 3, node function No. 2 has a behavior of acquiring a mutex a lock, that is, the whole security check area is in the critical area of lock a, and at this time, stack security protection can be performed by using mutex a. The specific method comprises the following steps:

mutex_lock(mutex A);

mutex_unlock(mutex A);

by the safety protection processing mode, the process can be prevented from entering a safety inspection area, and potential safety hazards caused by replacement work of the function to be replaced are avoided; meanwhile, when function replacement operation is carried out, shutdown or thread synchronous operation is not needed, and normal operation of the electronic equipment can be effectively guaranteed.

In another case: and when the function to be replaced is a scheduling function, the function to be replaced meets the stack safety protection condition, and the function in charge of process switching in the scheduling function is utilized to perform safety protection operation on the scheduling function.

Specifically, if the function to be replaced is the scheduling function __ schedule, the flag after performing the security protection operation on the function to be replaced includes: if the function to be replaced is a scheduling function, splitting the scheduling function so as to enable the context switching execution to jump to the lower half part of the scheduling function, and replacing the upper half part of the function to be replaced.

For example, the simplified structure of the existing __ schedule function is as follows:

pick_next_task → put_prev_task → context_switch → finish_task_switch → ...

↓↑

switch_to

when the safety protection operation is carried out on the scheduling function, the method comprises the following steps: and entering a shutdown state. And modifying a second function in charge of process switching in the scheduling function so as to split the scheduling function into two parts, namely an upper part without a stack safety problem and a lower part with the stack safety problem, so that the lower part with the stack safety problem is executed after the second function is scheduled back to the process where the second function is located. And when the replacement is carried out, replacing the upper half part of the stack-free security problem by using an objective function.

For example: when in the stop _ machine state, the processes, except the replacement program and the stopper thread, are all in the switch _ to function, i.e., they all have a physically context switch at this point. This stack security problem is solved by modifying the return value of the switch _ to function as follows:

pick_next_task → put_prev_task → context_switch

↓

switch_to

↓

bottom half of original __ schedule function → finish _ task _ switch

The above-mentioned "lower half of original __ schedule function" can be understood as a springboard, in other words, the return value of switch _ to is modified so as to always return to the lower half of original __ schedule function. The strategy of __ is split into two parts by using the springboard technology: the upper half of the unstacked security problem, and the lower half of the unstacked security part. When replacing, only the upper half part without stack security problem is replaced, and the lower half part function after the switch _ to is not replaced. Thus, whether the original function or the new function is adopted, the next context switching can return to the springboard of the original function, and the stack security problem of replacing the upper half of __ schedule is solved.

A context switch is a switch from one process to another. Context switching defines a context switch function in kernel/sched.c. which performs two basic tasks. Calling the Switch _ mm defined in include/asm/menu _ context.h, and responsible for switching the virtual memory from one process mapping to a new process. The Switch _ to defined in include/asm/system.h is invoked to be responsible for switching from the processor state of the last process to the processor state of the new process.

Based on the same idea, the embodiment of the application further provides a data processing method. The method execution subject can be an electronic device such as a computer, and the like, and the method can help a developer generate the hot upgrade data packet suitable for replacing the specified function. Fig. 4 is a schematic flow chart of another data processing method provided in the embodiment of the present application, which includes the following steps

401: and acquiring the path information of the call path of the function to be replaced in the kernel program.

402: analyzing the path information to determine whether a security check area exists, wherein the security check area contains a plurality of functions on the call path.

403: outputting the analysis result of whether the safety check area exists or not to assist in generating a hot upgrade data packet for the function to be replaced.

Many functions are included in the kernel program. And replacing the target function when some functions have problems or need to be upgraded. Typically by generating hot upgrade data packets. Before generating the hot upgrade data packet, different upgrade strategies are formulated for different functions and different process states.

Before making a hot upgrade data packet, a developer already determines which functions in a current program need to be replaced, and judges whether a scheduling function exists in a calling path of the function to be replaced when traversing upstream and downstream calling relations in the calling path (__ schedule). Because the process progress can be searched and analyzed through __ schedule, and the process switching is interfered. In addition, since the context switch and sleep function are defined in the __ schedule function, in practical application, the setting behavior of the context switch and/or sleep function in the call path can be checked, and if the context switch and/or sleep function is set, there may be a function that triggers the context switch or sleep function in the process call. For example, if a context switch is triggered and a function to be replaced, which sends trigger information to the context switch (for example, is in the same call path), happens to be called by a process, it is unsafe to perform replacement of the function to be replaced, which may result in replacing the function to be replaced completely and continuing to perform the function to be replaced, which may result in an uncontrollable result. Therefore, such a risk needs to be investigated. On the contrary, if the setting behavior of the context switch and/or the sleep function is not found in the check result, and the corresponding function to be replaced is not in the half-execution process, the check result is safe, and the function to be replaced can be replaced by using the target function.

It should be noted that, in the above scheme, when replacing the function to be replaced with the target function, the function to be replaced that needs to be replaced is backed up and stored in or copied to another spare storage space. And then, replacing the storage space of the function to be replaced with the target function in the hot upgrade data packet.

The path information referred to herein includes functions, process states, and the like included in the call path. The analysis of the path information may be, for example, analysis of stack security protection conditions of a function to be replaced in the call path, analysis of a specific function setting behavior, and thus a corresponding mode of generating a hot upgrade data packet is specified.

When the analysis is carried out, the analysis can be carried out according to the situations, one is to analyze the stack safety protection condition, and the other is to analyze the lightweight stack safety inspection. Two different case analyses are exemplified below.

The process of analyzing the stack security protection condition will be described first.

And analyzing whether the function to be replaced meets the stack safety protection condition or not. And outputting an analysis result of whether the function to be replaced meets the stack safety protection condition or not, so as to generate the hot upgrade data packet aiming at the function to be replaced in an auxiliary manner by combining the analysis result.

For example, if the mutex lock is found to be located upstream of the security check area by analyzing the upstream related path information in the call path, it is determined that the stack security protection scheme can be adopted. That is, when the hot upgrade data package is developed, the stack security protection related code may be preset in the hot upgrade data package.

In addition, a special function needs to adopt a corresponding safety protection scheme separately, and the function is a scheduling function __ schedule. If the function to be replaced is a scheduling function, splitting the scheduling function so as to enable the context switching execution to jump to the lower half part of the scheduling function, and replacing the upper half part of the function to be replaced. Specifically, the upper half of the scheduling function without the stack security problem is replaced by adjusting the position of the switch _ to in the scheduling function and the return value. That is, when the hot upgrade data package is developed, the security protection related code of the scheme may be preset in the hot upgrade data package.

After the path information of the call path is acquired, whether a security check area exists or not and whether lightweight stack security analysis can be adopted or not are determined based on the path information. Fig. 5 is a schematic flowchart of a method for determining a security check area according to an embodiment of the present application. From fig. 5 it can be seen that the following steps are included:

501: and traversing whether a preset function exists in the downstream functions of the functions to be replaced along a calling path according to the path information.

502: when the preset function exists, determining a plurality of functions from the function to be replaced on the calling path to the preset function as the safety inspection area; wherein the preset function comprises at least one of: a function of mutual exclusion lock, a function of triggering process to enter sleep state, and a function of triggering context switch are required to be acquired.

For ease of understanding, a schematic diagram of the determination of the security check region in the call path can be seen in conjunction with fig. 3. And searching whether a preset function (such as a function for acquiring a mutual exclusion lock, a function for triggering a process to enter a sleep state, a function for triggering context switching and the like) exists in the downstream functions of the functions to be replaced from the path information. If the function exists, all functions starting from the function to be replaced and within the preset function cut-off range form a safety check area.

After the security check area is determined, and the mutual exclusion lock is found to be located in the security check area through analysis, a lightweight stack security check scheme can be performed on the security check area, and when a hot upgrade data packet is developed, a lightweight stack security check related code of the scheme can be preset in the hot upgrade data packet.

In some application scenarios, if not only the function to be replaced is to be replaced with the objective function, the function to be replaced needs to be further offloaded. Specifically, a Reference counting function may be inserted, and a Reference counting function may be inserted before and after a sleep function and/or a context switching point in the security check region. When a hot upgrade data packet is developed, the scenario-related code may be preset in the hot upgrade data packet. For the specific implementation of the replacement operation of the target function to be replaced by using the reference count, reference may be made to the above-mentioned embodiment, and details are not repeated here.

In the technical scheme of the application, when data processing is performed, a developer can analyze a lightweight stack security check strategy in an actual application scenario. In the client device of the developer, the display interactive interface with the relevant information can be seen, and the developer can visually and clearly see the function calling information through the display interactive interface. Furthermore, in response to an input operation of a user (for example, a developer) on the interactive interface, a function to be replaced, which is imported into the program by the user, and function call information in the program are acquired. In the actual development process, the function processing requirements of the developer are clear, so that the developer can directly specify which functions to be replaced exist, and further import the functions to be replaced and the function call information thereof. Through the processing procedure of the above embodiment, it is possible to provide recommendation information that a policy is required to be adopted for performing thermal repair on the function to be replaced (for example, whether to adopt a lightweight stack security check policy, whether to perform stack security protection, and the like as described above) for a subsequent worker. Subsequent developers can intuitively know the recommendation information of the strategy through the display interactive interface.

For ease of understanding, the security check flow is illustrated in its entirety below. Fig. 6 is a schematic flowchart of a security check policy according to an embodiment of the present application. As can be seen from fig. 6, after performing stack security analysis on the function to be replaced in the program, suggestion information is output to a developer working subsequently, where the suggestion information is whether a condition for adopting lightweight stack security check is satisfied (for example, it is determined whether a security check area exists in a path where the function to be replaced is located as described above). And under the condition that the security check area does not exist, adopting the traditional stack security check. Under the condition that a security check area exists, whether security protection or lightweight stack security check is adopted can be specifically classified. And after determining that the strategy to be adopted is a lightweight stack security check strategy, further generating a hot upgrade data packet corresponding to the function to be replaced.

In order to facilitate understanding of the above technical solutions, a description will be given below by taking an example of upgrading a certain kernel module. And generating a kernel module upgrading data packet in advance, and extracting the kernel module and the relocation tool from the kernel module upgrading data packet. And locking the original interface function needing to be replaced in the kernel function by using a relocation tool. Furthermore, the shutdown processing is carried out based on the stop machine mechanism, and then whether the original interface function to be replaced in the current kernel can be replaced is checked. Specifically, the method comprises the following steps:

it is assumed that only the interface functions of the kernel module need to be replaced when the kernel module is upgraded. Determining a calling path of the original interface function, determining the position of at least one original interface function from the calling path, and searching the mutex lock in the calling path. If the mutex lock is located at the upstream of the security check area of a certain original interface function, processing can be performed in a security protection operation mode, the mutex lock is started, the original interface function is replaced, and unlocking is performed after replacement is completed. And synchronizing other functions, public data and private data in the kernel module. And after the synchronization is completed, the shutdown is released, and the electronic equipment is recovered to be normal. If the mutex lock is found to be located in the security check area of a certain original interface function to be replaced, the mutex lock can be processed in a lightweight stack security check mode.

Therefore, although the scheduler module is upgraded, the inspection can be completed without stopping for too long under the condition that each original interface function meets the lightweight stack security inspection condition or the stack security protection processing condition. If the function is directly replaced through checking, the technical scheme can effectively improve the stack security check efficiency and the function upgrading efficiency.

Based on the same idea, the embodiment of the application further provides a data processing system. Fig. 7 is a schematic structural diagram of a data processing system according to an embodiment of the present application. As shown in fig. 7, the system includes:

the first client device 71 is configured to obtain path information of a call path where a function to be replaced in the kernel program is located; analyzing the path information to determine whether a security check area exists, wherein the security check area contains a plurality of functions on the call path; acquiring a kernel program hot repair module aiming at the function to be replaced when the safety check area exists;

the server 72 is configured to obtain the kernel program hot repair module, and determine a target function, a function to be replaced in the kernel program, and a security check area according to the kernel program hot repair module; the safety check area comprises a plurality of functions on a calling path where the function to be replaced is located in the kernel program; entering a shutdown state; checking the processes of the functions in the safety check area; when the checking result is safe, carrying out replacement operation on the function to be replaced according to the target function; and recovering the kernel program to be in a working state, and completing the hot repair of the kernel program.

Or to at least one second client device 73.

As can be seen from fig. 7, in the data processing system, a developer performs development work using a client device, and then repair processing can be performed on a server device using a hot upgrade data packet. Or, in another application scenario, the server may send the hot upgrade data packet to the second client device, so that the second client device performs repair processing by using the hot upgrade data packet.

An embodiment of the present application further provides a client device. Fig. 8 is a schematic structural diagram of a client device according to an embodiment of the present application. The electronic device comprises a memory 801, a processor 802 and a communication component 803; wherein,

the memory 801 is used for storing programs;

the processor 802, coupled to the memory, is configured to execute the program stored in the memory to:

The memory 801 described above may be configured to store various other data to support operations on the electronic device. Examples of such data include instructions for any application or method operating on the electronic device. The memory may be implemented by any type or combination of volatile or non-volatile memory devices, such as Static Random Access Memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic or optical disks.

Further, the processor 802 in this embodiment may specifically be: and the programmable exchange processing chip is provided with a data copying engine and can copy the received data.

The processor 802 may also perform other functions besides the above functions when executing the program in the memory, which can be referred to in the foregoing description of the embodiments. Further, as shown in fig. 8, the electronic device further includes: display component 804, and the like.

Based on the same idea, the embodiment of the application further provides a data processing device. Fig. 9 is a schematic structural diagram of a data processing apparatus according to an embodiment of the present application. The data processing apparatus includes:

an obtaining module 901, configured to obtain path information of a call path where a function to be replaced in a kernel is located.

A determining module 902, configured to analyze the path information, and determine whether a security check area exists, where the security check area includes a plurality of functions on the call path.

An output module 903, configured to output an analysis result of whether the security check area exists, so as to assist in generating a hot upgrade data packet for the function to be replaced.

Further, still include: an analysis module 904, configured to analyze whether the function to be replaced meets a stack security protection condition. And outputting an analysis result of whether the function to be replaced meets the stack safety protection condition or not, so as to generate the hot upgrade data packet aiming at the function to be replaced in an auxiliary manner by combining the analysis result.

Further, the analysis module 904 is further configured to, when a mutex lock exists on an upstream call path of the function to be replaced, conform the function to be replaced to a stack security protection condition; and when the function to be replaced is a scheduling function, the function to be replaced meets the stack safety protection condition.

Further, the determining module 902 is further configured to, according to the path information, traverse, along a call path, whether a preset function exists in downstream functions of the function to be replaced. And when the preset function exists, determining a plurality of functions from the function to be replaced to the preset function on the calling path as the safety inspection area. Wherein the preset function comprises at least one of: a function of mutual exclusion lock, a function of triggering process to enter sleep state, and a function of triggering context switch are required to be acquired.

An embodiment of the application further provides a server device. Fig. 10 is a schematic structural diagram of a server device according to an embodiment of the present application. The electronic device comprises a memory 1001, a processor 1002 and a communication component 1003; wherein,

the memory 1001 is used for storing programs;

the processor 1002, coupled to the memory, is configured to execute the program stored in the memory to:

checking the processes of the functions in the safety check area;

The memory 1001 described above may be configured to store other various data to support operations on the electronic device. Examples of such data include instructions for any application or method operating on the electronic device. The memory may be implemented by any type or combination of volatile or non-volatile memory devices, such as Static Random Access Memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic or optical disks.

Further, the processor 1002 in this embodiment may specifically be: and the programmable exchange processing chip is provided with a data copying engine and can copy the received data.

When the processor 1002 executes the program in the memory, other functions may be implemented in addition to the above functions, which may be specifically referred to in the description of the foregoing embodiments. Further, as shown in fig. 10, the electronic apparatus further includes: power components 1004, and other components.

Based on the same idea, the embodiment of the application further provides a data processing device. Fig. 11 is a schematic structural diagram of another data processing apparatus according to an embodiment of the present application. The data processing apparatus includes:

a determining module 1101, configured to determine, according to the hot upgrade data packet, a target function, a function to be replaced in the kernel program, and a security check area, and enter a shutdown state; the safety check area comprises a plurality of functions on a calling path where the function to be replaced is located in the kernel program.

A checking module 1102, configured to check a process in which the plurality of functions are located in the security check area.

And a replacing module 1103, configured to, when the check result is safe, perform a replacing operation on the function to be replaced according to the target function.

Further, the checking module 1102 is further configured to obtain process descriptors of processes in which the plurality of functions are located in the security check area. And checking whether a function with set behaviors exists in the plurality of functions or not based on the process descriptors of the processes of the plurality of functions. If the function with the set behavior exists, the check result is no pass. And when the function with the set behavior does not exist, the checking result is pass.

Further, still include: an obtaining module 1104, configured to obtain a reference count value corresponding to a first function in charge of triggering a process to enter a sleep state or a context switch in the plurality of functions in the security check area. And determining whether the function to be replaced can be unloaded or not based on the reference count value.

Further, the safety protection module 1105 is further configured to perform a safety protection operation on the function to be replaced when it is determined that the function to be replaced meets the stack safety protection condition according to the hot upgrade data packet. And executing replacement operation on the function to be replaced which finishes the protection operation according to the target function.

Further, the security protection module 1105 is further configured to, when a mutual exclusion lock exists on an upstream call path of the function to be replaced, enable the function to be replaced to meet a stack security protection condition, and perform a security protection operation on the function to be replaced by using the mutual exclusion lock. And when the function to be replaced is a scheduling function, the function to be replaced meets the stack safety protection condition, and the function in charge of process switching in the scheduling function is utilized to perform safety protection operation on the scheduling function.

Further, the security protection module 1105 is further configured to define the mutex lock as an occupied state, so as to prevent the process in which the function to be replaced is located from triggering an action of calling the function to be replaced to generate a stack frame corresponding to the function to be replaced.

Further, the replacing module 1103 is further configured to replace the function to be replaced with the target function.

Further, the safety protection module 1105 is also configured to, after entering a shutdown state; and modifying a second function in charge of process switching in the scheduling function so as to split the scheduling function into two parts, namely an upper part without a stack safety problem and a lower part with the stack safety problem, so that the lower part with the stack safety problem is executed after the second function is scheduled back to the process where the second function is located.

Further, the replacing module 1103 is further configured to perform a replacing operation on the upper half of the stack-free security problem according to the objective function.

Based on the above embodiment, when repairing or upgrading a problem function in the Linux kernel through a hot repair technology, it needs to be ensured that the modified or replaced function does not exist on the stack of any process. Specifically, a target function of a program and function call information in the program are obtained; determining whether a safety check area containing a stack frame corresponding to the target function exists in at least one process stack of the program or not according to the function calling information; wherein, the security check area comprises at least one stack frame; when the safety check area exists, determining to adopt a lightweight stack safety check strategy when executing the thermal restoration corresponding to the target function; and the lightweight stack security inspection strategy is to inspect a stack frame in the security inspection area. By adopting the technical scheme, all processes and stack frames do not need to be comprehensively checked any more, but functions with possible risks in the safety inspection area corresponding to the function to be replaced are checked, so that the complexity of stack safety inspection is reduced, the efficiency of stack safety inspection can be effectively improved, and the user experience during thermal restoration can be further improved.

The above-described embodiments of the apparatus are merely illustrative, and the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the present embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.

Through the above description of the embodiments, those skilled in the art will clearly understand that each embodiment can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware. With this understanding in mind, the above-described technical solutions may be embodied in the form of a software product, which can be stored in a computer-readable storage medium such as ROM/RAM, magnetic disk, optical disk, etc., and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the methods described in the embodiments or some parts of the embodiments.

Finally, it should be noted that: the above embodiments are only used to illustrate the technical solutions of the present application, and not to limit the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and such modifications or substitutions do not depart from the spirit and scope of the corresponding technical solutions in the embodiments of the present application.

Claims

1. A method of data processing, comprising:

when a target function, a function to be replaced in the kernel program and a safety check area are determined according to the hot upgrade data packet, entering a shutdown state; the safety check area comprises a plurality of functions on a calling path where the function to be replaced is located in the kernel program; the determination mode of the safety check area is determined based on a plurality of functions from the function to be replaced to a preset function on the calling path;

checking the processes of the functions in the safety check area;

2. The method of claim 1, wherein checking the processes of the plurality of functions in the security check area comprises:

acquiring process descriptors of processes in which the functions are located in the security check area;

checking whether a function with set behaviors exists in the plurality of functions based on the process descriptors of the processes where the plurality of functions are located;

when the function with the set behavior exists, the checking result is failed;

and when the function with the set behavior does not exist, the checking result is pass.

3. The method of claim 1, further comprising:

acquiring a reference count value corresponding to a first function which is in charge of triggering a process to enter a sleep state or switching context in the plurality of functions in the security check area;

and determining whether the function to be replaced can be unloaded or not based on the reference count value.

4. The method of any of claims 1 to 3, further comprising:

when the function to be replaced meets the stack safety protection condition according to the hot upgrading data packet, carrying out safety protection operation on the function to be replaced;

and executing replacement operation on the function to be replaced which finishes the protection operation according to the target function.

5. The method according to claim 4, wherein when the function to be replaced meets the stack security protection condition, performing security protection operation on the function to be replaced includes:

when a mutual exclusion lock exists on an upstream calling path of the function to be replaced, the function to be replaced conforms to a stack safety protection condition, and the mutual exclusion lock is utilized to perform safety protection operation on the function to be replaced;

and when the function to be replaced is a scheduling function, the function to be replaced meets the stack safety protection condition, and the function in charge of process switching in the scheduling function is utilized to perform safety protection operation on the scheduling function.

6. The method of claim 5, the performing a security operation on the function to be replaced, comprising:

defining the mutual exclusion lock as an occupied state to prevent the process of the function to be replaced from triggering and calling the function to be replaced to generate a stack frame corresponding to the function to be replaced;

the executing the replacement operation on the function to be replaced which completes the protection operation according to the target function comprises:

and replacing the function to be replaced with the target function.

7. The method of claim 5, performing a security protection operation on the scheduling function by using a function in charge of process switching in the scheduling function, comprising:

entering a shutdown state;

and modifying a second function in charge of process switching in the scheduling function so as to split the scheduling function into two parts, namely an upper part without a stack safety problem and a lower part with the stack safety problem, so that the lower part with the stack safety problem is executed after the second function is scheduled back to the process where the second function is located.

8. The method of claim 7, performing a replacement operation on the function to be replaced according to the objective function, comprising:

and according to the target function, performing replacement operation on the upper half part of the stack-free security problem.

9. A method of data processing, comprising:

analyzing the path information to determine whether a security check area exists, wherein the security check area contains a plurality of functions on the call path; the determination mode of the safety check area is determined based on a plurality of functions from the function to be replaced to a preset function on the calling path;

10. The method of claim 9, further comprising:

analyzing whether the function to be replaced meets the stack safety protection condition or not;

and outputting an analysis result of whether the function to be replaced meets the stack safety protection condition or not, so as to generate the hot upgrade data packet aiming at the function to be replaced in an auxiliary manner by combining the analysis result.

11. The method of claim 10, analyzing whether the function to be replaced complies with stack security protection conditions, comprising:

when a mutual exclusion lock exists on an upstream calling path of the function to be replaced, the function to be replaced accords with a stack safety protection condition;

and when the function to be replaced is a scheduling function, the function to be replaced meets the stack safety protection condition.

12. The method of any of claims 9 to 11, analyzing the path information to determine whether a security check area exists, comprising:

traversing whether a preset function exists in the downstream functions of the functions to be replaced along a calling path according to the path information;

when the preset function exists, determining a plurality of functions from the function to be replaced on the calling path to the preset function as the safety inspection area;

wherein the preset function comprises at least one of: a function of mutual exclusion lock, a function of triggering process to enter sleep state, and a function of triggering context switch are required to be acquired.

13. A data processing system comprising:

the server is used for acquiring the kernel program hot repair module and determining a target function, a function to be replaced in the kernel program and a safety check area according to the kernel program hot repair module; the safety check area comprises a plurality of functions on a calling path where the function to be replaced is located in the kernel program; entering a shutdown state; checking the processes of the functions in the safety check area; when the checking result is safe, carrying out replacement operation on the function to be replaced according to the target function; restoring the kernel program to a working state, and completing the hot repair of the kernel program;

the determination mode of the safety check area is determined based on a plurality of functions from the function to be replaced to a preset function on the calling path.

14. An electronic device comprising a memory and a processor; wherein,

the memory is used for storing programs;

the processor, coupled with the memory, for executing the program stored in the memory for implementing the method of any of the preceding claims 1 to 8; or the method of any of the above claims 9 to 12.