[go: up one dir, main page]

WO2017039588A1 - Correction par patch logiciel sur la base de sommes de contrôle - Google Patents

Correction par patch logiciel sur la base de sommes de contrôle Download PDF

Info

Publication number
WO2017039588A1
WO2017039588A1 PCT/US2015/047474 US2015047474W WO2017039588A1 WO 2017039588 A1 WO2017039588 A1 WO 2017039588A1 US 2015047474 W US2015047474 W US 2015047474W WO 2017039588 A1 WO2017039588 A1 WO 2017039588A1
Authority
WO
WIPO (PCT)
Prior art keywords
software
patch
version
base
checksum
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.)
Ceased
Application number
PCT/US2015/047474
Other languages
English (en)
Inventor
Tadd Ottman
Arun Girish Krishna
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hewlett Packard Enterprise Development LP
Original Assignee
Hewlett Packard Enterprise Development LP
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Hewlett Packard Enterprise Development LP filed Critical Hewlett Packard Enterprise Development LP
Priority to PCT/US2015/047474 priority Critical patent/WO2017039588A1/fr
Publication of WO2017039588A1 publication Critical patent/WO2017039588A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0793—Remedial or corrective actions
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software

Definitions

  • FIGs. 1 and 2 are flowcharts illustrating example methods for producing a multi-base software patch according to the present disclosure.
  • FIG. 3 is a block diagram illustrating an example computer system installing a multi-base patch according to the present disclosure.
  • FIGs. 4 and 5 are block diagrams illustrating example computer systems for producing a multi-base software patch according to the present disclosure.
  • a software patch that applies a set of fixes to system-level commands or programs in an operating system is often called a kernel patch.
  • a run-time kernel patch (e.g., live kernel patch) is a type of a kernel patch that can apply a set of fixes to an operating system while the operating system is operating on a computer system.
  • a live software patch applies itself to a kernel by inserting itself a run-time namespace of global functions and causes a set of jumps from original functions to new functions (e.g., in memory).
  • live software patches Based on the assumption that different versions of a kernel have different name space of functions, live software patches often use a checksum of a target software module of the kernel to confirm that a fix will accurately fit info an expected run-time environment (e.g., expected name space of functions).
  • an expected run-time environment e.g., expected name space of functions.
  • different versions of a kernel e.g., release 1 .0 and release 2.0 that includes a compiled fix compiled that release 1 .0 does not
  • a live software patch generated for one version of a kernel is usually not compatible with another version of kernel, which would require its own, unique live software patch.
  • an instance of a software can be a copy of a particular version of the software on a computer system.
  • an instance of a software may be a copy of the software that resides on a computer system or that is installed on a computer system.
  • a software patch (e.g., live software patch) applicable to only single version of a particular software may be referred to as a single-based software patch (e.g., single-based live software patch), while a software patch applicable to more than one version of the particular software may be referred to as a multi-base software patch.
  • a single-base kernel patch enforces its application on the single base of a kernel (e.g., UNIX or LINUX kernel) by verifying the checksum of a target kernel module included by a software
  • a multi-base kernel patch enforces flexible application on more than one expected base of a kernel by comparing the checksum of the target kernel module with two or more expected checksums.
  • a software patch may be packaged as an executable file that applies a set of fixes to a version of a software upon execution. Additionally, the act of applying a software patch to a software may be referred to as installing the software patch, regardless of how the software patch is packaged.
  • a software patch may comprise a set of control or installation scripts that facilitate the application of a set of fixes to a version of a software.
  • Applying a particular fix by a software patch may comprise adding to the version of the software binary data that implements a new function (e.g., as a new software module), where the new function may address a bug affecting a version of a software.
  • the software patch may locate an existing function in the version of the software it is patching, and may insert a jump from that existing function to the new function added by the software patch (e.g., new function in an additional software module added by the software patch).
  • generation of a multi-base software patch applicable to at least two versions of a software comprises performing a baseline source-code build of a first version of a software to be patched (e.g., compiling a first version of a kernel from its source-code). Separately, a baseline source- code build of a second version (e.g., newer version) of the software may also be performed.
  • a baseline source-code build of a first version of a software to be patched e.g., compiling a first version of a kernel from its source-code.
  • a baseline source- code build of a second version e.g., newer version
  • a software-patch analysis can be performed on the first and second versions of the software to identify a set of differences in the two version.
  • the software-patch analysis is performed by a tool that runs a binary or assembly level comparison between the first and second versions of the software (e.g., the kernel object of the first and second versions) and produces analysis data that is useful in inferring the list of functions and name-space that are different between the versions.
  • Analysis data provided by the soft software-patch analysis can include information describing differences between the software binaries of the two versions. The analysis data can be utilized to determine the set of differences between the two version falls below a threshold, which can indicate that the name space of functions for the two versions is not significantly different.
  • the difference may not be significant where the name space and functions between the two versions of the software remain stable, well-defined, and not significantly altered.
  • the stability of a name space may be judged based on what percentage of global symbols for the jumps remain the same across between the two versions of the software.
  • the multi-base software patch for the two versions of the software is generated if if is determined that the set of differences described by the analysis data indicates that the name space of the two versions of the software remains significantly the same. Accordingly, the process for generating the multi-base software patch may only continue where the analysis data indicates that the set of differences are insignificant.
  • a single-base software patch (e.g., single-base kernel patch) to apply a set of fixes to the first version of the software (e.g., first version of the kernel) may be generated.
  • this single-base software patch may be tested on an instance (e.g., installation) of the first version of the software to determine whether it successfully applies its intended set of fixes to instances of the first version of the software.
  • logic e.g., patch-installation logic
  • logic that generates and verifies the checksum of a first software module of the first version of the software before application of the set of software fixes can be identified (e.g., location identified within the single-base software patch).
  • the checksum of the first software module may be generated by MD5 cryptographic hash function.
  • the first software module may be the software module receiving the set of fixes from the single-base software patch. For instance, where the software patch is a kernel patch, the checksum may be of the entire kernel object before the kernel patch has applied any fix to the kernel object.
  • a second software module e.g., kernel object
  • the second software module and the second software module may be the same target software module, but may differ in data content (e.g., functional logic).
  • a checksum of this second software module may be generated in manner similar to the checksum generated and verified by the single-base software patch (e.g., generated by a D5 cryptographic hash function) with respect to the first software module.
  • the single-base software patch can be modified to generate a multi-base software patch applicable to both the first version of the software and the second version of the software, in particular, the logic earlier identified in the single-base software patch can be modified so that it applies its set of fixes to the first version of the software after verifying the checksum of the first software module, and applies its set of fixes to the second version of the software after verifying the checksum of the second software module.
  • the multi-base software patch records a checksum associated with each of the versions of the software to which it can be applied.
  • the logic of the multi-base software patch can be implemented or further modified to include and verify the checksum of those additional versions of the software.
  • the multi-base software patch can be tested on an instance (e.g., installation) of the first version of the software to determine whether it successfully applies its intended set of fixes to instances of the first version of the software, and can be separately tested on an instance (e.g., installation) of the second version of the software to determine it successfully applies its intended set of fixes to instances of the second version of the software.
  • multi-base software patching a kernel of an operating system
  • functionalities and features described can be applied to multi-base software patching other types of software, including user applications (e.g., word processing, spreadsheet software, web browser, etc.) and background applications (e.g., anti-virus software, server processes, etc.).
  • user applications e.g., word processing, spreadsheet software, web browser, etc.
  • background applications e.g., anti-virus software, server processes, etc.
  • the first and second versions of the software may differ from each other in additions, features, or fixes included in their respective source-code.
  • FIG. 1 is a flowchart illustrating an example method 100 for producing a multi-base software patch according to the present disclosure.
  • the method 100 may be one performed with respect to a computer system, which can include , a desktop, a server, a mobile computing device (e.g., a laptop or tablet), or any other suitable computing device.
  • the method 100 may be implemented in the form of executable instructions stored on a computer-readable medium or in the form of electronic circuitry.
  • the operations performed, or the order in which they are performed may differ from what is illustrated by FIG. 1 .
  • the method 100 may begin at block 102 by a computer system generating a single-base software patch that applies a fix to a first version of a software after verifying a first checksum of a first software module included by the first version of the software.
  • the single-base software patch may be one that applies the fix to the first version of the software by applying the fix to the first software module.
  • the single-base software patch may include logic to facilitate the verification of the first checksum before the fix is applied to the first version of the software.
  • the first checksum is one generated by way of a MD5 cryptographic hash function or the like.
  • the method 100 may continue to block 104 with the computer system generating a second checksum of a second software module included by a second version of the software, where the second software module corresponds to the first software module included by the first version of the software.
  • the second checksum is generated in the same manner as the first checksum verified at block 102 (e.g., using a MD5 cryptographic hash function).
  • each of the first and second software modules is a kernel object.
  • the method 100 may continue to block 106 with the computer system producing a multi-base software patch based on the single-base software patch generated at block 102.
  • producing the multi-base software patch based on the single-base software patch may comprise modifying logic in the single-base software patch to convert it to the multi-base software patch.
  • the multi-base software patch generated is capable of applying the fix to the first version of the software after verifying the first checksum of a first software module, and is further capable of applying the fix to the second version of the software after verifying the second checksum of the second software module.
  • the multi-base software patch may implement the preceding verification (of the first and second checksums) by including (e.g., storing) the first checksum and the second checksum as part of a plurality (e.g., a list) of recorded checksums that the multi-base software patch matches a given checksum against before applying the fix to an instance of a software.
  • Each checksum in the plurality of recorded checksums can be associated with a version of the software that can receive the fix from the multi-base software patch.
  • the multi-base software patch is be packaged as a single distributable file (e.g., DEBIAN package file), which may include control and installation scripts to facilitate the application of the fix to an instance of a software.
  • FIG. 2 is a flowchart illustrating an example method 200 for producing a multi-base software patch according to the present disclosure.
  • the method 200 may be one performed with respect to a computer system, which can include a desktop, a server, a mobile computing device (e.g., a laptop or tablet), or any other suitable computing device.
  • the method 200 may be implemented in the form of executable instructions stored on a computer-readable medium or in the form of electronic circuitry.
  • the operations performed, or the order in which they are performed may differ from what is illustrated by FIG. 2.
  • the method 200 may begin at block 202 with the computer system determining whether a set of differences between a first version of a software and a second version of the software is below a difference threshold.
  • the difference threshold is defined such that the set of differences is below the difference threshold if the name space of functions for the two versions is not significantly different. This might be the case where the name space and functions remain stable and well-defined between the two versions of the software.
  • a set of differences between a first version of a software and a second version of the software are first determined before it is determined whether the set of differences is below a difference threshold.
  • an instance of the first version of the software and an instance of the second version of the software are first built (e.g., compiled from their respective source code) before the computer system can determine whether a set of differences between the first version of the software and the second version of the software.
  • the set of differences between the first version of the software and the second version of the software may involve a set of software-patch analysis tools or processes (e.g., kernel-patch analysis tool), which can generate analysis data describing the differences between the two versions.
  • the method 200 may continue to block 204, which may be similar to block 102 of the method 100 as described above with respect to FIG. 1 .
  • the method 200 may continue to block 206 with the computer system testing whether the single-base software patch generated at block 204successfuily applies the fix to the first version of the software before producing the multi-base software patch. Such testing may involve applying the single-base software patch on an instance of the first version of the software and confirming that a set of bugs expected to be addressed by the single-base software patch is not present in the patched instance of the first version.
  • the method 200 may continue to blocks 208 and 210, which may be respectively similar to blocks 104 and 106 of the method 100 as described above with respect to FIG. 1 .
  • the method 200 may continue to block 212 with the computer system testing whether the multi-base software patch produced at block 210 successfully applies the fix to the first version of the software and successfully applies the fix to the second version of the software.
  • Such testing may involve: applying the multi-base software patch on an instance of the first version of the software; confirming that a set of bugs expected to be addressed by the multi- base software patch is not present in the patched instance of the first version; applying the multi-base software patch on an instance of the second version of the software; and confirming that the set of bugs is not present in the patched instance of the second version,
  • FIG. 3 is a block diagram illustrating an example computer system 300 installing a multi-base patch according to the present disclosure.
  • the computer system 30(3 can include, without limitation, a desktop, a server, a mobile computing device, or any other suitable computing device.
  • the computer system 300 as illustrated includes a computer-readable medium 302 and a processor 304.
  • the components or the arrangement of components of the computer system 300 may differ from what is depicted in FIG. 3.
  • the computer system 300 can include more or less components than those depicted in FIG. 3.
  • the computer-readable medium 302 may be any electronic, magnetic, optical, or other physical storage device that stores executable instructions.
  • the computer-readable medium 302 may be a Random Access Memory (RAM), an Electrically-Erasable Programmable Read-Oniy Memory (EEPROM), a storage drive, an optical disc, or the like.
  • RAM Random Access Memory
  • EEPROM Electrically-Erasable Programmable Read-Oniy Memory
  • the computer-readable medium 302 can be encoded to store executable instructions that cause the processor 304 to perform operations in accordance with various examples described herein.
  • the computer-readable medium 302 is non-transitory. As shown in FIG. 3, the computer-readable medium 302 includes generate checksum of target software module instructions 308, determine whether checksum included in plurality instructions 308, and patch software based on determination instructions 310.
  • the instructions 306, 308, and 310 implement at least part of a multi-base software patch described herein, in some examples, the instructions 306, 308, and 310 are generated by the method 100 described above with respect of FIG. 1 , the method 200 described above with respect of FIG. 2, a computer system 400 as described below with respect to FIG. 4, or a computer system 500 as described below with respect to FIG. 5.
  • the processor 304 may be one or more central processing units (CPUs), microprocessors, or other hardware devices suitable for retrieval and execution of one or more instructions stored in the computer-readable medium 302.
  • the processor 304 may fetch, decode, and execute the instructions 308, 308, and 310 to enable the computer system 300 to perform operations in accordance with various examples described herein.
  • the processor 304 includes one or more electronic circuits comprising a number of electronic components for performing the functionality of one or more of the instructions 306, 308, and 310.
  • the generate checksum of target software module instructions 306 may cause the processor 304 to generate a checksum of a target software module included by an instance of a software that does not include a patch fix (e.g., a fix applied by a particular software patch).
  • a patch fix e.g., a fix applied by a particular software patch.
  • an instance of a software can be a copy of a particular version of the software on a computer system (e.g., installed on the computer system).
  • the determine whether checksum included in plurality instructions 308 may cause the processor 304 to determine whether (e.g., verify) the generated checksum is included in a plurality of recorded checksums, where each of the recorded checksums in the plurality is associated with a different version of the software.
  • the patch software based on determination instructions 310 may cause the processor 304 to patch the instance of the software in response to determining that the plurality of recorded checksums includes the generated checksum, where patching the instance of the software applies the patch fix.
  • the patch fix may be applied to the target software module, among other software modules.
  • FIG. 4 is a block diagram illustrating an example computer system 400 for producing a multi-base software patch according to the present disclosure.
  • the computer system 400 can include, without limitation, a desktop, a server, a mobile computing device, or any other suitable computing device.
  • the computer system 40(3 as illustrated includes a single-base software patch generation module 402, a patch analysis module 404, a checksum generation module 406, and a multi-base software patch generation module 408.
  • the components or the arrangement of components in the computer system 400 may differ from what is depicted in FIG. 4.
  • modules and other components of various examples may comprise, in whole or in part, hardware (e.g., electronic circuitry), programming (e.g., machine-readable instructions), or a combination of both to implement functionalities described herein.
  • a module may comprise computer-readable instructions executable by a processor to perform one or more functions in accordance with various examples described herein.
  • a module may comprise electronic circuitry to perform one or more functions in accordance with various examples described herein.
  • a module may comprise a combination of machine-readable instructions, stored on at least one non-transitory machine-readable storage medium, and at least one processing resource to execute those instructions.
  • the machine-readable instructions when executed by the at least one processing resource, implements the module of the computer system 400.
  • the elements of a module may be combined in a single package, maintained in several packages, or maintained separately.
  • the hardware and programming implementing modules 402, 404, 406, and 408 may be divided among multiple computing devices.
  • the single-base software patch generation module 402 may facilitate generating a single-base software patch that applies a fix to a first version of a software after verifying a first checksum of a first software module included by the first version of the software.
  • the single-base software patch may include logic that performs verification of the first checksum before application of the fix. in particular, for an instance of a software upon which the single-base software patch is to apply the fix, the logic of the single-base software patch may first generate a checksum for a software module, of the instance, that corresponds to the first software module.
  • the logic may compare the generated checksum against an expected checksum stored in the single-base software patch, if the generated checksum matches the expected checksum, the first checksum of the first software module can be considered verified (i.e., the instance of the software is an instance of the first version of the software), and the fix can be applied to the instance, if otherwise, the first checksum cannot be considered verified and the fix, thus, cannot be applied to the instance.
  • checksums may be generated by a MD5 cryptographic hash function.
  • the patch analysis module 404 may facilitate locating logic in the single- base software patch where the first checksum of the first software module is verified.
  • the logic may be located at the time the single-base software patch is being generated or sometime thereafter.
  • the logic of the single-base software patch can determine whether a checksum of a software module of an instance of a software verifies against an expected checksum.
  • the checksum generation module 406 may facilitate generating a second checksum of a second software module included by a second version of the software, where the second software module corresponds to the first software module.
  • the second checksum may be generated in a manner similar to which the first checksum was generated for the single-base software patch.
  • the first and second checksums may be generated by a D5 cryptographic hash function.
  • the multi-base software patch generation module 408 may facilitate producing a multi-base software patch from the single-base software patch by modifying the logic of the single-base software patch.
  • the modified logic is such that it causes the multi-base software patch to apply the fix to the first version of the software after verifying the first checksum of the first software module, and causes the multi-base software patch to apply the fix to the second version of the software after verifying the second checksum of the second software module.
  • the logic may be modified to generate a checksum of a software module of an instance of a software, and to compare the generated checksum against a plurality of expected (e.g., recorded) checksums to verify that the instance of the software is either a first version or a second version of the software. Where verified, the multi-base software module may proceed with applying the fix to the instance of the software.
  • FIG. 5 is a block diagram illustrating an example computer system 500 for producing a multi-base software patch according to the present disclosure.
  • the computer system 500 can include, without limitation, a desktop, a server, a mobile computing device, or any other suitable computing device.
  • the computer system 500 as illustrated includes a single-base software patch generation module 502, a software difference analysis module 504, a patch analysis module 508, a checksum generation module 508, a multi- base software patch generation module 510, and a test module 512.
  • the components or the arrangement of components in the computer system 500 may differ from what is depicted in FIG. 5.
  • the single-base software patch generation module 502, the patch analysis module 506, the checksum generation module 508, and the multi-base software patch generation module 510 are respectively similar to the single-base software patch generation module 402, the patch analysis module 404, the checksum generation module 406, and the multi- base software patch generation module 408 of the computer system 400 described above with respect to FIG. 4.
  • the software difference analysis module 504 may facilitate determining a set of differences between the first version of the software and the second version of the software. As described herein, for some examples, the set of differences between the first and second versions of the software need to be crizo a difference threshold before a multi-base software patch can be produced by the computer system 500.
  • the difference threshold may be defined such that the set of differences is crizo the difference threshold if the name space of functions for the two versions is not significantly different. This might be the case where the name space and functions remain stable and well-defined between the two versions of the software.
  • the test module 512 may facilitate testing whether the multi-base software patch successfully applies the fix to the first version of the software and successfully applies the fix the second version of the software. As described herein, such testing may involve: applying the multi-base software patch on an instance of the first version of the software; confirming that a set of bugs expected to be addressed by the multi-base software patch is not present in the patched instance of the first version; applying the multi-base software patch on an instance of the second version of the software; and confirming that the set of bugs is not present in the patched instance of the second version. [44] In the foregoing description, numerous details are set forth to provide an understanding of the subject disclosed herein. However, various examples may be practiced without some or all of these details. Some examples may include modifications and variations from the details discussed above, if is intended that the appended claims cover such modifications and variations.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Stored Programmes (AREA)

Abstract

Divers exemples fournissent des solutions relatives à un patch logiciel multi-bases. En particulier, certaines solutions permettent de générer un patch logiciel à base unique qui applique une correction à une première version d'un logiciel et, sur la base de ce patch logiciel à base unique, de générer un patch logiciel multi-bases capable d'appliquer la correction soit à la première version du logiciel, soit à une seconde version du logiciel. Pour faciliter cette opération, le patch logiciel multi-bases peut comprendre une logique qui vérifie une somme de contrôle d'un module logiciel correspondant dans chacune de la première version du logiciel et de la seconde version du logiciel avant l'application de la correction à l'un ou à l'autre.
PCT/US2015/047474 2015-08-28 2015-08-28 Correction par patch logiciel sur la base de sommes de contrôle Ceased WO2017039588A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/US2015/047474 WO2017039588A1 (fr) 2015-08-28 2015-08-28 Correction par patch logiciel sur la base de sommes de contrôle

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2015/047474 WO2017039588A1 (fr) 2015-08-28 2015-08-28 Correction par patch logiciel sur la base de sommes de contrôle

Publications (1)

Publication Number Publication Date
WO2017039588A1 true WO2017039588A1 (fr) 2017-03-09

Family

ID=58188211

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2015/047474 Ceased WO2017039588A1 (fr) 2015-08-28 2015-08-28 Correction par patch logiciel sur la base de sommes de contrôle

Country Status (1)

Country Link
WO (1) WO2017039588A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112650531A (zh) * 2019-10-09 2021-04-13 富士通株式会社 解释性且可执行的修复示例的生成
US11010151B2 (en) 2018-07-05 2021-05-18 International Business Machines Corporation Software patch ordering
NO20201064A1 (en) * 2020-09-29 2022-03-30 Mhwirth As A method and system for verifying a software application
CN118964113A (zh) * 2024-10-18 2024-11-15 麒麟软件有限公司 改进的防抖内核性能下降补丁快速二分定位方法及系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040177338A1 (en) * 2003-03-07 2004-09-09 Microsoft Corporation Method for testing a software shim
US20060280150A1 (en) * 2005-06-13 2006-12-14 Qualcomm Incorporated Apparatus and methods for managing firmware verification on a wireless device
US20060288341A1 (en) * 2005-06-15 2006-12-21 Microsoft Corporation Patch-impact assessment through runtime insertion of code path instrumentation
US20070150524A1 (en) * 2003-11-19 2007-06-28 Johan Eker Uptating data in a mobile terminal
US20130124807A1 (en) * 2011-11-14 2013-05-16 Eric H. Nielsen Enhanced Software Application Platform

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040177338A1 (en) * 2003-03-07 2004-09-09 Microsoft Corporation Method for testing a software shim
US20070150524A1 (en) * 2003-11-19 2007-06-28 Johan Eker Uptating data in a mobile terminal
US20060280150A1 (en) * 2005-06-13 2006-12-14 Qualcomm Incorporated Apparatus and methods for managing firmware verification on a wireless device
US20060288341A1 (en) * 2005-06-15 2006-12-21 Microsoft Corporation Patch-impact assessment through runtime insertion of code path instrumentation
US20130124807A1 (en) * 2011-11-14 2013-05-16 Eric H. Nielsen Enhanced Software Application Platform

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11010151B2 (en) 2018-07-05 2021-05-18 International Business Machines Corporation Software patch ordering
CN112650531A (zh) * 2019-10-09 2021-04-13 富士通株式会社 解释性且可执行的修复示例的生成
NO20201064A1 (en) * 2020-09-29 2022-03-30 Mhwirth As A method and system for verifying a software application
NO346991B1 (en) * 2020-09-29 2023-03-27 Mhwirth As A method and system for verifying a software application
CN118964113A (zh) * 2024-10-18 2024-11-15 麒麟软件有限公司 改进的防抖内核性能下降补丁快速二分定位方法及系统

Similar Documents

Publication Publication Date Title
US9696989B1 (en) Systems and methods for generating and applying operating system live updates
CN102521081B (zh) 修复遭破坏的软件
US9201632B2 (en) Systems and methods for incremental software development
US11507362B1 (en) System and method for generating a binary patch file for live patching of an application
US9027014B2 (en) Updating firmware compatibility data
US8978015B2 (en) Self validating applications
US9690567B2 (en) Runtime detection of software configurations and upgrades
US20180032322A1 (en) Automated devops application deployment
KR20190061075A (ko) 소프트웨어 재패키징 방지 방법 및 장치
CN114546819B (zh) 代码处理方法、装置、电子设备及可读介质
CN109614107B (zh) 一种软件开发工具包的集成方法和装置
Zhang et al. Embroidery: Patching vulnerable binary code of fragmentized android devices
WO2017039588A1 (fr) Correction par patch logiciel sur la base de sommes de contrôle
CN111752548A (zh) 一种sdk嵌入方法及装置、计算机可读存储介质
US20250348596A1 (en) Automated back-propagation of a fix using a reproducible build, test, and validation process to create a patched artifact
CN118092989B (zh) 一种存储器的固件升级方法、系统、设备及介质
US20060190933A1 (en) Method and apparatus for quickly developing an embedded operating system through utilizing an automated building framework
WO2015184732A1 (fr) Procédé de stockage d'amorçage, procédé et dispositif de reprise après défaillance d'amorçage, et support de stockage informatique
US10585665B2 (en) Setting a build indicator to enable or disable a feature
CN112527336A (zh) 操作系统软件安装方法、装置、设备及存储介质
BR102013006506A2 (pt) Método de atualização e sistema multidomínio incorporado
US10210334B2 (en) Systems and methods for software integrity assurance via validation using build-time integrity windows
US20080109793A1 (en) Verifying loaded module during debugging
CN113454606B (zh) 不同编译的可执行文件之间的软件检查点-恢复
US20240036887A1 (en) Intercepting calls to a dynamic library

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15903179

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15903179

Country of ref document: EP

Kind code of ref document: A1