EP4356247A1 - Pile fantôme circulaire en mode d'audit - Google Patents

Pile fantôme circulaire en mode d'audit

Info

Publication number
EP4356247A1
EP4356247A1 EP22727629.2A EP22727629A EP4356247A1 EP 4356247 A1 EP4356247 A1 EP 4356247A1 EP 22727629 A EP22727629 A EP 22727629A EP 4356247 A1 EP4356247 A1 EP 4356247A1
Authority
EP
European Patent Office
Prior art keywords
shadow stack
stack
thread
shadow
computer system
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP22727629.2A
Other languages
German (de)
English (en)
Inventor
Jin Lin
Mehmet Iyigun
Jason Lin
Matthew John WOOLMAN
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Technology Licensing LLC
Original Assignee
Microsoft Technology Licensing LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US17/352,283 external-priority patent/US11861364B2/en
Application filed by Microsoft Technology Licensing LLC filed Critical Microsoft Technology Licensing LLC
Publication of EP4356247A1 publication Critical patent/EP4356247A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/485—Task life-cycle, e.g. stopping, restarting, resuming execution
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/073—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a memory management context, e.g. virtual memory or cache management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766—Error or fault reporting or storing
    • G06F11/0775—Content or structure details of the error report, e.g. specific table structure, specific error fields
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0766—Error or fault reporting or storing
    • G06F11/0778—Dumping, i.e. gathering error/state information after a fault for later diagnosis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0793—Remedial or corrective actions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/554—Detecting local intrusion or implementing counter-measures involving event detection and direct action
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3037—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a memory, e.g. virtual memory, cache
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3604—Software analysis for verifying properties of programs
    • G06F11/3612—Software analysis for verifying properties of programs by runtime analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/81—Threshold
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2101—Auditing as a secondary aspect

