CN118260766A - Bug repairing method and device for vehicle-mounted Linux operating system and electronic equipment - Google Patents
Bug repairing method and device for vehicle-mounted Linux operating system and electronic equipment Download PDFInfo
- Publication number
- CN118260766A CN118260766A CN202410346707.1A CN202410346707A CN118260766A CN 118260766 A CN118260766 A CN 118260766A CN 202410346707 A CN202410346707 A CN 202410346707A CN 118260766 A CN118260766 A CN 118260766A
- Authority
- CN
- China
- Prior art keywords
- data set
- patch
- vulnerability
- patch data
- semantic model
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 62
- 238000012549 training Methods 0.000 claims abstract description 44
- 238000012937 correction Methods 0.000 claims abstract description 24
- 238000012550 audit Methods 0.000 claims abstract description 6
- 238000004891 communication Methods 0.000 claims description 21
- 238000012552 review Methods 0.000 claims description 13
- 238000004590 computer program Methods 0.000 claims description 3
- 230000008569 process Effects 0.000 description 5
- 238000001514 detection method Methods 0.000 description 4
- 238000011156 evaluation Methods 0.000 description 4
- 238000012545 processing Methods 0.000 description 4
- 230000008439 repair process Effects 0.000 description 4
- 238000010586 diagram Methods 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 238000005457 optimization Methods 0.000 description 3
- 238000002790 cross-validation Methods 0.000 description 2
- 238000013135 deep learning Methods 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 238000007781 pre-processing Methods 0.000 description 2
- 238000010200 validation analysis Methods 0.000 description 2
- 230000004913 activation Effects 0.000 description 1
- 238000004458 analytical method Methods 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 238000013528 artificial neural network Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000015572 biosynthetic process Effects 0.000 description 1
- 238000004422 calculation algorithm Methods 0.000 description 1
- 238000004140 cleaning Methods 0.000 description 1
- 238000013527 convolutional neural network Methods 0.000 description 1
- 238000013480 data collection Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 230000008713 feedback mechanism Effects 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 238000003058 natural language processing Methods 0.000 description 1
- 210000002569 neuron Anatomy 0.000 description 1
- 238000011022 operating instruction Methods 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 230000000306 recurrent effect Effects 0.000 description 1
- 238000013515 script Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
- 239000013598 vector Substances 0.000 description 1
Classifications
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02T—CLIMATE CHANGE MITIGATION TECHNOLOGIES RELATED TO TRANSPORTATION
- Y02T10/00—Road transport of goods or passengers
- Y02T10/10—Internal combustion engine [ICE] based vehicles
- Y02T10/40—Engine management systems
Landscapes
- Debugging And Monitoring (AREA)
Abstract
The embodiment of the application provides a method, a device and electronic equipment for repairing loopholes of a vehicle-mounted Linux operating system, wherein the method comprises the following steps: periodically acquiring an issued Linux system patch by a Linux functional network, and comparing the distributed Linux system patch with the patch of the current Linux system to form an initial patch data set; identifying the initial patch data set based on the semantic model to obtain a first vulnerability patch data set and a first non-vulnerability patch data set; obtaining a second vulnerability patch data set and a second non-vulnerability patch data set from the first non-vulnerability patch data set based on the CVE list of the NVD database; the auditing team audits the first vulnerability patch data set and the second vulnerability patch data set to obtain a correction training set; the revised training set is input into the semantic model to update the semantic model. According to the bug repairing method of the vehicular Linux operating system, the bug can be repaired before the system running problem is caused by the bug, and the bug recognition accuracy is high and the speed is high.
Description
Technical Field
The embodiment of the application relates to the technical field of the safety enhancement of a vehicular Linux kernel, in particular to a method and a device for repairing loopholes of a vehicular Linux operating system, electronic equipment and a computer storage medium.
Background
Currently, for vulnerability detection of a Linux operating system, the following modes are mainly adopted:
Rule-based vulnerability detection techniques: such techniques primarily identify possible vulnerabilities through preset rules. For example, the static code analysis tool can identify vulnerabilities that may exist in the source code according to established rules.
Signature-based vulnerability detection technology: this type of technique identifies known vulnerabilities by matching known malicious code signatures. However, this approach is less effective at identifying unknown or newly emerging vulnerabilities.
Expert system: this is an early technique to identify and solve problems through the knowledge of the coding expert. But the cost of updating and maintenance is high and it is difficult to deal with the new unknown problem.
Moreover, in all the above ways, it is necessary to determine based on a signature of a man-made operation or a specific vulnerability with malicious code. And when the loopholes do not appear, the loopholes cannot be detected and repaired in time.
Disclosure of Invention
In view of the above, the embodiment of the application provides a method, a device, an electronic device and a computer storage medium for repairing a bug of a vehicular Linux operating system, which can repair the bug before the bug causes the system running problem, and has high bug recognition accuracy and high speed.
According to a first aspect of an embodiment of the present application, there is provided a bug fix method for a vehicular Linux operating system, the method including: periodically acquiring an issued Linux system patch by a Linux official network, and comparing the distributed Linux system patch with the patch of the Linux system to form an initial patch data set; identifying the initial patch data set based on a semantic model to obtain a first vulnerability patch data set and a first non-vulnerability patch data set; obtaining a second vulnerability patch data set and a second non-vulnerability patch data set from the first non-vulnerability patch data set based on the CVE list of the NVD database; an auditing team audits the first vulnerability patch data set and the second vulnerability patch data set to obtain a correction training set; inputting the correction training set into the semantic model to update the semantic model.
According to a second aspect of the embodiment of the present application, there is provided a device for repairing a bug in a vehicular Linux operating system, including: the first acquisition module is used for periodically acquiring an issued Linux system patch by a Linux official network and comparing the distributed Linux system patch with the current Linux system patch to form an initial patch data set; the first identification module is used for identifying the initial patch data set based on a semantic model so as to obtain a first vulnerability patch data set and a first non-vulnerability patch data set; the second acquisition module is used for acquiring a second vulnerability patch data set and a second non-vulnerability patch data set from the first non-vulnerability patch data set based on the CVE list of the NVD database; the correction module is used for auditing the first vulnerability patch data set and the second vulnerability patch data set by an auditing team to obtain a correction training set; and the updating module is used for inputting the correction training set into the semantic model so as to update the semantic model.
According to a third aspect of an embodiment of the present application, there is provided an electronic apparatus including: the device comprises a processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface complete communication with each other through the communication bus; the memory is configured to store at least one executable instruction, where the executable instruction causes the processor to execute an operation corresponding to the bug fix method for a vehicular Linux operating system according to the first aspect.
According to a fourth aspect of an embodiment of the present application, there is provided a computer storage medium having stored thereon a computer program which, when executed by a processor, implements the bug fix method of the vehicular Linux operating system according to the first aspect.
According to the bug repairing method for the vehicular Linux operating system provided by the embodiment of the application, a semantic model is adopted to identify whether the patches in the initial patch data set acquired from the Linux functional network are bug patches. If the identified patch is a corresponding vulnerability and is suitable for the currently used Linux version, then the patch is automatically incorporated into the Linux kernel. The obtained initial patch data is identified through the semantic model, so that the method is more rapid, and the step of manual operation is saved. The safety and stability of the vehicular Linux system are improved. And the vulnerability can be identified and repaired before the vulnerability of the Linux system is subjected to the operation problem.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments described in the embodiments of the present application, and other drawings may be obtained according to these drawings for a person having ordinary skill in the art.
FIG. 1 is a flowchart of a bug fixes method for a vehicular Linux operating system according to an embodiment of the first aspect of the present application;
FIG. 2 is a flowchart illustrating steps after step S1 of a bug fix method for a vehicular Linux operating system according to an embodiment of the first aspect of the present application;
FIG. 3 is a step-by-step flowchart of step S3 of a bug fix method for a vehicular Linux operating system according to an embodiment of the first aspect of the present application;
FIG. 4 is a step-by-step flowchart of step S4 of a bug fix method for a vehicular Linux operating system according to an embodiment of the first aspect of the present application;
FIG. 5 is a flowchart of one embodiment of a method for bug fixes in a vehicular Linux operating system according to an embodiment of the first aspect of the present application;
FIG. 6 is a flowchart illustrating a method for bug fixes in a vehicular Linux operating system according to an embodiment of the first aspect of the present application;
FIG. 7 is a flowchart of a semantic model update of a bug fix method of an on-vehicle Linux operating system according to an embodiment of the first aspect of the present application;
FIG. 8 is a schematic diagram illustrating a bug fixing apparatus for a vehicular Linux operating system according to a second embodiment of the present application;
Fig. 9 is a schematic structural diagram of an electronic device according to a third embodiment of the present application.
Detailed Description
In order to better understand the technical solutions in the embodiments of the present application, the following description will clearly and completely describe the technical solutions in the embodiments of the present application with reference to the accompanying drawings in the embodiments of the present application, and it is obvious that the described embodiments are only some embodiments of the present application, not all embodiments. All other embodiments, which are derived by a person skilled in the art based on the embodiments of the present application, shall fall within the scope of protection of the embodiments of the present application.
The following describes in detail a method, a device, an electronic device and a computer storage medium for repairing a bug in a vehicular Linux operating system according to an embodiment of the present application with reference to fig. 1 to fig. 9 of the accompanying drawings.
According to an embodiment of the first aspect of the present invention, as shown in fig. 1, a bug fix method for a vehicular Linux operating system includes:
Step S1, periodically acquiring an issued Linux system patch by a Linux official network, and comparing the distributed Linux system patch with the current Linux system patch to form an initial patch data set;
In this step, specifically, the latest patch of the Linux system may be obtained by periodically using the Linux functional network, so as to ensure that the patch of the Linux system is latest. Comparing all patches of Linux obtained in a single time with patch information of a local Linux system, removing updated patches of the Linux system, and reserving the latest patches obtained in the current time to form an initial patch data set.
Step S2, identifying the initial patch data set based on a semantic model to obtain a first vulnerability patch data set and a first non-vulnerability patch data set;
In this step, specifically, the patches in the initial patch dataset may be semantically identified by a semantic model. Thus, the patches are automatically identified as vulnerability patches or non-vulnerability patches through the semantic model. Thereby improving the identification efficiency of the patch. No manual operation is required. The vulnerability patches are formed into a first vulnerability patch data set, and the non-vulnerability patches are formed into a first non-vulnerability patch data set.
One skilled in the art will appreciate that the semantic model can perform targeted semantic recognition based on training and user configuration.
Step S3, obtaining a second vulnerability patch data set and a second non-vulnerability patch data set from the first non-vulnerability patch data set based on the CVE list of the NVD database;
And comparing the first non-vulnerability patch data set identified by the semantic model with the CVE list of the NVD database, and judging whether misjudged vulnerability patches exist in the first non-vulnerability patch data set. And if so, forming a second vulnerability patch data set. The remaining non-vulnerability patches form a second non-vulnerability patch data set.
S4, auditing the first vulnerability patch data set and the second vulnerability patch data set by an auditing team to obtain a correction training set;
And auditing the first vulnerability patch data set and the second vulnerability patch data set by an auditing team. Checking whether the first vulnerability patch data has a non-vulnerability patch or not, and for which reason the first non-vulnerability patch data forms a second vulnerability patch data set.
In other words, the semantic model is identified as a non-vulnerability patch and is actually identified as a vulnerability patch by comparing with the CVE list of the NVD database, and the semantic model is identified as a vulnerability patch and the review team identifies that the patch is not a vulnerability patch, so that a data error sample, namely a correction training set, is formed.
And S5, inputting the correction training set into the semantic model to update the semantic model.
In the step, the training set is corrected to continuously keep up with the new semantic model, so that the model is subjected to self correction and continuous training, and the recognition accuracy of the semantic model can be improved.
According to the bug repairing method for the vehicular Linux operating system provided by the embodiment of the application, a semantic model is adopted to identify whether the patches in the initial patch data set acquired from the Linux functional network are bug patches. If the identified patch is a corresponding vulnerability and is suitable for the currently used Linux version, then the patch is automatically incorporated into the Linux kernel. The obtained initial patch data is identified through the semantic model, so that the method is more rapid, and the step of manual operation is saved. The safety and stability of the vehicular Linux system are improved. And the vulnerability can be identified and repaired before the vulnerability of the Linux system is subjected to the operation problem.
In some embodiments of the present invention, step S1 further comprises:
step S101: comparing the initial patch data set with the kernel patch of the Linux system to obtain patch update data;
the system periodically synchronizes patch submission of the main line branch and the stable branch of the Linux kernel, and ensures that the system is synchronized with the latest kernel patch.
And step S102, a patch update log is established based on the patch update data.
By the patch update data, a patch update log including the patch update data is established locally, so that a patch update record log can be formed.
In some embodiments of the present invention, step S3 further comprises:
step S301, a first Hash value of a patch in the non-vulnerability patch dataset and a second Hash value of a CVE list of an NVD database are obtained;
Specifically, in this step, all patches can acquire a unique Hash value, i.e., a Hash value, through processing. The hash value may be used as a unique matching sequence number.
Step S302, comparing the first Hash value with the second Hash value to obtain a second vulnerability patch data set and a second non-vulnerability patch data set.
In this step, the patch hash value in the data set may be passed through a non-vulnerability patch. And compares to hash values that match vulnerabilities in the NVD database CVE list. If the two correspond to each other, the method indicates that the needed vulnerability patches exist in the non-vulnerability patch dataset. If the two are not corresponding, the fact that the two are not corresponding is indicated.
Thereby enabling the formation of a second vulnerability patch data set and a second non-vulnerability patch data set.
In some embodiments of the present invention, step S4 further comprises:
In step S401, the review team compares the first vulnerability patch data set and the second vulnerability patch data set with the preset patch information to confirm the data of the first vulnerability patch data set and the second vulnerability patch data set and obtain a correction training set.
Specifically, in this step, after the latest patch of the Linux network is obtained, the review team may perform comparison based on predetermined patch information, that is, a patch information table that may be required, provided by a technician for the review team. Whereby the predetermined patch information is compared by both the first vulnerability patch data set and the second vulnerability patch data set.
In other words, the semantic model is identified as a non-vulnerability patch and is actually identified as a vulnerability patch by comparing with the CVE list of the NVD database, and the semantic model is identified as a vulnerability patch and the review team identifies that the patch is not a vulnerability patch, so that a data error sample, namely a correction training set, is formed.
In some embodiments of the invention, the method further comprises:
S6, identifying patches in the initial patch data set through the updated semantic model pair to obtain a target patch data set;
In the step, the patches in the initial patch data can be re-identified through the updated semantic model, and after debugging, the semantic model can identify the patches in the initial patch data set and acquire effective vulnerability patches to form a target patch data set. I.e. an automated identification patch. The quality of the patch can be improved without manual participation, and the unsuitable patch is prevented from being used in the system.
And S7, updating the target patch data set to a system.
The target patch data set is automatically updated to the system through the semantic model, and the system greatly reduces the need of manual intervention, has high degree of automation and improves the efficiency through automatic identification and application of vulnerability patches.
According to the bug repairing method for the vehicular Linux operating system, provided by the embodiment of the invention, the security of the vehicular Linux system can be greatly improved by periodically synchronizing the latest patches of the inner core of the Linux functional network and using the semantic model to perform bug recognition on the newly-appearing patches, so that potential security threats are timely prevented. And the system safety is improved. By automatically identifying and applying the vulnerability patches, the system greatly reduces the need of manual intervention, has high automation degree and improves the efficiency. Through continuous training of deep learning, the semantic model can automatically learn and adapt to the newly appeared loopholes, so that the system has stronger intelligent learning capacity and better prediction performance. The system can improve the quality of the patch by combining the intelligent identification of the semantic model and the review of the manual review team, and avoid the problems caused by the inapplicable or wrong patch being applied. The system periodically synchronizes the latest kernel patch released by the official network, and performs real-time vulnerability identification and repair, so that the real-time performance of the system is ensured, and the newly-appearing vulnerability can be responded in time.
The following describes steps of a bug fix method for a vehicular Linux operating system according to an embodiment of the first aspect of the present invention with reference to fig. 5.
Patches released by become an official networks are obtained periodically. Specifically, periodically pulling the core branch. Including the Linuxstable branch patch and the Mainline patch in the Linux kernel, both of which are available through Gitshow. The acquired patch is then compared to the current system patch to determine if the acquired patch is the most current patch.
And then inputting the patch into a semantic model to identify the patch, so as to judge whether the patches are all required vulnerability patches. After identifying the book vulnerability patch, the vulnerability patch is sent to a review team for review, and the patch identified as a non-vulnerability patch by the semantic model is compared with the hash value in the NVD database CVElist. Thereby again checking whether the patches are all non-vulnerability patches. And then continuously training the semantic model through a correction training set obtained by the examination of the review team so as to continuously update and correct the semantic model.
Therefore, the automatic identification of the loopholes and the automatic application of the patches are realized by using the semantic model, and the efficiency of repairing the loopholes is greatly improved. The semantic model can continuously learn new vulnerabilities and corresponding patches, and the recognition and repair capability of future vulnerabilities is improved through self-optimization. In addition, the semantic model is used, so that automation of a bug repairing process is realized, error patch application caused by human errors can be reduced, and more serious system problems possibly caused are avoided. The semantic model can also use natural language processing technology to understand and match vulnerabilities and patches, which helps to improve the accuracy of the system. Meanwhile, after the new vulnerability appears, the system can predict possible patches through the trained semantic model and then apply the possible patches to kernel codes of the system. In addition, the bug repairing method of the vehicle-mounted Linux operating system is not limited to bug detection. The latest vulnerability patches can also be automatically identified through the semantic model, and the integration method of automatic application is performed on the new patches.
It should be noted that, as shown in fig. 6, the semantic model used in the embodiment of the present invention is established by the following steps:
step S10, data acquisition: acquiring normal patches and vulnerability patches of a Linux kernel history from an open source community or a professional security organization;
Step S20, data preprocessing: and cleaning and marking the historical patch data, and mapping the description of the patch and the patch to form a training set. Marking whether each patch is a vulnerability or a function enhancement patch, and processing metadata of the patch, such as time, author, size, associated file, and the like.
Step S30, extracting features: the collected data needs to be converted into feature vectors suitable for processing by a deep learning algorithm so that the semantic model can learn how to distinguish normal patches from vulnerability patches. The feature extraction method comprises the following steps: word2Vec, bag of Words, etc.
Step S40, constructing a semantic model: after the preprocessed training set is obtained, the structure of the semantic model needs to be built. This typically includes selecting the type of semantic model (e.g., convolutional neural network, recurrent neural network, etc.), and defining the number of layers, the number of neurons per layer, activation functions, loss functions, optimizers, etc. of the semantic model.
Step S50, training a semantic model: after the semantic model is defined, the semantic model is trained using the training dataset. In one training iteration, the semantic model can generate prediction output, then the prediction output is compared with an actual value, loss is calculated, finally the weight of the semantic model is adjusted through gradient descent and other methods according to loss back propagation. This process may iterate through the training dataset multiple times until the semantic model performs satisfactorily.
Step S60, cross-validation and super-parameter optimization: during training, the validation set is used for cross-validation to prevent overfitting and adjust semantic model superparameters. In addition, in order to find the optimal semantic model structure and parameters, a hyper-parameter optimization method such as grid search or random search can be performed.
Step S70, semantic model evaluation: the semantic model is evaluated using an independent test dataset to accurately learn about the performance of the semantic model.
Step S80, semantic model application: after the semantic model training and evaluation is completed, the semantic model training and evaluation is applied to the actual Linux kernel patch identification so as to automatically identify whether the semantic model is a vulnerability patch.
Further, as shown in fig. 7, the continuous training of the semantic model is performed by the following steps:
S100, data updating: because the Linux kernel is continuously updated and bug repaired, the latest patch data needs to be obtained regularly and combined with the existing data set. This ensures that the data trained by the semantic model is up-to-date to accommodate changes in vulnerabilities.
S200, performing incremental learning on the basis of the original semantic model: the incremental learning method can continue training on the basis of the existing semantic model without retraining the whole semantic model. This reduces computational resources and time costs and enables new vulnerability information to be quickly incorporated into the semantic model.
The primitive semantic model is the initial model which is built, and after the initial model is subjected to subsequent deep training, the initial model can be updated into the semantic model which is required to realize automatic patch identification and system bug repair.
S300, semantic model monitoring and evaluation: in the continuous training process, the performance of the semantic model needs to be monitored and evaluated. Indexes such as accuracy, recall rate and the like of the semantic model can be evaluated regularly, and the semantic model is optimized and improved.
S400: feedback mechanism: when the prediction result of the semantic model is confirmed to be error by the manual review team, the feedback information is used for guiding the next training of the semantic model, so that the semantic model learns from the error and the prediction capability of the semantic model is optimized.
S500, an automatic flow: in order to achieve continuous training and updating, the whole training process is automated. Such as using scripts or workflow management tools to handle data collection, preprocessing, semantic model training, validation, deployment, etc., to improve efficiency and repeatability.
According to an embodiment of the second aspect of the present invention, the bug fixing device 1000 of the vehicular Linux operating system includes:
The first obtaining module 100 is configured to obtain, periodically, an issued Linux system patch from a Linux official network, and compare the Linux system patch with a patch of the Linux system to form an initial patch data set;
A first identifying module 200, configured to identify the initial patch data set based on a semantic model, so as to obtain a first vulnerability patch data set and a first non-vulnerability patch data set;
The second obtaining module 300 obtains a second vulnerability patch data set and a second non-vulnerability patch data set from the first non-vulnerability patch data set based on the NVD database CVE list;
The correction module 400 is configured to audit the first vulnerability patch data set and the second vulnerability patch data set by an audit team to obtain a correction training set;
The updating module 500 inputs the correction training set into the semantic model to update the semantic model.
According to the vehicular Linux operating system bug repairing device of the second aspect of the embodiment of the present invention, the vehicular Linux operating system bug repairing method of the first aspect of the embodiment is introduced, so that the vehicular Linux operating system bug repairing method of the first aspect of the embodiment has the same beneficial effects, and therefore, a semantic model can be adopted to identify whether a patch in an initial patch dataset acquired from a Linux official network is a bug patch. If the identified patch is a corresponding vulnerability and is suitable for the currently used Linux version, then the patch is automatically incorporated into the Linux kernel. The obtained initial patch data is identified through the semantic model, so that the method is more rapid, and the step of manual operation is saved. The safety and stability of the vehicular Linux system are improved. And the vulnerability can be identified and repaired before the vulnerability of the Linux system is subjected to the operation problem.
In some embodiments of the present invention, the device for repairing a bug in a vehicular Linux operating system further includes:
The comparison module 600 is configured to compare the initial patch dataset with a kernel patch of the Linux system to obtain patch update data;
The establishing module 700 is configured to establish a patch update log based on the patch update data.
In some embodiments of the present invention, the device for repairing a bug in a vehicular Linux operating system further includes:
a second identifying module 800, configured to identify patches in the initial patch dataset through the updated semantic model pair to obtain a target patch dataset;
a second updating module 900 is configured to update the target patch data set to the system.
In some embodiments of the present invention, the second obtaining module 300 is further configured to obtain a first Hash value of a patch in the non-vulnerability patch dataset and a second Hash value of a CVE list of the NVD database;
The second obtaining module 300 is further configured to compare the first Hash value with the second Hash value to obtain a second vulnerability patch data set and a second non-vulnerability patch data set.
In some embodiments of the present invention, the correction module 400 is further configured to compare the first vulnerability patch data set and the second vulnerability patch data set with the predetermined patch information by a review team to confirm the data of the first vulnerability patch data set and the second vulnerability patch data set, and obtain a correction training set.
An electronic device according to an embodiment of a third aspect of the present invention includes: the device comprises a processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface complete communication with each other through the communication bus; the memory is configured to store at least one executable instruction, where the executable instruction causes the processor to execute an operation corresponding to the bug fix method of the vehicular Linux operating system according to the embodiment of the first aspect.
Referring to fig. 9, there is shown a schematic structural diagram of an electronic device according to an embodiment of the third aspect of the present application, and the embodiment of the present application is not limited to the specific implementation of the electronic device.
As shown in fig. 9, the electronic device may include: a processor 902, a communication interface (Communications Interface), a memory 906, and a communication bus 908.
Wherein:
Processor 902, communication interface 904, and memory 906 communicate with each other via a communication bus 908.
A communication interface 904 for communicating with other electronic devices or servers.
The processor 902 is configured to execute the program 910, and may specifically perform the relevant steps in the foregoing embodiments of the first aspect.
In particular, the program 910 may include program code including computer-operating instructions.
The processor 902 may be a central processing unit, CPU, or Application specific integrated Circuit ASIC (Application SPECIFIC INTEGRATED circuits), or one or more integrated circuits configured to implement embodiments of the present application. The one or more processors comprised by the smart device may be the same type of processor, such as one or more CPUs; but may also be different types of processors such as one or more CPUs and one or more ASICs.
A memory 906 for storing a program 910. Memory 906 may comprise high-speed RAM memory or may also include non-volatile memory (non-volatile memory), such as at least one disk memory.
The program 910 may be used to cause the processor 802 to perform operations including:
The specific implementation of each step in the procedure 910 may refer to the corresponding step and corresponding description in the unit in the foregoing embodiment of the first aspect, which is not repeated herein. It will be clear to those skilled in the art that, for convenience and brevity of description, specific working procedures of the apparatus and modules described above may refer to corresponding procedure descriptions in the foregoing method embodiments, which are not repeated herein.
A computer storage medium according to an embodiment of the fourth aspect of the present application has stored thereon a computer program which, when executed by a processor, implements the on-vehicle Linux operating system bug fix method according to the embodiment of the first aspect of the present application.
It should be noted that, according to implementation requirements, each component/step described in the embodiments of the present application may be split into more components/steps, or two or more components/steps or part of operations of the components/steps may be combined into new components/steps, so as to achieve the objects of the embodiments of the present application.
The above-described methods according to embodiments of the present application may be implemented in hardware, firmware, or as software or computer code storable in a recording medium such as a CD ROM, RAM, floppy disk, hard disk, or magneto-optical disk, or as computer code originally stored in a remote recording medium or a non-transitory machine-readable medium and to be stored in a local recording medium downloaded through a network, so that the methods described herein may be stored on such software processes on a recording medium using a general purpose computer, special purpose processor, or programmable or special purpose hardware such as an ASIC or FPGA. It is understood that a computer, processor, microprocessor controller, or programmable hardware includes a memory component (e.g., RAM, ROM, flash memory, etc.) that can store or receive software or computer code that, when accessed and executed by the computer, processor, or hardware, implements the alert methods described herein. In addition, when the general purpose computer accesses code for implementing the in-vehicle Linux operating system bug fix method shown herein, execution of the code converts the general purpose computer into a special purpose computer for executing the in-vehicle Linux operating system bug fix method shown herein.
Those of ordinary skill in the art will appreciate that the elements and method steps of the examples described in connection with the embodiments disclosed herein can be implemented as electronic hardware, or as a combination of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the embodiments of the present application.
The above embodiments are only for illustrating the embodiments of the present application, but not for limiting the embodiments of the present application, and various changes and modifications may be made by one skilled in the relevant art without departing from the spirit and scope of the embodiments of the present application, so that all equivalent technical solutions also fall within the scope of the embodiments of the present application, and the scope of the embodiments of the present application should be defined by the claims.
Claims (10)
1. The method for repairing the loopholes of the vehicle-mounted Li nux operating system is characterized by comprising the following steps of:
periodically acquiring an issued Linux system patch by a Linux official network, and comparing the distributed Linux system patch with the patch of the Li nux system to form an initial patch data set;
identifying the initial patch data set based on a semantic model to obtain a first vulnerability patch data set and a first non-vulnerability patch data set;
Obtaining a second vulnerability patch data set and a second non-vulnerability patch data set from the first non-vulnerability patch data set based on the CVE list of the NVD database;
An auditing team audits the first vulnerability patch data set and the second vulnerability patch data set to obtain a correction training set;
inputting the correction training set into the semantic model to update the semantic model.
2. The method of claim 1, wherein said periodically retrieving the released Li nux system patch from the Linux network and comparing it to the patch of the current Li nux system to form an initial patch dataset comprises:
Comparing the initial patch data set with the kernel patch of the Li nux system to obtain patch update data;
And establishing a patch update log based on the patch update data.
3. The method of claim 1, wherein the obtaining a second vulnerability patch data set and a second non-vulnerability patch data set from the first non-vulnerability patch data set based on the NVD database CVE list comprises:
acquiring a first Hash value of a patch in the non-vulnerability patch data set and a second Hash value of a CVE list of an NVD database;
Comparing the first Hash value with the second Hash value to obtain a second vulnerability patch data set and a second non-vulnerability patch data set.
4. The method of claim 1, wherein the auditing team audits the first vulnerability patch dataset and the second vulnerability patch dataset to obtain a revised training set, comprising:
And comparing the first vulnerability patch data set and the second vulnerability patch data set with the preset patch information by a review team to confirm the data of the first vulnerability patch data set and the second vulnerability patch data set and obtain a correction training set.
5. The method of claim 4, wherein inputting the revised training set into the semantic model to update the semantic model, then comprises:
Identifying patches in the initial patch dataset through the updated semantic model pair to obtain a target patch dataset;
Updating the target patch data set to the system.
6. A vehicle-mounted Li nux operating system bug fixes device, comprising:
the first acquisition module is used for periodically acquiring the distributed Li nux system patches by the Linux official network and comparing the patches with the patches of the Li nux system to form an initial patch data set;
The first identification module is used for identifying the initial patch data set based on a semantic model so as to obtain a first vulnerability patch data set and a first non-vulnerability patch data set;
The second acquisition module is used for acquiring a second vulnerability patch data set and a second non-vulnerability patch data set from the first non-vulnerability patch data set based on the CVE list of the NVD database;
the correction module is used for auditing the first vulnerability patch data set and the second vulnerability patch data set by an auditing team to obtain a correction training set;
and the updating module is used for inputting the correction training set into the semantic model so as to update the semantic model.
7. The in-vehicle Linux operating system bug fix apparatus of claim 1, wherein the in-vehicle Li nux operating system bug fix apparatus further comprises:
the comparison module is used for comparing the initial patch data set with the kernel patch of the Linux system to obtain patch update data;
And the building module is used for building a patch update log based on the patch update data.
8. The in-vehicle Linux operating system bug fix apparatus of claim 1, wherein the in-vehicle Li nux operating system bug fix apparatus further comprises:
the second identification module is used for identifying the patches in the initial patch data set through the updated semantic model pair so as to obtain a target patch data set;
And the second updating module is used for updating the target patch data set to the system.
9. An electronic device, comprising: the device comprises a processor, a memory, a communication interface and a communication bus, wherein the processor, the memory and the communication interface complete communication with each other through the communication bus;
The memory is configured to store at least one executable instruction, where the executable instruction causes the processor to perform the operations corresponding to the bug fix method according to any of claims 1-5.
10. A computer storage medium having stored thereon a computer program which when executed by a processor implements a method of bug fixes for an on-board Linux operating system according to any of claims 1-5.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410346707.1A CN118260766A (en) | 2024-03-25 | 2024-03-25 | Bug repairing method and device for vehicle-mounted Linux operating system and electronic equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410346707.1A CN118260766A (en) | 2024-03-25 | 2024-03-25 | Bug repairing method and device for vehicle-mounted Linux operating system and electronic equipment |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN118260766A true CN118260766A (en) | 2024-06-28 |
Family
ID=91604456
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202410346707.1A Pending CN118260766A (en) | 2024-03-25 | 2024-03-25 | Bug repairing method and device for vehicle-mounted Linux operating system and electronic equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN118260766A (en) |
-
2024
- 2024-03-25 CN CN202410346707.1A patent/CN118260766A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110688288B (en) | Automatic test method, device, equipment and storage medium based on artificial intelligence | |
| EP3428828B1 (en) | System and method for locating and correcting vulnerabilites in a target computer system | |
| CN113221960B (en) | Construction method and collection method of high-quality vulnerability data collection model | |
| EP3107009A1 (en) | Self-learning based crawling and rule-based data mining for automatic information extraction | |
| CN112949711B (en) | Neural network model multiplexing training method and device for software defined satellites | |
| WO2016031681A1 (en) | Log analysis device, log analysis system, log analysis method, and computer program | |
| CN114826768A (en) | Cloud vulnerability processing method applying big data and AI technology and AI analysis system | |
| CN112783508B (en) | File compiling method, device, equipment and storage medium | |
| CN112363465B (en) | Expert rule set training method, trainer and industrial equipment early warning system | |
| US7543274B2 (en) | System and method for deriving a process-based specification | |
| CN118260766A (en) | Bug repairing method and device for vehicle-mounted Linux operating system and electronic equipment | |
| CN116069676B (en) | Version comparison method, device, terminal equipment and storage medium | |
| CN117033209A (en) | AI model training method, BIOS testing method, device, equipment and storage medium | |
| CN116032654B (en) | Firmware vulnerability detection and data security management method and system | |
| CN116361191A (en) | Software compatibility processing method based on artificial intelligence | |
| US20240161109A1 (en) | Distributed evaluation platform for nonfungible tokens using virtual token cloning | |
| CN113297583B (en) | Vulnerability risk analysis method, device, equipment and storage medium | |
| CN112395280B (en) | Data quality detection method and system | |
| CN115499164A (en) | Multi-feature fusion block chain intelligent contract vulnerability detection method and device based on graph neural network, computer and storage medium | |
| US11003825B1 (en) | System, method, and computer program product for optimization in an electronic design | |
| Fellir et al. | Analyzing the non-functional requirements to improve accuracy of software effort estimation through case based reasoning | |
| CN114153447A (en) | Method for automatically generating AI training code | |
| CN112434079A (en) | Secondary equipment abnormity discrimination decision method and device based on big data | |
| CN113850565B (en) | Maturity model-based overall process consultation project management monitoring system and method | |
| CN116703470B (en) | Method, device, equipment and storage medium for predicting supply information |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination |