Method, system and storage medium for determining corruption of data items

Abstract

In some examples, a system receives a first measurement result of a data item used by a build server when building an executable program, the data item being copied from a data repository to a storage partition separate from the data repository, and the storage partition being used to store the data item related to the build server building the executable program. The system determines whether the data item used by the build server when building the executable program has been corrupted based on the first measurement result and in accordance with a policy specified for the storage partition.

Description

Technical Field

[0001] The present disclosure relates to corruption determination of data items used by a build server. Background Art

[0002] The build server may include a compiler for building an executable program based on source files. The source files may be obtained from a source file repository. Once the compiler has built the executable program based on the source files, the executable program may be delivered to an electronic device (or multiple electronic devices) for execution. Summary of the invention

[0003] According to a first aspect of the present disclosure, a non-transitory machine-readable storage medium is provided, comprising instructions, which when executed cause a system to perform the following operations: receiving a first measurement result of a data item used by a build server when building an executable program, the data item being copied from a data repository to a storage partition separate from the data repository, and the storage partition being used to store the data item related to the build server building the executable program; and determining, based on the first measurement result and according to a policy specified for the storage partition, whether the data item used by the build server when building the executable program has been damaged, comprising: generating a second measurement result of the data item received from the data repository; and in response to a mismatch between the first measurement result and the second measurement result, indicating that the data item used by the build server when building the executable program has been damaged, wherein the first measurement result comes from a log protected by a security processor in the build server, and wherein the first measurement result is based on the data item in the storage partition that is part of the build server or separate from the build server.

[0004] According to a second aspect of the present disclosure, a method for determining damage of a data item is provided, comprising: copying a data item from a first storage partition of a data repository to a second storage partition separate from the first storage partition, the data item being dynamically added to the data repository and being related to building an executable program by a build server; triggering a verification process for the data item in the build server according to a policy for the second storage partition by a verification system; receiving, as part of the verification process, a first measurement result of the data item used by the build server when building the executable program at the verification system; and determining, as part of the verification process, by the verification system whether the data item used by the build server when building the executable program has been damaged based on the first measurement result, comprising: generating, by the verification system, a second measurement result of the data item received from the data repository; and indicating, in response to a mismatch between the first measurement result and the second measurement result, that the data item used to build the executable program in the build server is not in the data repository or is different from the corresponding data item in the data repository, wherein the first measurement result is obtained from a log protected by a security processor in the build server.

[0005] According to a third aspect of the present disclosure, a system for determining corruption of a data item is provided, comprising: a build server, the build server comprising: at least one hardware processor; a program builder, for executing via the at least one hardware processor to build an executable program based on a first data item obtained from a data repository and stored in a storage partition of the build server, the storage partition being separate from the data repository, a security processor, and a log, the log being protected by the security processor and for storing a first measurement result of the first data item in the build server; and a verification system, the verification system comprising machine-readable instructions, the machine-readable instructions being executable on the hardware processor of the verification system to perform the following operations: receiving the first measurement result from the log in the build server, and determining whether the first data item in the build server has been corrupted based on the first measurement result and a second measurement result of a copy of the first data item obtained from the data repository. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Some embodiments of the disclosure are described with respect to the following figures.

[0007] Figure 1 is a block diagram of an arrangement including a build server, a source file repository, and a source file verification engine according to some examples.

[0008] Figure 2is a message flow diagram of a process according to some examples.

[0009] Figure 3 is a block diagram of a storage medium storing machine-readable instructions according to some examples.

[0010] Figure 4 is a flow diagram of a process according to some examples.

[0011] Figure 5 is a block diagram of a system according to some examples.

[0012] Throughout the drawings, the same reference numerals refer to similar, but not necessarily identical, elements. The drawings are not necessarily to scale, and the dimensions of some parts may be exaggerated to more clearly illustrate the examples shown. In addition, the drawings provide examples and / or implementations consistent with the description; however, the description is not limited to the examples and / or implementations provided in the drawings. DETAILED DESCRIPTION

[0013] In the present disclosure, unless the context clearly indicates otherwise, the use of the terms "a / an" or "the" is intended to include the plural forms as well. Similarly, when used in the present disclosure, the terms "includes / including / comprises / comprising", "have / having" indicate the presence of stated elements, but do not exclude the presence or addition of other elements.

[0014] Malware may be introduced into the build server, thereby damaging the executable program built at the build server.For example, the malware may add a source file (or multiple source files) to the source file collection obtained from the source file repository.

[0015] "Malware" may refer to a program or machine that performs unauthorized actions on a build server. "Malware" may also refer to a person who performs unauthorized actions on a build server. "Source file collection" may refer to a single source file or multiple source files. "Source files" include files containing source code according to a programming language. "File" may refer to any identifiable aggregation of data. "Builder server" may refer to a collection of computers where a program builder is executed to produce an executable program. "Computer collection" may refer to a single computer or multiple computers.

[0016] In some examples, the program builder in the build server may include a compiler that uses a set of source files as input and generates a binary program in an executable format. In other examples, the program builder may include an interpreter that converts source code in a programming language into machine code during the runtime of a program that includes the source code. More generally, a "program builder" receives a set of source files (and / or other data items) as input and generates an executable program that can be executed in an electronic device.

[0017] Source files added by malware can create a backdoor to an executable program. When the executable program is executed in an electronic device, an unauthorized entity (e.g., a person, program, or machine) can access the backdoor, causing the executable program to perform unauthorized actions. "Electronic device" may refer to any type of computing device capable of executing machine-readable instructions, such as a desktop computer, a laptop computer, a tablet computer, a smart phone, an Internet of Things (IoT) device, a gaming device, a printer, a home appliance, a communication node, a storage system, a vehicle, a controller in a vehicle, etc.

[0018] A backdoor may allow an unauthorized entity to use the executable program to obtain confidential or other information. Alternatively, a source file added to the executable program may cause the executable program to perform malicious actions that may damage data in the electronic device or devices connected to the electronic device or damage other items in these devices.

[0019] In other examples, instead of adding a source file to a set of source files that a program builder uses to build an executable program, malware may modify a source file to produce a modified source file that may cause an executable program built using the modified source file to perform malicious actions.

[0020] In some examples, source files added by malware or modified by malware may exist in a build server for a relatively short amount of time because the source files may be removed from the build server once the corresponding executable program has been built. Therefore, it may be difficult to detect the presence of added source files or modified source files generated by malware in the build server.

[0021] In a large computing environment, the build server may deploy the corrupted executable program to a large number of electronic devices (e.g., thousands to hundreds of thousands of electronic devices). Examples of computing environments include data centers, cloud environments, storage area networks (SANs), communication networks, etc. In such cases, the corrupted executable program may cause large-scale outages on a large number of electronic devices.

[0022] In some cases, source files used to build an executable program can be added dynamically, such as being added to the file system of a given operating system (OS). The OS can maintain a large number of files in its file system. Therefore, a verification system that attempts to detect corruption of all files of the OS file system may not be able to reliably detect corruption of source files used to build an executable program, because if all files in the OS file system are measured, there will be a lot of noise.

[0023] According to some embodiments of the present disclosure, a verification system copies data items (e.g., source files) from a data repository to a separate storage partition (e.g., located in or separate from a build server). If the data repository is implemented on a collection of storage devices (where "collection of storage devices" may refer to a single storage device or multiple storage devices), the separate storage partition may be implemented on a collection of storage devices that is different from and separate from the collection of storage devices used to implement the data repository. In other examples, the separate storage partition may be a fragment in the collection of storage devices that is separate from a fragment in the collection of storage devices used to store data items of the data repository.

[0024] "Storage device" may refer to a disk-based storage device, a solid-state drive, a memory device, etc.

[0025] The verification system may receive a first measurement result of a data item used to construct the executable program in the separate storage partition, and the verification system may compare the first measurement result with a second measurement result of the data item from the data repository. The comparison of the first measurement result with the second measurement result may provide an indication of whether the data item used to construct the executable program has been corrupted, such as by malware or for other reasons.

[0026] Figure 1 is a block diagram of an example arrangement that includes build server 102, source file repository 104, and source file verification engine 107. In some examples, source file repository 104 may be implemented with one or more storage devices.

[0027] As used herein, an "engine" may refer to a hardware processing circuit that may include any one or some combination of a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, or another hardware processing circuit. Alternatively, an "engine" may refer to a combination of a hardware processing circuit and machine-readable instructions (software and / or firmware) that may be executed on the hardware processing circuit.

[0028] Source file repository 104 stores source files 106 to be used to build executable programs, such as executable program 108 that may be built in build server 102 .

