Protecting sensitive information in time travel tracing debugging

Abstract

Protecting and tracking sensitive information related to the original execution of an entity. Embodiments include identifying that the original information includes sensitive information accessed based on the original execution of one or more original executable instructions of the entity. Based on the inclusion of sensitive information in the original information, embodiments include performing one or both of the following: (i) storing a first trace data that includes alternative information rather than the original information in the trace, while ensuring that the execution path adopted by the entity based on the original information is also adopted during replay of the original execution of the entity using the trace; (ii) storing a second trace data in the trace that causes zero or more alternative executable instructions rather than one or more original executable instructions of the entity to be executed during replay of the entity's original execution.

Description

Background Art

[0001] When writing code during the development of a software application, developers often spend a lot of time "debugging" the code to find runtime errors and other source code errors. In doing so, developers can use several methods to reproduce and locate source code errors, such as observing the behavior of the program based on different inputs, inserting debugging code (e.g., to print variable values, trace execution branches, etc.), temporarily deleting code sections, etc. Tracking down runtime errors to pinpoint code errors can take up a large portion of application development time.

[0002] In order to assist developers in the code debugging process, many types of debugging applications ("debuggers") have been developed. These tools enable developers to track, visualize, and change the execution of computer code. For example, a debugger can visualize the execution of code instructions, can present the values ​​of code variables at different times during code execution, can enable developers to change the code execution path, and / or can enable developers to set "breakpoints" and / or "watchpoints" on code elements of interest (which, when reached during execution, cause the execution of the code to be suspended), etc.

[0003] Emerging forms of debugging applications enable "time travel," "reverse," or "historical" debugging. With "time travel" debugging, the execution of a program (e.g., an executable entity, such as a thread) is recorded / traced by a tracing application into one or more tracing data streams. These tracing data streams can then be used to replay the execution of the program at a later time for both forward and backward analysis. For example, a "time travel" debugger can enable a developer to set forward breakpoints / watchpoints (like a conventional debugger) as well as reverse breakpoints / watchpoints.

[0004] Because time-travel debuggers record bit-accurate traces of program execution (including the code executed and the memory values ​​read during program execution), they have the potential to capture and leak sensitive code and / or data that, in many cases, should not be available to those who have access to the resulting trace data (e.g., developers using debuggers that consume the trace data stream). This may be due to security context (e.g., kernel vs. user mode), changes in code authors (e.g., code developed by one author vs. calling libraries developed by another author), organizational divisions, policy / legal issues, etc. For example, a time-travel debugger may capture cryptographic information, such as the values ​​of encryption keys, random numbers, salts, hashes, random numbers, etc.; personally identifiable information (PII), such as name, mailing address, birthday, social security number, email address, IP address, MAC address, etc.; financial information, such as credit card number, account number, financial institution; authentication information, such as username, password, biometric data, etc.; general input, such as search terms, file names, etc.; code that may be desired to be kept confidential; and so on. The ability of time travel debuggers to leak sensitive information is becoming more and more of a concern as time travel debugging technology is evolving to the point where it can have sufficiently low logging overhead to make it feasible for use in production systems and potentially even in an "always on" configuration. Summary of the invention

[0005] At least some embodiments described herein identify sensitive information associated with a time travel trace (during trace recording and / or at some later time), and remove and / or mask the sensitive information in the trace. For example, embodiments may include storing alternative data in the trace (rather than the original data identified as sensitive), replacing original instructions in the trace with alternative instructions that avoid executing sensitive code or cause correct execution in view of data replacement, overwriting the execution behavior of one or more instructions, etc. In this way, embodiments support that time travel traces will be generated and consumed even in a production environment, while keeping sensitive information from being disclosed.

[0006] Embodiments may include methods, systems, and computer program products for protecting sensitive information associated with an original execution of a traced entity. These embodiments may include, for example, identifying that original information includes sensitive information, which original information was accessed based on an original execution of one or more original executable instructions of the entity. Based on the original information including the sensitive information, these embodiments may include performing one or both of the following: (i) storing first trace data including alternative information instead of the original information in a first trace data stream, while ensuring that an execution path taken by the entity based on the original information will also be taken during a replay of the original execution of the entity using the first trace data stream; or (ii) storing second trace data in a second trace data stream, the second trace data stream causing one or more alternative executable instructions to be executed instead of the one or more original executable instructions of the entity during a replay of the original execution of the entity using the second trace data stream.

[0007] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] In order to describe the manner in which the above and other advantages and features of the present invention can be obtained, the invention briefly described above will be described in more detail with reference to specific embodiments of the invention shown in the accompanying drawings. After understanding that these drawings show only typical embodiments of the invention and are not therefore to be considered as limiting the scope of the invention, the invention will be described and explained with additional specificity and detail through the use of the accompanying drawings, in which:

[0009] Figure 1 illustrates an example computer architecture that facilitates protecting sensitive information associated with origin execution of a tracking entity;

[0010] Figure 2 An example embodiment of a security component is illustrated;

[0011] Figure 3A illustrates an example of reliance on bit accurate tracing to identify derived data and / or code in a forward direction on an execution timeline;

[0012] Figure 3B Figure illustrates an example of reliance on bit-accurate tracing to identify derived data and / or code in the reverse direction on an execution timeline;

[0013] Figure 4A An example of sensitive data item replacement / masking with respect to a single trace data flow is illustrated;

[0014] Figure 4B illustrates an example of sensitive data item replacement / masking with respect to multiple trace data flows;

[0015] Figure 5A illustrates an example of ensuring that an execution path taken by an entity during its original execution will be taken during replay even with data replacement;

[0016] Figure 5B illustrates an example of storing data into a single trace data stream that enables alternative executable instructions to be executed during replay of an entity;

[0017] Figure 5C illustrates an example of storing data into at least one tracing data stream that causes alternative executable instructions to be executed during replay of an entity; and

[0018] Figure 6 A flow diagram of an example method for protecting sensitive information related to original execution of a tracking entity is illustrated. DETAILED DESCRIPTION

[0019] At least some embodiments described herein identify sensitive information associated with a time travel trace (during trace recording and / or at some later time), and remove and / or mask the sensitive information in the trace. For example, embodiments may include storing alternative data in the trace (rather than the original data identified as sensitive), replacing original instructions in the trace with alternative instructions that avoid executing sensitive code or cause correct execution in view of the data replacement, overwriting the execution behavior of one or more instructions, etc. In this way, embodiments support time travel traces being generated and consumed even in a production environment, while keeping sensitive information from being disclosed.

[0020] As used in this specification and claims, the phrases "sensitive information", "sensitive data", "sensitive code", etc. refer to data and / or code that is consumed in one or more processing units during the tracing of these processing units into one or more tracing data streams and should (or may) be restricted and / or blocked from being available to consumers of these tracing data streams. As described in the background technology, sensitive data may correspond to, for example: cryptographic information, such as values ​​of encryption keys, random numbers, salts, hashes, nonce, etc.; personally identifiable information (PII), such as name, mailing address, birthday, social security number, email address, IP address, MAC address, etc.; financial information, such as credit card number, account number, financial institution; authentication information, such as user name, password, biometric data, etc.; regular input, such as search terms, file names, etc.; and the like. Sensitive code may correspond to code that executes encryption routines, code that implements proprietary algorithms, etc. Classification of sensitive data or code may be based on security context (e.g., kernel vs. user mode), changes in code authors (e.g., code developed by one author vs. call libraries developed by another author), organizational departments, policies and / or legal issues, etc.

[0021] As used herein, the phrases "non-sensitive information", "non-sensitive data", "non-sensitive code", etc. refer to information that may be non-sensitive. For example, this may include information that the confidence that the information is non-sensitive information is substantially 0% or below a predetermined threshold (e.g., such as 10%). In contrast, "sensitive information", "sensitive data", "sensitive code", etc. cover information that is deterministically sensitive, information that may be sensitive, and information that is potentially sensitive. Thus, unless otherwise specified, the use of the phrases "sensitive information", "sensitive data", "sensitive code" (etc.) should be broadly interpreted to include information that is deterministically sensitive, information that may be sensitive, and information that is potentially sensitive. In some embodiments, deterministic sensitive information may include information that the confidence that the information is sensitive information is substantially 100% or above a predetermined threshold (e.g., such as 95%). In some embodiments, potentially sensitive information may include information that the confidence that the information is sensitive information exceeds a predetermined threshold (e.g., such as >50% or >=75%). In some embodiments, potentially sensitive information may include information that the confidence that the information is sensitive information is between a threshold for non-sensitive information and a threshold for potentially sensitive information.

[0022] Figure 1An example computing environment 100 that facilitates protecting sensitive information associated with the original execution of a tracking entity is illustrated. As shown, an embodiment may include or utilize a special purpose or general purpose computer system 101 that includes computer hardware such as, for example, one or more processors 102, a system memory 103, one or more data repositories 104, and / or input / output hardware 105.

[0023] Embodiments within the scope of the present invention include physical and other computer-readable media for carrying or storing computer-executable instructions and / or data structures. Such computer-readable media can be any available media that the computer system 101 can access. The computer-readable media that stores computer-executable instructions and / or data structures are computer storage devices. The computer-readable media that carries computer-executable instructions and / or data structures are transmission media. Therefore, by way of example and not limitation, embodiments of the present invention may include at least two distinct types of computer-readable media: computer storage devices and transmission media.

