Protecting sensitive data in software products and in generating core dumps

PRIOR FOREIGN APPLICATION

0001This application claims priority from Chinese patent application number 201410072282.6, filed Feb. 28, 2014, which is hereby incorporated herein by reference in its entirety.

BACKGROUND

0002One or more aspects relate to sensitive data protection technology, and more particularly, to protecting sensitive data in a software product to avoid sensitive data leak during core dumps.

0003Most of the existing operating systems and software products support a core dump mechanism. When a software product crashes during running, the operating system generates a core dump and creates a core dump file. The core dump file saves the data in the memory at the crash point, which helps in troubleshooting. It is understood that the crash problem is very hard to reproduce in the test environment since such problem may depend on some special data of the running environment. The core dump file can truly record the state of the computer's memory when a crash happens. Therefore, the data in the core dump file is very helpful for developers to debug the software product. In many cases, debugging the core dump file is the most efficient method to find out the root causes and accordingly solve the crash problem. In this sense, the core dump mechanism is useful for developing and debugging the software product.

0004On the other hand, the data in the memory is fully recorded during the core dump process, so the core dump file may contain sensitive data, especially in the case that the software product is for a finance related system or a security related system. When the software product provider requires a core dump file for debugging, the software product user is often concerned about sensitive data leak.

0005Software product providers, especially some system level software providers, hope to reduce the risk of exposing the sensitive data when the core dump happens. This requires the software product developers to release or remove data structures or data variants associated with sensitive data in the memory.

0006Some software providers may also provide other methods to help debug different problems. These methods also dump some structures and caches in the memory to a file. For example, some operating systems use a core trace program for problem debugging, which writes some trace entries as defined by the developers to the trace buffer. While the trace is recycled, the content in the trace buffer is formatted to the readable trace report file. In addition, the other software products running on the operating system also use the trace mechanism to dump the data in the memory to readable text files. If the software product user worries about exposure of sensitive data and does not want to provide enough debug data, it will make debugging the problem more difficult or impossible.

0007So it is desired to protect the sensitive data in the software product, so as to avoid sensitive data leak during the core dump.

SUMMARY

0008Embodiments of the present invention provide a method and device for protecting sensitive data in a software product, and a method and device for protecting sensitive data when a core dump is generated.

0009According to one aspect of the present invention, there is provided a method of protecting sensitive data in a software product, which includes compiling a source file of the software product to generate an object file, wherein the source file includes at least one piece of sensitive data marked with a specific identifier, and the object file has a secure data section for saving storage information of the at least one piece of sensitive data at compile-time and run-time; and linking the object file to generate an executable file, wherein the executable file is to update the secure data section at run-time.

0010According to another aspect of the present invention, there is provided a method of protecting sensitive data when a core dump is generated, which includes scanning a memory of a computer to find a secure data section in the memory, wherein the secure data section saves storage information of the sensitive data; acquiring the sensitive data according to the storage information of the sensitive data in the found secure data section; processing the sensitive data to hide the sensitive data; and generating a core dump file.

0011Devices, systems and/or computer program products for protecting sensitive data in a software product and/or when a core dump is generated may also be provided.

BRIEF DESCRIPTION OF THE DRAWINGS

Through the more detailed description of some embodiments of the present disclosure in the accompanying drawings, the above and other objects, features and advantages of the present disclosure will become more apparent, wherein the same reference number generally refers to the same components in the embodiments of the present disclosure.

<figref idref="DRAWINGS">FIG. 1</figref> shows a diagram of an exemplary computer system/server, which is applicable to implement one or more embodiments of the present invention;

<figref idref="DRAWINGS">FIG. 2</figref> is one example of a flow chart of a method for protecting sensitive data in a software product according to an embodiment of the present invention;

<figref idref="DRAWINGS">FIG. 3</figref> is one example of a schematic flow chart of one example of the compiling process in the embodiment shown in <figref idref="DRAWINGS">FIG. 2</figref>;

<figref idref="DRAWINGS">FIG. 4</figref> is a schematic diagram for illustrating one example of an object file having a secure data section;