[0029] Build server 102 receives a copy of source file 106 from source file repository 104 via network 110. In some examples, network 110 may include any one or some combination of the following: a local area network (LAN), a wide area network (WAN), a public network (e.g., the Internet), or any other type of network. The copy of source file 106 is represented as 106A in build server 102. In the discussion that follows, references to "source file 106A" are references to the copy of source file 106 in source file repository 104.

[0030] Source files 106 may be retrieved by build server 102 from source file repository 104 , or another entity may copy source files 106 from source file repository 104 to build server 102 .

[0031] Source files 106A (including source files 1 to N, where N≥1) are stored in storage partition 112, which is separate from the storage partition used to store source files 106 in source file repository 104. Storage partition 112 is a partition designated to store source files used to build an executable program.

[0032] exist Figure 1 In the example, storage partition 112 is part of build server 102. For example, storage partition 112 can be implemented using a collection of storage devices of build server 102. In other examples, storage partition 112 can be implemented on a collection of storage devices separate from build server 102.

[0033] like Figure 1 As further shown, malware 114 has been introduced into build server 102. If malware 114 is in the form of a program, malware 114 may be introduced into build server 102 based on downloading malware 114 over network 110 or introduced into build server 102 from another source (e.g., removable storage media, email attachment, etc.). If malware 114 is in the form of hardware, malware 114 may include a physical chip or another device that has been physically installed or connected to build server 102. As a further example, malware 114 may refer to a human user accessing build server 102 directly or over network 110.

[0034] like Figure 1As shown, malware 114 has added malware source file 116 to storage partition 112 to be included as a set of source files (also including source files 1 to N) used by build process 118 when building executable program 108. If malware source file 116 is used by build process 118 to build executable program 108, executable program 108 is a corrupted executable program that may include a backdoor for allowing unauthorized entities to access executable program 108 when executable program 108 is executed at electronic device 121 after executable program 108 is deployed in electronic device 121. Executable program 108 may be deployed in multiple electronic devices.

[0035] In some examples, instead of being a separate source file from source files 106A, malware source file 116 may be a modified source file (or files) in source files 106A.

[0036] In some examples, malware 114 can monitor processes invoked in build server 102 to monitor build processes, such as build process 118. If malware 114 detects that a build process has been invoked, malware 114 can add or modify source files in storage partition 112 to corrupt source files used by the build process when building executable program 108.

[0037] The build process 118 is a process of a program builder 122 in the build server 102. As examples, the program builder 122 may include a compiler or an interpreter.

[0038] Build server 102 includes an OS kernel 124 that can provide a file system. Source file 106A can be stored in the file system of OS kernel 124. In some examples, source file 106A is part of a build tree (including a hierarchical arrangement of source files, such as a hierarchical arrangement of directories and files of a file system). In some examples, when source file 106A is received at build server 102, source file 106A can be added to the build tree. When program builder 122 triggers build process 118, build process 118 obtains source files from the build tree in storage partition 112 to build executable program 108.

[0039] According to some embodiments of the present disclosure, a protection policy 126 may be associated with a storage partition 112 for storing source files 106A. The protection policy 126 may be associated with a subset of all files in the file system of the OS kernel 124. The subset includes files belonging to the storage partition 112 and does not include files in the OS file system that do not belong to the storage partition 112.

[0040] Protection policy 126 may specify that measurements are to be calculated for source files in storage partition 112. Thus, any source file present in storage partition 112 (including source files 1 through N and malware source file 116) will be measured according to protection policy 126.

[0041] The measurements of the source files in the storage partition 112 can be performed by the integrity measurement engine 128. In some examples, the integrity measurement engine 128 is implemented in the build server 102. In other examples, the integrity measurement engine 128 is implemented external to the build server 102.

[0042] In an example, the integrity measurement engine 128 may include an integrity measurement architecture (IMA) module of the Linux OS. The IMA is part of the Linux Security Module (LSM) subsystem and provides a measured and secure boot for the Linux OS. In some examples, the integrity measurement engine 128 applies measurements to source files in the storage partition 112 according to the protection policy 126 (which may be an IMA policy). Although reference is made to the IMA of the Linux OS, in other examples, the integrity measurement engine 128 may refer to any engine that performs measurements on source files in the storage partition 112.

[0043] A "measurement" of a source file (or more generally, a data item) may include applying a function to the data item to produce a corresponding measurement. For example, the applied function may be a cryptographic hash function that, when applied to the data item, produces a hash value based on the content of the data item. In other examples, other types of functions may be applied to the data item to produce a measurement as part of a measurement. A "data item" refers to any identifiable aggregate of data.

[0044] Before source file 106A is provided to build process 118 in build server 102, integrity measurement engine 128 calculates measurement values ​​by applying functions to source file 106A according to protection policy 126. Integrity measurement engine 128 adds the measurement values ​​generated by measuring the received source file 106A to corresponding entries in integrity log 130.

[0045] The integrity log 130 and the protection policy 126 may be stored in a memory of the build server 102 , which may be implemented using a collection of memory devices (non-volatile memory devices and / or volatile memory devices).

[0046] exist Figure 1In the example of , integrity log 130 includes a plurality of entries corresponding to respective source files in storage partition 112. Entries 1 to N correspond to source files 1 to N (where N ≥ 1). For example, when source file 1 is received at build server 102, integrity measurement engine 128 measures source file 1 and adds the corresponding measurement value to entry 1 in integrity log 130. Similarly, when source file N is received at build server 102, integrity measurement engine 128 measures source file N and writes the corresponding measurement value to entry N of integrity log 130.

[0047] For example, if the source file-based measurement value is a hash value based on applying a cryptographic hash function to the source file, each entry i (i=1 to N) of the integrity log 130 includes a corresponding hash value generated by measuring the corresponding source file i. Each entry i may additionally include further information, such as location information (e.g., path name, uniform resource locator, etc.) identifying the location where the source file i is stored, and so on.

[0048] exist Figure 1 In the example of FIG. 1 , it is assumed that malware source file 116 is added by malware 114 after source file N is received, at which time integrity measurement engine 128 measures malware source file 116 and adds the corresponding measurement value to entry N+1. In other examples, malware source file 116 may be received in storage partition 112 before source file 1 or somewhere between the receipt of source file 1 and the receipt of source file N.

[0049] In some examples, build server 102 includes a trusted platform module (TPM) 132. A TPM can refer to a secure cryptographic processor that performs various security operations in build server 102. In some examples, TPM 132 can be implemented as a hardware chip to provide hardware-based, security-related operations in build server 102. For example, TPM 132 can perform cryptographic operations. TPM 132 includes physical security mechanisms to make TPM 132 tamper-resistant, such as to prevent tampering by malware 114.

[0050] The TPM 132 is separate from the main processor 135 of the build server 102. The main processor 135 executes various machine-readable instructions of the build server 102, which includes the OS kernel 124, the program builder 122, etc. In some cases, the integrity measurement engine 128 may include machine-readable instructions executable on the main processor 135.

[0051] More generally, a secure processor (TPM 132 is an example of a secure processor) is included in build server 102 , where the secure processor is separate from main processor 135 and can provide protection for integrity log 130 according to some embodiments of the present disclosure.

[0052] In some examples, TPM 132 includes integrity log protection logic 134 to protect integrity log 130 from tampering, such as from unauthorized entities including malware 114. Integrity log protection logic 134 may be implemented using a portion of hardware processing circuitry of TPM 132, or may be implemented using machine-readable instructions executable in TPM 132. Note that TPM 132 may execute machine-readable instructions, which may include machine-readable instructions stored in secure storage of TPM 132.

[0053] TPM 132 further includes various platform configuration registers (PCRs), including Figure 1 Depicted PCR 136. PCR allows for secure storage and reporting of safety-related indicators.

[0054] According to some embodiments of the present disclosure, PCR 136 stores a cumulative hash value 138 calculated based on entries of integrity log 130. In response to adding a new entry to integrity log 130, integrity log protection logic 134 applies a cryptographic hash function to all entries of integrity log 130, including the newly added new entry.

[0055] For example, when source file 1 is received and integrity measurement engine 128 adds corresponding entry 1 to integrity log 130, integrity log protection logic 134 in TPM 132 calculates a first cryptographic hash value based on entry 1. When source file 2 is received and integrity measurement engine 128 adds corresponding entry 2 to integrity log 130, integrity log protection logic 134 calculates a second cryptographic hash value based on entry 2, and integrity log protection logic 134 combines the second cryptographic hash value with cumulative hash value 138 in PCR 136 to form new cumulative hash value 138. When source file N is received and integrity measurement engine 120 adds corresponding entry N to integrity log 130, integrity log protection logic 134 calculates an Nth cryptographic hash value, and combines the Nth cumulative hash value with current cumulative hash value 138 in PCR 136 to form a new cumulative hash value. The new cumulative hash value obtained by combining the Nth cumulative hash value with the current cumulative hash value 138 in the PCR 136 is actually based on the cumulative hash values ​​of all entries 1 to N of the integrity log 130 .