[0024] Computer storage devices are physical hardware devices that store computer-executable instructions and / or data structures. Computer storage devices include various computer hardware such as RAM, ROM, EEPROM, solid-state drives ("SSD"), flash memory, phase-change memory ("PCM"), optical disk storage, magnetic disk storage or other magnetic storage devices, or any other hardware device that can be used to store program code in the form of computer-executable instructions or data structures and can be accessed and executed by the computer system 101 to implement the functions disclosed in the present invention. Thus, for example, computer storage devices can include the illustrated system memory 103, the illustrated data repository 104 that can store computer-executable instructions and / or data structures, or other storage devices such as on-processor storage devices described later.

[0025] Transmission medium can comprise the network and / or data link that can be used to carry the program code in the form of computer executable instruction or data structure and can be accessed by computer system 101." network " is defined as one or more data links that can transmit electronic data between computer system and / or module and / or other electronic equipment.When information is transmitted or offered to computer system by network or another communication connection (hardwire, wireless or hardwire or wireless combination), computer system can be considered as transmission medium by connection.The combination of the above-mentioned also should be included in the scope of computer readable medium.For example, input / output hardware 105 can comprise the hardware (for example, network interface module (for example, " NIC ")) that can be used for the network and / or data link of carrying program code in the form of computer executable instruction or data structure.

[0026] Furthermore, after reaching various computer system components, program code in the form of computer executable instructions or data structures may be automatically transferred from the transmission medium to the computer storage device (or vice versa). For example, computer executable instructions or data structures received over a network or data link may be buffered in RAM within a NIC (e.g., input / output hardware 105), and then ultimately transferred to system memory 103 and / or a less volatile computer storage device (e.g., data repository 104) at computer system 101. Thus, it should be understood that computer storage devices may be included in computer system components that also (or even primarily) utilize transmission media.

[0027] For example, computer executable instructions include instructions and data that cause computer system 101 to perform a specific function or group of functions when executed at processor 102. Computer executable instructions may be, for example, binary, intermediate format instructions (such as assembly language), or even source code.

[0028] Those skilled in the art will appreciate that the present invention can be put into practice in a network computing environment with many types of computer system configurations, including personal computers, desktop computers, laptop computers, message processors, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile phones, PDAs, tablet computers, pagers, routers, switches, etc. The present invention can also be put into practice in a distributed system environment, in which local and remote computer systems linked by a network (by a hardwired data link, a wireless data link, or by a combination of a hardwired and wireless data link) all perform tasks. Like this, in a distributed system environment, a computer system can include multiple component computer systems. In a distributed system environment, a program module can be located in both local and remote memory storage devices.

[0029] Those skilled in the art will also appreciate that the present invention can be practiced in a cloud computing environment. A cloud computing environment can be distributed, although this is not required. When distributed, a cloud computing environment can be distributed internationally within an organization, and / or have components owned across multiple organizations. In this specification and the appended claims, "cloud computing" is defined as a model for enabling on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services). The definition of "cloud computing" is not limited to any of the other numerous advantages that can be obtained from such a model when properly deployed.

[0030] The cloud computing model can consist of various features, such as on-demand self-service, broad network access, resource pooling, rapid elasticity, metered services, etc. The cloud computing model can also take the form of various service models, such as, for example, software as a service ("SaaS"), platform as a service ("PaaS"), and infrastructure as a service ("IaaS"). The cloud computing model can also be deployed using different deployment models, such as private cloud, community cloud, public cloud, hybrid cloud, etc.

[0031] Some embodiments, such as a cloud computing environment, may include a system that includes one or more hosts, each of which is capable of running one or more virtual machines. During operation, the virtual machine emulates an operating computing system, supporting an operating system and perhaps one or more other applications. In some embodiments, each host includes a hypervisor that emulates the virtual resources of the virtual machine using physical resources abstracted from the perspective of the virtual machine. The hypervisor also provides appropriate isolation between virtual machines. Thus, from the perspective of any given virtual machine, the hypervisor provides the illusion that the virtual machine is interfacing with physical resources, even though the virtual machine is only interacting with the appearance of physical resources (e.g., virtual resources). Examples of physical resources include processing power, memory, disk space, network bandwidth, media drives, etc.

[0032] Figure 1 A simplified representation of the internal hardware components of processor 102 is included. As shown, each processor 102 includes multiple processing units 102a. Each processing unit can be physical (i.e., a physical processor core) and / or logical (i.e., a logical core provided by a physical core supporting hyperthreading, where more than one application thread executes at the physical core). Thus, for example, even though processor 102 may include only a single physical processing unit (core) in some embodiments, it may include two or more logical processing units 102a presented by the single physical processing unit.

[0033] Each processing unit 102a executes processor instructions defined by an application (e.g., tracker 104a, operating kernel 104f, application 104g, etc.), and these instructions are selected from a predefined processor instruction set architecture (ISA). The specific ISA of each processor 102 varies based on the processor manufacturer and processor model. Common ISAs include IA-64 and IA-32 architectures of INTEL, INC., AMD64 architecture of ADVANCED MICRO DEVICES, INC., and various advanced RISC machines ("ARM") architectures of ARM HOLDINGS, PLC, but there are a large number of other ISAs and these ISAs can be used by the present invention. Typically, an "instruction" is the smallest externally visible (i.e., outside the processor) code unit that can be executed by a processor.

[0034] Each processing unit 102a retrieves processor instructions from one or more processor caches 102b and executes the processor instructions based on data in the cache(s) 102b, based on data in registers 102d, and / or without input data. Typically, each cache 102b is a small amount (i.e., a small amount relative to the typical amount of system memory 103) of random access memory that stores on-processor copies of portions of a backing store, such as system memory 103 and / or another cache in cache 102b. For example, when executing application code 103a, one or more caches 102b contain portions of application runtime data 103b. If a processing unit 102a requests data that is not already stored in a particular cache 102b, a "cache miss" occurs, and the data is retrieved from system memory 103 or another cache, potentially "evicting" some other data from that cache 102b. Caches 102b may include a code cache portion and a data cache portion. When application code 103a is executed, the code portion of cache(s) 102b may store at least a portion of the processor instructions stored in application code 103a and the data portion of cache 102b may store at least a portion of the data structure of application runtime data 103b.

[0035] Each processor 102 also includes microcode 102c, which includes control logic (i.e., executable instructions) that controls the operation of the processor 102 and generally acts as an interpreter between the processor's hardware and the processor ISA exposed by the processor 102 to execute applications. The microcode 102 is generally implemented in an on-processor storage device such as a ROM, EEPROM, or the like.

[0036] Register 102d is a hardware-based storage location that is defined based on the ISA of the processor(s) 102 and is read from or written to by processor instructions. For example, register 102d is typically used to store values ​​retrieved from cache 102b for use by instructions, to store the results of executing instructions, and / or to store status or state, such as certain side effects of executing instructions (e.g., the sign of a value changes, a value reaches zero, a carry occurs, etc.), processor cycle counts, etc. Therefore, some registers 102d may include "flags" that are used to signal certain state changes caused by executing processor instructions. In some embodiments, processor 102 may also include control registers for controlling different aspects of processor operation. Although Figure 1Registers 102d are shown as a single box, but it is understood that each processing unit 102a typically includes one or more corresponding sets of registers 102d specific to that processing unit.

[0037] Data repository 104 may store computer executable instructions representing application programs, such as, for example, tracer 104a, indexer 104b, debugger 104c, security component 104d, operating system kernel 104f, application 104g (e.g., an application that is the subject of tracing performed by tracer 104a). When these programs are executing (e.g., using processor 102), system memory 103 may store corresponding runtime data, such as runtime data structures, computer executable instructions, etc. Thus, Figure 1 System memory 103 is shown as including application code 103a and application runtime data 103b (e.g., each corresponding to application 104g). Data repository 104 may also store data structures, such as tracking data stored in one or more tracking data repositories 104e. As shown by oval 104h, data repository 104 may also store other computer executable instructions and / or data structures.

[0038] The tracer 104a may be used to record a bit-accurate trace of the execution of one or more entities, such as an application 104g or one or more threads of a kernel 104f, and store the trace data in a trace data repository 104e. In some embodiments, the tracer 104a is a standalone application, while in other embodiments, the tracer 104a is integrated into another software component, such as a kernel 104f, a hypervisor, a cloud fabric, etc. Although the trace data repository 104e is shown as part of the data repository 104, the trace data repository 104e may also be implemented at least in part in the system memory 103, in the cache 102b, or at some other storage device.

[0039] In some embodiments, the tracer 104a records a bit-accurate trace of the execution of one or more entities. As used herein, a "bit-accurate" trace is a trace that includes sufficient data to support that code previously executed at one or more processing units 102a will be replayed so that it executes at the replay time in substantially the same manner as it was during the trace. There are a variety of methods that the tracer 104a can use to record bit-accurate traces. Two different families of methods that provide high levels of performance and reasonable trace sizes will now be briefly outlined, but it should be understood that the embodiments herein can operate in conjunction with traces recorded using other methods. In addition, optimizations can be applied to any of these families of methods that are not described herein for brevity.

