Configuration file-based hot patch making method

Abstract

The present application relates to a configuration file-based hot patch making method, comprising: adding a patch_conf parameter for storing a storage path of a hot patch configuration file; customizing the hot patch configuration file; obtaining and parsing the configuration file to obtain a hashmap type variable; sequentially returning corresponding file contents from the hashmap type variable according to required parsed key values; checking the returned file contents; further processing the returned file contents to make a hot patch using a hot patch making command. The present application is based on a configuration file, can simplify a complex making process, is more in line with hot patch making and management requirements, and can standardize made management hot patches.

Description

Hot-patching method based on configuration files Technical Field

[0001] This invention relates to the field of hot patch creation technology, and more specifically to a hot patch creation method based on configuration files. Background Technology

[0002] Hot patching refers to a technique that fixes code vulnerabilities or defects without restarting the current service, ensuring uninterrupted business operations. As hot patching technology continues to develop, hot patch creation tools are also constantly being updated and iterated. These tools allow developers to more easily create hot patches from modified code and flexibly enable or disable them, providing convenient management functions for hot patch creation and implementation.

[0003] However, current hot patch creation tools can only meet single creation needs and cannot create in batches. If you want to create another hot patch after it has been created, you still need to repeat the tedious creation process and repeatedly input too many complex parameters.

[0004] Current hot patch creation and management tools simply generate hot patches by passing the necessary parameters to the tool via a creation command. Hot patches created in this way are only suitable for temporary use. If the patch code needs to be modified multiple times, complex parameters must be manually entered each time the patch is recreated. Furthermore, the generated patches lack a unified identifier and naming convention, making it difficult to manage and trace a large number of patches, thus unsuitable for standardized large-scale patch creation and management. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention provides a hot patching method based on configuration files, comprising the following steps:

[0006] Step S1: In the hot patch generation program, add the patch_conf parameter to the input parameters. The patch_conf parameter is used to store the storage path of the hot patch configuration file.

[0007] Step S2: Customize the hot patch configuration file and save the storage path of the configuration file in the patch_conf parameter;

[0008] Step S3: Read the path given in the patch_conf parameter, obtain and parse the configuration file, and get a variable of type hashmap;

[0009] Step S4: Read the hashmap type variable and return the corresponding file content from the hashmap type variable according to the key value to be parsed;

[0010] Step S5: Check the file content returned in step S4. If it does not meet the requirements, return an error. If it meets the requirements, proceed to step S6.

[0011] Step S6: Further process the returned file content and use the hot patch creation command to create a hot patch.

[0012] In step S2, the hot patch configuration file includes a hot patch build field build_args and a specific information record field patch_info. The hot patch build field build_args is used to record the parameters required for hot patch building, and the specific information record field patch_info is used to record relevant information that is unrelated to the build but needs to be known by the creator.

[0013] The parameter information recorded in the hot patch build_args field includes: patch name, patch description, modified source code location, corresponding debug package location (debuginfo), modified code patch, output file and save file location (output), patch version information (patch-version), and the system architecture matched by the patch (patch_arch).

[0014] The specific information recorded in the patch_info field includes the following parameters: the name of the single patch (patch-full-name), the number of the VCE issue resolved (cve_id), the commit point ID of the submitted code (commit-id), and the kernel version from which the patch comes (patch-from-kernel-version).

[0015] In the hot patch configuration file, the parameter information recorded in the hot patch build field build_args and the specific information record field patch_info is stored in the form of key-value pairs.

[0016] In step S3, the configuration file is parsed to obtain a variable of type hashmap:

[0017] Combine the key value corresponding to the parameter information in the hot patch build domain build_args with "build_args" to get a new key value "build_args::key". Combine the new key value "build_args::key" with the value corresponding to the original key value to get a new key-value pair.

[0018] The key value corresponding to the parameter information in the specific information record field patch_info is combined with "patch_info" to obtain a new key value "patch_info::key". The new key value "patch_info::key" is combined with the value corresponding to the original key value to obtain a new key-value pair.

[0019] Step S4 includes:

[0020] Determine if the value corresponding to the parameter represented by the key to be parsed can be multiple:

[0021] If the value corresponding to the parameter represented by the key can only be one, check if the "patch_info::key" or "build_args::key" corresponding to the key exists in the hashmap variable: if it exists, retrieve the value of "patch_info::key" or "build_args::key" corresponding to the key from the hashmap variable and return the key and value; if it does not exist, return the key and the default value corresponding to that key.

[0022] If the value corresponding to the parameter represented by the key can be multiple, check whether the "patch_info::key" or "build_args::key" corresponding to the key exists in the hashmap variable:

[0023] If it exists, retrieve multiple values ​​corresponding to the key value from the hashmap type variable, such as "patch_info::key" or "build_args::key", separate the multiple values ​​with commas, convert them to string type, convert them to vec type using collect(), and return the key value and the corresponding vec.

[0024] If it does not exist, return the key value and an empty array vec![].

[0025] Step S5 includes:

[0026] Step S51: Define an empty variable of type vec;

[0027] Step S52: For each key field that the configuration file must contain, check whether the returned file content includes the required key fields:

[0028] If it is not included, the key value of the missing key field will be pushed into a variable of type vec;

[0029] Step S53: After all the required key fields have been checked, if the vec type variable is still empty, return success; if the vec type variable is not empty, return error.

[0030] Step S5 further includes:

[0031] Check if the value corresponding to the key "source" is a file; if not, return an error.

[0032] Check if the value corresponding to the key "debuginfo" is a file; if not, return an error.

[0033] Check if the value corresponding to the key "patch" is a file; if not, return an error.

[0034] Check if the value corresponding to the key "patch_arch" is consistent with the system architecture "arch". If they are inconsistent, return an error.

[0035] Step S6 includes:

[0036] Check if the value corresponding to the key "patch-name" starts with "SGL": if it does not start with "SGL", do not process this value; if it does start with "SGL", then further check as follows:

[0037] If the value only contains SGL, then add the time information after SGL;

[0038] If SGL is followed by a "-12-digit number", then check if the key value is the same as the value corresponding to patch-version and patch-release. If so, then report an error.

[0039] If there are other string formats after SGL, an error will be reported directly.

[0040] This invention is based on configuration files, which simplifies the complex production process, better meets the needs of hot patch production and management, and can standardize the management of existing hot patches. Detailed Implementation

[0041] To gain a better understanding of the technical solution and beneficial effects of the present invention, the technical solution of the present invention and its beneficial effects are described in detail below.

[0042] Existing methods for creating hot patches first involve modifying the code of the program to be patched; then, a hot patch creation command is used, followed by parameters such as patch-name, patch-description, source, debuginfo, output, verbose, skip-cleanup, and patch, to execute the command and create the corresponding hot patch. These commands have numerous parameters, and errors are difficult to pinpoint if entered incorrectly.

[0043] This invention attempts to simplify the above command parameter operations by providing only one configuration file parameter, checking the configuration file parameter for correctness before production, providing error parameter information, and storing the configuration file for making hot patches and all raw materials in a designated storage for future reference or reuse.

[0044] Based on this, the concept of this invention is to provide a unified production template. Each time a patch is created, only the information specified in the template needs to be filled in and the configuration file saved. Afterwards, patches can be created based on the configuration file, and the original data can be saved. A customized template configuration file is written, containing all parameters and related information. If multiple hot patches need to be created, multiple configuration files can be created simultaneously, or multiple hot patch configurations can be added to a configuration file. The parameters in the configuration file are obtained, and based on the parameter type, they are parsed into different processing methods, returning the corresponding data structure. The type of each parameter is analyzed, and it is checked whether the parameter meets the requirements for hot patch creation. If it does, the parsed parameters are used to create the hot patch; otherwise, an error message is returned. The current configuration file is stored, and relevant patch information and production materials are saved to a specified storage location.