<figref idref="DRAWINGS">FIG. 5</figref> is a schematic diagram for illustrating one example of a structure of a secure data section;

<figref idref="DRAWINGS">FIG. 6</figref> is one example of a flow chart of a method for protecting sensitive data when generating a core dump according to an embodiment of the present invention;

<figref idref="DRAWINGS">FIG. 7</figref> is a schematic block diagram of one example of a device for protecting sensitive data in a software product according to an embodiment of the present invention; and

<figref idref="DRAWINGS">FIG. 8</figref> is a schematic block diagram of one example of a device for protecting sensitive data when a core dump is generated according to an embodiment of the present invention.

DETAILED DESCRIPTION

0021Embodiments are described in more detail with reference to the accompanying drawings, in which embodiments of the present disclosure have been illustrated. However, aspects of the present disclosure can be implemented in various ways, and thus, should not be construed to be limited to the embodiments disclosed herein. On the contrary, the embodiments are provided for a thorough and complete understanding of aspects of the present disclosure.

0022Referring now to <figref idref="DRAWINGS">FIG. 1</figref>, an exemplary computer system/server <b>12</b>, which is applicable to implement embodiments of the present invention, is shown. Computer system/server <b>12</b> is only illustrative and is not intended to suggest any limitation as to the scope of use or functionality of embodiments of the invention described herein.

0023As shown in <figref idref="DRAWINGS">FIG. 1</figref>, computer system/server <b>12</b> is shown in the form of a general-purpose computing device. The components of computer system/server <b>12</b> may include, but are not limited to, one or more processors or processing units <b>16</b>, a system memory <b>28</b>, and a bus <b>18</b> that couples various system components including system memory <b>28</b> to processor <b>16</b>.

0024Bus <b>18</b> represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include the Industry Standard Architecture (ISA), the Micro Channel Architecture (MCA), the Enhanced ISA (EISA), the Video Electronics Standards Association (VESA), and the Peripheral Component Interconnect (PCI).

0025Computer system/server <b>12</b> typically includes a variety of computer system readable media. Such media may be any available media that is accessible by computer system/server <b>12</b>, including both volatile and non-volatile media, removable and non-removable media.

0026System memory <b>28</b> may include computer system readable media in the form of volatile memory, such as random access memory (RAM) <b>30</b> and/or cache memory <b>32</b>. Computer system/server <b>12</b> may further include other removable/non-removable, volatile/non-volatile computer system storage media. By way of example only, storage system <b>34</b> may be provided for reading from and writing to a non-removable, non-volatile magnetic media (typically called a “hard drive”). Although not shown, a magnetic disk drive for reading from and writing to a removable, non-volatile magnetic disk (e.g., a “floppy disk”), and an optical disk drive for reading from or writing to a removable, non-volatile optical disk such as a CD-ROM, DVD-ROM or other optical media may be provided. In such instances, each can be connected to bus <b>18</b> by one or more data media interfaces. As is further depicted and described below, memory <b>28</b> may include at least one program product having a set (e.g., at least one) of program modules that are configured to carry out the functions of embodiments of the invention.

0027Program/utility <b>40</b>, having a set (at least one) of program modules <b>42</b>, may be stored in memory <b>28</b> by way of example, and not limitation, as well as an operating system, one or more application programs, other program modules, and program data. Each of the operating system, one or more application programs, other program modules, and program data or some combination thereof, may include an implementation of a networking environment. Program modules <b>42</b> generally carry out the functions and/or methodologies of embodiments of the invention as described herein.

0028Computer system/server <b>12</b> may also communicate with one or more external devices <b>14</b> such as a keyboard, a pointing device, a display <b>24</b>, etc.; one or more devices that enable a user to interact with computer system/server <b>12</b>; and/or any devices (e.g., network card, modem, etc.) that enable computer system/server <b>12</b> to communicate with one or more other computing devices. Such communication may occur via Input/Output (I/O) interfaces <b>22</b>. Still yet, computer system/server <b>12</b> may communicate with one or more networks such as a local area network (LAN), a general wide area network (WAN), and/or a public network (e.g., the Internet) via network adapter <b>20</b>. As depicted, network adapter <b>20</b> communicates with other components of computer system/server <b>12</b> via bus <b>18</b>. It is understood that although not shown, other hardware and/or software components may be used in conjunction with computer system/server <b>12</b>. Examples, include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems, etc.