Definitions

  • an operating system allocates a portion of system memory for each thread to a call stack (sometimes referred to as a machine stack or an execution stack).
  • This call stack is used to facilitate procedure calls (e.g., functions, routines, etc.) within application code.
  • procedure calls e.g., functions, routines, etc.
  • each time a procedure is called during execution of a thread a new stack frame is added or "pushed" to the call stack for that thread.
  • This stack frame is generally created by a "prologue" to the procedure which can save state information needed to return to the calling context (e.g., a return address of the next instruction to be executed after the procedure exits, saved register values, etc.), allocate memory for any parameters passed to the procedure, allocate memory for local variables to the procedure, etc.
  • the particular data that is included in a stack frame, and the layout of that data, varies depending on processor architecture, operating system, etc.
  • a procedure exits its stack frame is removed or "popped" from the call stack for the thread.
  • This stack frame is generally removed by an "epilogue" to the procedure, which can restore saved information needed by the calling context (e.g., by placing a saved return address in a program counter or instruction counter, restore saved register values, etc.) and deallocate any call stack memory that was occupied by the stack frame.
  • a shadow stack is a mechanism for protecting a procedure's stored return address from malicious or unintentional modification, such as when a call stack "buffer overflow" causes the procedure to return to an address other than its proper return address when it completes (e.g., within malicious code, rather than the calling context).
  • a malicious actor may be able to accomplish a stack buffer overflow attack by taking advantage of flaws in a procedure's bounds checking to write beyond the amount of memory allocated to parameters and/or local variables in the procedure's stack frame, and into stack memory in the procedure's stack frame that is used to store the procedure's return address.
  • a shadow stack for a thread is a second, separate stack that "shadows" a thread's normal call stack.
  • shadow stack enforcement is enabled for an application's thread
  • execution of each of that application's procedure prologues causes a return address to be stored in both the thread's call stack and the thread's shadow stack.
  • Execution of each of that application's procedure epilogues causes a return address to be loaded from both the thread's call stack and the thread's shadow stack, and then compared. If the two records of the return address differ between the call stack and the shadow stack, then a shadow stack violation is detected, and the thread (or the process to which the thread belongs) is terminated.
  • Shadow stack enforcement features are enabled within an ecosystem, executing code is required utilize its call stack in an expected manner; otherwise, that code may cause a fatal system error, such as a “blue screen,” kernel panic, etc.
  • a fatal system error such as a “blue screen,” kernel panic, etc.
  • an audit mode may be enabled to get telemetry on what code breaks when shadow stack enforcement is enabled.
  • the CPU issues an exception (e.g., a control protection exception).
  • the mismatched entry in the shadow stack is replaced with the entry in the call stack, and a reporting telemetry may be generated (including, for example, an application binary name, back-trace information, etc.).
  • This telemetry can then be utilized by a developer to improve shadow stack compatibility, to add the application binary to shadow stack block-list, etc. As such, the incompatibilities with shadow stacks can be caught in the audit mode.
  • shadow stack incompliant software programs such as (but not limited to) certain games
  • some incompliant software programs are running in the audit mode, they are not aware of shadow stacks.
  • many addresses are kept on being pushed onto both the call stack and the shadow stack. Because such a phenomenon does not trigger the CPU to issue a traditional control protection exception, the shadow stack may overflow its allocated memory buffer and cause a fatal system error.
  • At least some embodiments described herein solve the above problem by enabling at least a portion of a shadow stack to be a circular stack in the audit mode, such that when usage of the shadow stack has reached a defined usage threshold, contents in at least a portion of the shadow stack are overwritten. Accordingly, in the audit mode, the computer system is able to get data on certain application binaries that currently are not compliant with the shadow stack, while simultaneously preventing the shadow stack from overflowing and causing a fatal system error.
  • Some embodiments are directed to methods, systems, and computer program products that enable at least a portion of a shadow stack to be a circular stack in an audit mode. Execution of a thread is initiated at a processor. This includes initiating execution of executable code of an application binary as part of the thread.
  • the application binary is enabled for shadow stack functionality in the audit mode. Based at least on execution of the thread at the processor in the audit mode, at least a portion of a shadow stack is made a circular stack. Making at least a portion of the shadow stack a circular stack includes determining whether usage of the shadow stack has reached a defined usage threshold. In response to determining that usage of the shadow stack has reached the defined usage threshold, one or more entries of return addresses in the shadow stack are overwritten to prevent the shadow stack from overflowing a memory region allocated to the shadow stack.
  • a software program may manually self- manage its call stack (including return addresses) to allow deeper recursion, causing the shadow stack to run out of a memory region allocated to the shadow stack.
  • the software program may repeatedly use “call”-like instructions (e.g., function calls) which also use shadow stack, without intervening “ret”-like instructions. Since the “ret” like instructions are configured to pop and validate the entries in the shadow stack, such “call”-like instructions without “ret”-like instructions would cause the shadow stack to keep on growing. When such “call”-like instructions or function calls are excessive, their pushing values onto the shadow stack can cause exhaustion of the shadow stack (also referred to as “shadow stack overflow”).
  • the embodiments described herein prevent the fatal CPU exception, even though it may mean corrupting at least a portion of the shadow stack (by making it circular).
  • the software program uses a branch instruction to return to. In such a case, the corresponding return address on the shadow stack would not be popped, and shadow stack overflow may also eventually occur.
  • one or more telemetries associated with the thread are logged.
  • the one or more telemetries include (but are not limited to) at least one of (1) an identifier of a process to which the thread belongs, (2) an identifier of the thread, and/or or (3) an identifier of the application binary associated with the thread.
  • the application binary is a device driver. Examples of application binary identifiers include (but are not limited to) a file name, a hash of a particular portion of the binary, an embedded version metadata of the application binary, and/or a combination thereof.
  • the shadow stack functionality can also be enabled in an enforcement mode.
  • the computer system refrains from enabling any portion of the shadow stack to be a circular stack.
  • enabling the shadow stack to be a circular stack further includes determining that the audit mode is enabled prior to making the shadow stack a circular stack.
  • the shadow stack comprises a maximum number of spaces for entries of return addresses based on a size of memory region allocated to the shadow stack, and one or more entries of return addresses are entered in one or more sequential spaces among the maximum number of spaces until usage of the shadow stack has reached the defined usage threshold.
  • Figure 1A illustrates an example computer system that facilitates enforcing shadow stack violations at module granularity
  • Figure IB illustrates example operating system components that facilitate enforcing shadow stack violations at module granularity
  • Figures 2A-2C illustrate an example operation of enforcement of shadow stack violations at module granularity
  • Figure 2D illustrates an example shadow stack, a portion of which is enabled to be a circular stack in an audit mode
  • Figure 3 illustrates a flow chart of an example method for enforcing a shadow stack violation at module granularity
  • Figure 4 illustrates a flowchart of an example method for enabling at least a portion of a shadow stack to be a circular stack in an audit mode
  • Figure 5 illustrates a flowchart of an example method for processing a shadow stack violation in the audit mode.
  • Figure 1A illustrates an example computer system 101 that facilitates enforcing shadow stack violations at module granularity.
  • Computer system 101 comprises or utilizes a special-purpose or general-purpose computer hardware, such as, for example, one or more processors 102, system memory 103, and durable storage 104, which are communicatively coupled using one or more communications buses 105.
  • 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 are accessible by a general- purpose or special-purpose computer system.
  • Computer-readable media that store computer- executable instructions and/or data structures are computer storage media.
  • Computer-readable media that carry computer-executable instructions and/or data structures are transmission media.
  • embodiments of the invention can comprise at least two distinctly different kinds of computer-readable media: computer storage media and transmission media.
  • Computer storage media are physical storage media (e.g., system memory 103 and/or durable storage 104) that store computer-executable instructions and/or data structures.
  • Physical storage media include computer hardware, such as RAM, ROM, EEPROM, solid-state drives (“SSDs”), flash memory, phase-change memory (“PCM”), optical disk storage, magnetic disk storage or other magnetic storage devices, or any other hardware storage device(s) which can be used to store program code in the form of computer-executable instructions or data structures, which can be accessed and executed by a general-purpose or special-purpose computer system to implement the disclosed functionality of the invention.
  • Transmission media can include a network and/or data links that can be used to carry program code in the form of computer-executable instructions or data structures, and which can be accessed by a general-purpose or special-purpose computer system.
  • a "network" is defined as one or more data links that enable the transport of electronic data between computer systems and/or modules and/or other electronic devices.
  • program code in the form of computer-executable instructions or data structures can be transferred automatically from transmission media to computer storage media (or vice versa).
  • computer-executable instructions or data structures received over a network, or data link can be buffered in RAM within a network interface module, and then eventually transferred to computer system RAM (e.g., system memory 103) and/or to less volatile computer storage media (e.g., durable storage 104) at the computer system.
  • computer system RAM e.g., system memory 103
  • less volatile computer storage media e.g., durable storage 10
  • Computer-executable instructions comprise, for example, instructions and data which, when executed at one or more processors, cause a general-purpose computer system, special-purpose computer system, or special-purpose processing device to perform a certain function or group of functions.
  • Computer-executable instructions may be, for example, machine code instructions (e.g., binaries), intermediate format instructions such as assembly language, or even source code.
  • the invention may be practiced in network computing environments with many types of computer system configurations, including personal computers, desktop computers, laptop computers, message processors, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, tablets, pagers, routers, switches, and the like.
  • the invention may also be practiced in distributed system environments where local and remote computer systems, which are linked (either by hardwired data links, wireless data links, or by a combination of hardwired and wireless data links) through a network, both perform tasks.
  • a computer system may include a plurality of constituent computer systems.
  • program modules may be located in both local and remote memory storage devices.
  • Cloud computing environments may be distributed, although this is not required. When distributed, cloud computing environments may be distributed internationally within an organization and/or have components possessed across multiple organizations.
  • “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.
  • a cloud computing model can be composed of various characteristics, such as on-demand self- service, broad network access, resource pooling, rapid elasticity, measured service, and so forth.
  • a cloud computing model may also come in 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”).
  • SaaS Software as a Service
  • PaaS Platform as a Service
  • IaaS Infrastructure as a Service
  • the cloud computing model may also be deployed using different deployment models such as private cloud, community cloud, public cloud, hybrid cloud, and so forth.
  • Some embodiments may comprise a system that includes one or more hosts that are each capable of running one or more virtual machines.
  • virtual machines emulate an operational computer system, supporting an operating system and perhaps one or more other applications as well.
  • each host includes a hypervisor that emulates virtual resources for the virtual machines using physical resources that are abstracted from view of the virtual machines.
  • the hypervisor also provides proper isolation between the virtual machines.
  • the hypervisor provides the illusion that the virtual machine is interfacing with a physical resource, even though the virtual machine only interfaces with the appearance (e.g., a virtual resource) of a physical resource.
  • Examples of physical resources include processing capacity, memory, disk space, network bandwidth, media drives, and so forth.
  • each processor 102 includes (among other things) one or more processing units 106 (e.g., processor cores), each of which loads and executes machine code instructions from system memory 103 (usually via one or more processor caches, not shown).
  • processor(s) 102 include hardware and/or microcode that provide shadow stack support 107 by the processor 102.
  • processor-based shadow stack support 107 can vary depending on design choices, but example functionality includes the ability to allocate and protect memory regions for shadow stack use (e.g., via page table mappings), the ability to "push” return addresses onto a shadow stack during execution of a procedure prologue (e.g., as part of execution of a "call” instruction), the ability to "pop" a return address from a shadow stack during execution of a procedure epilogue (e.g., as part of execution of a "return” instruction), the ability to compare one return address popped from a call stack with another return address popped from a shadow stack (e.g., as part of execution of a "return” instruction), and/or the ability to trigger an exception when there is a mismatch between the return address popped from a call stack and the return address popped from a shadow stack.
  • a procedure prologue e.g., as part of execution of a "call” instruction
  • shadow stack support 107 could instead be provided by an operating system and/or could be complied into procedure prologues and epilogues of an application binary.
  • the durable storage 104 stores computer-executable instructions and/or data structures representing executable software components; correspondingly, during execution of this software at the processor(s) 102, one or more portions of these computer-executable instructions and/or data structures are loaded into system memory 103.
  • the durable storage 104 is shown as storing computer-executable instructions and/or data structures corresponding to an operating system 108, one or more module(s) 109, and one or more application(s) 110.
  • the durable storage 104 also stores data, such as rules 111 and logs 112.
  • the system memory 103 is capable of storing a broad variety of data, but for purposes of illustrating the embodiments herein, the system memory 103 is shown as storing at least a portion of code of at least one running application (i.e., application code 110a) and at least a portion of code of a module called by that running application (i.e., module code 109a), as well as memory allocated to call stacks 113 and shadow stacks 114 (including, for example, a call stack and a shadow stack for the running application).
  • application code 110a i.e., application code 110a
  • module code 109a module code 109a
  • memory allocated to call stacks 113 and shadow stacks 114 including, for example, a call stack and a shadow stack for the running application.
  • Figure IB illustrates details of operating system 108, including example components that facilitate enforcing shadow stack violations at module granularity, according to some embodiments. It will be appreciated that the depicted components — including their identity, sub-components, and arrangement — are presented merely as an aid in describing various embodiments of operating system 108 described herein, and that these components are non-limiting to how software and/or hardware might implement various embodiments described herein, or of the particular functionality thereof.
  • Operating system 108 is illustrated as including kernel 115 that includes a task manager 116 which is responsible for launching and managing execution of processes (including one or more threads) at processor(s) 102 based on code of operating system 108 and application(s) 110.
  • the kernel 115 is also shown as including a shadow stack violation exception handler 117 (referred to hereinafter as exception handler 117) that processes exceptions when a shadow stack violation is detected during execution of a thread.
  • exception handler 117 a shadow stack violation exception handler 117
  • execution of the exception handler 117 is triggered by the shadow stack support 107 of processor(s) 102 (e.g., via a hardware interrupt) when a mismatch between a call stack return address and a shadow stack return address is detected.
  • the exception handler 117 could be triggered in other ways (e.g., via a software interrupt or exception), such as by code that executes as part of a procedure epilogue and that determines whether or not a call stack return address and a shadow stack return address match.
  • the exception handler 117 is capable of being utilized in a wide variety of environments, including those that include hardware support for shadow stacks (e.g., shadow stack support 107), and those that lack hardware shadow stack support (e.g., in which shadow stack functionality is implemented entirely in software, such as via specially-configured procedure prologues and epilogues).
  • exception handler 117 is focused on handling of exceptions when a module called by a primary application binary causes a shadow stack violation. It will be appreciated that the exception handler 117 could be invoked in other situations as well, such as when the primary application binary, itself, causes a shadow stack violation. Thus, in addition to the description herein of the handling of exceptions when a module called by a primary application binary causes a shadow stack violation, the exception handler 117 could also be configured to handle other situations, such as such as when the primary application binary, itself, causes a shadow stack violation. It will be appreciated, therefore, that the description of the exception handler 117 herein is not limited to those scenarios and functions specifically described herein.
  • the operating system 108 is also shown as including a logger 122, and as potentially including a rule generator 123.
  • the logger 122 generates log entries (e.g., which are stored in logs 112) in connection with operation of the exception handler 117.
  • the rule generator 123 if present, processes logs 112, and/or sends logs 112 to a remote system for processing.
  • computer system 101 generates and/or receives rules 111 that are usable by the exception handler 117.
  • the rule generator 123 is depicted, for ease in illustration, as being part of operating system 108, in some embodiments the rule generator 123 is part of a separate application 110 (e.g., a system security application, such as an antivirus application).
  • Figures 2A-2D which illustrate an example operation of enforcement of shadow stack violations at module granularity
  • Figure 3 which illustrates a flow chart of an example method 300 for enforcing a shadow stack violation at module granularity
  • Figure 4 which illustrates a flowchart of an example method 400 for making a shadow stack a circular stack in an audit mode.
  • the following discussion refers to a number of methods and method acts. Although the method acts may be discussed in a certain order, or may be illustrated in a flow chart as occurring in a particular order, no particular ordering is required unless specifically stated, or required because an act is specifically described as being dependent on another act being completed prior to the act being performed.
  • method 300 comprises an act 301 of initiating execution of a thread at a processor, based on an application binary having shadow stack enforcement enabled.
  • act 301 comprises initiating execution of a thread at the processor, including initiating execution of first executable code of an application binary that calls second executable code of an external module, the application binary having been enabled for shadow stack enforcement.
  • the task manager 116 initiates execution of one of applications 110 at processors(s) 102.
  • Initiating execution includes the task manager 116 causing application code 110a for the application 110 to be loaded into system memory 103, creating kernel data structures supporting execution of one or more threads at processing unit(s) 106, and creating (or initiating creation of) a call stack (i.e., within call stacks 113) for each of these one or more threads.
  • initiating execution also includes the task manager 116 creating (or initiating creation of) a shadow stack 114 (i.e., within shadow stacks 114) for each of these one or more threads.
  • Figure 2A illustrates an example 200a that depicts a representation of an application binary 201. While binary formats vary from operating system to operating system, in general, a binary includes a header describing properties and layout of the binary, and a body that comprises application code and data (e.g., in the form a text segment, a data segment, etc.). Thus, in Figure 2A, application binary 201 is shown as including a header 201a portion and a body 201b portion.
  • the task manager 116 reads the binary's header (e.g., header 201a) to obtain binary properties and layout, and loads at least a portion of the binary's body (e.g., body 201b) into system memory 103 (e.g., at least a portion of which could correspond to application code 110a).
  • header 201a is shown as including a checkbox containing a checkmark. In Figure 2A, this checkbox represents a flag or other indicator of whether or not the application binary 201 was compiled with support for, and requests enforcement of, shadow stacks.
  • header 201a is shown as including a binary indicator (i.e., checked or not), it is possible for header 201a to have a more comprehensive set of flags/indicators.
  • header 201a since header 201a includes checkmark, shadow stack enforcement is enabled for application binary 201 and/or the binary has opted-in to shadow stack enforcement.
  • task manager 116 creates shadow stack(s) for any thread(s) created for that binary.
  • Figure 2A shows that the task manager 116 has initiated execution of at least one thread for application binary 201, since it creates a call stack 203 and a shadow stack 204 corresponding to that initiated thread. It is noted that, in Figure 2B, call stack 203 and shadow stack 204 "grow" downward; that is, new information is pushed onto the bottom of these stacks, such that the "top" item on the stack is visually shown at the bottom of the call stack 203 and the shadow stack 204.
  • the task manager 116 identifies any module(s) that will be accessed by that binary during its execution (e.g., based on information in header 201a).
  • Figure 2A depicts a module 202 that is called by application binary 201. Similar to application binary 201, module 202 is shown as including a header 202a portion and a body 202b portion. At least a portion of the code of body 202b can be loaded to system memory (e.g., module code 109a) in connection with initiating execution of application binary 201, or at some later time.
  • header 202a is shown as having an empty checkbox.
  • header 201a lacks checkmark in the checkbox
  • shadow stack enforcement is not supported by module 202 and/or the module has not opted-in to shadow stack enforcement.
  • shadow stack enforcement is enabled for application binary 201, and since the code of module 202 executes within the context of call stack 203, computer system 101 also maintains shadow stack 204 during execution of the code of module 202.
  • act 301 comprises storing a record of whether or not the external module is enabled for shadow stack enforcement in connection with initiating execution of the thread.
  • Figure 2A shows a state of call stack 203 and shadow stack 204 after the initiated thread has executed for at least some period of time.
  • call stack 203 is shown as including four stack frames 203a-203d that were created in connection with execution of code of application binary 201 (e.g., due to internal procedure calls within that binary), as well as two stack frames 203e-203f that were subsequently created in connection with execution of code of module 202 (e.g., due to application binary 201 calling a procedure within module 202, and due to module 202 calling an internal procedure).
  • Each of these stack frames 203a-203f is illustrated as storing a corresponding return address (i.e., return address 205a for stack frame 203a, return address 205b for stack frame 203b, return address 205c for stack frame 203c, return address 205d for stack frame 203d, return address 205e for stack frame 203e, and return address 205f for stack frame 203f).
  • shadow stack 204 is shown as also storing these same return addresses 205, in the same order.
  • the current "top" stack frame 203f on call stack 203 now contains a new return address (i.e., return address 205g), which differs from the "top" return address on shadow stack 204 (i.e., return address 205f).
  • This new return address 205g could have been written to stack frame 203f due to a bug within module 202, due to intentional ROP behavior by module 202, or even due to a malicious attack targeting module 202.
  • stack frame 203f is now being "popped" from call stack 203 (e.g., due to execution of a procedure epilogue within module 202). As a result, the return address 205f is also popped from shadow stack 204.
  • method 300 also comprises an act of 302 of processing a shadow stack violation based on execution of the thread.
  • act 301 comprises, based at least on execution of the thread at the processor, processing an exception triggered by a mismatch between a first return address popped from a call stack corresponding to the thread and a second return address popped from a shadow stack corresponding to the thread.
  • the exception handler 117 is invoked to handle the exception.
  • the exception handler 117 is shown as including a variety of components that are usable for handling the exception. These components are described in connection with acts 303-306, which are shown in Figure 3 as sub acts of act 302.
  • Act 302 comprises an act of 303 of determining that the exception was triggered by execution of a module called by the application binary.
  • act 303 comprises determining that the exception resulted from execution of an instruction in the second executable code of the external module.
  • the exception handler 117 is shown as including a module identifier 118.
  • the module identifier 118 operates to determine an identity of a module that triggered the exception, if any.
  • the module identifier 118 operates by identifying a memory address corresponding to a "calling site" of an instruction that triggered the exception. For instance, if the instruction that triggered the instruction was a "return" instruction in a procedure epilogue, the memory address corresponding to the "calling site” of this instruction is the memory address at which the "return" instruction is stored in system memory. If this "return" instruction is part of a procedure epilogue of the executing application binary (e.g., application binary 201), then the instruction's memory address would be within a range of memory addresses occupied by application code 110a in system memory 103; in this case, the module identifier 118 would determine that the calling site address is part of the application binary.
  • this "return" instruction is part of a procedure epilogue of the executing application binary (e.g., application binary 201)
  • the instruction's memory address would be within a range of memory addresses occupied by application code 110a in system memory 103; in this case, the module identifier 118
  • this "return" instruction is part of a procedure epilogue of the module called by the application binary (e.g., module 202)
  • the instruction's memory address would be within a range of memory addresses occupied by module code 109a in system memory 103; in this case, the module identifier 118 would determine that the calling site address is part of the module.
  • the module identifier 118 operates by identifying a memory address corresponding to a memory address that was the "target address" of the instruction that triggered the exception. For instance, if the instruction that triggered the instruction was a "return" instruction in a procedure epilogue, the memory address corresponding to the "target address” of this instruction is the saved return address in the call stack frame for this procedure. If this saved return instruction is part of the executing application binary (e.g., application binary 201), then the instruction's memory address would be within a range of memory addresses occupied by application code 110a in system memory 103; in this case, the module identifier 118 would determine that the target site address is part of the application binary.
  • the executing application binary e.g., application binary 201
  • this saved return instruction is part of the module called by the application binary (e.g., module 202)
  • the instruction's memory address would be within a range of memory addresses occupied by module code 109a in system memory 103; in this case, the module identifier 118 would determine that the target site address is part of the module.
  • the module identifier 118 could identify the same entity for both of the calling site and the target address, or the module identifier 118 could identify different entities for each of the calling site and the target address.
  • a "return" instruction within module 202 could have as its target address a return address within module 202, in which case both of the calling site and the target address would correspond to the same entity.
  • a "return" instruction within module 202 could have as its target a return address within application binary 201, or some other entity, in which case the calling site and the target address would correspond to different entities.
  • determining that the exception resulted from execution of the instruction in the second executable code of the external module comprises determining one or more of, (i) that a calling site address of the instruction corresponds to the second executable code of the external module, or (ii) that a target address of the instruction corresponds to the second executable code of the external module.
  • the module identifier 118 identifies module 202 as corresponding to a calling site address (i.e., since it would be a procedure epilogue of module 202 that removes the procedure epilogue). Depending on which code return address 205g corresponds to (if any), in some embodiments the module identifier 118 identifies a target site address as corresponding to module 202, to application binary 201, to some other entity, or to no entity at all.
  • act 302 also comprises an act of 304 of determining whether the module has shadow stack enforcement enabled.
  • act 304 comprises determining whether or not the external module is enabled for shadow stack enforcement.
  • the exception handler 117 is shown as including a shadow stack enforcement identifier 119 (referred to hereinafter as enforcement identifier 119).
  • the enforcement identifier 119 determines whether or not the module identified in act 303 has shadow stack enforcement enabled. For example, referring to module 202, the enforcement identifier 119 would determine that module 202 does not have shadow stack enforcement enabled (i.e., because there is no check mark in the header 202a of module 202).
  • the enforcement identifier 119 determines one or more of (i) whether or not the module was compiled with support for shadow stacks, or (ii) whether or not the module opted-in to shadow stack enforcement.
  • an external module is enabled for shadow stack enforcement when (i) the external module is compiled for shadow stack compliance (i.e., if there is no option to opt-in or opt-out), or (ii) when the external module is compiled to opt-in to shadow stack enforcement (i.e., if there is an option to opt-in or opt-out).
  • an external module is not enabled for shadow stack enforcement when the external module is not compiled for shadow stack compliance (i.e., if there is no option to opt-in or opt-out), or (ii) when the external module is compiled to opt-out of shadow stack enforcement (i.e., if there is an option to opt-in or opt-out).
  • the enforcement identifier 119 consults the header of the module identified in act 303 to determine whether or not the module is enabled for shadow stack enforcement.
  • act 301 comprises storing a record of whether or not the external module is enabled for shadow stack enforcement in connection with initiating execution of the thread.
  • determining whether or not the external module is enabled shadow stack enforcement can comprise the enforcement identifier 119 consulting this record, rather than needing to actually look at the module header itself.
  • act 302 also comprises an act of 305 of identifying an enforcement rule for the module.
  • act 305 comprises identifying a rule based at least on an identity of the external module.
  • the exception handler 117 is shown as including a rule identifier 120.
  • the rule identifier 120 consults rules 111 to determine if there exists a rule that specifies whether the exception should be permitted for the external module (i.e., in which case the thread should be permitted to continue executing), or whether the exception for should be disallowed for the external module (i.e., in which case the thread should be terminated).
  • rules 111 are created based on analysis of prior logging (i.e., by logger 122) of shadow stack violations involving the external module at computer system 101 and/or at another computer system.
  • the rule identifier 120 identifies a rule further based an identity of the application binary (i.e., in addition to an identity of the external module).
  • the rules 111 are specific to a particular combination of application binary and external module.
  • Act 302 also comprises an act of 306 of enforcing a shadow stack violation policy for the module.
  • act 306 comprises, based on having determined whether the external module is enabled for shadow stack enforcement, performing one of terminating the thread (i.e., act 306a) or permitting the thread to continue executing (i.e., act 306b).
  • the exception handler 117 is shown as including a shadow stack policy enforcer 121 (referred to hereinafter as policy enforcer 121).
  • the policy enforcer 121 either terminates the thread or permits the thread to continue executing depending on whether or not shadow stack enforcement is enabled for the external module, whether or not a rule identified in act 305 specifies that shadow stack violations should be permitted, and/or whether or not an enforcement mode or an audit mode is enabled.
  • the second return address 205f in the shadow stack 204 is replaced with the first return address 205g in the call stack 203, such that the shadow stack violation policy is not enforced in the audit mode. Even though the shadow stack violation policy is not enforced in the audit mode, the audit mode is still useful for logging the shadow stack violation, which will be further described below.
  • act 306 can invoke act 306a to terminate the thread based at least on (i) shadow stack enforcement being enabled for the module, or (ii) shadow stack enforcement not being enabled for the module but a rule (i.e., accessed in act 305) specifies that the shadow stack violation should not be permitted. For example, if shadow stack enforcement is enabled for the module, then the module has requested that shadow stack violations by the module be enforced, so the policy enforcer 121 terminates the thread.
  • the policy enforcer 121 can default to permitting the thread to continue executing but override that default if a rule so specifies; thus, the module may not be compiled for shadow stack compliance (or may opt-out of shadow stack enforcement), but the policy enforcer 121 may nonetheless enforce shadow stack violations by the module.
  • act 306 can invoke act 306b to permit the thread to continue executing based at least on (i) shadow stack enforcement not being enabled for the module (and there are no rules for the module), or (ii) shadow stack enforcement not being enabled for the module and a rule specifies that the shadow stack violation should be permitted.
  • a rule i.e., rules 111
  • the computer system permits the thread to continue executing when the external module is not enabled for shadow stack enforcement and when the rule specifies that a shadow stack violation should be permitted.
  • Act 306a also shows that the thread could be terminated based at least on enforcement mode being enabled, while act 306b also shows that the thread could be permitted to continue executing based at least on audit mode being enabled.
  • the policy enforcer 121 operates in either an enforcement mode or an audit mode— either globally, or on a per-thread, per-application binary, and/or per-module basis.
  • enforcement mode the policy enforcer 121 terminates a thread, or permits it to execute, based on the policies already described in connection with acts 306a and 306b.
  • audit mode on the other hand, the policy enforcer 121 permits a thread to continue executing even in cases where it would normally be terminated under the polices described in connection with act 306a.
  • audit mode is useful for logging shadow stack violations by executing code (whether that be code within a primary application binary and/or within an external module called by that application binary) without actually terminating a thread when a violation occurs.
  • Method 300 also comprises an act of 307 of logging the exception.
  • the logger 122 can log one or more data items about the exception into logs 112.
  • act 307 is performed both when the policy enforcer 121 operates in enforcement mode and when it operates in audit mode, though it could be configured to refrain from logging in some situations.
  • the logger 122 logs one or more of a calling site address, a target address, an identifier of the external module, an identifier of a process to which the thread belongs, an identifier of the thread, an identifier of an application binary, whether enforcement mode or audit mode is enabled, whether a shadow stack violation was enforced or permitted, etc.
  • logger 122 when logging an identifier of an external module or an application binary, logs a filesystem path to the external module or the application binary. In some embodiments, the logger 122 preserves user privacy in these situations by removing or obfuscating personally identifiable information, such as a path portion corresponding to a user's home or profile directory. As mentioned, the rule generator 123 (if present) processes logs 112, and/or sends logs 112 to a remote system for processing, in order to generate and/or receive rules 111 that are usable by the exception handler 117.
  • the rule identifier 120 (if present) consults these rules 111 to determine if an exception should be permitted for an external module based on an identity of the external module, potentially in combination with an identity of the application binary.
  • the rule generator 123 (together with any remote system(s) involved) can use a vast variety of techniques to process logs 112 in order to generate rules 111, including the use of any appropriate machine learning techniques.
  • the rule generator 123 can generate rules based on identifying modules that frequently (or infrequently) cause shadow stack violations, identifying application/module combinations frequently (or infrequently) shadow stack violations, identifying situations in which an allowed shadow stack violation later caused a thread to crash, identifying situations in suspicious behavior was observed after an allowed shadow stack violation, etc.
  • the embodiments herein enforce shadow stack violations at module granularity, rather than at the granularity of an entire thread (or process).
  • the embodiments herein perform checks to determine if the shadow stack violation occurred during execution of an external module, and if so, whether or not shadow stack enforcement is enabled for that module. If the shadow stack violation occurred during execution of a module, and if shadow stack enforcement is enabled for that module, embodiments proceed to terminate the thread (or the process to which it belongs). However, if shadow stack enforcement is not enabled for that module, some embodiments choose to permit the thread to continue executing, rather than terminating it as would be typical.
  • the embodiments herein enforce shadow stack violations for the application's code, while permitting shadow stack violations by called module code.
  • shadow stack enforcement can be enabled for an application even if it calls external modules that intentionally tamper with return addresses or that are not yet shadow stack compatible.
  • the embodiments herein enable the use of shadow stack enforcement for an application— even in situations where it was previously impractical due to the module(s) upon which the application relies, or due to the environment in which the application executes.
  • shadow stack enforcement features when shadow stack enforcement features are enabled within an ecosystem, executing code is required to utilize its call stack in an expected manner; otherwise, that code may cause a fatal system error, such as a “blue screen,” kernel panic, etc.
  • a fatal system error such as a “blue screen,” kernel panic, etc.
  • an audit mode may be enabled to get telemetry on what code breaks when shadow stack enforcement is enabled.
  • the CPU issues an exception (e.g., a control protection exception).
  • a reporting telemetry may be generated (including, for example, one or more of an application binary identifier, back-trace information from the call stack, back-trace information from the shadow stack, etc.).
  • application binary identifiers include (but are not limited to) a file name, a hash of a particular portion of the binary, an embedded version metadata of the application binary, and/or a combination thereof. This telemetry can then be utilized by a developer to improve shadow stack compatibility, to add the application binary identifier to a shadow stack block-list, etc.
  • shadow stack incompliant software programs such as (but not limited to) certain games
  • some incompliant software programs continuously performs calls without corresponding returns, many addresses are pushed onto both the call stack and the shadow stack.
  • some incompliant software programs manually adjust their own call stack, such as to allow more repeated function calls. Because such a phenomenon does not trigger the CPU to issue a traditional control protection exception, the shadow stack may overflow its allocated memory buffer and cause a fatal system error.
  • a software program may self-manage its call stack (including return addresses) to avoid deep recursion, causing the call stack to run out of a memory region allocated to the call stack.
  • the software program may repeatedly use “cair-like instructions (e.g., function calls) which also use shadow stack without intervening “ret”-like instructions. Since the “ret” like instructions are configured to pop and validate the entries in the shadow stack, such “call”-like instructions without “ret”-like instructions would cause the shadow stack to keep on growing. When such “call”-like instructions or function calls are excessive, their returns can cause exhaustion of the shadow stack (also referred to as “shadow stack overflow”).
  • the software program uses a branch instruction to return from a function call. In such a case, the corresponding return address doesn’t pop from the shadow stack, and shadow stack overflow may also occur.
  • At least some embodiments described herein are directed to methods, systems, and computer program products that enable at least a portion of a shadow stack to be a circular stack in an audit mode, such that when the usage of the shadow stack has reached a defined usage threshold, contents in at least a portion of the shadow stack are overwritten.
  • a computer system in the audit mode, is able to get data on certain application binaries (such as, but not limited to, certain drivers) that currently do not work with the shadow stack, while preventing the shadow stack from overflowing a memory region allocated to the shadow stack.
  • Figure 4 illustrates a flowchart of an example method 400 for making a shadow stack a circular stack in an audit mode.
  • the method 400 includes initiating execution of a thread at a processor (act 410).
  • the act 410 includes initiating execution of executable code of an application binary as part of a thread (act 412) and enabling shadow stack functionality of the thread in an audit mode (act 414).
  • the task manager 116 of Figure IB initiates execution of one of applications 110 at processors(s) 102.
  • Initiating execution includes the task manager 116 causes application code 110a for the application 110 to be loaded into system memory 103, creating kernel data structures supporting execution of one or more threads at processing unit(s) 106, and creating (or initiating creation of) a call stack (i.e., within call stacks 113) for each of these one or more threads.
  • an audit mode is enabled by default.
  • shadow stack functionality is enabled. Since shadow stack functionality is enabled for the application's binary, initiating execution also includes the task manager 116 creating (or initiating creation of) a shadow stack 114 for each of these one or more threads.
  • Figure 2A illustrates an example 200a that depicts a representation of an application binary 201. While binary formats vary from operating system to operating system, in general, a binary includes a header describing properties and layout of the binary, and a body that comprises application code and data (e.g., in the form a text segment, a data segment, etc.). Thus, in Figure 2A, application binary 201 is shown as including a header 201a portion and a body 201b portion.
  • the task manager 116 reads the binary's header (e.g., header 201a) to obtain binary properties and layout, and loads at least a portion of the binary's body (e.g., body 201b) into system memory 103 (e.g., at least a portion of which could correspond to application code 110a).
  • Figure 2A shows the state after the task manager 116 has initiated execution of at least one thread for application binary 201, and after it created a call stack 203 and a shadow stack 204 corresponding to that initiated thread.
  • call stack 203 and shadow stack 204 "grow" downward; that is, new information is pushed onto the bottom of these stacks, such that the "top” item on the stack is visually shown at the bottom of the call stack 203 and the shadow stack 204.
  • Figure 2A shows a state of call stack 203 and shadow stack 204 after the initiated thread has executed for at least some period of time.
  • call stack 203 is shown as including four stack frames 203a-203d that were created in connection with execution of code of application binary 201 (e.g., due to internal procedure calls within that binary), as well as two stack frames 203e-203f that were subsequently created in connection with execution of code of module 202 (e.g., due to application binary 201 calling a procedure within module 202, and due to module 202 calling an internal procedure).
  • Each of these stack frames 203a-203f is illustrated as storing a corresponding return address (i.e., return address 205a for stack frame 203a, return address 205b for stack frame 203b, return address 205c for stack frame 203c, return address 205d for stack frame 203d, return address 205e for stack frame 203e, and return address 205f for stack frame 203f).
  • shadow stack 204 is shown as also storing these same return addresses 205, in the same order.
  • the current "top" stack frame 203f on call stack 203 now contains a new return address (i.e., return address 205g), which differs from the "top" return address on shadow stack 204 (i.e., return address 205f).
  • This new return address 205g could have been written to stack frame 203f due to a bug within module 202, due to intentional ROP behavior by module 202, or even due to a malicious attack targeting module 202.
  • shadow stack logic or functionality e.g., as part of a procedure epilogue and/or by shadow stack support 107 within processor(s) 102
  • a mismatch is detected between return address 205g and return address 205f.
  • a shadow stack violation is detected (e.g., by procedure epilogue code and/or by shadow stack support 107), triggering a hardware or software exception (such as a control protection exception).
  • processing a shadow stack violation in the audit mode includes replacing the return address in the shadow stack with the return address in the call stack (act 432).
  • the audit mode when the exception is triggered by a mismatch between a first return address 205g in a call stack 203 corresponding to a thread and a second address 205f in a shadow stack 204 corresponding to the same thread, the second return address 205f in the shadow stack 204 is replaced with the first return address 205g.
  • the violation is not enforced in the audit mode.
  • telemetries associated with the exception may still be logged in the audit mode.
  • processing the exception in the audit mode also includes logging at least one of (1) an identification of a process to which the thread belongs, (2) an identifier of the thread, or (3) an identifier of the application binary (act 436).
  • the application binary is a device driver. Examples of application binary identifiers include (but are not limited to) a file name, a hash of a particular portion of the binary, an embedded version metadata of the application binary, and/or a combination thereof.
  • this mechanism does not handle a shadow stack overflow.
  • certain software programs such as (but not limited to) certain games are running in the audit mode, they may continuously perform calls, pushing addresses onto both the call stack and the shadow stack.
  • the software program has instructions that manually check if the call stack is nearing its end to prevent the call stack from exceeding its allocated space.
  • the application may manually start using an earlier portion of its own stack. In some cases, the application may not properly unwind the stack using standard methods, and therefore the shadow stack will continue to grow, causing the shadow stack to overflow.
  • the software program may use a branch instruction to return to the caller of a function.
  • the corresponding return address on the shadow stack would not be popped, effectively “leaking” one shadow stack location each time, and shadow stack overflow may occur.
  • at least some embodiments described herein enable at least a portion of the shadow stack to be a circular stack in the audit mode (act 420), such that when usage of the shadow stack has reached a defined usage threshold, contents in at least a portion of the shadow stack are overwritten.
  • the method 400 further includes determining whether usage of the shadow stack has reached a defined usage threshold (act 422).
  • a flag (e.g., a Boolean value) is set to indicate whether at least one entry of the shadow stack has been overwritten.
  • the flag indicates that at least one entry of the shadow stack has been overwritten, it is understood that at least a portion of the shadow stack is corrupted; thus, the data contained in at least the portion of the shadow stack is not usable for enforcement purposes.
  • FIG 5 illustrates a flowchart of an example of method 500 for checking whether the shadow stack has reached the defined threshold during processing of a shadow stack violation, which corresponds to the act 430 of processing shadow stack violation in audit mode in Figure 4.
  • an exception is received (act 510).
  • the method 500 includes replacing the second return address in the shadow stack with the first return address (act 510).
  • the method 500 also includes enabling at least a portion of the shadow stack to be a circular stack (act 530) and determining whether usage of the shadow stack has reached a defined usage threshold (act 540). In response to determining that the usage of the shadow stack has reached the defined usage threshold, one or more entries of the shadow stack is overwritten to prevent the shadow stack from overflowing a memory region allocated to the shadow stack (act 550). In some embodiments, regardless of whether the shadow stack is overwritten, telemetry data associated with the thread is logged (act 560). Such telemetry data includes (but is not limited to) (1) an identification of a process to which the thread belongs, (2) an identifier of the thread, and/or (3) an identifier of the application binary.
  • the application binary is a device driver.
  • application binary identifiers include (but are not limited to) a file name, a hash of a particular portion of the binary, an embedded version metadata of the application binary, and/or a combination thereof.
  • the shadow stack comprises a maximum number of spaces for entries of return addresses based on a size of the memory region allocated to the shadow stack.
  • One or more entries of return addresses are entered in one or more spaces among the maximum number of sequential spaces until usage of the shadow stack has reached the defined usage threshold.
  • FIG. 2D illustrates an example of a shadow stack 220 (e.g., which corresponds to the shadow stack 204 of Figures 2A-2C).
  • a memory region is allocated to the shadow stack 220, which allows the shadow stack 220 to store a maximum number M of entries of return addresses, where M is a natural number.
  • M is a natural number.
  • a first space 221 is shown at the top of the shadow stack 220, and a last space (i.e., a Mth space 231) is shown at the bottom of the shadow stack 220.
  • the shadow stack 220 grows downward; that is, newly generated return addresses are pushed onto a lower side of the shadow stack 220.
  • a first generated return address 215a is stored at the first space 221
  • a second generated return address 215b is stored at the second space 222
  • the (N-l)th return address 215c is stored at the (N-l)th space 223, and so on and so forth.
  • determining that usage of the shadow stack has reached the defined usage threshold comprises determining that a number of entries of return addresses in the shadow stack has reached (e.g., equal to or greater than) a predetermined limit (also referred to a "first predetermined limit").
  • a predetermined limit also referred to a "first predetermined limit”
  • the first predetermined limit is P, where P is a natural number.
  • determining that usage of the shadow stack has reached the defined usage threshold comprises determining that a ratio between the number of entries of return addresses in the shadow stack and a maximum number M of spaces for entries in the shadow stack is greater than a predetermined limit (also referred to as a second predetermined limit).
  • a predetermined limit also referred to as a second predetermined limit.
  • an existing entry that is stored at a particular numbered space (e.g., N) is first to be overwritten, where N is a natural number, and N ⁇ P.
  • N is a natural number
  • N ⁇ P.
  • the (P+l)th return address 215h will be stored at an Nth space 224 where an existing entry 215d has been previously entered; the (P+2)th return address 215i will be stored at an (N+l)th space 225 where an existing entry 215e has been previously entered, and so on and so forth, until the Pth space is reached again.
  • the return address 215k overwrites the return address 215g in the Pth space, the usage of the shadow stack has reached the defined usage threshold again.
  • the circular stack 232 will circulate again, and one or more existing entries of return addresses in the circular stack 232 will be overwritten again by one or more new entries.
  • the return address 2151 (following the return address 215k) will be stored in the Nth space again, overwriting the currently stored return address 215h in the Nth space; the return address 215m (following the return address 2151) will be stored in the (N+l)th space again, overwriting the currently stored return address 215i in the Nth space.
  • This process may repeat, and the return addresses stored in the spaces between (and including) the Nth space and the Pth space may be overwritten as many times as necessary, such that the spaces between (and including) the Nth space and the Pth space forms a circular stack 232.
  • an operating system of computer system is configured to enable at least a portion of the shadow stack to be a circular stack.
  • a CPU is configured to allow privileged instructions to directly set a next shadow stack location of an active shadow stack, setting it to N.
  • a CPU may be configured with a shadow stack end address, and generate an exception when pushing a value to the shadow stack would write to the end address.
  • a CPU may be configured with a shadow stack end address and a shadow stack circular start address.
  • the CPU may set a flag (e.g., a Boolean value) to indicate whether at least one entry of the shadow stack has been overwritten, while still causing an exception on a shadow stack mismatch.
  • a flag e.g., a Boolean value
  • the starting point N of the circular stack 232 and/or the ending point P of the circular stack 232 are predetermined numbers. In some embodiments, the starting point N of the circular stack 232 and/or the ending point P of the circular stack 232 are based on a ratio N/M of between the starting point N and the maximum space M of the shadow stack 220 and/or a ratio P/M of between the ending point P and the maximum space M of the shadow stack 220. In some embodiments, the starting point N and/or the ending point P may be randomly selected within a range of numbers.
  • the starting point N of the circular stack 232 may be any point in the shadow stack.
  • a beginning portion (from the first to the (N-l)th entry) is preserved, i.e. not overwritten. It is advantageous to preserve a beginning portion of the shadow stack 220 because the beginning portion might provide more useful information about what has happened.
  • the third predetermined limit and/or the ending point P are determined based on a maximum number of entries of return addresses that can be simultaneously entered in the shadow stack when a particular event occurs. For example, when an intercept occurs, there may be up to 30 return addresses generated substantially simultaneously. Thus, to prevent shadow stack overflow from occurring, at least 30 spaces should be left after the ending point P of the circular stack 232, i.e., M-P > 30. In some embodiments, out of an abundance of caution, about 100 spaces are left after the ending point P of the circular point, i.e., M-P > 100; as such, it is almost certain that the shadow stack would never overflow. In some embodiments, statistical data may be gathered to determine the maximum number of return addresses that can be simultaneously entered in the shadow stack, and P is determined based on the gathered statistical data.
  • one or more telemetries associated with the thread is logged (act 426).
  • the one or more telemetries include (but are not limited to) (1) an identification of a process to which the thread belongs, (2) an identifier of the thread, and/or (3) an identifier of an application binary (act 426).
  • the application binary is a device driver. Examples of application binary identifiers include (but are not limited to) a file name, a hash of a particular portion of the binary, an embedded version metadata of the application binary, and/or a combination thereof.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Quality & Reliability (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Executing Machine-Instructions (AREA)

Abstract

L'exécution d'une fonctionnalité de pile fantôme pour un fil dans un mode d'audit comprend l'initiation de l'exécution d'un fil au niveau du processeur. L'exécution du fil comprend l'initiation de l'exécution d'un code exécutable d'un binaire d'application en tant que partie du fil et l'activation d'une fonctionnalité de pile fantôme pour le fil dans un mode d'audit. Sur la base au moins de l'exécution du fil dans le mode d'audit, au moins une partie de la pile fantôme est activée pour se convertir en pile circulaire. En réponse à la détermination du fait que l'utilisation de la pile fantôme a atteint le seuil défini, une ou plusieurs entrées actuellement utilisées de la pile fantôme sont écrasées, empêchant ainsi la pile fantôme de déborder.
EP22727629.2A 2021-06-19 2022-05-12 Pile fantôme circulaire en mode d'audit Pending EP4356247A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US17/352,283 US11861364B2 (en) 2020-03-24 2021-06-19 Circular shadow stack in audit mode
PCT/US2022/028891 WO2022265762A1 (fr) 2021-06-19 2022-05-12 Pile fantôme circulaire en mode d'audit

Publications (1)

Publication Number Publication Date
EP4356247A1 true EP4356247A1 (fr) 2024-04-24

Family

ID=81927417

Family Applications (1)

Application Number Title Priority Date Filing Date
EP22727629.2A Pending EP4356247A1 (fr) 2021-06-19 2022-05-12 Pile fantôme circulaire en mode d'audit

Country Status (3)

Country Link
EP (1) EP4356247A1 (fr)
CN (1) CN117501244A (fr)
WO (1) WO2022265762A1 (fr)

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7617383B2 (en) * 2006-02-16 2009-11-10 Vns Portfolio Llc Circular register arrays of a computer
US9501637B2 (en) * 2014-09-26 2016-11-22 Intel Corporation Hardware shadow stack support for legacy guests

Also Published As

Publication number Publication date
CN117501244A (zh) 2024-02-02
WO2022265762A1 (fr) 2022-12-22

Similar Documents

Publication Publication Date Title
US10489187B2 (en) Systems and methods for auditing a virtual machine
US10032024B2 (en) System and method for virtual partition monitoring
EP3355226B1 (fr) Politiques d'appel de système pour contenants
US9336018B2 (en) Mechanism for class data sharing using extension and application class-loaders
US11709931B2 (en) Shadow stack violation enforcement at module granularity
WO2018099292A1 (fr) Procédé et appareil de gestion de processus
CN110612512A (zh) 保护虚拟执行环境
US8910155B1 (en) Methods and systems for injecting endpoint management agents into virtual machines
WO2015113052A1 (fr) Détection et évitement de l'exécution d'exploits de logiciel
US10101915B2 (en) Methods and apparatus to manage inter-virtual disk relations in a modularized virtualization topology using virtual hard disks
US9928010B2 (en) Methods and apparatus to re-direct detected access requests in a modularized virtualization topology using virtual hard disks
JP2005327239A (ja) セキュリティ関連プログラミング・インターフェース
US11861364B2 (en) Circular shadow stack in audit mode
CN109784039B (zh) 移动终端安全运行空间的构建方法、电子设备、存储介质
US9804789B2 (en) Methods and apparatus to apply a modularized virtualization topology using virtual hard disks
EP4127922A1 (fr) Plage d'application de pile fantôme pour code dynamique
EP4356247A1 (fr) Pile fantôme circulaire en mode d'audit
CN108241801B (zh) 处理系统调用的方法和装置
CN115495343A (zh) 一种安全维护方法、装置、存储介质及电子设备
US10126983B2 (en) Methods and apparatus to enforce life cycle rules in a modularized virtualization topology using virtual hard disks
CN110806860B (zh) 安卓环境下的应用封装方法、装置及应用运行方法、装置
CN110795164B (zh) 应用封装方法、装置及应用运行方法、装置
US20220300315A1 (en) Supporting execution of a computer program by using a memory page of another computer program
US20220300314A1 (en) Hypervisor-assisted secured memory sharing among host and guest operating system
EP3286653A1 (fr) Protection de mémoire à grains fins pour empêcher des attaques de dépassement de mémoire

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20231117

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR