Search

CN-115552381-B - Recording memory value tracking for use with independent cache coherency protocol tracking

CN115552381BCN 115552381 BCN115552381 BCN 115552381BCN-115552381-B

Abstract

A computer system records a replayable execution trace based on recording a Cache Coherence Protocol (CCP) message into a first trace and a memory snapshot into a second trace. Based on determining that tracking of execution of the first execution context is to be enabled, the computer system begins logging one or more memory snapshot logs of a memory space of the first execution context into a second tracking, and enables a hardware tracking function of the processor. Enabling the trace function causes CCP message log generated by the processor in response to one or more memory accesses to a memory space of the first execution context to be recorded into the first trace. After enabling the hardware tracking feature of the processor, the computer system also logs or otherwise processes the writing of the second execution context to the memory space of the first execution context.

Inventors

  • J. Mora

Assignees

  • 微软技术许可有限责任公司

Dates

Publication Date
20260505
Application Date
20210430
Priority Date
20200505

Claims (15)

  1. 1. A computer system (101), comprising: a processor (102) comprising a plurality of processing units (106) and a cache (107); memory (103), and A computer readable medium (104) having stored thereon computer executable instructions executable by the processor to cause the computer system to record a replayable execution trace based on recording a cache coherence protocol, CCP, message to a first trace and based on recording one or more memory snapshots to a second trace, the CCP message being usable to obtain a memory value from the one or more memory snapshots, characterized by: The computer-executable instructions include instructions executable by the processor to cause the computer system to perform at least the following: determining (118) that tracking of execution of the first execution context by the plurality of processing units is to be enabled, and Based on determining that tracking of execution of the first execution context is to be enabled, at least the following is performed: initiating (118 b) a log record in the second trace of one or more memory snapshots of a memory space of the first execution context, and Enabling (118 c) a hardware trace feature of the processor that causes the processor to log one or more CCP messages into the first trace, the one or more CCP messages generated in response to memory accesses of the memory space of the first execution context by one or more of the plurality of processing units, and After enabling the hardware tracking feature of the processor, in conjunction with execution of a second execution context, at least one of: logging writes of the second execution context to the memory space of the first execution context into one or more of the first trace or the second trace; Logging the identity of a mapped file in the memory space of the second execution context to the first execution context into the second trace; writing a cache line in the cache that overlaps a memory location in a memory space of the first execution context based at least on the second execution context, evicting or marking the cache line from the cache as invalid, or A memory region within the memory space of the first execution context is written based at least on the second execution context, the memory region marked as requiring logging in connection with execution of the first execution context.
  2. 2. The computer system of claim 1, the computer-executable instructions further comprising instructions executable by the processor to cause the computer system to encrypt the second trace.
  3. 3. The computer system of claim 1, wherein enabling the hardware trace function of the processor further causes the processor to flush (116) from the cache at least one cache line overlapping a memory space of the first execution context.
  4. 4. The computer system of claim 1, wherein the first trace and the second trace are combinable to replay execution of the first execution context.
  5. 5. The computer system of claim 4, wherein memory values logged into the one or more memory snapshots in the second trace and consumed by at least one of the plurality of processing units are identified based on using the one or more CCP messages logged into the first trace, the first trace and the second trace being combinable to replay execution of the first execution context.
  6. 6. The computer system of claim 4, wherein memory values consumed by a first processing unit of the plurality of processing units that were previously consumed by a second processing unit of the plurality of processing units are identified based on using the one or more CCP messages logged into the first trace, the first trace and the second trace being combinable to replay execution of the first execution context.
  7. 7. The computer system of claim 1, wherein initiating logging of the one or more memory snapshots comprises initiating logging of a portion of the memory snapshots.
  8. 8. The computer system of claim 7, wherein the partial memory snapshot does not include at least one of (i) a paged out memory page within the memory space of the first execution context, or (ii) a memory page within the memory space of the first execution context that is not accessed by the first execution context.
  9. 9. The computer system of claim 1, wherein initiating logging of the one or more memory snapshots comprises initiating tracking of one or more memory regions within the memory space of the first execution context, the one or more memory regions being accessed by at least one of the plurality of processing units.
  10. 10. The computer system of claim 1, wherein the computer system logs writing of the second execution context to the storage area within the storage space of the first execution context.
  11. 11. The computer system of claim 10, wherein logging the write of the second execution context comprises logging a result of a Direct Memory Access (DMA) operation into the second trace.
  12. 12. The computer system of claim 1, wherein the computer system logs the identity of the mapped file in the memory space of the second execution context to the first execution context.
  13. 13. The computer system of claim 1, wherein the computer system evicts (118 a) the cache line that overlaps the memory location in a memory space of the first execution context and is written to by the second execution context.
  14. 14. The computer system of claim 1, wherein the computer system marks the memory region as needing to be journaled in connection with execution of the first execution context based at least on the second execution context having written to the memory region within the memory space of the first execution context.
  15. 15. The computer system of claim 14, wherein in connection with subsequent execution of the first execution context, the computer system logs at least a portion of the memory region into the second trace.

