BACKGROUND

[1] Software fixes are useful in improving operation of a computer system that has experienced an unexpected exception or is failing to operate as designed (e.g., experiencing errors due to software problems or "bugs").

BR EF DESCRIPTION OF THE DRAWINGS

[2] Certain examples are described in the following detailed description in reference to the following drawings,

[3] FIGs. 1 and 2 are flowcharts illustrating example methods for producing a multi-base software patch according to the present disclosure.

[4] FIG. 3 is a block diagram illustrating an example computer system installing a multi-base patch according to the present disclosure.

[5] FIGs. 4 and 5 are block diagrams illustrating example computer systems for producing a multi-base software patch according to the present disclosure.

DETAILED DESCRI TION

[6] Software fixes are useful in improving operation of a computer system that has experienced an unexpected exception or is failing to operate as designed (e.g., experiencing errors due to software problems or "bugs"). Rather than producing a replacement version for the software that experienced a bug, software developers often prepare a set of small additions or fixes to the original software code written to correct specific bugs. A set of these additions or fixes can be packaged into a single distributable software patch (hereafter, referred to as a "software patch") that once applied to a specific version of a software can correct a set of bugs that affect that version (e.g., by applying a set of fixes). A software patch that applies a set of fixes to system-level commands or programs in an operating system (collectively referred to as an operating system kernel or kernel software) 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. [7] Generally, 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). 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). This is useful because 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) usually have different binary code and, thus, different checksums. Accordingly, 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. This unfortunately burdens software developers (e.g., software development companies) with having to maintain different series of software patches for different versions of a software, and further burdens software customers with having to tracking these different series of software patches for affected versions software they operate.

[8] Various examples described herein address such burdens. In particular, various examples can generate a multi-base software patch that is applicable to more than one version of a particular software.

[9] As used herein, an instance of a software can be a copy of a particular version of the software on a computer system. For example, 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.

[10] As also used herein, 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. Accordingly, where 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.

[11] Depending on the example, 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).

[12] For some examples, 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.

[13] Subsequently, 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. According to some examples, 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. For instance, 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. In some examples, 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.

[14] Next, 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. Prior continuing generation of the multi-base software patch, 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. Subsequently, within the single-base software patch, logic (e.g., patch-installation 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). In some examples, 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.

[15] Thereafter, in the second version of the software, a second software module (e.g., kernel object) that corresponds to the first software module (e.g., kernel object) of the first version of the software may be identified (e.g., located). 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.

[16] Using the checksum of the second 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. In this way, the multi-base software patch records a checksum associated with each of the versions of the software to which it can be applied. Where the muiti-base software patch can be applied to more than two versions of the software, 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.

[17] Eventually, 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.

[18] Though various examples described herein are done so with respect to multi-base software patching a kernel of an operating system, the 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.). The first and second versions of the software may differ from each other in additions, features, or fixes included in their respective source-code.

[19] The following provides a detailed description of the examples illustrated by FIGs. 1 -5. [20] FIG. 1 is a flowchart illustrating an example method 100 for producing a multi-base software patch according to the present disclosure. For some examples, 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. Depending on the example, 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. For some examples, the operations performed, or the order in which they are performed, may differ from what is illustrated by FIG. 1 .

[21] 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. Additionally, 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. Depending on the example, the first checksum is one generated by way of a MD5 cryptographic hash function or the like.

[22] 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. For some examples, 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). Where the software is a kernel of an operating system, each of the first and second software modules is a kernel object.

[23] 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. Depending on the example, 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. For some examples, 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. In various examples, 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.

[24] FIG. 2 is a flowchart illustrating an example method 200 for producing a multi-base software patch according to the present disclosure. For some examples, 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. Depending on the example, 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. For some examples, the operations performed, or the order in which they are performed, may differ from what is illustrated by FIG. 2.

[25] 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. For some examples, 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. [28] According to some examples, 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. Additionally, for some examples, 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.

[27] In response to determining that the set of differences is below the difference threshold at block 202, 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.

[28] 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,

[29] FIG. 3 is a block diagram illustrating an example computer system 300 installing a multi-base patch according to the present disclosure. As described herein, the computer system 30(3 can include, without limitation, a desktop, a server, a mobile computing device, or any other suitable computing device. In FIG. 3, the computer system 300 as illustrated includes a computer-readable medium 302 and a processor 304. in various examples, the components or the arrangement of components of the computer system 300 may differ from what is depicted in FIG. 3. For instance, the computer system 300 can include more or less components than those depicted in FIG. 3.

[30] The computer-readable medium 302 may be any electronic, magnetic, optical, or other physical storage device that stores executable instructions. For example, 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. 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. In various examples, 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.

[31] For some examples, 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.

[32] 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. For some examples, 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.

[33] 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). As described herein, 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.

[34] FIG. 4 is a block diagram illustrating an example computer system 400 for producing a multi-base software patch according to the present disclosure. As described herein, the computer system 400 can include, without limitation, a desktop, a server, a mobile computing device, or any other suitable computing device. In FIG. 4, 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. In various examples, the components or the arrangement of components in the computer system 400 may differ from what is depicted in FIG. 4.

[35] As used herein, 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. For instance, a module may comprise computer-readable instructions executable by a processor to perform one or more functions in accordance with various examples described herein. In another instance, a module may comprise electronic circuitry to perform one or more functions in accordance with various examples described herein. In yet another instance, 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. In such an example, the machine-readable instructions, when executed by the at least one processing resource, implements the module of the computer system 400. Depending on the example, the elements of a module may be combined in a single package, maintained in several packages, or maintained separately. Accordingly, for some examples, the hardware and programming implementing modules 402, 404, 406, and 408 may be divided among multiple computing devices.

[36] 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. Subsequently, 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. As described herein, checksums may be generated by a MD5 cryptographic hash function.

[37] 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. As described herein, 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.

[38] 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. As described herein, the second checksum may be generated in a manner similar to which the first checksum was generated for the single-base software patch. For instance, the first and second checksums may be generated by a D5 cryptographic hash function.

[39] 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. For some examples, 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. Accordingly, 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.

[40] FIG. 5 is a block diagram illustrating an example computer system 500 for producing a multi-base software patch according to the present disclosure. As described herein, the computer system 500 can include, without limitation, a desktop, a server, a mobile computing device, or any other suitable computing device. In FIG. 5, 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. In various examples, the components or the arrangement of components in the computer system 500 may differ from what is depicted in FIG. 5.

[41] According to some examples, 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.

[42] 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 beiow 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 beiow 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.

[43] 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.