0029<figref idref="DRAWINGS">FIG. 2</figref> shows one example of a flow chart of a method for protecting sensitive data in a software product according to an embodiment of the present invention. Aspects of the embodiment are described in detail below in conjunction with the drawing.

0030A basic idea of the method according to one embodiment is that protection of sensitive data is implemented by marking the sensitive data and tracing the sensitive data at compile-time and run-time.

0031As shown in <figref idref="DRAWINGS">FIG. 2</figref>, in step S<b>210</b>, a source file of a software product is compiled to generate an object file, wherein the source file includes at least one piece of sensitive data marked with a specific identifier, and the generated object file has a secure data section for saving storage information of the sensitive data at compile-time and run-time.

0032Generally, only software product developers know exactly what data is sensitive data, and which data variables carry these sensitive data. Therefore, in one embodiment, a specific identifier is introduced to clearly mark the sensitive data in the source file, so that the sensitive data can be identified at compile-time. For example, the specific identifier may be a modifier indicating security (hereinafter called “a secure modifier”), which may be indicated by “secure”. Of course, those skilled in the art understand that other ways may be used to mark the sensitive data.

0033In one example, the secure modifier may be set before a data type of the sensitive data in the source file. The secure modifier may be used to mark any data type of the sensitive data, for example, an elementary data type such as int, float, long, character, pointer, and so on, and a composite data type such as struct, array, list or function, and so on. When the secure modifier is used to mark the sensitive data of the composite data type, all the data included in the sensitive data is also marked as sensitive data. Table 1 shows several usage examples of the secure modifier.

0000<tables id="TABLE-US-00001" num="00001"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="3"><colspec colname="1" colwidth="42pt" align="center" /><colspec colname="2" colwidth="70pt" align="left" /><colspec colname="3" colwidth="105pt" align="left" /><thead><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row><row><entry>Example</entry><entry>Data type</entry><entry>Data type with secure modifier</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></thead><tbody valign="top"><row><entry>1</entry><entry>Int</entry><entry>secure int</entry></row><row><entry>2</entry><entry>char *</entry><entry>secure char *</entry></row><row><entry>3</entry><entry>float[ ]</entry><entry>secure float [ ]</entry></row><row><entry>4</entry><entry>struct{</entry><entry>secure struct{</entry></row><row><entry /><entry> int</entry><entry> int</entry></row><row><entry /><entry> char *</entry><entry> char *</entry></row><row><entry /><entry>}</entry><entry>}</entry></row><row><entry>5</entry><entry>struct{</entry><entry>struct{</entry></row><row><entry /><entry> int</entry><entry> secure int</entry></row><row><entry /><entry> char *</entry><entry> char *</entry></row><row><entry /><entry>}</entry><entry>}</entry></row><row><entry>6</entry><entry>Void function ( ) {</entry><entry>Secure void function( ){</entry></row><row><entry /><entry> int</entry><entry> int</entry></row><row><entry /><entry>}</entry><entry>}</entry></row><row><entry namest="1" nameend="3" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

0034As shown in Table 1, in Example 4, the secure modifier “secure” is set prior to “struct”, so the struct data as well as the int data and the character data therein are all sensitive data. In Example 5, because the secure modifier “secure” is set prior to the int data, only the int data is sensitive data, while the character data and the struct data are not sensitive data.

0035<figref idref="DRAWINGS">FIG. 3</figref> is a schematic flow chart of one example of the compiling process in the embodiment shown in <figref idref="DRAWINGS">FIG. 2</figref>. As shown in <figref idref="DRAWINGS">FIG. 3</figref>, in step S<b>301</b>, the sensitive data is identified from the source file based on the specific identifier (e.g., the secure modifier). As mentioned before, the sensitive data has been marked with the specific identifier. Therefore, at compile-time, it may be identified from the source file which data is the sensitive data with the specific identifier, for further processing.

0036Further, in addition to identifying the sensitive data directly marked with the specific identifier, the data associated with the sensitive data may also be identified from the source file as indirect sensitive data, according to the relationship between the sensitive data and other data or function parameters in the source file, even if the data is not marked with any specific identifier.

0037For example, in the case of a variable assignment, if the sensitive data is assigned to other data, the indirect sensitive data may be identified according to an Abstract Syntax Tree. For example, in the case of a function call, if the sensitive data is transmitted as parameters of a function, the indirect sensitive data may be identified according to the Abstract Semantics Tree. For another example, in the case of object inheritance, the sensitive data also has the inheritance.

0038Therefore, the indirect sensitive data may include any one of the following: the data assigned with the sensitive data, the data obtained by mathematical computation of the sensitive data, the data obtained by a function call with the sensitive data as parameters, and the data having an inheritance relationship with the sensitive data. By identifying the indirect sensitive data, all the data in the source file that needs to be protected may be fully obtained, thereby overcoming the problem in the prior art that the sensitive data is impossible to trace when the sensitive data changes, resulting in sensitive data leak.

0039Next, in step S<b>305</b>, a secure data section for saving storage information of the sensitive data at compile-time and run-time is set up. In one embodiment, in order to implement trace of the sensitive data, the secure data section is newly added to the object file. Furthermore, the secure data section also saves storage information of the indirect sensitive data.

0040<figref idref="DRAWINGS">FIG. 4</figref> is a schematic diagram for illustrating one example of an object file having a secure data section. As shown in <figref idref="DRAWINGS">FIG. 4</figref>, the object file typically has a file header, a code section, a relocation section, a data section (including an uninitialized data section and an initialized data section), a dynamic area (including a heap and a stack), etc. The file header contains pointers to every other section. The code section is used for storing the machine instructions generated by the compiling. The relocation section is used for storing content associated with relocation. The data section is a static section for storing static variables. The dynamic area is typically allocated at run-time, wherein the heap is growing upward, and the stack is growing downward. In step S<b>305</b> (<figref idref="DRAWINGS">FIG. 3</figref>), the secure data section is set up. The secure data section may be set up at any location in the object file, for example, between the data section and the dynamic area (as shown in <figref idref="DRAWINGS">FIG. 4</figref>), or within the data section. The file header also includes a pointer to the secure data section. The secure data section may include a header and a record section following the header. An identifier of the secure data section is saved in the header, to identify the secure data section. The header also saves an amount of storage information of the sensitive data and the indirect sensitive data recorded in the record section and a back pointer to the file header.

0041In the record section, the storage information of the sensitive data or indirect sensitive data may be recorded in the form of an entry. Each entry records the storage information of a piece of sensitive data or indirect sensitive data. The storage information of the sensitive data or indirect sensitive data may contain a data type of the sensitive data or indirect sensitive data, a memory address of the sensitive data or indirect sensitive data and an address offset. The data type of the sensitive data or indirect sensitive data has been defined in the source file, and thus may be determined at compile-time. The memory address of the sensitive data or indirect sensitive data may either be the initial address of the sensitive data or indirect sensitive data in the memory, or the initial address of the section for saving the sensitive data or indirect sensitive data. The memory address is determined at different stages according to the variable types of the sensitive data or indirect sensitive data. The determination of the memory address of the sensitive data or indirect sensitive data is described later in detail. The address offset is an offset based on the memory address, which may be zero. The address of the sensitive data or indirect sensitive data in the memory is actually the sum of the above-mentioned memory address and the address offset. In addition, the storage information may also contain the length of the sensitive data or indirect sensitive data. <figref idref="DRAWINGS">FIG. 5</figref> illustrates one example of a structure of the secure data section.

0042When the secure data section is set up, the address of the secure data section may be determined. In the object file, except for the dynamic area which is allocated at run-time, the addresses of the other sections may be determined at compile-time. The length of the secure data section consists of a fixed length and a dynamic length. The fixed length may be determined at compile-time, which is the sum of the length of the header of the secure data section and the length of the storage information saved in the record section at compile-time. The length of the storage information is the sum of the length of the data type, the length of the memory address, the length of the address offset and the length of the sensitive data. The storage information of some sensitive data may be saved in the secure data section only at run-time; therefore, the length of this part, which is called a “dynamic length,” is not determined at compile-time. A certain amount of space may be reserved in the secure data section at compile-time, for saving the storage information of the sensitive data at run-time.

0043In the High Level Language used for coding the source file, the variables are divided into constants, global variables, local variables (also “stack variables”) and user-allocated-memory variables (also “heap variables”) based on different scopes of action. The constants and global variables are also known as “static variables”, which are stored in the data section at compile-time. The local variables and the user-allocated-memory variables are also known as “dynamic variables”, wherein the local variables are saved in the stack at run-time and the user-allocated-memory variables are saved in the heap at run-time. Accordingly, the sensitive data may also be divided into static sensitive data pertaining to static variables and dynamic sensitive data pertaining to dynamic variables. Similarly, the indirect sensitive data may also be divided into static indirect sensitive data and dynamic indirect sensitive data.

0044As the data type, memory address, address offset and length of the static sensitive data are known at compile-time and will not change, the storage information of the static sensitive data is recorded in the secure data section as a static storage record in step S<b>310</b> (<figref idref="DRAWINGS">FIG. 3</figref>). An entry index may be established for the static storage record, and recorded. Further, the storage information of the static indirect sensitive data is recorded in the secure data section as the static storage record.

0045However, for the dynamic sensitive data, except for the data type and the length of the local variables which are known at compile-time, the memory address of the dynamic sensitive data, the address offset, and the length of the user-allocated-memory variables in the dynamic variables are known only at run-time. Therefore, an extra machine instruction is generated at compile-time to indicate tracing and recording the storage information of the dynamic sensitive data at run-time. Specifically, in step S<b>315</b>, a machine instruction for recording the storage information of the dynamic sensitive data into the secure data section at run-time is generated, wherein the recorded storage information of the dynamic sensitive data is regarded as the dynamic storage record. In order to record the storage information of the local variables and the user-allocated-memory variables, a stack address and a heap address are traced respectively. Further, for the dynamic indirect sensitive data, a machine instruction for recording the storage information of the dynamic indirect sensitive data as the dynamic storage record is also generated.

0046Furthermore, a machine instruction for removing the corresponding dynamic storage records when the dynamic sensitive data is released may also be generated in step S<b>320</b>. The dynamic variables are only used within their scope of action, and are released when they exceed the scope of action. Therefore, when the dynamic sensitive data is used within the scope of action, the dynamic sensitive data is saved in the dynamic section, and the storage information thereof is recorded in the secure data section. When the dynamic sensitive data is released from the dynamic section, the storage information thereof is removed from the secure data section. Further, a machine instruction for removing the corresponding dynamic storage records when the dynamic indirect sensitive data is released is generated for the dynamic indirect sensitive data.

0047In addition, a relocation record for relocating the addresses of the static storage record and the dynamic storage record in the secure data section when linking a plurality of object files may also be generated in step S<b>325</b>. When a plurality of object files is linked, the location of the secure data section changes. Correspondingly, the addresses of the static storage record and the dynamic storage record in the secure data section also change. Therefore, the secure data section is to be relocated at link-time.

0048Although it is described above in the order of steps S<b>310</b>, S<b>315</b>, S<b>320</b> and S<b>325</b>, those skilled in the art may know that these steps may be executed in parallel or in other orders.

0049In the compiling of the source file, in addition to the above-mentioned operations associated with the sensitive data, other conventional compiling operations may also be performed, the description of which is omitted here. Finally, the object file having the secure data section is generated in step S<b>330</b>.

0050Returning to <figref idref="DRAWINGS">FIG. 2</figref>, after the object file having the secure data section is generated, the generated object file is linked to generate an executable file in step S<b>220</b>, wherein the generated executable file updates the secure data section at run-time.