[0045] The hot patch creation method based on configuration files includes the following steps 1 to 7.

[0046] 1. To ensure compatibility with scenarios where no configuration file is used, the patch_conf parameter will be added to the input parameters of the hot patch generation program. The patch_conf parameter is used to store the storage path of the hot patch configuration file.

[0047] `patch_conf` is the parameter name of the hot patch creation command, followed by the path to the configuration file defined in the first step. For example, `command --patch_conf file_path`, where `command` is the hot patch creation command, `--patch_conf` is the parameter name, and `file_path` is the actual path to the configuration file defined in the first step. The program reads the data following `patch_conf` as its input parameters, thus retrieving the configuration file.

[0048] 2. Customize a hot patch configuration file that conforms to the rules of the configuration file, and save the storage path of the configuration file in the patch_conf parameter.

[0049] The configuration file includes the `build_args` field for hot patch builds and the `patch_info` field for recording detailed information. The `build_args` field records parameters required for hot patch builds, such as: patch name (`patch-name`), patch description (`patch-description`), location of modified source code (`source`), location of the corresponding debug package (`debuginfo`), patch name (`patch`), output file and save location (`output`), patch version information (`patch-version`), and the system architecture matched by the patch (`patch_arch`). The `patch_info` field records information unrelated to the build process but necessary for developers, such as: patch name (`patch-full-name`), the VCE issue number (`cve_id`) that the patch addresses (`cve_id`, which is empty if it's not a CVE patch), the commit ID of the submitted code (`commit-id`), and the kernel version from which the patch comes (`patch-from-kernel-version`). The `patch_info` field includes two types of detailed information recording fields: CVE patch detailed information recording fields and ordinary patch detailed information recording fields.

[0050] The `patch-for-kernel-version` field applies to the entire hot patch, so it has only one value. However, a hot patch may contain multiple specific patches that address different issues. Since the number is uncertain, the format of the description information is also uncertain. Therefore, it's necessary to add numbers to the other parameters in the `patch_info` field, giving each patch a prefix, such as `patch1.patch-full-name`, `patch2.patch-full-name`. During parsing, the numbers are incremented sequentially starting from 1. If the user skipped one of the numbers when writing the configuration file, and `patch3` was defined directly without `patch2`, then the incrementing continues until a number matching the prefix is ​​found and parsed.

[0051] The hot-patching build field `build_args` and the detailed information record field `patch_info` are enclosed in brackets `[]`, indicating that all parameter definitions within that field begin from this point. Each field contains the corresponding parameter, defined using the format "name=value". If a parameter has multiple values, they are separated by commas.

[0052] 3. Read the configuration file to obtain a variable of type hashmap.

[0053] The program first checks if the `patch_conf` parameter appears in the input parameters. If it doesn't, it defaults to using the original program's parameter configuration and parsing method. Otherwise, it uses the path defined by the `patch_conf` parameter as the program's input parameter, reads the path information, and opens the file at the given path. If this fails, it returns an error message. Otherwise, it reads the contents of the file sequentially, filtering out lines starting with `#`. If a line is enclosed in square brackets `[]`, it represents the field value, either the `[build_args]` field or the `[patch_info]` field. The left side of the equals sign in the `[build_args]` or `[patch_info]` field is the key value. The field value and the key value are combined using `::` to form a new key value, and the right side is the value value, forming a new key-value pair. For example, for the `[build_args]` field, each line is stored in the format "build_args::patch-name:TEST-SGL", where `build_args::patch-name` is the combined key value, and `TEST-SGL` is the corresponding value value. The value value is stored as a string by default.

[0054] 4. Read the hashmap type variable and return the corresponding file content from the hashmap type variable according to the key value to be parsed.

[0055] Specifically, the type of the corresponding parameter can have multiple values ​​based on the name of the key value to be parsed. For example, in the build_arg field, patch can have multiple values ​​(i.e., a hot patch can contain multiple specific patches), and multiple values ​​are separated by commas. Other parameters can only have one value.

[0056] If the value corresponding to the parameter represented by the key can only be one, check if the "patch_info::key" or "build_args::key" corresponding to the key exists in the hashmap variable: if it exists, retrieve the value of "patch_info::key" or "build_args::key" corresponding to the key from the hashmap variable and return the key and value; if it does not exist, return the key and the default value corresponding to that key.

[0057] If the value corresponding to the parameter represented by the key can be multiple, check whether the "patch_info::key" or "build_args::key" corresponding to the key exists in the hashmap variable:

[0058] If it exists, retrieve multiple values ​​corresponding to the key value from the hashmap type variable, such as "patch_info::key" or "build_args::key", separate the multiple values ​​with commas, convert them to string type, convert them to vec type using collect(), and return the key value and the corresponding vec.

[0059] If it does not exist, return the key value and an empty array vec![].

[0060] 5. Check the contents of the returned file. If the contents do not meet the requirements, return an error. This includes steps 51 to 57 below.

[0061] 51. Define an empty variable of type vec;

[0062] 52. For each key field that the configuration file must contain, check whether the returned file content includes the required key fields:

[0063] If it is not included, the key value of the missing key field will be pushed into a variable of type vec;

[0064] 53. After all required key fields have been checked, if the vec type variable is still empty, it means that no required parameters are missing, and a success result is returned; if the vec type variable is not empty, it means that the key value stored in the vec type variable is the key value of the missing required key field, and the missing key value information is returned to the user as an error message.

[0065] 54. Check if the value corresponding to the key "source" is a file; if not, return an error.

[0066] 55. Check if the value corresponding to the key "debuginfo" is a file; if not, return an error.

[0067] 56. Check if the value corresponding to the key "patch" is a file; if not, return an error.

[0068] 57. Determine whether the value corresponding to the key value patch_arch is consistent with the system architecture arch. If they are inconsistent, return an error.

[0069] If any of the above steps are incorrect, an error message will be returned; if all are correct, proceed to the next step.

[0070] 6. Further process the parameter values ​​of the returned file content.

[0071] All parameters related to the paths contained in the parameter definitions in the configuration file, including the source code storage path in build_args, the debug package storage path debuginfo, and the patch storage path, are converted to fs::normalize format.

[0072] Check if the value corresponding to the key "patch-name" starts with "SGL": if it does not start with "SGL", do not process the value and use the original name directly;

[0073] If it starts with SGL, then the following further checks are performed:

[0074] If the value only contains SGL, then time information is added after SGL to change the name of the package, so that the name of the SGL package is different each time it is created;

[0075] If SGL is followed by "-12 digits", it means that this package is an upgrade package of a previous SGL. In this case, the key value and the value corresponding to patch-version and patch-release cannot both be 1 at the same time, otherwise an error will occur.

[0076] If there are other types of strings after SGL, then patch-name does not meet the definition requirements and will directly report an error.

[0077] 7. Create and save hot patch information. Assuming the parameters are correct based on the parsed data, use the hot patch creation command to create a hot patch. After creation, save the configuration file and source code materials (specifically the debug package and the actual patch file) created in step 1 to the specified storage location. When the user needs to create another patch or needs to view specific patch information, they can easily retrieve the relevant information based on the current structure.

[0078] This invention is based on configuration files, which simplifies the complex production process, better meets the needs of hot patch production and management, and can standardize the management of existing hot patches.

[0079] Although the present invention has been described using the above preferred embodiments, it is not intended to limit the scope of protection of the present invention. Any changes and modifications made by those skilled in the art to the above embodiments without departing from the spirit and scope of the present invention shall still fall within the scope of protection of the present invention. Therefore, the scope of protection of the present invention shall be defined by the claims.

Claims

1. A hot-patching method based on configuration files, characterized in that, The process includes the following steps: Step S1: In the hot patch generation program, add the `patch_conf` parameter to the input parameters. The `patch_conf` parameter is used to store the storage path of the hot patch configuration file. Step S2: Customize the hot patch configuration file and save the storage path of the configuration file in the `patch_conf` parameter. The hot patch configuration file includes a hot patch build field `build_args` and a specific information recording field `patch_info`. The hot patch build field `build_args` is used to record the parameters required for hot patch building, and the specific information recording field `patch_info` is used to record relevant information that is unrelated to the build but needs to be known by the creator. The parameter information recorded in the hot patch build field `build_args` includes: patch name `patch-name`, patch description `patch-description`, modified source code location `source`, corresponding debug package location `debuginfo`, modified code patch `patch`, output file and save file location `output`, patch version information `patch-version`, and the system architecture matched by the patch `patch_arch`. The parameter information recorded in the specific information recording field `patch_info` includes: the name of a single patch `patch-full-name`, and the VCE problem number `cve_i`. d. The commit ID of the submitted code (commit-id) and the kernel version from which the patch comes (patch-fromkernel-version); In the hot patch configuration file, the parameter information recorded in the hot patch build field (build_args) and the specific information record field (patch_info) is stored in the form of key-value pairs; Step S3: Read the path given in the patch_conf parameter, obtain and parse the configuration file to get a hashmap type variable; Combine the key value corresponding to the parameter information in the hot patch build field (build_args) with "build_args" to get a new key value "bu The code snippet `ild_args::key` combines the new key value `build_args::key` with the value corresponding to the original key value to obtain a new key-value pair. It then combines the key value corresponding to the parameter information in the `patch_info` field with `patch_info` to obtain a new key value `patch_info::key`. Finally, it combines the new key value `patch_info::key` with the value corresponding to the original key value to obtain a new key-value pair. Step S4: Read the hashmap type variable and return the corresponding file content from the hashmap type variable according to the key value to be parsed.Step S4 includes: determining whether the value corresponding to the parameter represented by the key value to be parsed can be multiple; if the value corresponding to the parameter represented by the key value can only be one, determining whether the "patch_info::key" or "build_args::key" corresponding to the key value exists in a hashmap variable; if it exists, retrieving the value of "patch_info::key" or "build_args::key" corresponding to the key value from the hashmap variable and returning the key value and value; if it does not exist, returning the key value and the default value corresponding to that key value; if the value corresponding to the parameter represented by the key value can be multiple, determining whether the "patch_info::key" or "build_args::key" corresponding to the key value exists in a hashmap variable; if it exists, retrieving multiple values ​​of "patch_info::key" or "build_args::key" corresponding to the key value from the hashmap variable, separating the multiple values ​​with commas, converting them to string type, and then using collect( Convert the key to a vec and return the key value and the corresponding vec; if it does not exist, return the key value and an empty array vec![]; Step S5: Check the file content returned in step S4. If it does not meet the requirements, return an error. If it meets the requirements, execute step S6; Step S5 includes: Step S51: Define an empty vec type variable; Step S52: For the key fields that the configuration file must contain, determine whether the returned file content contains the required key fields. If not, push the key value of the missing key field into the vec type variable; Step S53: After all the required key fields have been determined, if the vec type variable is still empty, return success; if the vec type variable is not empty, return an error; Step S5 also includes: Determine whether the key value is the source. The system checks whether the value corresponding to the key "debuginfo" is a file; if not, it returns an error. It also checks whether the value corresponding to the key "patch" is a file; if not, it returns an error. Finally, it checks whether the value corresponding to the key "patch_arch" matches the system architecture (arch); if not, it returns an error. Step S6 further processes the returned file content and uses a hot patch creation command to create a hot patch. Step S6 includes: determining whether the value corresponding to the key "patch-name" starts with "SGL"; if not, no processing is performed on this value.If it starts with "SGL", then further checks are performed as follows: If the value only contains "SGL", then add the time information after "SGL"; if "SGL" is followed by a "-12-digit number", then check if the key value corresponding to both "patch-version" and "patch-release" is 1; if so, an error is raised; if "SGL" is followed by other types of strings, an error is raised directly.