[0040] The first family of methods is based on the recognition that processor instructions (including virtual machine "virtual processor" instructions) generally fall into one of three categories: (1) instructions identified as "non-deterministic" because they do not produce predictable outputs because their outputs are not completely determined by data in general registers 102d or cache(s) 102b, (2) deterministic instructions whose inputs do not depend on memory values ​​(e.g., they depend only on processor register values ​​or values ​​defined in the code itself), and (3) deterministic instructions whose inputs depend on reading values ​​from memory. Therefore, in some embodiments, storing sufficient state data to reproduce the execution of instructions can be achieved by solving the following problems: (1) how to record non-deterministic instructions that produce outputs that are not completely determined by their inputs, (2) how to depend on registers to reproduce the values ​​of input registers to instructions, and (3) how to depend on memory reads to reproduce the values ​​of input memory to instructions.

[0041] In some embodiments, the first method (s) for recording the trace records non-deterministic instructions that produce outputs that are not completely determined by their inputs by storing the side effects of the execution of such instructions in the trace data repository 104e. As used herein, "non-deterministic" instructions may include slightly less common instructions that (i) produce non-deterministic outputs each time they are executed (e.g., RDTSC on an INTEL processor, which writes the number of processor cycles since the last processor reset into a register), (ii) can produce deterministic outputs, but depend on inputs that are not tracked by the tracer 104a (e.g., debug registers, timers, etc.), and / or (iii) produce processor-specific information (e.g., CPUID on an INTEL processor, which writes processor-specific data into a register). Storing the side effects of the execution of such instructions may include, for example, storing register values ​​and / or memory values ​​that are changed by the execution of the instructions. In some architectures such as from INTEL, processor features such as those found in the virtual machine extension (VMX) can be used to capture instructions for recording their side effects into the trace data repository 104e.

[0042] Solving how to reproduce the values ​​of the input registers for deterministic instructions (e.g., whose inputs depend only on processor register values) is straightforward, since they are the output of the execution of the previous instruction(s). Thus, the first method(s) for recording a trace can therefore be reduced to recording the execution of an entire series of processor instructions into the trace data repository 104e to reproduce the register values ​​at the beginning of the series; the trace data in the trace data repository 104e does not need to store records of which specific instructions were executed in the series, or intermediate register values. This is because the actual instructions are accessible from the application code 103a itself. Therefore, these instructions can be provided with the recorded inputs (i.e., the initial set of recorded register values) during the reply, executing in the same manner as they did during the trace.

[0043] Finally, the first method(s) for recording traces may address how to reproduce the values ​​of input memory for deterministic instructions whose inputs depend on memory values ​​by recording the memory values ​​consumed (i.e., reads) by these instructions into the trace data repository 104e, regardless of how the values ​​read by the instructions are written to memory. In other words, some embodiments include recording only memory reads, and not memory writes. For example, although values ​​may be written to memory by the current thread, by another thread (including the kernel, e.g., as part of handling an interrupt), or by a hardware device (e.g., input / output hardware 105), it is only the values ​​read by the instructions of the thread that are required to fully replay the instructions of the thread that executed the reads. This is because the values ​​read by the thread (not necessarily all values ​​written to memory) determine how the thread executes.

[0044] The second family of methods for recording bit-accurate traces is based on the recognition that the processor 102 (including the cache 102b) forms a semi-closed or quasi-closed system. For example, once a portion of the data for a process (i.e., code data and runtime application data) is loaded into the cache(s) 102b, the processor 102 can run multiple bursts of time on its own as a semi-closed or quasi-closed system without any input. In particular, once the cache(s) 102b are loaded with data, one or more of the processing units 102a use the runtime data stored in the data portion(s) of the cache(s) 102b and use the registers 102d to execute instructions from the code portion(s) of the cache(s) 102b. When processing unit 102a needs some information to be flushed in (e.g., because the instruction it is executing, is about to execute, or can execute accesses code or runtime data that is not in cache 102b), a "cache miss" will occur and the information will be brought into cache 102b from system memory 103. For example, if a data cache miss occurs when the executed instruction performs a memory operation at a memory address within application runtime data 103b, the data from that memory address is brought into one of the cache lines of the data portion of cache 102b. Similarly, if a code cache miss occurs when an instruction performs a memory operation at a memory address application code 103a stored in system memory 103, the code from that memory address will be brought into one of the cache lines of the code portion of cache 102b. Processing unit 102a then continues to execute using the new information in cache 102b until new information is brought into cache 102b again (e.g., due to another cache miss or uncached read).

[0045] Thus, in the second method family, tracer 104a may record sufficient data to be able to reproduce the influx of information into cache 102b as the traced processing unit executes.Four example implementations within this second method family will now be described, although it will be appreciated that these are not exhaustive.

[0046] A first implementation may log all data brought into cache 102b into trace data repository 104e by recording all cache misses and uncached reads (i.e., reads from hardware components and non-cacheable), as well as the time each piece of data was brought into cache 102b during execution (e.g., using a count of executed instructions or some other counter). Thus, the effect is to record a log of all data consumed by the traced processing unit 102a during execution of the code. However, due to the alternating and / or speculative execution of multiple threads, this implementation may log more data than is necessary to replay the execution of the traced code.

[0047] The second implementation in the second method family improves on the first implementation by tracking and recording only the cache lines "consumed" by each processing unit 102a, and / or tracking and recording only a subset of the cache lines used by the processing units 102a participating in the tracking, rather than recording all cache misses. As used herein, a processing unit "consumes" a cache line when it knows the current value of the cache line. This may be because the processing unit is the unit that writes the current value of the cache line, or because the processing unit performs a read on the cache line. Some embodiments track consumed cache lines and extensions to one or more caches 102b (e.g., additional "logging" or "billing" bits) that enable the processor 102 to identify, for each cache line, the one or more processing units 102a that consumed the cache line. Embodiments may track a subset of cache lines being used by the processing units 102a participating in the tracking by using way locks in the associated cache, e.g., the processor 102 may dedicate a subset of ways in each address group of the associated cache to the tracked processing unit and only log cache misses related to those ways.

[0048] A third implementation in the second family of methods may additionally or alternatively be built on top of a cache coherence protocol (CCP) used by the cache(s) 102b. In particular, the third implementation may use the CCP to determine a subset of "consumed" cache lines to record into the tracking data repository 104e, and this will still enable the activity of the cache(s) 102b to be reproduced. The method may operate at a single cache level (e.g., L1), and log data influxes and CCP operations to that cache level at the granularity of the processing unit that caused the given CCP operation. This includes logging which processing unit(s) have previously read and / or written accesses to cache lines.

[0049] A fourth implementation may also utilize CCP data, but operates when two or more cache level logging floods of data going to a "higher level" shared cache (e.g., at the L2 cache), while using the CCP of at least one "lower level" cache (e.g., one CCP and another L1 cache) to log a subset of CCP state transitions for each cached memory location (i.e., between segments of "load" operations and segments of "store" operations). The effect is that less CCP data is logged than the third implementation (i.e., because it logs much less CCP state data than the third implementation because it logs based on load / store transitions rather than per-processing unit activity). Such a log may be post-processed and enhanced to reach the level of detail logged in the third implementation, but may also be built into silicon using potentially less costly hardware modifications than the third implementation (e.g., because less CCP data needs to be tracked and logged by processor 102).

[0050] Regardless of the recording method used by the tracer 104a, it can record the trace data into one or more trace data repositories 104e. As an example, the trace data repository 104e may include one or more trace files, one or more areas of physical memory, one or more areas of a processor cache (e.g., an L2 or L3 cache), or any combination or multiple thereof. The trace data repository 104e may include one or more trace data streams. In some embodiments, for example, multiple entities (e.g., processes, threads, etc.) may be tracked to separate trace files or trace data streams within a given trace file. Alternatively, the data packets corresponding to each entity may be marked so that they are identified as corresponding to the entity. If multiple related entities (e.g., multiple threads of the same process) are tracked, the trace data of each entity may also be tracked independently (so that they can be replayed independently), although any event that can be sequenced across entities (e.g., access to shared memory) may be identified using a global sequence number (e.g., a monotonically increasing number) that is tracked across independent traces. The trace data repository 104e may be configured to flexibly manage, modify, and / or create trace data streams. For example, modification of an existing trace data stream may involve modification of an existing trace file, replacement of segments of trace data within an existing file, and / or creation of a new trace file including the modification.

[0051] In some implementations, the tracer 104a can continuously attach to (multiple) trace data streams so that the trace data grows continuously during the trace. However, in other implementations, the trace data streams can be implemented as one or more circular buffers. In such an implementation, as new trace data is added to the trace data repository 104e, the oldest trace data is deleted from the data stream. In this way, when the trace data streams are implemented as buffers, they contain rolling traces of the most recent execution at the traced process. The use of a circular buffer can support the tracer 104a to perform "always on" tracing even in production systems. In some implementations, tracing can actually be enabled and disabled at any time. In this way, whether tracing is to a circular buffer or attached to a traditional trace data stream, the trace data can include the interval between the time periods during which tracing is enabled.