0051In this step, it is first determined whether there is a plurality of object files to be linked. If there is only one object file, i.e. the object file having the secure data section generated in step S<b>210</b>, the object file is linked in the conventional way to generate the executable file having the secure data section. If there is a plurality of object files to be linked and at least one object file has the secure data section, the plurality of object files is merged.

0052When merged, the sections of the plurality of object files are merged respectively. In the case that two or more object files have secure data sections, the two or more secure data sections are merged to form a new secure data section. During the merging, the length of the new secure data section is calculated. Note that, since the global variables may be marked as sensitive data, the repeated global variables are eliminated when the length is calculated. In addition, the entry index of the new secure data section is re-established.

0053Then, the new secure data section in the merged object file is relocated. During the relocation, the address of the new secure data section is obtained. The address of the new secure data section may be determined according to the length of each section of the plurality of object files before merging. Then, based on the determined address, relocation is performed according to the relocation record relating to the static storage record and the dynamic storage record in the object file.

0054In the linking process of the object file, in addition to the above operations related to the secure data section, other conventional linking operations may also be performed, the description of which is omitted here. Finally, the executable file having the new secure data section is generated.

0055When the generated executable file is loaded into the memory to run, the secure data section is updated according to the relevant machine instructions in the executable file. In one embodiment, the updating may include at least updating the memory address and the address offset of the sensitive data in the secure data section. Further, the length of the sensitive data may also be updated. In addition, as the storage information of the static sensitive data and the data type of the dynamic sensitive data are known at compile-time and will not change, they may not be updated at run-time either, but only the memory address and the address offset (optionally, the length as well) of the dynamic sensitive data that are not be acquired at compile-time are updated.

0056It can be seen from the above description that one or more aspects may accurately determine the sensitive data and trace the sensitive data at run-time, so as to protect the sensitive data at any granularity level, by using the specific identifier to mark the sensitive data during the coding stage of the source file, generating the object file and the executable file having the secure data section for storing the storage information of the sensitive data in the compiling and linking stages, and updating the storage information of the sensitive data at run-time. Moreover, even in the case of a shared memory in a plurality of processes, in the case of a function call and in the case of object inheritance, one or more aspects also avoid the sensitive data leak.

0057Further, when the method according to one embodiment is actually applied, the execution of the method of one embodiment may also be controlled by setting an enable/disable option. Specifically, when the source file is being compiled, it may be determined whether the sensitive data protection is enabled. If the sensitive data protection is enabled, the above process of the sensitive data protection is executed. If the sensitive data protection is not enabled, the specific identifier of the sensitive data is ignored, and the compiling is performed in the conventional compiling way, when the source file is being complied. In addition, when running the executable file, it may also be determined whether the sensitive data protection is enabled. If the sensitive data protection is enabled, the secure data section is updated at run-time; otherwise, the update is ignored.

0058<figref idref="DRAWINGS">FIG. 6</figref> is a flow chart of one example of a method for protecting sensitive data when a core dump is generated according to an embodiment of the present invention. This embodiment is described in detail in conjunction with the drawings. For the same parts as those in the previous embodiments, the description thereof is omitted appropriately.

0059As shown in <figref idref="DRAWINGS">FIG. 6</figref>, in step S<b>610</b>, when a core dump occurs due to failure of the software product, the computer's memory is scanned to find the secure data section. If the executable file has the secure data section, the secure data section is contained in the memory at run-time of the executable file. The secure data section saves the storage information of the sensitive data, which includes the data type, memory address, address offset and length of the sensitive data, as examples.

0060Next, after the secure data section is found, in step S<b>620</b>, the corresponding sensitive data is acquired according to the storage information of the sensitive data of the found secure data section. As mentioned above, the storage information of the sensitive data includes the memory address and the address offset of the sensitive data; thus the actual address of the sensitive data in the memory may be acquired, so as to find the corresponding sensitive data.