[0056] In some examples, combining the i-th encrypted hash value (CHV-i) in response to receiving a source file i (i=1 to N) may be as follows:

[0057] newPCRValue=HASH(oldPCRValue||CHV-i),

[0058] Here, HASH is a cryptographic hash function, and || represents an append operation in which CHV-i is appended to oldPCRValue (the current cumulative hash value 138 in PCR 136 ). The parameter newPCRValue represents the new cumulative hash value written as 138 in PCR 136 .

[0059] According to some examples of the present disclosure, the source file verification engine 107 is used to verify source files added to the storage partition 112 for use by the build process 118 when building the executable program 108 .

[0060] In accordance with Figure 1 In the example of , source file verification engine 107 can be implemented in a collection of computers separate from build server 102. In other examples, source file verification engine 107 can be implemented in build server 102.

[0061] In some examples, TPM 132 does not have network access, and agent 140 in build server 102 is used as a proxy between TPM 132 and source file verification engine 107. Source file verification engine 107 receives quote 137 from TPM 132 (via agent 140) and receives integrity log 130 from agent 140 in build server 102. Agent 140 is a program or another entity in build server 102 that interacts with source file verification engine 107. In an alternative example, TPM 132 may be configured to have network access so that TPM 132 can communicate directly with source file verification engine 107 (including sending quote 137 and providing a copy of integrity log 130 to source file verification engine 107).

[0062] Reference 137 from TPM 132 includes signature information provided by TPM 132, where the signature information includes the contents of PCR 136 in combination with other information (discussed further below). The signature information from TPM 132 may be signed using a private key of TPM 132. Source file verification engine 107 may include a public key that may be used by source file verification engine 107 to verify that the signature information originated from TPM 132.

[0063] Providing reference 137 to source file verification engine 107 allows source file verification engine 107 to confirm that the copy of integrity log 130 from agent 140 has not been tampered with. Source file verification engine 107 can check the copy of integrity log 130 entry by entry to calculate a cumulative hash value to be compared with the cumulative hash value included in reference 137, thereby confirming that the copy of integrity log 130 has not been tampered with.

[0064] Additionally, after confirming that the copy of integrity log 130 is valid, source file verification engine 107 compares the measurements contained in the entries of the copy of integrity log 130 with the measurements calculated based on the copies of source files 106 (106B) retrieved by source file verification engine 107 from source file repository 104 (e.g., via network 110). If the measurements contained in the copy of integrity log 130 match the measurements calculated by source file verification engine 107, source file verification engine 107 may confirm that no source files in storage partition 112 have been added or modified (and therefore executable program 108 built by build process 118 has not been corrupted). However, if the measurements contained in the entries of the copy of integrity log 130 do not match the measurements calculated by source file verification engine 107 based on source files 106B retrieved from source file repository 104, source file verification engine 107 may indicate that the source files in storage partition 112 have been corrupted.

[0065] The source file verification engine 107 outputs a verification result 142. The verification result 142 may indicate whether the verification of the source file in the storage partition 112 is successful. A successful verification result indicates that the source file in the storage partition 112 is not damaged, while an unsuccessful verification result indicates that the source file in the storage partition 112 is damaged.

[0066] In some examples, in response to determining that verification of the source files in storage partition 112 is unsuccessful, source file verification engine 107 can execute remediation control 144 on build server 102. Remediation control 144 can prevent any further booting of build server 102, and / or can disable build server 102 (e.g., by shutting down build server 102 or preventing build server 102 from completing its boot process), and / or send an alert to a target entity (e.g., an administrator or another entity), etc.

[0067] like Figure 1 As further shown in FIG. 1 , program builder 122 and build process 118 may be executed in container 150. Container 150 is an example of an isolated virtual environment in build server 102. In some examples, there may be multiple containers in build server 102 for performing different functions. Container 150 is used to execute executable program builds.

[0068] By running the build process 118 in a container 150 , the build process 118 itself may be protected from damage, such as from malware 114 .

[0069] In other examples, build process 118 may be performed using a different isolated virtual environment, such as a virtual machine (VM) in a hypervisor environment.

[0070] Figure 2 1 is a flow chart of a process involving source file verification engine 107, agent 140, TPM 132, and source file repository 104. Figure 2 A specific sequence of tasks is shown, but it should be noted that in other examples, the tasks may be performed in a different order, some tasks may be omitted, or other tasks may be employed. The following discussion also refers to Figure 1 .