Description

Recording memory value tracking for use with independent cache coherency protocol tracking Technical Field The present disclosure relates to systems, methods, and devices for protecting sensitive information while recording a replay-able execution trace of a computing context. Background Tracking and correcting undesirable software behavior is a core activity in software development. Undesirable software behavior may include a number of things, such as execution crashes, run-time exceptions, slow execution performance, incorrect data results, data corruption, and the like. Undesired software behavior is triggered by a variety of factors, such as data input, user input, race conditions (e.g., when accessing shared resources), and the like. Because of the diversity of triggers, undesirable software behavior is often rare, appears to be random, and is extremely difficult to reproduce. Thus, identifying a given unwanted software behavior is often very time consuming and difficult for a developer. Once an undesirable software behavior is determined, determining its root cause(s) is often time consuming and difficult. Developers have used various methods to identify unwanted software behavior and then identify the location(s) in the code of the application that resulted in the unwanted software behavior. For example, developers often test different portions of the application's code for different inputs (e.g., unit tests). As another example, developers often consider code that executes an application in a debugger (e.g., set breakpoints/watchpoints, step through lines of code as the code executes, etc.). As another example, developers often observe code execution behavior (e.g., timing, coverage) in an analyzer. As another example, developers often insert diagnostic code (e.g., trace statements) in the code of an application. While conventional diagnostic tools (e.g., debuggers, analyzers, etc.) operate on "real-time" forward executing code, emerging diagnostic tools support "historical" debugging (also referred to as "time travel" or "reverse" debugging) in which execution of at least a portion of an execution context is recorded into one or more trace files (i.e., execution traces). Using some tracing techniques, execution tracing may contain "bit-accurate" historical execution tracing data, which allows recorded portions of the traced execution context to be virtually "replayed" (e.g., through emulation) up to the granularity of a single instruction (e.g., machine code instructions, intermediate language code instructions, etc.). Thus, using "bit-accurate" trace data, the diagnostic tool enables the developer to infer previous executions of the recorded subject matter context, rather than traditional debugging, which is limited to "real-time" forward execution. For example, using replayable execution traces, some history debuggers provide a user experience, support forward and backward breakpoints/watchpoints, enable code to step forward and backward, and so on. On the other hand, some history probes are able to derive code execution behavior (e.g., timing, coverage) from previously executed code. Some techniques of logging execution tracking are based at least in part on execution tracking by a microprocessor (processor) logging at least a portion of an in-flow (i.e., cache miss) into a processor cache during execution of an execution context of the processor. Cache-based recording techniques offer a number of opportunities to reduce recording overhead and/or reduce the amount of data recorded into execution traces, as compared to non-cache-based recording techniques such as software emulation. However, if the execution context reads sensitive memory values, such as Personal Identification Information (PII), encryption keys, etc., from memory, these sensitive memory values may become cache-in, so conventional cache-based recording techniques may log these sensitive values into the execution trace. Thus, cache-based recording techniques present potential security issues in tracking execution context of memory interactions with which sensitive data values are stored. Disclosure of Invention At least some embodiments described herein alleviate security issues associated with cache-based recording techniques by separating execution tracking into two independent and distinct component tracking. The component trace includes a first component trace recorded by the processor that records at least a portion of Cache Coherence Protocol (CCP) messages communicated between the plurality of processing units when the processing units perform memory accesses to the execution context. Notably, the first component tracks the lack of memory values associated with these memory accesses. The component tracking also includes a second component tracking recorded by the software operating environment, the tracking recording one or more snapshots of at least a portion of the system memory. In an embodiment, the first component trac