0061Then in step S<b>630</b>, the acquired sensitive data is processed to hide the sensitive data. Such hiding process should not be reversible, in one embodiment, so as to prevent the reverse process on the hidden sensitive data. The hiding process may either replace the sensitive data by using an existing random replacement algorithm, or obscure the sensitive data by using an existing encryption algorithm such as the dynamic secret-key algorithm.

0062Finally in step S<b>640</b>, a core dump file is generated, in which there is no sensitive data.

0063It can be seen from the above description that one or more aspects ensure no sensitive data leak during the core dump by locating the sensitive data according to the secure data section in the memory.

0064<figref idref="DRAWINGS">FIG. 7</figref> is a schematic block diagram of a device <b>700</b> for protecting sensitive data in a software product according to an embodiment of the present invention. One embodiment is described in detail in conjunction with the drawing. For the same parts as those in the previous embodiments, the description thereof is omitted appropriately.

0065As shown in <figref idref="DRAWINGS">FIG. 7</figref>, device <b>700</b> of one embodiment may include: a compiler <b>701</b> configured to compile a source file of the software product to generate an object file, wherein the source file includes at least one piece of sensitive data marked with a specific identifier, and the object file has a secure data section for saving storage information of the at least one piece of sensitive data at compile-time and run-time; and a linker <b>702</b> configured to link the object file generated by compiler <b>701</b> to generate an executable file, wherein the executable file updates the secure data section at run-time.

0066In one embodiment, in the source file, the specific identifier for marking the sensitive data may be set prior to the data type of the sensitive data.

0067When the source file is input to compiler <b>701</b>, in compiler <b>701</b>, an identification module <b>7011</b> may identify the sensitive data from the source file according to the specific identifier. Further, identification module <b>7011</b> may also identify the data associated with the sensitive data, as the indirect sensitive data. Next, a setting up module <b>7012</b> may set up a secure data section. A pointer to the secure data section is saved in the file header of the object file. The secure data section may include a header and a record section, used for saving the storage information of the sensitive data and the indirect sensitive data. In one embodiment, the header may include an identifier of the secure data section, an amount of the storage information recorded in the record section and a back pointer to the file header. The storage information may include data type, memory address and address offset, as examples. In addition, the storage information may also include the length of the sensitive data or the indirect sensitive data.

0068As mentioned above, the sensitive data may be divided into static sensitive data pertaining to a static variable and dynamic sensitive data pertaining to a dynamic variable. The stages for acquiring the storage information of the static sensitive data and the dynamic sensitive data are different, so in compiler <b>701</b>, the static sensitive data and the dynamic sensitive data are processed differently. For the static sensitive data, a recording module <b>7013</b> records the storage information of the static sensitive data in the secure data section, as the static storage record. For the dynamic sensitive data, a machine instruction generation module <b>7014</b> may generate a machine instruction for recording the storage information of the dynamic sensitive data at run-time in the secure data section as the dynamic storage record. Further, machine instruction generation module <b>7014</b> may also generate a machine instruction for removing the corresponding dynamic storage records when the dynamic sensitive data is released. In addition, a relocation record generation module <b>7015</b> generates a relocation record for relocating the address of the static storage record and the dynamic storage record in the secure data section when a plurality of object files is linked. Finally, an object file generation module <b>7016</b> generates an object file having the secure data section.

0069Similarly, for the static indirect sensitive data, recording module <b>7013</b> records the storage information of the static indirect sensitive data in the secure data section as the static storage record. For the dynamic indirect sensitive data, machine instruction generation module <b>7014</b> may generate a machine instruction for recording the storage information of the dynamic indirect sensitive data in the secure data section at run-time as the dynamic storage record, and a machine instruction for removing the corresponding dynamic storage records when the dynamic indirect sensitive data is released.

0070The generated object file is provided to linker <b>702</b> for linking In linker <b>702</b>, a determination module <b>7021</b> determines whether there is a plurality of object files to be linked. If there is a plurality of object files, a merging module <b>7022</b> merges the plurality of object files. Then, a relocation module <b>7023</b> relocates a new secure data section of the merged object file. Finally, an executable file generation module <b>7024</b> generates an executable file having the new secure data section.