[0071] The source file verification engine 107 may be requested to perform verification on the source files in the storage partition 112 of the build server 102. The request may come from a user or another entity, such as a program or a machine.

[0072] The source file verification engine 107 sends (at 202) a challenge to the agent 140, which forwards the challenge to the TPM 132. The challenge includes a random number, which may be a random value generated by the source file verification engine 107. The random value may be generated by a random number generator or a pseudo-random number generator in the source file verification engine 107.

[0073] In response to the challenge, TPM 132 combines the random number with the cumulative hash value 138 in PCR 136 (at 204). Note that TPM 132 may also combine the random number and the cumulative hash value 138 with other information. The combination of the random number, the cumulative hash value 138, and possibly the other information produces combined information. TPM 132 signs the combined information (at 206), such as with a private key of TPM 132, to produce signed information.

[0074] TPM 132 sends (at 208) a reference (e.g. Figure 1 The agent forwards the reference to the source file verification engine 107. The reference includes signature information generated by the TPM 132.

[0075] In response to receiving the reference including the signature information from TPM 132, source file verification engine 107 verifies (at 210) the signature information, which includes decrypting the signature information. The decryption may use the public key of TPM 132 that has been sent to source file verification engine 107. If source file verification engine 107 is able to verify the signature information, this provides an indication to source file verification engine 107 that the source of the signature information (TPM 132) is trustworthy. As part of decrypting the signature information, a cumulative hash value 138 is extracted from the signature information.

[0076] Source file verification engine 107 also receives (at 212) a copy of integrity log 130 from agent 140. For example, agent 140 may send a copy of integrity log 130 to source file verification engine 107 in response to a request from source file verification engine 107.

[0077] The source file verification engine 107 calculates (at 214) a cumulative hash value based on the entries of the copy of the integrity log 130 (using a process similar to the process used by TPM 132 when calculating cumulative hash value 138), and the source file verification engine compares (at 216) the calculated cumulative hash value with the cumulative hash value extracted from the signature information received from TPM 132.

[0078] If the source file verification engine 107 determines (at 218) that the cumulative hash values ​​do not match, the source file verification engine 107 returns (at 220) an error and further verification operations are stopped. The error indication provides an indication that the integrity log 130 has been tampered with, making the verification of the source file in the storage partition 112 unsuccessful.

[0079] However, if it is determined (at 218 ) that the cumulative hash values ​​match, source file verification engine 107 retrieves (at 222 ) source file 106B from source file repository 104 .

[0080] The source file verification engine 107 calculates (at 224) a measurement value based on the measurement results of the obtained source file 106B (for example, based on applying a cryptographic hash function to the obtained source file 106B), and compares the calculated measurement value with the corresponding measurement value in the entry of the copy of the integrity log 130 (at 226).

[0081] The source file verification engine 107 determines (at 228) whether the measurements match. The source file verification engine 107 returns a verification result (e.g., Figure 1 142 in the ).

[0082] If the calculated measurement matches the measurement in the copy of integrity log 130, source file verification engine 107 returns (at 230) a “success” verification result indicating successful verification of the source file in storage partition 112. However, if the calculated measurement does not match the measurement in the copy of integrity log 130, source file verification engine 107 returns (at 232) a “failure” verification result indicating that verification of the source file in storage partition 112 was unsuccessful.

[0083] Figure 3 300 is a block diagram of a non-transitory machine-readable or computer-readable storage medium 300 storing machine-readable instructions that, when executed, cause the system to perform various tasks. For example, the system may include a source file verification engine 107 ( Figure 1 ) of computers.

[0084] The machine-readable instructions include first measurement result receiving instructions 302 for performing the following operations: receiving a measurement result received by a construction server (e.g., Figure 1 102) in building an executable program. The data item is retrieved from a data repository (e.g., Figure 1 104) to a storage partition separate from the data repository (e.g., Figure 1 112), and the storage partition stores data items related to the executable program built by the build server.

[0085] The machine-readable instructions include data item corruption determination instructions 304 for determining, based on the first measurement result and in accordance with a policy specified for the storage partition, whether a data item used by the build server in building the executable program has been corrupted.

[0086] In some examples, the machine-readable instructions can generate a second measurement of the data item received from the data repository, and in response to the first measurement and the second measurement not matching, indicate that the data item used by the build server when building the executable program has been corrupted. By comparing the first measurement and the second measurement, the system can identify the data item(s) used by the build server that are different from the corresponding data item(s) at the data repository.

[0087] In some examples, the policy specifies that verification is to be performed on data items in the storage partition that are dynamically added to build the executable program. No verification is performed on data items that are not in the storage partition. In this way, verification is not based on measurements of data items outside the storage partition - there may be a large number of such data items outside the storage partition (e.g., data items in the file system of the OS), which may make verification of data items used by the build server more complex and less reliable.

[0088] In some examples, the first measurement result comes from a secure processor in the server under construction (e.g., Figure 1 In this way, the system can first confirm that the log has not been tampered with, and then verify that the data items used by the build server have not been damaged.

[0089] In some examples, the policy specifies that temporary data items created as part of building the executable program are not to be measured, and the first measurement results do not include measurement results of the temporary data items. Temporary data items created by the build server when building the executable program would result in a verification error if included as part of the measured data items because the temporary data items are not in the data repository.

[0090] Figure 4 400 according to some examples. Process 400 includes transferring a data item from a data repository (e.g., Figure 1 104) is copied (at 402) to a second storage partition (e.g., Figure 1 112), wherein data items are dynamically added to a data repository and are related to building an executable program by a build server.

[0091] Process 400 includes triggering (at 404) a verification process for data items in a build server according to a policy for a second storage partition by a verification system. Triggering the verification process by the verification system may be a response to a user request or a request from another entity. Similarly, the policy for the second storage partition may specify that measurements are to be performed on data items in the second storage partition, while measurements are not to be performed on data items outside the second storage partition. Limiting the data items that are measured can reduce noise associated with verifying data items used to build an executable program.

[0092] Process 400 includes receiving (at 406) at a verification system, as part of a verification process, a first measurement of a data item used by a build server in building an executable program.

[0093] In some examples, the first measurement result is obtained from a log protected by a security processor in the build server. In some examples, the security processor is used to protect the log based on the following operations: calculating an encrypted value based on an entry in the log containing the first measurement result, and signing the encrypted value. In some examples, the first measurement result includes a hash value derived from a data item in the second storage partition.

[0094] Process 400 includes, as part of the verification process, determining (at 408) by the verification system based on the first measurement result, whether a data item used by the build server in building the executable program has been corrupted.

[0095] Figure 5 5 is a block diagram of a system 500 according to some examples. System 500 includes a build server 502. Build server 502 includes a program builder 504 for building an executable program based on a first data item retrieved from a data repository and stored in a storage partition 506 of the build server. Storage partition 506 is separate from the data repository.

[0096] Build server 502 includes a security processor 508, such as a TPM. Build server 502 also stores a log 510 protected by security processor 508. Log 510 stores in build server 502 a first measurement result of a first data item.

[0097] System 500 further includes verification system 512 including machine readable instructions executable on a processor of the verification system to perform various tasks. The machine readable instructions executable by verification system 512 include first measurement result receiving instructions 514 for receiving a first measurement result from log 510 in build server 502 .

[0098] Machine-readable instructions executable by verification system 512 include data item corruption determination instructions 516 for determining whether the first data item in build server 502 has been corrupted based on the first measurement and a second measurement of a copy of the first data item retrieved from the data repository.

[0099] If the first data item includes data items that do not exist or have been modified from data items in the data repository, then the verification system 512 will determine that the first data item has been corrupted.

[0100] If the first data item includes an identical copy of the first data item retrieved from the data repository, then the verification system 512 will determine that the first data item has not been corrupted.

[0101] Storage media (e.g. Figure 3300) may include any one or some combination of the following: a semiconductor memory device, such as a dynamic or static random access memory (DRAM or SRAM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), and a flash memory; a magnetic disk, such as a fixed floppy disk and a removable disk; another magnetic medium, including a tape; an optical medium, such as a compact disk (CD) or a digital video disk (DVD); or another type of storage device. Note that the instructions discussed above may be provided on one computer-readable or machine-readable storage medium, or alternatively, may be provided on multiple computer-readable or machine-readable storage media distributed in a large system with possibly multiple nodes. Such one or more computer-readable or machine-readable storage media are considered to be part of an article (or product). An article or product may refer to any manufactured single component or multiple components. One or more storage media may be located in a machine running machine-readable instructions, or at a remote site, from which machine-readable instructions may be downloaded over a network for execution.

[0102] In the foregoing description, many details are set forth to enable an understanding of the subject matter disclosed herein. However, embodiments may be practiced without some of these details. Other embodiments may include modifications and variations of the details discussed above. The appended claims are intended to cover such modifications and variations.

Claims

1. A non-transitory machine-readable storage medium comprising instructions that, when executed, cause a system to: receiving a first measurement result of a data item used by a build server in building an executable program, the data item being copied from a data repository to a storage partition separate from the data repository, and the storage partition being used to store the data item related to the build server building the executable program; as well as Determining whether the data item used by the build server when building the executable program has been damaged based on the first measurement result and according to a policy specified for the storage partition includes: generating a second measurement of the data item received from the data repository; and In response to the first measurement result and the second measurement result not matching, indicating that the data item used by the build server in building the executable program has been corrupted, Wherein the first measurement is from a log protected by a secure processor in the build server, and wherein the first measurement is based on the data item in the storage partition that is part of the build server or separate from the build server.

2. The non-transitory machine-readable storage medium of claim 1, wherein: When executed, the instructions cause the system to perform the following operations: In response to the first measurement result and the second measurement result not matching, it indicates that the data item used by the build server in building the executable program is not in the data repository or is different from the corresponding data item in the data repository.

3. The non-transitory machine-readable storage medium of claim 1, wherein: The policy specifies that verification is to be performed on the data items in the storage partition that are dynamically added to build the executable program.

4. The non-transitory machine-readable storage medium of claim 1, wherein: The first measurements of the data items used by the build server in building the executable program include measurements of the data items used in building the executable program in an isolated virtual environment of the build server.

5. The non-transitory machine-readable storage medium of claim 4, wherein: The building of the executable program is performed by a program builder in the isolated virtual environment, and the program builder in the isolated virtual environment is protected from being damaged by malware in the building server.

6. The non-transitory machine-readable storage medium of claim 1, wherein: The policy specifies that temporary data items created as part of building the executable program are not to be measured, and wherein the first measurements do not include measurements of the temporary data items.

7. A method for corruption determination of a data item, comprising: copying data items from a first storage partition of a data repository to a second storage partition separate from the first storage partition, the data items being dynamically added to the data repository and being related to building an executable program by a build server; triggering, by the verification system, a verification process for the data item in the build server according to a policy for the second storage partition; receiving, at the verification system as part of the verification process, a first measurement of the data item used by the build server in building the executable program; as well as As part of the verification process, determining by the verification system based on the first measurement result whether the data item used by the build server when building the executable program has been corrupted includes: generating, by the verification system, a second measurement of the data item received from the data repository; and In response to the first measurement result and the second measurement result not matching, indicating that the data item in the build server used to build the executable program is not in the data repository or is different from the corresponding data item in the data repository, The first measurement result is obtained from a log protected by a security processor in the build server.

8. The method of claim 7, wherein: The security processor is configured to protect the log based on: calculating an encrypted value based on an entry in the log containing the first measurement result, and signing the encrypted value.

9. The method of claim 7, wherein: The first measurement comprises a hash value derived from the data item in the second storage partition.

10. The method of claim 7, wherein: The first measurements of the data items used by the build server in building the executable program include measurements of the data items used by a compiler in building the executable program in an isolated container of the build server.

11. The method of claim 7, wherein: The policy specifies that temporary data items created as part of building the executable program are not to be measured, and wherein the first measurements do not include measurements of the temporary data items.

12. A system for corruption determination of a data item, comprising: A build server, the build server comprising: at least one hardware processor; a program builder for executing via the at least one hardware processor to build an executable program based on a first data item retrieved from a data repository and stored in a storage partition of the build server, the storage partition being separate from the data repository, security processor, and a log protected by the security processor and used to store a first measurement result of the first data item in the build server; and A verification system comprising machine-readable instructions executable on a hardware processor of the verification system to perform the following operations: receiving the first measurement result from the log in the build server, and A determination is made as to whether the first data item in the build server has been corrupted based on the first measurement result and a second measurement result of a copy of the first data item retrieved from the data repository.

13. The system of claim 12, wherein: If the first data item includes a data item that does not exist or has been modified from a data item in the data repository, the verification system determines that the first data item has been corrupted, and If the first data item comprises an identical copy of the first data item retrieved from the data repository, the verification system will determine that the first data item has not been corrupted.

14. The system of claim 12, wherein: The build server includes an isolated virtual environment, and the program builder is executable in the isolated virtual environment to build the executable program.

Images