[0052] The trace data repository 104e may include information that helps facilitate efficient trace replay and search on the trace data. For example, the trace data may include periodic key frames that support replaying the trace data stream starting at the time of the key frame. The key frame may include, for example, the values ​​of all processor registers 102d required to resume replay. The trace data may also include memory snapshots (e.g., the values ​​of one or more memory addresses at a given time), reverse lookup data structures (e.g., identifying information in the trace data based on memory addresses as keys), etc.

[0053] Even when using the above-described efficient tracing mechanisms, there may be practical limits to the richness of information that can be stored in the trace data repository 104e during tracing by the tracer 104a. This may be due to efforts to reduce memory usage, processor usage, and / or input / output bandwidth usage during tracing (i.e., reduce the impact of tracing on the application being traced), and / or to reduce the amount of trace data generated (i.e., reduce disk space usage). Thus, even though the trace data may include rich information (such as keyframes, memory snapshots, and / or reverse lookup data structures), the tracer 104a may still limit the frequency with which this information is recorded to the trace data repository 104e, or may even omit some of these types of information entirely.

[0054] To overcome these limitations, embodiments may include an indexer 104b that takes as input the trace data generated by the tracer 104a and performs transformations on the trace data to improve the performance of the trace data (or data derived therefrom) being consumed by the debugger 104c. For example, the indexer 104b may add keyframes, memory snapshots, reverse lookup data structures, etc. The indexer 104b may augment existing trace data, and / or may generate new trace data containing new information. The indexer 104b may operate based on a static analysis of the trace data, and / or may perform a runtime analysis (e.g., based on replaying one or more portions of the trace data).

[0055] The debugger 104c may be used to consume (e.g., replay) the trace data generated by the tracer 104a into the trace data repository 104e, including any derivation of the trace data generated by the indexer 104b (concurrently executed, or other computer systems), so as to assist a user in performing debugging operations on the trace data (or data derived therefrom). For example, the debugger 104c may present one or more debugging interfaces (e.g., user interfaces and / or application programming interfaces), replay before execution of one or more portions of the application 104g, set breakpoints / watchpoints (including reverse breakpoints / watchpoints), enable querying / searching the trace data, and the like.

[0056] The security component 104d identifies sensitive information (i.e., data and / or code) captured by the tracer 104a, and takes one or more actions to ensure that such information is restricted from being presented at the debugger 104c. With respect to sensitive data, this may include one or more of: preventing sensitive data from being placed in the trace data repository 104e, removing sensitive data from the trace data repository 104e, masking / encrypting sensitive data in the trace data repository 104e, distinguishing sensitive data in the trace data repository 104e (e.g., by storing it in a separate trace data stream), modifying the trace data such that execution during replay of the trace data is modified to avoid presenting the sensitive data, modifying the trace data such that the execution path taken during replay of the trace data is the same as the path taken during tracing even though the modified trace data lacks the sensitive data, preventing the debugger 104c from presenting the sensitive data even though the sensitive data is present in the unmodified trace data, and the like. With respect to sensitive code, this may include removing code from the trace data, bypassing code in the trace data 104e, encrypting code in the trace data 104e, and the like. In conjunction with Figure 2 An example embodiment of the security component 104d is described in further detail.

[0057] In some implementations, the security component 104d enhances the functionality of one or more of the tracer 104a, the indexer 104b, and the debugger 104c. Thus, for example, the security component 104d may enhance the tracer 104a to enable it to have the ability to avoid writing sensitive information to the trace data repository 104e and / or to protect sensitive information in the trace data repository 104e; the security component 104d may enhance the indexer 102b to enable it to have the ability to clear the trace data of sensitive information and / or to mask the sensitive information in the trace data; and / or the security component 104d may enhance the debugger 104c to enable it to have the ability to avoid presenting sensitive information contained in the trace data.