0071<figref idref="DRAWINGS">FIG. 8</figref> is a schematic block diagram of one example of a device <b>800</b> for protecting sensitive data when a core dump is generated according to an embodiment of the present invention. One embodiment is described in detail in conjunction with the drawing. For the same parts as those in the previous embodiments, the description thereof is omitted appropriately.

0072As shown in <figref idref="DRAWINGS">FIG. 8</figref>, a device <b>800</b> of this embodiment may include: a scanning module <b>801</b> configured to scan a computer's memory to find a secure data section in the memory, wherein the secure data section saves storage information of the sensitive data; a sensitive data acquisition module <b>802</b> configured to acquire the sensitive data, according to the storage information of the sensitive data in the found secure data section; a processing module <b>803</b> configured to process the acquired sensitive data to hide the sensitive data; and a file generation module <b>804</b> configured to generate a core dump file.

0073In one embodiment, after the secure data section has been found by scanning module <b>801</b>, since the secure data section saves the storage information of the sensitive data, which includes, for instance, the data type, memory address, address offset and length of the sensitive data, sensitive data acquisition module <b>802</b> may acquire the actual address of the sensitive data in the memory according to the memory address and the address offset of the sensitive data, so as to acquire the sensitive data. Then, processing module <b>803</b> may replace the sensitive data by using a random replacement algorithm, or obscure the sensitive data by using an existing encryption algorithm such as the dynamic secret-key algorithm, so that the core dump file generated by file generation module <b>804</b> does not contain any sensitive data.

0074The previous description of the methods as shown in <figref idref="DRAWINGS">FIG. 2</figref>, <figref idref="DRAWINGS">FIG. 3</figref> and <figref idref="DRAWINGS">FIG. 6</figref> in conjunction with the specific examples may be referred to for the specific implementation modes of device <b>700</b> for protecting the sensitive data in a software product and device <b>800</b> for protecting the sensitive data when generating a core dump, which will not be repeated herein.

0075As described herein, there is provided a method for protecting sensitive data in a software product, which comprises: compiling a source file of the software product to generate an object file, wherein the source file includes at least one piece of sensitive data marked with a specific identifier, and the object file has a secure data section for saving storage information of the at least one piece of sensitive data at compile-time and run-time; and linking the object file to generate an executable file, wherein the executable file updates the secure data section at run-time.

0076According to another aspect of the present invention, there is provided a method for protecting sensitive data when a core dump is generated, which comprises: scanning a computer's memory to find a secure data section in the memory, wherein the secure data section saves storage information of the sensitive data; acquiring the sensitive data according to the storage information of the sensitive data in the found secure data section; processing the sensitive data to hide the sensitive data; and generating a core dump file.

0077According to still another aspect of the present invention, there is provided a device for protecting sensitive data in a software product, which comprises: a compiler configured to compile a source file of the software product to generate an object file, wherein the source file includes at least one piece of sensitive data marked with a specific identifier, the object file has a secure data section for saving storage information of the at least one piece of sensitive data at compile-time and run-time; and a linker configured to link the object file to generate an executable file, wherein the executable file updates the secure data section at run-time.

0078According to still another aspect of the present invention, there is provided a device for protecting sensitive data when a core dump is generated, which comprises: a scanning module configured to scan a computer's memory to find a secure data section in the memory, wherein the secure data section saves storage information of the sensitive data; a sensitive data acquisition module configured to acquire the sensitive data according to the storage information of the sensitive data in the found secure data section; a processing module configured to process the sensitive data to hide the sensitive data; and a file generation module configured to generate a core dump file.

0079Embodiments of the present invention can accurately locate and trace the sensitive data, and avoid sensitive data leak during the core dump, thereby improving security.

0080Aspects of the present invention may be a system, a method, and/or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention.

0081The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

0082Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device.

0083Computer readable program instructions for carrying out operations of the present invention may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present invention.

0084Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.

0085These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.

0086The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks.

0087The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

0088The descriptions of the various embodiments of the present invention have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.