[0058] Although the tracker 104a, indexer 104b, debugger 104c, and security component 104d are depicted as separate entities (for clarity), it should be understood that one or more of these entities may be combined (e.g., subcomponents) into a single entity. For example, a debugging suite may include each of the tracker 104a, indexer 104b, debugger 104c, and security component 104d. In another example, the tracking suite may include the tracker 104a and indexer 104b, while the debugging suite may include the debugger 104c; alternatively, the tracking suite may include the tracker 104a, while the debugging suite may include the indexer 104b and debugger 104c. In these latter examples, the security component 104d may be implemented in each of the tracking suite and the debugging suite, or may be implemented as a common library shared by these suites. Of course, other variations are possible. It is worth noting that the tracker 104a, indexer 104b, debugger 104c, and security component 104d do not need to all be present at the same computer system. For example, a trace suite may be executed at one or more first computer systems (e.g., a production environment, a test environment, etc.), while a debug suite may be executed at one or more second computer systems (e.g., a developer's computer, a distributed computing system that facilitates distributed replay of trace data, etc.). Likewise, as shown, the tracer 104a, indexer 104b, and / or debugger 104c may access the trace data repository 104e directly (i.e., as indicated by dashed arrows) and / or through the security component 104c (i.e., as indicated by solid arrows).

[0059] As mentioned above, Figure 2 Shows such as Figure 1104d of the security component 104d. As shown, the security component 200 may include multiple subcomponents, such as, for example, an identification component 201 (including an annotation subcomponent 201a, a derivation subcomponent 201b, a replication subcomponent 201c, a user input subcomponent 201d, a database 201e, etc.), a data modification component 202, a code modification component 203, etc. Although these components are presented as an aid to describe the functionality of the security component 200, it should be understood that the specific number and identity of these components may vary depending on the implementation.

[0060] The identification component 201 identifies sensitive raw information. As previously described, this can include potentially sensitive information and deterministically sensitive information. The raw information can correspond to any form of code or data accessed by the processor 102, and is typically stored at one or more memory addresses. The raw information can correspond to at least a portion of one or more of a pointer, a data structure, a variable, a class, a field, a function, a source file, a component, a module, an executable instruction, etc.

[0061] The specific times at which identification component 201 identifies sensitive information may vary depending on the implementation. For example, identification may occur during initial recording into data repository 104e by tracker 104a (e.g., runtime analysis, such as using page table entries, enclave region metadata, etc.), during post-processing of the trace data by indexer 104b (e.g., static analysis, perhaps using debug symbols, etc.), and / or during replay of the trace data by indexer 104b and / or debugger 104c (e.g., static and / or runtime analysis). When it identifies sensitive information, identification component 201 may record it in one or more databases 201e for use by replication component 102c, as described later.

[0062] The identification component 201 can identify sensitive information in a variety of ways represented by the annotation subcomponent 201a, the derivation subcomponent 201b, the replication subcomponent 201c, and the user input subcomponent 201d (although other methods may also be used, as indicated by the ellipsis). The annotation subcomponent 201a, the derivation subcomponent 201b, and the replication subcomponent 201c will now be described in detail. However, it should be noted initially that the user input subcomponent 201d can be used in conjunction with any of these components, such as to manually identify code that interacts with sensitive data (i.e., as input to the annotation subcomponent 201a), manually identify data derived from the data (i.e., as input to the derivation subcomponent 201b), manually identify a copy of the data (i.e., as input to the replication subcomponent 201c), and / or provide data to the database 201e.

[0063] In general, the annotation subcomponent 201a may identify sensitive information based on annotations about an entity that is executing at the processor 102 and is being traced. For example, the code of the entity (whether source code, object code, assembly code, machine code, etc.) may be annotated to identify one or more portions of the code that are themselves sensitive, that take sensitive data as input, that process sensitive data, that generate sensitive data, that store sensitive data, and the like. For example, an entity may be annotated to identify functions, parameters, modules, variables, data structures, source code files, input fields, and the like that are themselves sensitive and / or that may involve the creation, consumption, or processing of sensitive data. As an example, a memory region of a secure enclave may be considered sensitive (for code, data reads, and / or data writes). As an example, a page table entry that was applicable during the original execution may indicate permissions that apply to part (or all) of the trace stream. As an example, a PCID, an ASID, a processor security level, a processor exception level, and the like may be used to determine security boundaries that apply to part (or all) of the trace stream. Thus, the annotation subcomponent 201a can use these annotations to identify when sensitive code portions are executed (e.g., as part of tracing the code, replaying the code and / or analyzing the code based on its previous execution being traced into the data repository 104e), and / or when sensitive data is accessed, processed and / or generated when the code portions are executed.

[0064] The annotations that the annotation subcomponent 201a relies on can be added to the entity's code itself, can be added as a separate metadata file, and / or can even be stored in the database 201e. These annotations can be created in a variety of ways, such as using one or more of manual, automatic, and / or semi-automatic techniques, such as human input (i.e., using the user input component 201d), machine learning, derived analysis performed by the annotation subcomponent 201a, etc. Annotations about an entity can be created before and / or during analysis by the annotation subcomponent 201a (e.g., based on user input, machine learning, derived analysis, etc.).

[0065] On the other hand, the inference subcomponent 201b exploits the rich properties of time travel traces (i.e., the fact that they capture a bit-accurate trace of the way code was previously executed) to trace code execution, including the flow of data during code execution, in one or both of the forward and reverse directions on the execution timeline. As part of this trace, the inference subcomponent 201b may identify at least one or more of the following: (i) data derived from data that has already been identified as sensitive; (ii) data from which data that has already been identified as sensitive is itself derived; (iii) code that may be annotated as being associated with sensitive data because it acts on data that was previously acted upon by code known to be associated with the data identified as sensitive; (iv) code that may be annotated as being associated with sensitive data because it acts on data that is later acted upon by code known to be associated with the data identified as sensitive; or (v) code that may itself be annotated as being sensitive because it has execution continuity with code that has already been identified as sensitive. To further understand these concepts, Figure 3A and 3B Examples of derived analysis for identifying derived data and / or code are shown.

[0066] Figure 3A An example embodiment 300a is shown that relies on bit-accurate tracing to identify derived data and / or code in a forward direction on an execution timeline. Example 300a includes a portion of a timeline 301 representing execution at a processing unit 102a, and a corresponding portion of a trace data stream 302 storing a bit-accurate trace of the execution. Example 300a may represent tracing the original execution of an entity into the trace data stream 302, or replaying the original execution of an entity from the trace data stream 302. Figure 3A Two points 303 and 305 are shown, both representing different execution moments during the timeline 301, and corresponding portions of data in the trace data stream 302. In particular, point 303 represents a particular moment at which the first data being accessed by the first code has been identified as sensitive (and by extension, the first code acts on sensitive data) and / or the first code itself is known to be identified as sensitive data. On the other hand, point 305 represents a later execution moment at which the second data is being accessed by the second code and / or the second code itself is being accessed or executed.

[0067] At point 305, it is not yet known whether the second data is sensitive; whether the second code acts on sensitive data; and / or whether the second code itself is sensitive. Figure 3AAlso shown is an arrow 304 from point 303 to point 305. Arrow 304 indicates that there is traced code and / or data continuity between points 303 and 305, which can be used to determine that the second data accessed at point 305 can be identified as sensitive because it is derived from the first data accessed at point 303 and / or the second code accessed / executed at point 305 can also itself be sensitive due to its relationship to the first code executed at point 303. Therefore, the continuity represented by arrow 304 enables the inference subcomponent 201b to analyze / replay the trace data flow 302 in the forward direction (i.e., from point 303 to point 305) and determine that the second data accessed at point 305 is derived from the first data accessed at point 303 and / or the second code is executed as a result of the first code.

[0068] Based on this continuity, the derivation subcomponent 201b can then identify the second data as sensitive data; the second code acts on sensitive data; and / or the second code itself is sensitive. If the second code itself is identified as acting on sensitive data and / or is sensitive data, the annotation subcomponent 201a can annotate the second code accordingly (if necessary). Figure 3A Only one example of derived data and / or code is shown in , but it should be understood that the analysis can be recursively applied to identify any number of additional derived terms.

[0069] on the other hand, Figure 3B An example 300b is shown that relies on bit-accurate tracking to identify derived data and / or code in the reverse direction on the execution timeline. Figure 3A , Figure 3B A portion of a timeline 306 representing execution at processing unit 102a is shown, along with a corresponding portion of a trace data stream 307 storing a bit accurate trace of the execution. Figure 3B Also included are two points 308 and 310, both of which represent different execution moments during timeline 306, and corresponding portions of data in trace data stream 307. Figure 3A different, Figure 3BAn arrow 309 is shown, which is in the reverse direction (i.e., from point 310 to point 308), and arrow 309 represents the tracked code / data continuity between these points. This indicates that point 310 is a point at which the data accessed is identified as sensitive and / or the code executed is identified as sensitive; and that point 308 is a point at which the relevant data and / or code is accessed (i.e., a previous time during the execution timeline 306). Here, the continuity represented by arrow 309 enables the derivation subcomponent 201b to determine in the reverse direction (i.e., from point 310 to point 308) that the data accessed at point 310 is derived from the data accessed at point 308 and / or the code executed at point 310 is related to the code executed at point 308. Therefore, the derivation subcomponent 201b can identify the data accessed at point 308 as sensitive data; the code executed at point 308 interacts with sensitive data; and / or the code executed at point 308 is itself sensitive code. Again, the annotation subcomponent 201a can annotate the code as needed and / or the analysis can be applied recursively (from point 310 forward and / or from point 308 backward) to identify any number of additional derived items. In implementation, this allows for backward identification (and therefore protection) of sensitive data during execution time.

[0070] The replication subcomponent 201c identifies copies of sensitive information based on a database 201e that identifies or includes information that has previously been identified as sensitive. The replication subcomponent 201c can make these identifications at runtime (e.g., as part of tracing using the tracer 104a, and / or as part of replay by the indexer 104b and / or debugger 104c) or statically (e.g., as part of static analysis of tracing data such as performed by the indexer 104b). In general, the replication subcomponent 201c can determine whether items that are accessed, generated, and / or executed at runtime (whether during tracing or during replay) and / or items that have been logged into the tracing data repository 104e can be identified as sensitive items based on directly comparing them to entries in the database 201e and / or comparing certain derived items of them to entries in the database 201e.

[0071] As described above, database 201e can be generated by identification component 201, and / or can be provided to identification component 201 (e.g., by a human user) in other ways. For example, when identification component 201 identifies an item as a sensitive item (e.g., based on the operation of annotation component 201a, the operation of deriving component 201b, or user input at user input component 201d), identification component 201 can store the item itself or its derived items in some form of searchable data repository (such as a lookup table, hash table, SQL data table, etc.). In this way, when operating, identification component 201 can develop an evolving knowledge base of identified sensitive information, which replica subcomponent 201c can rely on. In some implementations, data type information (e.g., from debug symbols, function prototype information, etc.) can enhance the identification of data, such as by identifying how sensitive data is embodied within a structure, string, or other data type. As described above, database 201e can store the information itself or its derived information. Storing derived information of the information (e.g., a hash of the information, an encrypted version of the information, etc.) can provide a variety of benefits, such as maintaining the security of the information, reducing storage requirements in the database 201e, and / or improving storage and / or search performance of the database 201e.

[0072] When replication subcomponent 201c is tasked with determining whether the original information is sensitive, it may compare the original information with entries in database(s) 201e to determine whether it has been previously identified as sensitive information in database(s) 201e. If so, replication subcomponent 201c may also identify the information instance as sensitive information. If database 201e stores hashed or encrypted versions of the sensitive information, replication subcomponent 201c may hash or encrypt the original information using the same algorithm / key prior to comparison.

[0073] By maintaining and using searchable (multiple) databases 201e in this manner, identification component 201 (utilizing replication subcomponent 201c) can help identify sensitive information that, in some cases, cannot normally be identified by annotation subcomponent 201a and / or derivation subcomponent 201b. The reason is that even if annotation subcomponent 201a and / or derivation subcomponent 201b can identify an item as sensitive at a first moment during code execution (e.g., because it is used in conjunction with code known to interact with sensitive data), this same information may not be identified as sensitive information by these components at a second moment during code execution (whether the second moment is before or after the first moment). Therefore, in at least some implementations, earlier accesses to data in a bit-accurate trace can be determined to be sensitive based on subsequent (later execution time) accesses to the data, thereby identifying the data as sensitive data. In at least some cases, this allows protection of information even at first use, even when this first use itself does not result in the data being identified as sensitive data, and before (execution time) any access that results in the data being identified as sensitive data.

[0074] For example, even if a data item or code may actually be related to sensitive information that has been identified in database 201e through code continuity, the code continuity may not be captured in trace data repository 104e. This may occur, for example, if trace data repository 104e lacks trace data during one or more execution time periods. If tracing is enabled and disabled while recording and / or if the trace data stream is implemented as a ring buffer, then trace data repository 104e may lack such data.

[0075] In the case where tracking is enabled / disabled while recording, sensitive data can be read by a first code while tracking is enabled, tracking can be subsequently disabled, and the same data can be read again by a second (but related) code when tracking is subsequently enabled. In this case, based on the annotation subcomponent 201a knowing that the first code interacts with the sensitive data, the sensitive data can be identified in relation to the first read; however, the annotation subcomponent 201a may not be able to identify the same data as sensitive data during a subsequent tracking period because the annotation subcomponent 201a lacks the knowledge that the second code interacts with the sensitive data. In addition, due to gaps in the available tracking data, the derivation subcomponent 201b may not be able to track the continuity between the first read and the second read. However, the replication subcomponent 201c can recognize that the second code is reading data that is known to be sensitive, and therefore identifies the second read as sensitive. This principle also applies to the other direction, that is, based on the second read being identified as sensitive by the annotation subcomponent 201a and / or the derivation subcomponent 201b, the replication subcomponent 201c can identify the first read as sensitive.

[0076] In the case of using (multiple) data streams implemented as (multiple) ring buffers, the trace data repository 104e can store one or more memory snapshots that are taken when tracing is active but contain values ​​that were written to memory when the trace data was not available (for example, because tracing was disabled, or the trace data has been cleared from the ring buffer). In these cases, the memory snapshot may contain sensitive data, but the annotation subcomponent 201 and / or the inference subcomponent 201b cannot identify the data as sensitive data because it does not know what code put these values ​​into memory (and whether there is continuity between that code and code that is known to interact with sensitive data). At this point, the replication subcomponent 201c can compare these values ​​with the database 201e to determine whether any values ​​should be identified as sensitive data. Similarly, the principle also applies in the other direction, that is, the replication subcomponent 201c can identify sensitive data in a memory snapshot taken after the period of execution being traced.

[0077] The replication subcomponent 201c can identify one or more copies of sensitive information even in cases where the copies are completely unrelated to known sensitive information through code continuity. For example, the same data can be provided as input to (or even generated by) completely independent and unrelated code execution paths. If the data is identified as sensitive data in one code execution path, the replication subcomponent 201c can also identify it as sensitive data when another code execution path uses the data. This principle also applies to the memory snapshot example above, that is, even though the data in the snapshot may be completely unrelated to the data identified as sensitive during code execution, the replication subcomponent 201c can still identify it as sensitive data.

[0078] It should be understood that the replication subcomponent 201c can process the entire tracking data in the tracking data repository 104e to locate all information in the tracking data that is identified as sensitive in the database 201e. Therefore, once at least one copy of an item is identified as sensitive, the replica subcomponent 201c can identify all other instances of the item in the tracking data repository 104e, regardless of how these instances entered the tracking data repository 104e. Once identified, this enables the security component 200 to delete / mask all instances of sensitive information from the tracking data repository 104e. Similarly, if there are inverted index structures in the tracking data repository 104e, once a storage location is identified as containing sensitive data, these inverted index structures can be used to quickly identify other accesses to sensitive data and / or identify when (at execution time) sensitive data is overwritten by non-sensitive data.

[0079] Non-sensitive data may include data that is explicitly defined as non-sensitive, or data that is discovered to be non-sensitive in a general manner (e.g., because it is discovered to be derived from or a copy of data that has been explicitly defined as non-sensitive). The identity of specific information may change from sensitive to non-sensitive, or vice versa. For example, in an implementation, sensitive data is considered sensitive until a type-specific condition is met. For example, a type-specific condition for a string that ends with zero may be that all bytes of the original string length are overwritten with non-sensitive data, or that all bytes of the original string length are overwritten with zeros. Similarly, a structure (or higher-level construct, such as a class) may have a type-specific condition indicating that the structure should continue to be considered sensitive until a destructor or other function is called, or a field / member has a specific value (in addition to or in lieu of a default requirement).

[0080] In some embodiments, the identification component 201 includes functionality for processing code that moves or copies data but does not actually consume or process the data it moves / copies. Examples of such code may be known memory copies (e.g., memcpy, memcpy_s, memmove, memmove_s, etc.) and string copies (e.g., strcpy, strncpy, etc.) used in the C programming language. Such functions may move or copy segments of memory that include sensitive information, but these functions do not actually do anything with the data other than move / copy (i.e., they are neutral with respect to sensitive data).

[0081] In some implementations, the derivation subcomponent 201c and / or the replication subcomponent 201c can cause such functions to be marked as being related to sensitive information, which may (unwantedly) cause all codes touched by such functions to be identified as sensitive code. In order to avoid this situation, an embodiment may retain a list of known functions that are neutral to sensitive data (e.g., in database 201e). Then, the list can be used to prevent these functions from being identified as being related to sensitive information. Although this can cover known functions that are neutral to sensitive data (such as memcpy and stringcpy), it may not cover custom coded functions that are neutral to sensitive data. In this way, additionally or alternatively, an embodiment can detect code that reads and / or writes data but does not make any decisions based on the data (i.e., it just moves / copies around), and avoids identifying such code as involving sensitive information. An example implementation may have comments indicating that a function is (or is not) neutral to sensitive data, comments in debug symbols, etc. in the binary code. Such detection may allow for exceptions that permit code to make limited decisions about the data it moves / copies (e.g., such as performing a copy up to but not including a null terminator) while still being considered sensitive data neutral.

[0082] Based on identification component 201 identifying the information as sensitive information, security component 200 removes it from or obscures it within tracking data repository 104e using one or both of data modification component 202 or code modification component 203 .

[0083] The data modification component 202 replaces data items that have been identified as sensitive with alternative data and / or causes these data items to be stored in the tracking data repository 104e in a masked or protected manner. Figure 4A and 4B An example embodiment of data item replacement and / or masking in time travel tracking is illustrated.

[0084] initial, Figure 4A An example 400a of sensitive data item replacement / masking with respect to a single trace data stream is illustrated. In particular, Figure 4A Illustrated is a portion of a timeline 401 representing execution of an entity at processing unit 102a, and a corresponding portion of a trace data stream 402 storing a bit accurate trace of the execution. Figure 4A Also illustrated is that a sensitive data item is identified at point 403 in the execution, and the sensitive data is replaced or masked by the data modification component 202 at a corresponding point 404 in the trace data stream 402. Replacing the data item may include identifying or generating alternative data to store in the trace data stream 402 instead of the original data identified at point 403. This may include the data modification component 202 generating random data, identifying predefined data, generating derived data (e.g., a hash) of the original data, and the like. In some embodiments, identifying or generating the replacement data may include preserving one or more characteristics of the original data, such as reserving a type of data (e.g., a string, an integer, a floating point number, etc.), a size of the reserved data (e.g., an integer size, a string length, etc.), a portion of the reserved data (e.g., replacing only a subset of the string), and the like. Masking the data item may include the data modification component 202 encrypting the data item before storing it in the trace data stream 402, encrypting the entire trace data stream 402 or a trace file, and the like.

[0085] on the other hand, Figure 4B An example 400b of sensitive data item replacement / masking with respect to multiple trace data flows is illustrated. In particular, Figure 4B A portion of a timeline 405 representing execution of an entity at processing unit 102a and corresponding portions of trace data streams 406 and 407 storing a bit accurate trace of the execution are illustrated. Figure 4A , Figure 4B The sensitive data item is shown identified at point 408 in the execution. However, rather than replacing or masking the data item in a single trace data stream, Figure 4B 4. The diagram shows replacing a data item in a first data stream (i.e., point 409 in tracking data stream 406) while storing it in its original or masked form in a second data stream (i.e., point 410 in tracking data stream 407). Replacing a data item in tracking data stream 406 may include generating or identifying the above combination. Figure 4A Any mechanism described for alternative data; storing data items in masked form may include a combination of the above Figure 4A 405. Debugger 104c may then use data items from trace data stream 406 when sensitive data should be protected, and may use data items from trace data stream 407 when sensitive data does not need to be protected (e.g., depending on the user using debugger 104c, the computer on which debugger 104c operates, whether a decryption key has been provided, etc.). Notably, trace data stream 407 need not be a complete trace of execution timeline 405. For example, trace data stream 406 may be used to store a complete trace, while trace data stream 407 may be used to store a subset of trace activity, such as trace activity related to sensitive information.

[0086] The data modification component 202 may operate at any time during trace generation or consumption. For example, the data modification component 202 may operate when the timeline 401 / 405 represents the original execution of the entity, and when the trace data stream 402 / 406 / 407 is the original trace data stream (e.g., as recorded by the tracer 104a). In another example, the data modification component 202 may operate when the timeline 401 / 405 represents the replayed execution of the entity (e.g., by the indexer 104b and / or the debugger 104c), and when the trace data stream 402 / 406 / 407 is the derived / indexed trace data stream. The data modification component 202 may also operate based on static analysis of the trace data, such as by the indexer 104b.

[0087] The code modification component 203 stores data in a trace that ensures that the execution path taken by the entity during its original execution will also be taken during replay, even if the data modification component 202 performs data replacement activities; and / or stores data in a trace that causes alternative executable instructions to be executed instead of the original executable instructions during replay of the entity. These concepts are combined Figures 5A-5C Give a description.

[0088] initial, Figure 5A An example 500a is illustrated that ensures that even with data replacement, the execution path taken by an entity during its original execution will be taken during replay. In particular, Figure 5AIllustrated is a portion of a timeline 501 representing execution of an entity at processing unit 102a, and a corresponding portion of a trace data stream 503 storing a bit accurate trace of the execution. Figure 5A Also shown is the identification of a sensitive data item at point 505 in the execution that can be replaced by the data modification component 202 in the trace data flow 503. However, Figure 5A It is shown that depending on the value of the sensitive data item, point 505 has caused the alternative execution path 502 to occur. For example, the sensitive data item may have been a parameter of a conditional statement in the code. In this way, replacing the sensitive data item by the data modification component 202 may cause the alternative execution path 502 to occur during replay, which will result in incorrect trace replay. In order to prevent this replay behavior, the code modification component 203 can store tracking data at point 506 in the tracking data stream 503, which ensures that the original execution path can be adopted during replay even if data replacement is performed. This is indicated by the replay timeline 504, which shows the original execution path being adopted.

[0089] In some embodiments, the code modification component 203 records tracking data, which includes one or more alternative executable instructions that will adopt the original path even if data replacement is performed. For example, the original instruction can be replaced by an alternative executable instruction that changes the condition. Additionally or alternatively, the code modification component 203 can record tracking data including code comments, which still cause the original execution path to be adopted even if the result execution is a conditional instruction during replay. For example, as described above, some tracking embodiments record the side effects of uncertain instructions so that these instructions can be replayed later. Embodiments can apply the same principle to deterministic conditional instructions, that is, the expected result of the conditional instruction can be recorded as a "side effect", and even if the actual result of the execution is a conditional instruction, the side effect can also be used to produce the expected result during replay.

[0090] Sometimes, the security component 200 can avoid using the code modification component 203 while still ensuring that the correct execution path is taken despite the data modification. For example, the data modification component 202 can ensure that the substitute data it uses to replace the original data will produce the same result of the condition. For example, if the result of the condition is based on the size of the data, this can be achieved by ensuring that the substitute data has the same size (e.g., string length) as the original data.

[0091] Figure 5B An example 500b of storing data into a single trace data stream that enables alternative executable instructions to be executed during replay of an entity is illustrated. In particular, Figure 5BIllustrated is a portion of a timeline 508 representing execution of an entity at processing unit 102a, and a corresponding portion of a trace data stream 509 storing a bit accurate trace of the execution. Figure 5B Also shown at segment 511 is the identification of the execution of sensitive code. As a result of segment 511 identifying sensitive code, code modification component 203 may record data at point 512 into trace data stream 509 that effectively bypasses segment 511 during replay, but enables replay to continue as usual (with less sensitive code executed), as shown at point 513 on replay timeline 510. For example, the data at point 512 may include one or more alternative instructions that replace the call to sensitive code with one or more instructions that establish the state that exists due to the execution of segment 511 (e.g., register and memory values), and jump to instructions executed immediately after segment 511. As part of this operation, code modification component 203 may replace any sensitive data in the state with data modification component 202, as needed. Additionally or alternatively, the data at point 512 may include one or more key frames, such as a key frame that causes replay to skip segment 511. Additionally or alternatively, the data at point 512 may include one or more "side effects," such as a side effect that causes existing instructions to bypass calls to segment 511. Regardless of how it is executed, the data stored at point 512 causes segment 511 of sensitive code to be effectively converted to a "black box" during replay. Thus, the technical effect is that timeline 508 can be replayed while skipping or bypassing segment 511. In some embodiments, code modification component 203 can capture memory snapshots and / or key frames at the beginning and / or end of segment 511 to capture memory and / or register states, and record these snapshots and / or key frames in trace data stream 509.

[0092] Figure 5C An example 500c of storing data in at least one tracing data stream that causes alternative executable instructions to be executed during replay of an entity is illustrated. In particular, Figure 5C A portion of a timeline 514 representing execution of an entity at processing unit 102a is shown, along with corresponding portions of trace data streams 515, 516 and / or 517 that may be used to store a bit accurate trace of the execution. Figure 5C Also shown is the execution of segment 521 identified as sensitive code (or access to sensitive data). In implementation, as a result of identifying segment 521 as sensitive, code modification component 203 can record data at point 522 that effectively bypasses segment 521 during replay into tracking data stream 515, such as in conjunction with Figure 5B Therefore, similar to Figure 5B509 , the trace data stream 515 may be used to replay execution while bypassing the sensitive instructions in box 521 , as shown at point 525 on the replay timeline 518 .

[0093] Additionally or alternatively, in an implementation, the code modification component 203 may record instructions 523 that cause some (or all) of the side effects that will be produced by the execution of the segment 521 into the trace data stream 516. As an example, the instructions 523 may write a final value to a memory modified by the execution of the segment 521, and / or the instructions 523 ensure that the register state matches the state at the end of the execution of the segment 521. As a specific example, if the segment 521 corresponds to an instruction to encrypt the original data (sensitive data) into an encrypted form (non-sensitive data) using a private key (sensitive data), the original sensitive data may be modified (as described throughout the specification), and the code in the segment 521 may be replaced with instructions 523 that write the final encrypted data. In this specific example, since the replacement instructions 523 recreate the side effects of the deleted segment 519, the replacement may eliminate any need for snapshots or keyframes in the trace data stream 516. Trace data stream 516 is then used to replay the effects of executing the sensitive instructions in block 521 without actually executing the instructions in block 521 , as shown by block 526 on replay timeline 519 .

[0094] Additionally or alternatively, in implementations, code modification component 203 may record the execution of block 521 into a trace data stream 517, which may be encrypted. This is illustrated by block 524. Thus, with the necessary permissions, trace data stream 517 may be used to actually replay the execution of the sensitive code in block 521 (as illustrated by block 527 on replay timeline 527).

[0095] Any combination of trace data streams 515, 516, or 517 may be recorded and / or used for debugging. For example, when sensitive code should be protected during replay, debugger 104c may replay instructions at point 522 in trace data stream 515, and / or may replay instructions at point 523 in trace data stream 516. When sensitive data is not protected during replay (e.g., depending on the user using debugger 104c, the computer on which debugger 104c operates, whether a decryption key has been provided, etc.), debugger 104c may replay from box 527 in trace data stream 520. It is worth noting that each trace data stream may not need to include a complete trace of execution timeline 514. For example, trace data stream 515 may be used to store a complete trace, while trace data streams 516 and / or 517 may be used to store a subset of trace activity, such as trace activity related to the execution of sensitive code.

[0096] Like data modification component 202, code modification component 203 can operate at any time during trace generation or consumption, whether during tracing by tracer 104a, indexing by indexer 104b, and / or debugging by debugger 104c. In addition, code modification component 203 can operate based on runtime analysis and / or static analysis.

[0097] It is worth noting that the embodiments herein may include Figures 4A-5C Any combination and / or repetition of the examples shown may apply.

[0098] Figure 6 A flow chart of an example method 600 for protecting sensitive information associated with the original execution of a tracking entity is illustrated. Figure 1 Components and data of computer architecture 100, Figure 2 Method 600 is described with reference to the security component 200 and the examples of FIGS. 3-5C .

[0099] As shown, method 600 includes an action 601: identifying that original information accessed during original execution of an entity includes sensitive information. In some embodiments, action 601 includes identifying that original information includes sensitive information, which is accessed based on the original execution of one or more original executable instructions of the entity. For example, during the original execution of the entity at one or more processing units 102a, or from a tracking data repository 104e, identification component 201 can use one or more of annotation subcomponent 201a, derivation subcomponent 201b, replication subcomponent 201c, or user input subcomponent 201d to identify sensitive information items. As explained throughout, sensitive information items can include sensitive data and / or sensitive code.

[0100] As shown, method 600 may also include an action 602 of storing alternative information while ensuring that the entity takes the same execution path during replay. In some embodiments, action 602 includes storing first tracing data including alternative information instead of the original information in a first tracing data stream based on the original information including sensitive information while ensuring that the execution path taken by the entity based on the original information will also be taken during replay of the original execution of the entity using the first tracing data stream. For example, once identification component 201 identifies sensitive data, data modification component 202 may replace the data in tracing data repository 104e (such as in Figure 4A and 4B 406 ), and may also store sensitive data in a protected form (such as in trace data stream 407 ) in trace data repository 104 e .

[0101] Ensuring that the execution path taken by the entity based on the original information will also be taken during the replay of the original execution of the entity using the trace can be achieved by one or both of the data modification component 202 or the code modification component 203. For example, the data modification component 202 can select alternative data that will result in the same condition evaluation result as the original data. For example, if the condition is based on string length, this can be achieved by replacing the string with a string of equal length. On the other hand, the code modification component 203 can replace one or more original instructions with alternative instructions that bypass or change the result of the condition (e.g., instructions at point 512 in the trace data stream 509, or instructions at point 522 in the trace data stream 515), the code modification component 203 can annotate one or more instructions to cover the result during replay, and / or the code modification component 203 can insert one or more key frames that simulate the result during replay.

[0102] As shown, method 600 may also include action 603: enabling alternative instructions to be executed during replay. In some embodiments, action 602 includes, based on the original information including sensitive information, storing second trace data in a second trace data stream, the second trace data stream enabling one or more alternative executable instructions to be executed instead of one or more original executable instructions of the entity during replay of the original execution of the entity using the second trace data stream. For example, in combination with Figure 5B and 5C As explained in the trace data flows 509 and 515 of FIG. 2 , the code modification component 203 can store trace data (e.g., at points 512 and 522) that causes code executed by the original entity to be bypassed during replay. This can include, for example, replacing a segment of instructions with one or more instructions that bypass the block, storing one or more instructions that replicate the side effects of executing the segment, storing at least one memory snapshot associated with the segment, and / or storing at least one key frame associated with the segment.

[0103] Depending on the specific sensitive information identified in action 601, method 600 may include only one of actions 602 and 603, or may include both actions 602 and 603. As shown, if actions 602 and 603 are performed simultaneously, although they may also be performed serially, they may also be performed in parallel. In addition, as shown by arrow 604, actions 602 and 603 may be performed in collaboration with each other. In addition, any combination of actions 602 and 603 may be applied repeatedly, and each repetition may be in any order, in parallel, or in collaboration with each other. Similarly, although actions 602 and 603 refer to a first tracing data stream and a second tracing data stream, it should be understood that these may be the same tracing data stream.

[0104] It is noteworthy that the method 600 may be performed during the activity of any of the tracer 104a, the indexer 104b, and / or the debugger 104c. Thus, the method 600 may be performed during one or both of: (i) the original execution of the entity, or (ii) post-processing of the trace (performed by the tracer 104b or the debugger 104c) after the original execution of the entity. Additionally, the method 600 may be performed whenever a potentially sensitive raw information item is encountered during any of these stages. Thus, the method 600 may be repeated multiple times during trace recording, trace indexing, and / or trace debugging.

[0105] As described above, action 601 may include identifying component 201 using derivation subcomponent 201b and / or replication subcomponent 201c. If derivation subcomponent 201b is used, action 601 may include identifying derived data resulting from execution of one or more original executable instructions as also including sensitive information. If replication subcomponent 201c is used, action 601 may include identifying that the copy of the original information in the trace includes sensitive information. In this case, the copy of the original information may exist at an execution time after the first existence of the original information in the trace (e.g., as in conjunction with Figure 3B ), or exists at an execution time prior to the first existence of the original information in the trace (e.g., in conjunction with Figure 3B The copy of the original information may be related to the original information by code continuity, or may be independent in tracking (e.g., separate user input). The copy of the original information may be used to identify the original information as sensitive information, or the original information may be used to identify the copy of the original information as sensitive information.

[0106] Thus, embodiments herein identify sensitive information associated with a time travel trace (during trace recording and / or at some later time), and remove and / or mask the sensitive information in the trace. As described above, embodiments may include storing alternative data in the trace (rather than the original data identified as sensitive), replacing original instructions in the trace with alternative instructions that avoid executing sensitive code or allow for correct execution due to data replacement, overwriting the execution behavior of one or more instructions, and the like. Thus, embodiments enable the generation and consumption of time travel traces even in a production environment while keeping sensitive information from being disclosed.

[0107] Although the subject matter has been described in language specific to structural features and / or methodological acts, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the features or acts, or the order of the acts, described above. Instead, the described features and acts are disclosed as example forms of implementing the claims.

[0108] Without departing from the spirit or essential features of the present invention, the present invention may be implemented in other specific forms. The described embodiments should be considered in all respects only as illustrative and not restrictive. Therefore, the scope of the present invention is indicated by the appended claims rather than the preceding description. All changes falling within the equivalent meaning and scope of the claims should be included within their scope.

Claims

1. A method implemented at a computer system, the computer system comprising one or more processors, for protecting sensitive information associated with original execution of a tracing entity, the method comprising: Recording a replayable trace of execution of an entity, comprising recording trace data, the trace data representing execution of a plurality of executable instructions of the entity; identifying that original information includes sensitive information, the original information being accessed based on execution of one or more first executable instructions by the entity; derived information identifying the original information, the identification being based on execution of one or more second executable instructions identifying the entity that operate on the original information to create the derived information; Based on the derived information derived from the original information, determining that the derived information also includes sensitive information; as well as Based on the original information including the sensitive information, perform one or more of the following: In the tracing, storing first tracing data including alternative information instead of the derived information in a first tracing data stream while ensuring that an execution path taken by the entity based on the derived information will also be taken during replay of the entity using the first tracing data stream; or In the tracing, second tracing data is stored in a second tracing data stream, the second tracing data stream causing one or more alternative executable instructions to be executed instead of the one or more second executable instructions of the entity during the replay of the entity using the second tracing data stream. The method according to claim 1 , wherein the method is performed during execution of the entity.

3. The method of claim 1, wherein the method is performed during post-processing of the trace after execution of the entity.

4. The method according to claim 1, further comprising: identifying that the copy of the original information in the trace includes sensitive information, the copy of the original information existing at an execution time prior to a first existence of the original information in the trace, and Wherein identifying that the original information includes sensitive information is based on identifying that the copy of the original information in the trace includes sensitive information.

5. The method according to claim 1, further comprising: identifying that the copy of the original information in the trace includes sensitive information, the copy of the original information existing at an execution time subsequent to a first occurrence of the original information in the trace, and Wherein identifying that the original information includes sensitive information is based on identifying that the copy of the original information in the trace includes sensitive information.

6. The method according to claim 1, further comprising: identifying that the copy of the original information in the trace includes sensitive information, and Wherein the copy of the original information and the original information are not related by code continuity.

7. The method of claim 1, wherein identifying that the original information includes sensitive information is based on determining that the original information is a type selected from a list consisting of: a data structure, a variable, a class, a field, a function, a source file, a component, a module, or an executable instruction.

8. The method of claim 1, wherein the original information is identified as sensitive until a condition related to a type has been satisfied, the type being associated with the original information.

9. The method of claim 1 , wherein the method stores the first trace data including alternative information instead of the derived information in the first trace data stream while ensuring that an execution path taken by the entity based on the derived information will also be taken during a replay of the entity using the first trace data stream, and wherein ensuring that the execution path taken by the entity based on the derived information will also be taken during a replay of the original execution of the entity using the trace comprises one or more of: Records the side effects of one or more instructions, record one or more alternative instructions, or Ensure that the alternative information will produce the same condition evaluation result as the derived information.

10. The method of claim 1, wherein the method stores the second trace data in the trace causing one or more alternative executable instructions to be executed during the replay of the original execution of the entity using the trace, and wherein storing the second trace data in the trace causing one or more alternative executable instructions to be executed during the replay of the original execution of the entity using the trace comprises one or more of: replacing the instruction segment with one or more instructions that bypass the segment, replacing the instruction segment with one or more instructions that replicate the side effects of having executed the instruction segment, or At least one memory snapshot is stored in association with the instruction segment.

11. The method of claim 1, wherein the method comprises storing both the first tracing data and the second tracing data, and wherein the first tracing data stream and the second tracing data stream are the same tracing data stream.

12. A computer system comprising: one or more processors; as well as One or more computer-readable media having computer-executable instructions stored thereon, which when executed by the one or more processors cause the computer system to perform at least the following: processing a replayable trace of execution of an entity, comprising processing trace data, the trace data representing execution of a plurality of executable instructions of the entity; identifying, based on processing the replayable trace, original information including sensitive information, the original information being accessed based on execution of one or more first executable instructions of an entity; derived information identifying the original information, the identification being based on execution of one or more second executable instructions identifying the entity that operate on the original information to create the derived information; Based on the derived information derived from the original information, determining that the derived information also includes sensitive information; as well as Based on the original information including the sensitive information, perform one or more of the following: In the tracing, storing first tracing data including alternative information instead of the derived information in a first tracing data stream while ensuring that an execution path taken by the entity based on the derived information will also be taken during replay of the execution of the entity using the first tracing data stream; or In the tracing, storing second tracing data in a second tracing data stream, The second trace data stream causes one or more alternative executable instructions to be executed instead of the one or more second executable instructions of the entity during the replay of the execution of the entity using the second trace data stream.

13. A computer system according to claim 12, wherein the computer executable instructions further cause the computer system to identify that: the copy of the original information in the trace potentially includes sensitive information, and the copy of the original information exists in the trace at an execution time before the original information first exists in the trace, wherein the identification that the copy of the original information includes sensitive information is based on the identification that the original information includes sensitive information.

14. A computer system according to claim 12, wherein the computer executable instructions further cause the computer system to identify that: the copy of the original information in the trace potentially includes sensitive information, and the copy of the original information exists in the trace at an execution time after the original information first exists in the trace, wherein the identification that the copy of the original information includes sensitive information is based on the identification that the original information includes sensitive information.

15. The computer system of claim 12, wherein ensuring that an execution path taken by the entity based on the original information will also be taken during replay of the execution of the entity using the trace comprises one or more of: Records the side effects of one or more instructions, record one or more alternative instructions, or Ensure that the alternative information will produce the same condition evaluation results as the original data.

16. According to claim 12, wherein storing second trace data into the trace that causes one or more alternative executable instructions to be executed during the replay of the execution of the entity using the trace comprises one or more of: replacing the instruction segment with one or more instructions that bypass the segment, replacing the instruction segment with one or more instructions that replicate the side effects of having executed the instruction segment, or At least one memory snapshot is stored in association with the instruction segment.

17. A computer program product comprising one or more physical hardware storage devices having stored thereon computer executable instructions which, when executed at a processor, cause a computer system to perform at least the following: replaying a replayable trace of execution of an entity, including replaying trace data, the trace data representing execution of a plurality of executable instructions of the entity; identifying, based on replaying the replayable trace, that original information includes sensitive information, the original information being accessed based on execution of one or more first executable instructions of the entity; derived information identifying the original information, the identification being based on execution of one or more second executable instructions identifying the entity that operate on the original information to create the derived information; Based on the derived information derived from the original information, determining that the derived information also includes sensitive information; as well as Based on the original information including the sensitive information, perform one or more of the following: in the tracing, storing first tracing data including alternative information instead of the derived information in a first tracing data stream while ensuring that an execution path taken by the entity based on the derived information will also be taken during a subsequent replay of the execution of the entity using the first tracing data stream; or In the tracing, second tracing data is stored in a second tracing data stream, the second tracing data stream causing one or more alternative executable instructions to be executed instead of the one or more second executable instructions of the entity during a subsequent replay of the execution of the entity using the second tracing data stream.

Images