SYSTEM FOR PROTECTING AGAINST INVALID MEMORY REFERENCES, COMPUTER IMPLEMENTED METHOD, AND COMPUTER PROGRAM PRODUCT (PROTECTING AGAINST INVALID MEMORY REFERENCES)

Abstract

To provide a system, computer-implemented method and computer program product for protecting against invalid memory references.SOLUTION: In one example, a system can comprise a processor that executes computer-executable components stored in a non-transitory computer readable medium. The computer executable components comprise an entry component and a re-purpose component. The entry component can allocate an entry in a table to store bounds-information when an object is allocated to the memory. The re-purpose component can re-purpose unused bits of an object address to store an index to the table entry.SELECTED DRAWING: Figure 6

Description

[Technical field]

[0001] The present disclosure relates to computing devices, and more particularly, to techniques that facilitate hardware-based memory-error mitigation for heap-objects. [Background technology]

[0002] Conventionally, many techniques have been proposed for detecting or preventing errors specific to heap objects. Summary of the Invention [Problem to be solved by the invention]

[0003] The present invention provides a system, computer-implemented method, and computer program product for protecting against invalid memory references. [Means for solving the problem]

[0004] The following presents a general summary of the invention in order to provide a basic understanding of one or more embodiments of the invention. This summary is not intended to identify key or critical elements or to limit the scope of particular embodiments or the claims. This summary is intended solely to present concepts in a simplified form as a prelude to the more detailed description that is presented later. In one or more embodiments described herein, a system, apparatus, computer-implemented method, or computer program product, or combination thereof, is described that facilitates hardware-based memory error mitigation for heap objects.

[0005] According to one embodiment, a system is provided. The system includes a processor executing computer-executable components stored on a non-transitory computer-readable medium. The computer-executable components include an entry component and a repurposing component. The entry component can allocate an entry in a table for storing bounds information when an object is allocated in memory. The repurposing component can repurpose unused bits of an object address to store an index to an entry in the table.

[0006] According to another embodiment, a computer-implemented method is provided that can include allocating, by a processor, an entry in a table for storing bounds information when an object is allocated in memory, and can further include, by the processor, repurposing unused bits of the object address to store an index to the entry in the table.

[0007] According to yet another embodiment, a computer program product is provided. The computer program product may include a computer readable storage medium having program instructions embodied therein. The program instructions are executable by a processor to cause the processor to perform operations. The operations include allocating an entry in a table for storing bounds information when an object is allocated. The operations further include repurposing unused bits of the object address to store an index to the entry in the table. [Brief description of the drawings]

[0008] [Figure 1] FIG. 1 is a diagram illustrating an example grouping of bounds-checking techniques based on the location of their bounds-metadata, according to one or more embodiments described herein. [Diagram 2]FIG. 2 is a block diagram illustrating a system that can facilitate hardware-based memory error mitigation for heap objects in accordance with one or more embodiments described herein. [Diagram 3] FIG. 3 is a conceptual illustration outlining a technique for reclaiming unused bits of object pointers to ensure spatial and temporal safety of heap objects in accordance with one or more embodiments described herein. [Figure 4] FIG. 4 is a conceptual illustration of an overview of the life-cycle of a pointer during program execution, in accordance with one or more embodiments described herein. [Diagram 5] FIG. 5 is a diagram illustrating an example organizational layout of a bounds checking framework in accordance with one or more embodiments described herein. [Figure 6] FIG. 6 is a diagram illustrating an example BITable in accordance with one or more embodiments described herein. [Figure 7] FIG. 7 is a diagram illustrating the layout of a program's 64-bit Virtual-Address space in accordance with one or more embodiments described herein. [Figure 8] FIG. 8 is a diagram illustrating a hardware configuration for implementing hardware-based bounds checking in accordance with one or more embodiments described herein. [Figure 9] FIG. 9 is a diagram illustrating a slowdown scenario with hardware-based bounds checking in accordance with one or more embodiments described herein. [Figure 10] FIG. 10 is a graph illustrating functions for which out-of-bounds accesses are detected under a hardware-based bounds checking framework in accordance with one or more embodiments described herein. [Figure 11]FIG. 11 is a graph illustrating instructions in a SPEC-CPU2017 application that caused an out-of-bounds run, according to one or more embodiments described herein. [Figure 12] FIG. 12 is a graph illustrating the performance impact of software instrumentation for BI table management in accordance with one or more embodiments described herein. [Figure 13] FIG. 13 is a graph illustrating the performance impact of hardware-based bounds checking in accordance with one or more embodiments described herein. [Figure 14] FIG. 14 is a graph illustrating loads per 1000 instructions including BI Cache misses according to one or more embodiments described herein. [Figure 15] FIG. 15 is a graph illustrating the percentage of loads that contain BI cache misses, in accordance with one or more embodiments described herein. [Figure 16] FIG. 16 is a graph illustrating the average slowdown due to bounds checking for different BI cache sizes in accordance with one or more embodiments described herein. [Figure 17] FIG. 17 is a graph illustrating BI Cache miss-rates for different BI cache sizes according to one or more embodiments described herein. [Figure 18] FIG. 18 is a graph illustrating memory bandwidth overhead associated with bounds checking in accordance with one or more embodiments described herein. [Figure 19] FIG. 19 is a graph illustrating memory bandwidth overhead associated with a BI table in accordance with one or more embodiments described herein. [Figure 20A] FIG. 20A illustrates an example operational flow for initializing BI tables in memory according to one or more embodiments described herein. [Figure 20B] FIG. 20B is a diagram illustrating an operational flow for initializing BI tables in memory according to one or more embodiments described herein. [Figure 20C] FIG. 20C illustrates an example operational flow for initializing BI tables in memory according to one or more embodiments described herein. [Figure 20D] FIG. 20D illustrates an example operational flow for initializing BI tables in memory according to one or more embodiments described herein. [Figure 20E] FIG. 20E is a diagram illustrating an operational flow for initializing BI tables in memory according to one or more embodiments described herein. [Figure 20F] FIG. 20F illustrates an operational flow for initializing BI tables in memory according to one or more embodiments described herein. [Figure 20G] FIG. 20G illustrates an example operational flow for initializing BI tables in memory according to one or more embodiments described herein. [Figure 21A] FIG. 21A is a diagram illustrating an operational flow for processing a memory allocation function according to one or more embodiments described herein. [Figure 21B] FIG. 21B is a diagram illustrating an operational flow for processing a memory allocation function according to one or more embodiments described herein. [Figure 21C] FIG. 21C is a diagram illustrating an operational flow for processing a memory allocation function according to one or more embodiments described herein. [Figure 21D] FIG. 21D is a diagram illustrating an operational flow for processing a memory allocation function according to one or more embodiments described herein. [Figure 21E] FIG. 21E is a diagram illustrating an operational flow for processing a memory allocation function according to one or more embodiments described herein. [Figure 22A]FIG. 22A is a diagram illustrating an operational flow for processing a load instruction according to one or more embodiments described herein. [Figure 22B] FIG. 22B is a diagram illustrating an operational flow for processing a load instruction in accordance with one or more embodiments described herein. [Figure 22C] FIG. 22C is a diagram illustrating an operational flow for processing a load instruction in accordance with one or more embodiments described herein. [Figure 22D] FIG. 22D is a diagram illustrating an operational flow for processing a load instruction in accordance with one or more embodiments described herein. [Figure 22E] FIG. 22E is a diagram illustrating an operational flow for processing a load instruction in accordance with one or more embodiments described herein. [Figure 22F] FIG. 22F is a diagram illustrating an operational flow for processing a load instruction in accordance with one or more embodiments described herein. [Figure 22G] FIG. 22G is a diagram illustrating an operational flow for processing a load instruction in accordance with one or more embodiments described herein. [Fig. 22H] FIG. 22H is a diagram illustrating an operational flow for processing a load instruction in accordance with one or more embodiments described herein. [Figure 22I] FIG. 22I is a diagram illustrating an operational flow for processing a load instruction in accordance with one or more embodiments described herein. [Figure 22J] FIG. 22J is a diagram illustrating an operational flow for processing a load instruction in accordance with one or more embodiments described herein. [Figure 22K] FIG. 22K is a diagram illustrating an operational flow for processing a load instruction in accordance with one or more embodiments described herein. [Diagram 23] FIG. 23 is a diagram illustrating a pointer according to one or more embodiments described herein. [Figure 24]FIG. 24 is a diagram illustrating a pointer according to one or more embodiments described herein. [Diagram 25] FIG. 25 is a diagram illustrating an addition operation performed on the pointers of FIG. [Figure 26] FIG. 26 is a flowchart illustrating an example computer-implemented method that can facilitate hardware-based memory error mitigation for heap objects in accordance with one or more embodiments described herein. [Figure 27] FIG. 27 is a block diagram illustrating an operating environment capable of facilitating one or more embodiments described herein. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] The following detailed description is illustrative only and is not intended to limit the embodiments or their application and / or uses, nor is it intended to be bound by any express or implied information provided in the Background or Summary of the Invention above, or in the Detailed Description of the Invention.

[0010] Hereinafter, each embodiment will be described with reference to the accompanying drawings. In the drawings, like elements are designated by like reference numerals. In the following description, numerous specific details are set forth to provide a more thorough understanding of each embodiment. However, in various instances, each embodiment can be practiced without these specific details.

[0011] Applications written in memory-unsafe languages ​​such as C and C++ are prone to memory safety errors such as buffer overflows and use-after-free errors because they explicitly manage memory using user code. These errors have been exploited in numerous attacks, including well-known attacks such as the Morris worm and Heartbleed. Moreover, these errors are ranked as one of the most dangerous software bugs by MITRE, a non-profit organization in the United States. A recent survey conducted by a technology company revealed that these errors still account for approximately 70% of the Common Vulnerabilities and Exposures (CVEs) identified in the company's production software. In particular, errors specific to heap objects, including heap corruption, out-of-bounds accesses, and use-after-free errors, accounted for nearly 50% of CVEs in 2019.

[0012] To date, many techniques have been proposed to detect or prevent these errors, which can be broadly divided into blacklist and whitelist approaches. Blacklist approaches prevent access to (some) unsafe locations (e.g., by inserting tripwires around objects) and generally have fewer barriers to implementation, such as excessive performance overhead or the need to invasively modify program source code. However, blacklist approaches do not provide complete coverage, so some errors remain undetected and can be freely exploited. In contrast, whitelist approaches enforce safe program behavior based on authorizations (e.g., bounds-checking mechanisms that verify that all pointer dereferences are within object-bounds), allowing for more precise spatial and temporal memory-safety. However, whitelist approaches often come with significant slowdowns, which can range from 24% to 116%. Furthermore, whitelisting approaches often require disruptive changes to source code and binary layout, making them difficult to adopt. Ideally, a practical approach to enhance memory safety would leverage the strong security of whitelisting approaches without their performance and compatibility drawbacks.

[0013] As mentioned above, applications written in C / C++ are prone to memory errors where pointers are allowed to be manipulated without safety checks, resulting in pointers dereferencing invalid memory regions. Spatial errors (out-of-bounds access) can occur when a buffer pointer accesses memory beyond the buffer bounds due to pointer-arithmetic using unvalidated inputs. Similarly, temporal errors (e.g., using a freed memory) can result from reading or writing using a dangling pointer (a pointer that points to a freed object whose memory has been reused). Attacks have been carried out by exploiting memory leaks and memory corruption caused by these errors to violate data confidentiality, attempt privilege escalation, and destroy system integrity. Such attacks against product software can be prevented by strengthening memory safety and preventing memory errors. Various techniques can be implemented to strengthen memory safety and prevent memory errors.

[0014] These techniques include probabilistic techniques that can probabilistically detect memory accesses that cross object boundaries using either tripwires, randomization, or tagged memory. An example of a tripwire technique is Address Sanitizer (ASAN) from Google LLC (Mountain View, California). Tripwire techniques typically insert red-zones or tripwires around objects to detect common spatial bugs that cross object boundaries by a small amount. An example of a randomization technique is DieHard. Randomization techniques typically randomize the memory layout with the support of a memory-allocator to make bugs easier to detect. An example of a hardware-based memory tagging technique is Memory Tagging Extension (MTE) from Arm Limited (Cambridge, UK). Hardware-based memory tagging techniques typically assign random 4-bit tags ("colors") to object-pointer pairs to make it easier to probabilistically detect bugs based on mismatches in the "colors." Probabilistic methods are relatively easy to adopt because they minimize speed degradation and compatibility issues, but by design they may not provide complete coverage for error detection.

[0015] Such techniques also include bounds-checked techniques that can accurately enforce safe program behavior by tracking object bases and bounds and performing bounds checks on all object accesses. As shown in FIG. 1, bounds-checked techniques 100 can be grouped based on the location of their bounds metadata. For example, bounds-checked techniques 100 include adjacent bounds group 110. Adjacent bounds group 110 includes fat-pointer techniques such as CCured and Cyclone. In fat-pointer techniques, base and bounds metadata can be stored in separate words alongside the actual pointer value. Storing the base and bounds metadata in this manner can facilitate performing bounds checks to detect spatial errors when the actual pointer is dereferenced. Similarly, in some examples of fat-pointer techniques, pointers can be replaced with 256-bit "capabilities." Capabilities can include addresses, boundary information, permission bits, and other metadata, and can enforce fine-grain compartmentalization along with bounds checking. However, contiguous boundary groups 110 of the bounds-checked approach typically require source code changes and / or binary layout changes, thus impacting compatibility with library code.

[0016] Another example of a bounds-checked approach is the inline bounds group 120, which is a low-fat-pointer approach. Low-fat-pointer approaches allow object bounds to be encoded inline in the pointer without affecting the binary layout. As an example of a low-fat-pointer approach, a compact floating-point format can be used to store the base and bound addresses (the least significant bits) of an object in the most significant 18 bits of a 64-bit pointer. As another example of a low-fat-pointer approach, objects can be allocated in size-specific partitions of memory at size-aligned base addresses, with the base and bounds implicitly encoded in the pointer value. These low-fat-pointer example approaches allow pointer arithmetic to be tracked (either in hardware or via explicit instructions inserted by the compiler / instrumentation) to ensure that pointers do not cross inline-bounds. However, the inline bounds group 120 of bounds-checked approaches typically cannot ensure time safety because inserted checks that exploit bounds in dangling pointers can still be passed even after the memory that the pointer points to is reused.

[0017] Another example of a bounds-checked approach is the disjoint bounds group 130. The bounds-checked approach in the disjoint bounds group 130 can store the bounds metadata (per pointer or per object) in a disjoint table in a shadow memory, avoiding any changes to the binary layout. The bounds table is typically indexed using the pointer value, either as a linear table lookup or using a multi-level trie lookup. Such bounds-checked approaches can detect spatial errors (and in some designs, temporal errors as well) by performing bounds checks with table lookups (inserted by software or implicitly inserted by hardware) on pointer dereferences or every pointer arithmetic. Purely software-based approaches in the disjoint bounds group 130 can incur significant performance overhead (e.g., 50% to 112% on average) due to the need for additional instructions to propagate the bounds metadata during pointer arithmetic and for table lookups. Additionally, within isolation boundary group 130, hardware-based approaches may provide less overhead compared to software-based approaches by using microcode or dedicated hardware to communicate boundaries and perform checks, however, such hardware-based approaches may still incur moderate to significant slowdowns due to expensive table lookups using pointer values ​​to access boundary metadata.

[0018] Unlike the various memory protection techniques described above, implementations of the present disclosure use a hardware-based bounds checker that can accurately enforce object bounds to prevent spatial errors. The hardware-based bounds checking framework embodiment efficiently invalidates bounds of dangling pointers to facilitate detection of temporal errors. In practice, the hardware-based bounds checking framework embodiment may desirably reduce performance overhead and avoid modifying binary layout. To that end, implementations of the present disclosure include a bounds metadata design that can associate pointers with unique inline identifiers that can be used to index into a disjoint bounds table. One or more implementations of the present disclosure include an inline index, disjoint bounds group 140 as a bounds-checked technique.

[0019] 2 is a block diagram illustrating a system 200 capable of facilitating memory error mitigation for heap objects in accordance with one or more embodiments described herein. The system 200 includes a non-transitory computer-readable storage medium (storage medium) 210 for storing computer-executable components, and one or more processors 220 operably connected to the storage medium 210 via one or more communication buses 230 for executing the computer-executable components stored on the storage medium 210. As shown in FIG. 2, the computer-executable components include an entry component 240 and a re-purpose component 250.

[0020] An entry component 240 can allocate an entry in a table to store bounds information when an object is allocated in memory. A repurposing component 250 can re-purpose unused bits of an object address to store an index to an entry in the table. In one embodiment, the repurposing component 250 can re-purpose unused bits of an object address to track the range of accessible memory addresses.

[0021] In one embodiment, the computer-executable components stored in memory device 210 may further include a check component 260. Check component 260 may perform bounds checking in hardware on load and store instructions by using index bits in an address to access bounds information. In one embodiment, check component 260 may check array bounds. In one embodiment, check component 260 may determine whether an array reference is in-bounds or out-of-bounds and mitigate the occurrence of out-of-bounds array references.

[0022] In one embodiment, the computer-executable components stored in storage device 210 may further include a propagation component 270. The propagation component 270 may automatically propagate the index when subsequent object addresses are derived through assignment statements or pointer arithmetic. In one embodiment, the propagation component 270 may propagate extra information in unused bits when object addresses are copied into assignment statements. In one embodiment, the propagation component 270 may propagate extra information in unused bits when object addresses are passed as arguments to function calls. In one embodiment, the propagation component 270 may propagate extra information in unused bits when object addresses are used in address calculations. The functionality of the computer-executable components utilized by the present embodiment is described in more detail below.

[0023] A low-cost, minimally invasive framework for bounds checking in hardware is disclosed below. The disclosed approach uses a hardware-enabled pointer bounds checking framework to provide low-cost, accurate memory safety for heap objects. In one embodiment, the disclosed bounds checking framework for heap objects can be implemented using LLVM-instrumentation to replace malloc / free calls in a program with custom library-functions to maintain bounds information.

[0024] As described in further detail below, implementation of the disclosed techniques facilitates mitigating heap object memory errors through accurate enforcement of object bounds on pointer dereferences, and preventing out-of-bounds access and use-of-free errors. The disclosed techniques facilitate accurate enforcement of object bounds with minimal impact on performance. Moreover, the disclosed techniques can be implemented without modifications to source code or binary layout. According to embodiments of the disclosed techniques, memory errors for heap objects can be mitigated by re-thinking hardware bounds checking in a vertically integrated hardware / software (HW / SW) ecosystem with minimal changes to C / C++ memory allocation functions, instruction set architecture (ISA), and hardware.

[0025] One aspect of the disclosed technique repurposes "unused bits" in a pointer to check or track the range of addresses that are legitimately accessible through that pointer. In 64-bit architectures, object pointers typically store virtual addresses with 48 bits or less of information, and therefore the unused bits in the pointer are present. The disclosed technique leverages these unused bits to (a) allocate an entry in a bounds table to store bounds information when an object is allocated, (b) repurpose unused bits (e.g., high order bits) of the object pointer to store an index to an entry in the bounds table, (c) automatically propagate the index when subsequent addresses are derived through assignment statements or pointer arithmetic, or (d) perform bounds checking in hardware on load and store instructions by using index bits in the address to access the appropriate bounds information, or any combination of (a)-(d).

[0026] By leveraging these unused bits, the techniques disclosed herein can facilitate ensuring the spatial and temporal safety of heap objects and prevent errors such as reading and writing outside the bounds of the heap and using freed memory. In addition to mitigating heap errors, one or more embodiments of the techniques disclosed herein can also be generally applied to ensuring the memory safety of globals and stack-objects. Such errors are desirable to prevent, as they account for nearly 50% of the CVEs mentioned above in relation to technology company research, and further account for nearly 60% of the memory safety bugs found in the OSS-Fuzz service provided by Google LLC (Mountain View, Calif.).

[0027] FIG. 3 is a conceptual illustration of an overview of a technique for reusing unused bits (e.g., high-order bits) of an object pointer to ensure spatial and temporal safety of heap objects, according to one or more embodiments described herein. As shown in FIG. 3, the technique generally repurposes unused bits (e.g., high-order bits) of an object pointer to store an index to an entry in a bounds information table (BITable) that contains bounds metadata corresponding to the object pointer. In one embodiment, the BI Table is a per-process BI Table. In one or more embodiments, the technique intercepts memory allocation functions in the C library to allocate entries in the BI Table with malloc and invalidate the entries with free. As shown in FIG. 3, the BI Table can facilitate checking and tracking of bounds metadata for each object on the heap. Such metadata can be used to perform bounds checking on pointer dereferences through bounds checking operations at load / store execution time in hardware. The technique of the present disclosure uses the index to bounds table entries stored in the unused bits (e.g., high-order bits) of an object pointer to detect out-of-bounds accesses during the object's lifetime. As shown in FIG. 3, the techniques disclosed herein further detect use-after-free errors using an index in a dangling pointer that points to an invalid bounds table entry after an object is freed.

[0028] Notably, the disclosed technique can easily avoid changes to the binary layout, unlike conventional approaches using fat pointers. Moreover, the disclosed technique does not incur index propagation overhead (which may occur "automatically" by program semantics) when one pointer is assigned to another, passed in a function call, or used to calculate another address in array indexing or pointer arithmetic. In contrast, existing techniques may require additional instructions or micro-ops to propagate pointer metadata. In one embodiment, index propagation is "automatic" without fetching or executing "extra" instructions.

[0029] Moreover, the performance impact of the actual bounds check can be minimized for at least two reasons. First, because all addresses associated with a given buffer can have the same index, the index bits of the address and the bounds information are often available in an on-chip bounds information (BI) cache. Simulations of the implementation have shown that with an 8KB on-chip BI cache, the bounds information hit rate is over 98%. Second, the bounds check for a load or store operation can be performed in parallel with the address translation of the load or store operation, and this can often be done without adding extra latency to the load or store instruction. Finally, because the location of the bounds information (identifiable by the index) is independent of the pointer value, the disclosed technique can maintain the invalid-bounds status of dangling pointers even after the freed memory is reused. Furthermore, the disclosed technique can ensure time safety without additional cost, unlike existing hardware-based bounds checking techniques, where the location of the bounds metadata is often linked to the pointer value.

[0030] In one embodiment, the disclosed bounds checking framework for heap objects can include a threat model that includes one or more assumptions. For example, an assumption is that a program may have heap memory safety bugs, such as out-of-bounds access, use-after-free, double-free, invalid-free, etc. An assumption is also that an adversary may pass unverified inputs to the program in an attempt to exploit such memory bugs. An assumption is also that an adversary cannot modify user program code to introduce bugs or directly access or tamper with the bounds metadata. An assumption is also that memory-allocator functions available to the disclosed framework for managing bounds metadata are bug-free and reliable.

[0031] One aspect of the bounds checking framework of the present disclosure stores bounds metadata for objects throughout their lifetime in a BI table within the virtual address space of a program. In one embodiment, the BI table is a per-process BI table. Another aspect of the bounds checking framework of the present disclosure performs hardware-based bounds checking on all object accesses at program runtime.

[0032] FIG. 4 is a conceptual illustration of an overview of the life-cycle of a pointer during program execution, according to one or more embodiments described herein. As shown in FIG. 4, when an object is created, an entry (BIEntry) can be created in the BI table. The BI entry can be used to store the base address and size of the object. In another embodiment, the BI entry can be used to store the addresses for the upper and lower bounds of the object. An index to a corresponding entry in the BI table can be embedded in the unused bits of the pointer. The term "index bits" as used herein refers to unused bits of a pointer that are embedded with an index to a corresponding entry in the BI table. For ease of implementation, the following description assumes that the top 24-bits of a pointer are available as index bits. However, the index bits of the embodiments of the present disclosure are not limited to contiguous bits or the top 24 bits of a pointer. In one embodiment, the index bits are non-contiguous. In one embodiment, one or more bits of a pointer precede the index bits of the pointer. Furthermore, the hardware can access the corresponding BI entry using the index in the high-order bits, and perform bounds checks to detect out-of-bounds accesses when the pointer is dereferenced, as shown in Figure 4. Furthermore, the hardware can invalidate the corresponding BI entry when the object is freed, as shown in Figure 4. Invalidating the corresponding BI entry facilitates the detection of temporal errors when dangling pointers pointing to these freed objects are used later.

[0033] FIG. 5 is a diagram illustrating an architectural layout 500 of a bounds checking framework, according to one or more embodiments described herein. As shown in FIG. 5, a software element can manage the BI table. For example, hooks for malloc and free functions can be used to intercept calls to these functions and perform associated BI table operations (such as allocating and invalidating BI entries). Such hooks can be defined in a shared-library that can be added by a linker at program compile time. Moreover, such hooks can be added at program compile time without requiring source code changes or compatibility issues associated with binary layout changes. Furthermore, as shown in FIG. 5, a hardware element on which the binary runs can transparently perform bounds checks on all load and / or store instructions to detect memory safety violations. Also, execution of load and / or store instructions can be modified in hardware to access the BI table to obtain bounds metadata for bounds checking. Also, a bounds information cache (BI cache) can be added to limit the slowdown caused by accessing the BI table in memory.

[0034] 6 is a diagram illustrating a BI table 600 according to one or more embodiments described herein. As described above, the BI table 600 can be maintained in a program's virtual address space. The BI table 600 can store bounds metadata for each heap object in the program. Additionally, the BI table 600 can be accessed to perform bounds checking for each load and / or store instruction to a heap object.

[0035] As shown in FIG. 6, the BI table 600 may be configured as a linear table including multiple BI entries (e.g., BI entry 610). Each BI entry includes a base address field 620 and an object size field 630. In FIG. 6, each BI entry in the BI table 600 is implemented as a 16-byte BI entry including a 64-bit base address field and a 64-bit object size field. In one embodiment, each BI entry in the BI table 600 may be implemented as a 12-byte BI entry including a 48-bit base address field and a 48-bit object size field. Each BI entry in the BI table 600 may be associated with a heap object. To access a particular BI entry in the BI table 600 corresponding to a given object, only a single table-lookup is required (BITable[index]). This single table-lookup may use an index 640 that may be embedded in a pointer 650 during object allocation. In contrast, accessing the boundary metadata using some implementations of the isolation boundary group 130 bounds-checking approach described above with reference to FIG. 1 may require multi-level table lookups using the pointer values ​​themselves.

[0036] The memory space for the BI table can be reserved at program initialization time by specifying the MAP_ANONYMOUS flag in the mmap call, which facilitates lazily allocating physical pages when accessed. Thus, the memory consumed by the BI table grows in proportion to the number of malloced objects in the program. The base virtual address of the BI table and its size can be stored in dedicated hardware registers (BTBASE and BTSIZE, respectively). In one embodiment, these dedicated hardware registers are accessible only by privileged software or within the hardware. The base virtual address of the BI table and its size can be saved and / or restored with other process state by context switches, similar to the CR3 register that stores the page-table base in the x86 architecture. This facilitates the hardware to calculate the virtual address of the BI entry as BTBASE + index*16, with bounds checking. From the size of the BI table, it can be determined whether an entry invalidated by free needs to be reused. In general, the BI table should be large enough to accommodate the maximum number of live objects (objects that have been allocated and not yet freed) in the program. The size of the BI table can be set to 16 million entries (in the SPEC-CPU2017 workload described below, the maximum number of live objects was 2.4 million), but users can choose a smaller value at compile time to reduce memory consumption.

[0037] LLVM-based instrumentation can be used to initialize malloc / free hooks before main is executed. In one embodiment, LLVM-based instrumentation can insert functions that initialize malloc / free hooks. These hooks can intercept subsequent malloc and free calls from the program, which may call internal memory allocation functions or create or delete BI entries. Special instructions (setBIEntry / getBIEntry) can be used to update or check BI entries in trusted hook functions. To prevent unauthorized reads and writes to the BI tables, these special instructions can be used to prohibit access to the BI tables from other unprivileged software (outside the trusted memory allocator functions) (this can be done by a trusted compiler or binary inspection by the runtime). In one embodiment, the createBIEntry and deleteBIEntry functions can be implemented as new ISA instructions to secure the BI tables, and unprivileged usage is only allowed in the malloc / free functions (binary checks can ensure this). The hardware can explicitly prevent loads / stores to the BI tables from unprivileged software.

[0038] Examples of function hooks that can be called on malloc / free are shown in Listings 1 and 2. When malloc is intercepted, real_malloc can be called. The returned base address and requested object size can also be stored in a BI entry when malloc is intercepted by the setBIEntry instruction. For the first 16 million mallocs, a new BI entry can be used in the BI table. Otherwise, one of the BI entries invalidated by free can be reused in FIFO order using a FIFO that can store the index value of the freed BI entry. The index of this BI entry is then embedded in the upper 24 bits of a pointer and returned to the program. When free is intercepted, the BI entry can be obtained by the getBIEntry instruction using the index in the upper 24 bits of this pointer. The index in the upper 24 bits of this pointer can also be used to verify whether the pointer value matches the base address of the object. The BI entry can then be invalidated (for example, the base address and object size of the corresponding object can be set to 0), and real_free can be called to free the object. Listing 1

[0039] TIFF0007657134000001.tif50129 List 2

[0040] TIFF0007657134000002.tif67137

[0041] FIG. 7 is a diagram illustrating a layout 700 of a program's 64-bit virtual address space, according to one or more embodiments described herein. As described above, in one or more embodiments of the bounds checking framework of the present disclosure, the upper 24 bits of a heap object pointer may be replaced with an index of a corresponding BI entry in a BI table. In a 64-bit Linux system with four levels of page tables, a program typically has available to it a 48-bit user Virtual-Address space. To avoid collisions between heap addresses containing 24 index bits and program addresses, as shown in FIG. 7, the program's virtual address space may be limited to a 2 terabyte (TB) region, since the index bits may overlap with the upper 8 bits of the 48-bit user address. Examples of how embodiments of the bounds checking framework of the present disclosure handle uncommon scenarios are described in more detail below. Examples of such uncommon scenarios include when a program requires a virtual address space larger than 2TB, when not enough index bits are available in the pointer, when the BI table is insufficiently sized, etc.

[0042] In layout 700, the heap grows upwards from 0x0 to 0xFFFFFFFFFF, and the stack grows downwards from 0x7FFFFFFFFFFF to 0x7F0000000000. The remaining 254TB of user virtual address space (i.e., the remainder of the 48-bit virtual address space) can be reserved with an mmap call using the PROT_NONE memory protection argument. In layout 700, the use of index value 0x7F can be skipped for heap objects to avoid collisions with stack addresses. Also, the use of index values ​​from 0xFFFF80 to 0xFFFFFF in layout 700 can be skipped to avoid collisions with kernel addresses. Index 0x0 can be reserved for a NULL pointer (e.g., pointer value "0") to support calling free with a NULL pointer, which is a valid program operation.

[0043] The detection of out-of-bounds accesses and use-of-free memory in the bounds checking framework of the present disclosure relies on hardware-inserted bounds checks on loads and stores. An example of the design and implementation of such hardware-based bounds checks is described below. In this example of the bounds checking framework of the present disclosure, all loads and stores to heap objects (identifiable by the presence of an index in the upper 24 bits) can include a hardware-based bounds check as part of the load / store execution. The bounds check can use the index to look up the corresponding BI table entry to obtain the base address and size of the object. Based on the obtained object base address and size, the hardware-based bounds check can ensure that the access is within [base address, base address+object size]. If it is not within this range, an out-of-bounds exception can be raised. If the base address and object size of the BI entry are zero, a use-after-free exception can be raised. If the BI entry has been reused, a dangling pointer access is detected with a high probability due to a boundary mismatch, which can be flagged as an out-of-bounds exception.

[0044] FIG. 8 illustrates a hardware configuration 800 for implementing hardware-based bounds checking, according to one or more embodiments described herein. For hardware-based bounds checking, the address of the BI entry to be bounds checked can be calculated as BTBASE+Index*16 using the BI table Base register and index bits from the load / store address, and the address translation can be the same as for a regular load. The bounds check can start executing when the virtual address of the load / store is ready, and can continue in parallel with the execution of the load / store without affecting it. The hardware-based bounds check is only on the critical path of the commit-stage of the load / store. The commit stage commits the load / store only if the check passes, otherwise it stalls until the bounds check is completed. As shown in FIG. 8, the entries of the BI table can be cached in a dedicated cache (BICache) in the hardware configuration 800. The dedicated cache can be similar to an L1-D cache. The performance impact of hardware-based bounds checking is minimal because the BI cache can perform hardware-based bounds checking in parallel with the L1-D cache on loads and stores: hardware-based bounds checking that hits the BI cache has little or no impact on load / store latency.

[0045] 9 is a diagram illustrating a slowdown scenario with hardware-based bounds checking, according to one or more embodiments described herein. As shown in FIG. 9, the slowdown typically occurs only when the bounds check results in a BI cache miss and is pending until the corresponding load / store instruction reaches the commit stage.

[0046] In one embodiment, the bounds checking framework of the present disclosure may use a dedicated 8 kilobyte (KB), 8-way BI cache for the entries of the BI table. All accesses to the BI table (for bounds checking and for loads and stores from malloc and free to the BI table) may go through the BI cache. The BI cache may be designed as a virtually-indexed physically tagged (VIPT) cache. It may be designed similarly to the L1-D cache and may have similar latency (but much smaller in size). This design allows the hardware-based bounds check to be unaffected by the execution of the load / store on a BI cache hit. On a BI cache miss, the BI entries may be serviced from memory for simplicity. In one embodiment, the entries may be cached in a last-level cache to further reduce overhead. The load / store queue entries may be expanded to store the status of pending bounds checks when a BI cache miss causes a bounds check to be delayed. Storing the status of the pending bounds check may include storing a 48-bit BI entry address, a 1-bit checkIssued flag, and a 1-bit checkComplete flag.

[0047] In one embodiment, the bounds checking framework of the present disclosure can utilize ISA support for some instructions to prevent unauthorized access to the BI table by an unprivileged adversary. Such instructions can include an initBITable instruction. An operating system (OS) can use the initBITable instruction to set the base address of the BI table in a hardware BTBASE register to an arbitrary virtual address at program initialization and set the size in a BTSIZE register. Accesses to the BTBASE register and / or the BTSIZE register from unprivileged software can generate an exception.

[0048] Such instructions may further include setBIEntry and getBIEntry instructions that allow trusted malloc / free functions to write and read BI entries. For example, the setBIEntry instruction allows a specific BI entry (BITable[index]={base,size}) to be set. The setBIEntry instruction can also be used by malloc and free to allocate and invalidate BI entries. The getBIEntry instruction allows free to read the BI entry and check if the pointer to be freed is valid (BITable[index].base==ptr_val). A trusted compiler or runtime can easily ensure that setBIEntry and / or getBIEntry instructions are only used by trusted memory allocator functions. Furthermore, the hardware can easily prevent unprivileged software from explicitly loading or storing to addresses where the BI table is mapped. This ensures that an unprivileged attacker cannot read or write to the BI table even if he guesses the address of the BI table.

[0049] In one embodiment, the malloc and free hook functions can be implemented in a thread-safe manner by using locks to allow atomic updates of the BI table and the BI table's management data structures (e.g., free-entry FIFO). Furthermore, coherence between BI caches across different cores (VIPT design) can be maintained by using the existing cache-coherence fabric in hardware. Updates to the BI table from one core can be reflected in accesses from other cores without the need for extra software intervention. As long as the program itself is written to be thread-safe (e.g., there is no data race between accesses to the same object from different threads and free) and the internal memory allocator itself is thread-safe, the bounds checking framework of the present disclosure can maintain compatibility with multi-threaded programs.

[0050] As described above, some unusual scenarios may occur when implementing the bounds checking framework embodiments of the present disclosure. In exceptional cases, the BI table may not be able to store all the BI entries of a program. For example, if the number of active objects of a program exceeds the size of the BI table, the BI table may not be able to store all the BI entries of the program. As another example, if a sufficient number of index bits are not available in the pointer, the BI table may not be able to store all the BI entries of the program.

[0051] In such cases, an overflow-table can be used to store the bounds metadata. A pointer whose metadata is kept in the overflow table can be identified by embedding a special value in its index bits. For such a pointer, the pointer value itself can be used to search the overflow table. Since such a table lookup may require expensive multi-level table lookups, a program can ensure that only seldom-used BI entries are placed in the overflow table. For the SPEC-CPU2017 workload evaluated by implementing the bounds checking framework of this disclosure, a BI table with a capacity of 16 million entries was more than sufficient (with a maximum of less than 3 million entries used), and no overflow table was required.

[0052] Examples of types of memory safety bugs that can be detected by one or more embodiments of the disclosed bounds checking framework are provided below, along with further examples of preventing an attacker from accessing bounds checking metadata. Additionally, new potential bugs that can be detected using one or more embodiments of the disclosed bounds checking framework are also described below.

[0053] An example implementation of the disclosed bounds checking framework was tested with 25 exploits from the How2Heap exploit suite, which exploits heap spatial and temporal safety bugs such as out-of-bounds access, use-of-free memory, invalid free, and double free. The example implementation of the disclosed bounds checking framework was able to detect the bugs in all 25 programs, raise an exception, and terminate the program before the exploit's goal was achieved. Of these, the example implementation of the disclosed bounds checking framework detected out-of-bounds access in 8 exploits, use-of-free memory in 10 exploits, and invalid / double free in 7 exploits.

[0054] For out-of-bounds accesses, a bounds check inserted in parallel with the load / store can check the BI entry to ensure that the access is within the object bounds of the load or store. For use-after-free, if the bounds check on the load / store finds that the BI entry has base=0 and size=0, then either the object was recently freed or the BI entry is uninitialized (the object has no memory allocation). In this case, the implementation of the bounds checking framework disclosed herein can flag both scenarios and identify these bugs in 10 out of 25 exploits. If the BI entry is reallocated between the free and the use-after-free, then the use-after-free can be detected as an out-of-bounds access with a high probability. Also, the overflow table can be used to completely avoid reusing the BI entry. For double and invalid frees, a BI entry check on a free that verifies that the pointer-to-be-freed matches the object base of the corresponding BI entry, if a mismatch is detected, this may indicate an invalid or double free bug. If the index in the high-order bits of the pointer is not a valid value, or the object bases of the BI entries do not match, the invalid free bug can be flagged, or if the base and size of the BI entries are zero, the double free bug can be flagged.

[0055] In one or more embodiments of the bounds checking framework of the present disclosure, two types of metadata used to check the bounds of a load or store are (i) the BI entry in the BI table that contains the bounds, and (ii) the index bit in the pointer used to access the BI table. The following describes an example of protecting these two types of metadata in accordance with one or more embodiments described herein.

[0056] Regarding protection of the BI table, an unprivileged attacker cannot directly read or modify it. The hardware can prevent unprivileged software from performing loads or stores to the virtual memory where the BI table is mapped. This check can be enforced by the load / store unit by preventing unprivileged loads and stores to the address range from BTBase to BTBase+BITableSize. The setBIEntry and getBIEntry instructions that allow unprivileged software to access the BI table are typically only allowed in trusted memory allocator functions (this can be enforced by a trusted compiler or runtime). In general, only privileged OS or system software, or hardware, can directly access the BI table.

[0057] With regard to the protection of pointer index bits, it can be assumed that an attacker cannot modify the victim code to arbitrarily overwrite pointers or generate wild pointers. However, an attacker may attempt to exploit unsafe pointer arithmetic in the victim code to corrupt index bits by using unvalidated inputs to cause overflows or underflows. Such corruption is likely to be detected as an error in bounds checking implemented according to one or more embodiments described herein. Corruption of index bits can also be prevented by extending CPU registers to store pointer index bits separately and explicitly isolating the index bits from pointer arithmetic.

[0058] Below, we describe example test results for example bounds checking implemented by embodiments of the disclosed bounds checking framework and modeled in Gem5. The example tests were performed using 13 C / C++ SPEC-CPU2017 binaries compiled using clang-11 and Glibc-v2.27. Below, we describe out-of-bounds accesses detected by the example bounds checking when checking pointer accesses against object allocation-bounds, where the BI entry stores a 16-Byte aligned size allocated by malloc. One or more embodiments of the disclosed bounds checking framework further support byte-granularity bounds-checks by storing the object size requested by the program in the BI entry.

[0059] FIG. 10 illustrates the results of this test example. Specifically, FIG. 10 is a graph 1000 illustrating functions for which out-of-bounds accesses were detected by an embodiment of the bounds checking framework of the present disclosure. FIG. 10 illustrates functions for which out-of-bounds accesses were detected by an example implementation of the bounds checking framework of the present disclosure across 13 SPEC C / C++ binaries executed on the Gem5 simulator for 11 billion instructions. Overall, as shown in FIG. 10, this example implementation of the bounds checking framework detected out-of-bounds accesses in 87 lines of code. Of the 87 lines of code, 80 lines of code were highly optimized string processing functions (including strlen, strchr, strcmp, etc.) in Glibc-v2.27, and 7 lines of code were four user functions in the blender program. In this test example, the maximum number of bytes for which these accesses were out-of-bounds was 62 bytes for Glibc functions and only 4 bytes for blender functions.

[0060] All of these bugs found in the test example were confirmed to be caused by SIMD instructions that load data from memory to SIMD registers. FIG. 11 is a graph 1100 illustrating instructions in a SPEC-CPU2017 application that caused out-of-bounds errors, according to one or more embodiments described herein. As shown in FIG. 11, such instructions in Glibc string processing functions include SIMD move (MOVDQA, MOVDQU, MOVHPD, MOVLPD), compare (PCMPEQB), or minimize (PMINUP) instructions. Also, as shown in FIG. 11, such instructions in blender include SIMD arithmetic instructions (MUSS, ADSS, SUBSS). Investigations revealed that the blender bugs were caused in part by out-of-bounds accesses when the compiler uses unaligned 16-byte SIMD loads to access memory at object boundaries when compiled with the O3 flag. These bugs disappeared by using the O0 flag because SIMD operations were not used. The bug in the Glibc function exists in the shared library (libc.a) distributed with Ubuntu 18.04, and is considered to be more serious because the number of out-of-bounds bytes during memory access is up to 62 bytes.

[0061] Looking at strlen, the function with the most lines of code for out-of-bounds accesses (20 lines), we found that more than half of the bugs (11 of 20) were due to the PCMPEQB instruction for byte-wise comparison of 16-byte operands, one from memory and one from a register. The strlen function uses these to perform a fast check for the NULL character ("\0") in the input string and to calculate the length of the string. Listing 3 shows an example of strlen assembly code generated from an object-dump of libc.a in Glibc-v2.27. The code issues three simultaneous 16-byte comparisons (up to four elsewhere), then uses a test-and-jump instruction to stop the comparison if a NULL is encountered. This unsafe code can access up to 47 bytes of memory outside the string object (up to 63 bytes for four 16-byte comparisons). We also tested these binaries with the default version of ASAN, which did not detect any of these bugs. This is because ASAN requires recompilation of shared libraries to detect bugs in them. Furthermore, the default implementation of ASAN did not detect partial out-of-bounds accesses due to unaligned loads, which the embodiment of the bounds checking framework of this disclosure detected in Blender.

[0062] TIFF0007657134000003.tif57147

[0063] Below, we outline an evaluation methodology for performing the above-described test examples, and also discuss example software and hardware modification overhead that may be incurred when implementing one or more embodiments of the bounds checking framework of the present disclosure.

[0064] As an evaluation method, software changes to realize an embodiment of the bounds checking framework of the present disclosure (including malloc / free hooks) were packaged as a shared library. Furthermore, as an evaluation method, an initialization function was added before the program main using the instrumentation added in LLVM10. Hardware changes to realize an embodiment of the bounds checking framework of the present disclosure were modeled with Gem5 v20.0. As an evaluation method for performance evaluation, 13 types of benchmarks out of 16 types of C / C++ benchmarks published in SPEC-CPU2017 were used together with the ref dataset (3 types of workloads did not work with this evaluation method). Additionally, we evaluated the overhead of software instrumentation by running the instrumented binaries to completion (ISA changes emulated in C code) on a native machine (Intel Xeon CPU E-2174G, 3.80GHz, Santa Clara, California) and comparing them with uninstrumented binaries. To evaluate the hardware overhead, we used the instrumented binaries and ran them with and without bounds checking in Gem5's System-Call Emulation mode. We also skipped the initialization phase and fast-forwarded the first 10 billion instructions to warm up the cache, tracking statistics for the 1 billion instructions. The hardware configuration used by our evaluation method for Gem5 is shown in Table 1. [Table 1]

[0065] FIG. 12 is a graph 1200 illustrating the performance impact of software instrumentation for BI table management, according to one or more embodiments described herein. Specifically, graph 1200 shows execution times of an application linked with a shared library that intercepts malloc / free calls and updates the BI table. In general, graph 1200 facilitates the evaluation of the slowdown associated with malloc / free instrumentation. The execution times shown in graph 1200 are normalized to the execution time of the binary before instrumentation. Each execution time shown in graph 1200 was obtained by running the corresponding program to completion on a native system and measuring the overall execution time. To facilitate native execution and model the overhead of BI table management, multiple BI entries were allocated by malloc without embedding index bits in the pointers, and the BI entries were randomly deleted by free. As shown in Figure 12, software instrumentation for BI table management (without bounds checking) can add an average slowdown of about 0.5% across all programs. Malloc-heavy workloads (e.g., gcc and perlbench) can experience up to 1.8%-2.4% slowdown due to increased cache accesses for BI table updates. Other workloads where malloc is used infrequently have a negligible impact on performance.

[0066] FIG. 13 is a graph 1300 illustrating the performance impact of hardware-based bounds checking, according to one or more embodiments described herein. Specifically, graph 1300 shows the execution time per billion instructions of an instrumented binary executed with bounds checking, normalized to the execution time of a corresponding binary without bounds checking. Overall, graph 1300 facilitates the evaluation of the slowdown associated with hardware-based bounds checking in Gem5 using instrumented binaries. As shown in FIG. 13, hardware-based bounds checking can add an average slowdown of about 1%. The main contributor to these overheads is the memory accesses incurred by bounds checking due to BI cache misses. Malloc-heavy workloads (e.g., xalancbmk, gcc, parest) tend to have smaller buffers and therefore fewer buffer accesses sharing the same index. This can result in larger boundary metadata working-sets, which can lead to higher BI cache miss rates (e.g., 2%-16%) and slower performance (e.g., 1%-6%). Other workloads with BI cache hit rates above 99% experience negligible slowdown.

[0067] 14 and 15 are diagrams illustrating an example scenario breakdown for loads that experience BI cache misses. Specifically, FIG. 14 is a graph 1400 illustrating loads per 1000 instructions with BI cache misses, according to one or more embodiments described herein. FIG. 15 is a graph 1500 illustrating the percentage of loads with BI cache misses, according to one or more embodiments described herein. Since there is no slowdown when the bounds check is a BI cache hit, scenarios where BI cache misses occur in workloads such as xalancbmk, gcc, and parest were evaluated to understand the slowdown in these workloads. The evaluation showed that, overall, over 98% of BI cache misses occur on bounds checks during load operations, and only 2% are misses on stores.

[0068] Graphs 1400 and 1500 show the breakdown of BI cache misses during load operations based on where the load operation occurred (in absolute numbers and percentages, respectively). As shown in graphs 1400 and 1500, the xalancbmk workload has the most BI cache misses (highest miss rate) and therefore the largest slowdown. Meanwhile, the gcc workload has a higher miss rate than the parest workload, but the slowdown is smaller for the gcc workload. In general, the slowdown is smaller for the gcc workload because it has a very small percentage of BI cache misses where the load is an L1-hit (which has a larger impact on performance than a BI cache miss on a load that is an L1-miss). Thus, the lack of locality in BI cache accesses on L1-hits can be the main factor in the slowdown of the xalancbmk and parest workloads. However, this can be addressed by making the BI entry allocation algorithm more locality-sensitive, especially to sub-cacheline objects that are common in these benchmarks, thereby reducing the overhead for these workloads.

[0069] 16 and 17 are diagrams illustrating an example of the slowdown due to bounds checking for each BI cache size. Specifically, FIG. 16 is a graph 1600 illustrating an average slowdown due to bounds checking for each different BI cache size, according to one or more embodiments described herein. FIG. 17 is a graph 1700 illustrating a BI cache miss rate for each different BI cache size, according to one or more embodiments described herein. The example of the evaluation of the overhead of bounds checking described above used a default BI cache size of 8 KB, but graphs 1600 and 1700 illustrate evaluations for other BI cache sizes. Specifically, graphs 1600 and 1700 illustrate the slowdown due to bounds checking and the BI cache miss rate when the BI cache size is changed from 1 KB to 64 KB. As shown in graphs 1600 and 1700, as the BI cache size increases, the slowdown decreases from 7% (1 KB), to 3% (4 KB), to 1% (8 KB). However, the degree of reduction in the slowdown may be small when the BI cache size is further increased. This is because above 8KB most workloads are likely to have miss rates below 1%, and the average BI cache miss rate does not decrease significantly overall.

[0070] 18 and 19 are diagrams illustrating example memory overhead associated with implementing embodiments of the bounds checking framework of the present disclosure. Specifically, FIG. 18 is a graph 1800 illustrating memory bandwidth overhead associated with bounds checking, according to one or more embodiments described herein. FIG. 19 is a graph 1900 illustrating memory overhead associated with a BI table, according to one or more embodiments described herein. As shown in graph 1800, bounds checking can increase memory bandwidth consumption by an application by about 29% on average. However, this memory bandwidth consumption by an application can vary depending on the design of the BI cache. For example, additional caching of BI entries in a shared last-level cache can reduce the required bandwidth. Fortunately, DDR4 DRAM can meet the additional bandwidth requirement without slowdown. In terms of memory consumption, if the BI table is configured with 16 million entries with 16 bytes per entry, the BI table can consume up to 256 MB. In this configuration, the BI table can consume an additional memory of 39% on average. In one embodiment, for a memory optimized BI table design (e.g., BI Table-MemOpt) configured with 8 million 12-byte entries (storing 48-bit base and bounds), the additional memory consumption can be approximately 17%. These overheads can be much smaller than the bounds-checked approach described above with reference to FIG. 1 using shadow memory such as the isolated bounds group 130, because the memory required by the BI table grows with the number of mallocs, not with the amount of program memory used.

[0071] In the following, we describe other hardware-based approaches to ensure spatial-temporal safety and compare them with our hardware-based bounds checking framework. One distinguishing feature of our bounds checking framework over other bounds checking approaches is that our bounds checking framework allows for easy propagation and lookup of bounds information at very low cost.

[0072] As described above with reference to FIG. 1, one approach in the isolation boundary group 130 performs bounds checking by accessing bounds metadata from a shadow memory, which provides only spatial safety. Another approach in the isolation boundary group 130 extends this design to provide temporal safety at a moderate cost (e.g., an average 24% slowdown) by associating a pointer with a unique identifier (also stored in the shadow memory) that can be revoked. Such accesses to the shadow memory during bounds checking have limited temporal locality because different locations in the shadow memory are accessed to load / store different words of a single object. In one or more embodiments of the bounds checking framework of the present disclosure, the BI table can be accessed using index bits in the pointer, which can easily ensure that all loads / stores to a single object use the same BI table entry. This facilitates performing low-cost bounds checking (e.g., 1% slowdown) that can achieve a BI cache hit rate of over 98%.

[0073] Another approach in the isolation boundary group 130 provides spatial and temporal safety by associating pointers with capabilities stored in a separate capability-table indexed by the capability-ID to obtain bounds for bounds checking. However, deriving capability-IDs from pointer values ​​can be expensive in the case of pointers spilled to memory, requiring a second expensive lookup into a 5-level Pointer-Alias ​​Table. This approach proposes a speculative pointer-tracking mechanism in hardware to propagate capability-IDs to derived pointers at low cost and cache capabilities and identifiers, resulting in an average slowdown of 15%, but the expensive table lookups can result in a worst case slowdown of as much as 40%. Furthermore, a speculative pointer-tracking mechanism is required to transport capability-IDs through pointer arithmetic. In contrast, embodiments of the bounds checking framework disclosed herein utilize a BI table that can be looked up using an index embedded within the unused bits of the pointer, allowing the BI table to be automatically transferred to the derived pointer without incurring any additional cost, resulting in a worst-case speed degradation of approximately 7%.

[0074] While other approaches to isolation boundary groups 130 may provide spatial and temporal safety, their bounds checking requires extra explicit instructions and involves costly table lookups due to the bounds table being structured as a two-level trie, resulting in significant overhead (e.g., 50%-60% on average). In contrast, embodiments of the bounds checking framework disclosed herein can implement bounds checking with high temporal locality and at most one table lookup that can be transparently inserted into hardware at load / store execution time.

[0075] The contiguous boundary group 110 approach can ensure memory safety, but requires changes to the binary layout, which impacts compatibility with existing library code. The inline boundary group 120 approach can avoid compatibility issues by repurposing unused pointer bits for bounds metadata, but cannot ensure time safety. Embodiments of the disclosed bounds checking framework can maintain compatibility with legacy shared-libraries and ensure memory safety (both time and space safety) for pointers passed to existing shared libraries, with negligible speed degradation.

[0076] Probabilistic approaches using tripwires can achieve low-cost memory error detection (e.g., 2%-18% slowdown) by inserting magic-values ​​(i.e., tripwires) at the granularity of objects or sub-objects and checking these magic-values ​​in hardware to detect out-of-bounds accesses that activate the tripwires. However, such approaches cannot detect larger out-of-bounds accesses that access memory beyond the tripwires. Embodiments of the bounds checking framework of the present disclosure allow accurate detection of all out-of-bounds accesses with comparable or better performance.

[0077] A probabilistic approach using memory tagging assigns a tag or "color" to an object-pointer pair, keeps these tags separate, and checks whether the pointer and the tag of the accessed memory match when dereferencing the pointer. This approach incurs negligible speed degradation (e.g., less than 5% slowdown), but uses a 4-bit tag (stored in the most significant bits of the pointer) that is reused for different objects, so errors can only be detected probabilistically, leading to false-negatives. In contrast to the above, embodiments of the bounds checking framework of the present disclosure also repurpose pointer bits, but use them to store an index to the actual bounds information. Thus, embodiments of the bounds checking framework of the present disclosure can achieve accurate enforcement of object bounds (high coverage) with comparable speed degradation.

[0078] 20A-20G are diagrams illustrating an operational flow 2000 for initializing a BI table in memory, according to one or more embodiments described herein. As shown in FIG. 20A, the operational flow 2000 includes a state 2002 where an application or user program enters runtime. From state 2002, the operational flow 2000 transitions to state 2004, shown in FIG. 20B. In state 2004, the application generates a BI table initialization call that includes two arguments. The first argument of the BI table initialization call includes a mask value (e.g., 0xff00). The mask value defines which unused bits in the pointer are used to store index information for the corresponding BI entry in the BI table. The second argument of the BI table initialization call includes a size value (e.g., 128). The size value defines the number of BI entries that are allocated to the BI table at initialization. From state 2004, the operational flow 2000 transitions to state 2006, shown in FIG. 20C.

[0079] In state 2006, the application issues a BI table initialization call to the bounds checking library (BC_Library). From state 2006, the operational flow 2000 transitions to state 2008, shown in FIG. 20D. In state 2008, a creation routine of BC_Library creates the BI table in memory by allocating an area of ​​memory for the BI table based on a size value included in the BI table initialization call. From state 2008, the operational flow 2000 transitions to state 2010, shown in FIG. 20E. In state 2010, an initialization routine of BC_Library initializes the BI table by populating each BI entry in the BI table with an initial value. From state 2010, the operational flow 2000 transitions to state 2012, shown in FIG. 20F.

[0080] In state 2012, a special register routine of the BC_Library populates a number of special hardware registers with values ​​corresponding to the BI table. As shown in FIG. 20F, the number of special hardware registers include a Boundary Table Register (BTR), a Boundary Mask Register (BMR), and a Boundary Table Size Register (BTSR). The BTR stores the base address of the BI table that resides in an allocated area in memory. The BMR stores the mask value from the BI table initialization call issued by the application to the BC_Library in state 2006. The BTSR stores the size value from the BI table initialization call issued by the application to the BC_Library in state 2006. The size value defines the number of BI entries that make up the BI table. From state 2012, the operational flow 2000 transitions to state 2014, shown in FIG. 20G. In state 2014, a handler routine of the BC_Library sets up a bt_handler that can be used to operate on the BI table. In one embodiment, bt_handler is a global variable. In one embodiment, bt_handler is comprised of multiple fields that store data related to the base address of a BI table, a size value of a BI table initialization call, a mask value of a BI table initialization call, or a combination thereof.

[0081] 21A-21E are diagrams illustrating an operational flow 2100 for processing a memory allocation function according to one or more embodiments described herein. As shown in FIG. 21A, the operational flow 2100 includes a state 2102 in which an application generates a memory allocation call to request allocation of a memory region. The memory allocation call includes an argument including a length value that defines the size of the requested memory region allocation. From state 2102, the operational flow 2100 transitions to state 2104 shown in FIG. 21B. In state 2104, the application issues a memory allocation call to a memory allocation function of a Heap_Library. As shown in FIG. 21B, the memory allocation function generates a BIEntry creation call that includes two arguments to create an entry in a BI table (p=createBI(p,len)). Additionally, the memory allocation function processes the original memory allocation call and allocates the requested memory region (p=origin_malloc(len)). The two arguments of the BI entry creation include a first argument that includes a pointer value that defines the base address of the newly allocated memory region, and a second argument that includes a length value that defines the size of the allocated memory region. From state 2104, the operational flow 2100 transitions to state 2106, which is shown in FIG. 21C.

[0082] In state 2106, the memory allocation function of the HEAP_Library issues a BI entry creation call to the BI entry creation function of the BC_Library. From state 2106, the operational flow 2100 transitions to state 2108 shown in FIG. 21D. In state 2108, the BI entry creation function searches for a free BI entry in the BI table to store the bounds metadata associated with the allocated memory region. From state 2108, the operational flow 2100 transitions to state 2110 shown in FIG. 21E. In state 2110, the BI entry creation function populates the free BI entry with a pointer value that defines the base address of the allocated memory region and a length value that defines the size of the allocated memory region. The BI entry creation function further embeds the index value (idx) of the free BI entry into the pointer value to create a new pointer value that is returned to the memory allocation function.

[0083] 22A-22K are diagrams illustrating an operational flow 2200 for processing a load instruction, according to one or more embodiments described herein. As shown in FIG. 22A, the operational flow 2200 includes a state 2202 where an application can execute a load instruction from an address Ra. From state 2202, the operational flow 2200 transitions to state 2204 shown in FIG. 22B. In state 2204, a bound protection unit (BPU) can extract an address value and a mask value from the Ra register and the BMR. From state 2204, the operational flow 2200 transitions to state 2206 shown in FIG. 22C. In state 2206, the BPU can extract a memory address of a heap object associated with the load instruction and extract an index value from the address and mask value. From state 2206, the operational flow 2200 transitions to state 2208 shown in FIG. 22D. In state 2208, the memory address derived from Ra and the mask value may be utilized by a load instruction to load bytes from the heap object. From state 2208, the operational flow 2200 transitions to state 2210, which is shown in Figure 22E.

[0084] In state 2210, the BPU may determine the address of the BI entry corresponding to the address Ra using the BTR, which contains the base address of the BI table associated with the application, and the index derived from Ra and the BMR. From state 2210, the operational flow 2200 transitions to state 2212, shown in FIG. 22F. In state 2212, the BPU uses the address of the BI entry determined in state 2210 to obtain the appropriate BI entry for the load instruction. From state 2212, the operational flow 2200 transitions to state 2214, shown in FIG. 22G. In state 2214, the BPU may compare the index value to the size value of the BI table obtained from the BTSR to evaluate whether the index value is valid. From state 2214, the operational flow 2200 transitions to state 2216, shown in FIG. 22H.

[0085] At state 2216, if the evaluation at state 2214 determines that the index value is invalid, the BPU may generate and store an exception value in a bounds status register (BSR). Alternatively, if the evaluation at state 2214 determines that the index value is valid, the BPU may issue a BI load instruction to the bound cache that includes a BI entry address. From state 2216, the operational flow 2200 transitions to state 2218, shown in FIG. 22I. At state 2218, if the bound cache contains bound metadata, the BPU may retrieve the bound metadata corresponding to the heap object from the bound cache in response to the BI load instruction. Alternatively, if the bound cache does not contain bound metadata, the BPU may retrieve the bound metadata corresponding to the heap object from an in-memory BI table in response to the BI load instruction. From state 2218, the operational flow 2200 transitions to state 2220, shown in FIG. 22J.

[0086] In state 2220, the BPU may compare the bounds metadata to the memory address of the heap object extracted in state 2206 to evaluate whether the memory address to be loaded is valid. From state 2220, operational flow 2200 transitions to state 2222, shown in FIG. 22K. In state 2222, if the evaluation in state 2220 determines that the memory address is invalid, the BPU may generate and store an exception value in the BSR. Alternatively, if the evaluation in state 2220 determines that the memory address of the heap object is valid, the BPU may allow the load instruction executed by the application to proceed.

[0087] FIG. 23 illustrates an example pointer 2300, according to one or more embodiments described herein. In some cases, array indexing or pointer arithmetic may result in the arithmetic "overflowing" into unused bits (or index bits) of a pointer used as an index into a BI table, thus "corrupting" the unused bits. For an out-of-bounds reference to go undetected in such a case, the corrupted index value must reference a valid BI entry in the BI table, and the pointer value bits (or address bits) of the pointer must correspond to a valid address within the bounds of that BI entry. While this is unlikely to occur, pointers can be modified to reduce or avoid the likelihood of this occurring. To that end, the pointer 2300 includes guard bits 2310 (e.g., bits 41 and 40) that facilitate a guard band between the index bits 2320 (e.g., bits 42-63) and the address bits 2330 (e.g., bits 0-39). As described in more detail below with reference to Figures 24 and 25, guard bits 2310 can protect index bits 2320 when a "moderately sized" offset is added to or subtracted from an address.

[0088] FIG. 24 is a diagram illustrating a pointer 2400 in accordance with one or more embodiments described herein. As shown in FIG. 24, the pointer 2400 includes index bits 2420, address bits 2430, and guard bits 2440 interposed between the index bits 2420 and the address bits 2430. In FIG. 24, the guard bits are composed of a binary value of "10" from left to right. The pointer 2400 may be provided with a moderately large offset (e.g., <2 40 ), a carry may occur in which the lower bit of the guard bit 2440 (e.g., bit 40) flips from a binary value of “0” to a binary value of “1”, but this is not expected to overflow into and corrupt the index bit 2420. Furthermore, subtracting a moderately large offset from the pointer 2400 may cause a borrow to occur in which bit 41 of the guard bit 2440 flips from a binary value of “1” to a binary value of “0”, but this is not expected to overflow into and corrupt the index bit 2420.

[0089] For example, as shown in FIG. 25, a binary value of negative "1" can be added to (or subtracted from) pointer value 2400. Adding a binary value of negative "1" to the most significant bit (e.g., bit 41) of guard bit 2440 can generate a carry that effectively makes the binary value of the "1" to the left of bit 41 zero in the 64-bit representation of negative 1. Thus, the bits to the left of bit 41 sum to those bits in the original address represented by pointer 2400 of FIG. 24. The index bit corruption mitigation technique described above with reference to FIGS. 23-25 ​​facilitates the execution of applications or user programs that use over 1 Terabyte (TB) of address space and track bounds information for over 4 million arrays. The technique accomplishes this while preventing out-of-bounds array references and allowing for reasonably large offsets (e.g., <2 40 This can prevent or reduce "index corruption" in pointer arithmetic associated with

[0090] 26 is a flow chart illustrating a computer-implemented method 2600 for facilitating hardware-based memory error mitigation for heap objects, according to one or more embodiments described herein. For the sake of brevity, elements similar to elements in other embodiments herein are not described.

[0091] At step 2602, the computer-implemented method 2600 can include allocating, with a processor (e.g., including entry component 240), an entry in a table for storing bounds information when an object is allocated in memory. At step 2604, the computer-implemented method 2600 can include repurposing, with a processor (e.g., including repurposing component 250), unused bits of an object address to store an index to an entry in the table.

[0092] In one embodiment, the computer-implemented method 2600 may further include using a processor (e.g., including a checking component 260) to perform bounds checking in hardware on load and store instructions by using index bits in the address to access bounds information. In one embodiment, the computer-implemented method 2600 may further include using a processor (e.g., including a propagation component 270) to automatically propagate the index when subsequent object addresses are derived via assignment statements or pointer arithmetic. In one embodiment, the computer-implemented method 2600 may further include using a processor to check array bounds. In one embodiment, the computer-implemented method 2600 may further include using a processor to determine whether an array reference is in-bounds or out-of-bounds. In one embodiment, the computer-implemented method 2600 may further include using a processor to mitigate the occurrence of out-of-bounds array references.

[0093] In one embodiment, the computer-implemented method 2600 may further include, using a processor, using unused bits in the object address to check a range of accessible memory addresses. In one embodiment, the computer-implemented method 2600 may further include, using a processor, propagating additional information in the unused bits when the object address is copied into an assignment statement. In one embodiment, the computer-implemented method 2600 may further include, using a processor, propagating additional information in the unused bits when the object address is passed as an argument to a function call. In one embodiment, the computer-implemented method 2600 may further include, using a processor, propagating additional information in the unused bits when the object address is used in an address calculation.

[0094] Although the above has been focused on protecting heap objects from erroneous memory references, the mechanisms described herein are applicable to other kinds of objects, such as global objects and objects allocated on the stack. Global objects can be protected by allocating a BI entry in the BI table for each global object in the program at program startup. Stack objects can also be protected. One way to protect stack objects is to add a preprocessing step that preprocesses the source language files (e.g., C and C++ files) that make up the program. The preprocessing of the source language files can involve static analysis of each function in the file to determine whether the function can call itself recursively, either directly or indirectly. If the function cannot call itself recursively, the preprocessing can involve editing the function to translate declarations of automatic objects in the function into static objects. Then, at program startup, BI entries for these static objects can be allocated in a manner similar to the allocation of BI entries for global objects described above. Objects in functions that can be called recursively can be handled in a different manner. In this case, in a separate processing step, the function prologue and epilogue can be edited to include code for allocating and freeing BI entries for each object in the function, or all recursive and non-recursive functions can be treated similarly, with the prologue and epilogue of each function edited to include code for allocating and freeing the appropriate BI entries.

[0095] It is also possible to prevent the use of uninitialized pointers by assigning them a null value (i.e., 0) when you define them, thus protecting your program from de-referencing bugs, where memory is read or written through the "garbage" of an uninitialized pointer.

[0096] Note that it is possible to build a program with or without the above mentioned protection mechanisms - for example, by using appropriate "make" flags, a program can be built without the protection mechanisms if desired, without incurring performance degradation.

[0097] As background information for understanding various aspects of the subject matter of the present disclosure, FIG. 27 and the following description outline a suitable environment in which various aspects of the subject matter of the present disclosure may be implemented. FIG. 27 illustrates a suitable operating environment 2700 for implementing various aspects of the subject matter of the present disclosure. The operating environment 2700 may include a computer 2712. The computer 2712 may also include a processing unit 2714, a system memory 2716, and a system bus 2718. The system bus 2718 connects system components including the system memory 2716 to the processing unit 2714. The processing unit 2714 may be any of a variety of available processors. Dual microprocessors and other multi-processor architectures may also be employed as the processing unit 2714. The system bus 2718 may be any of a number of types of bus structures. These bus structures include a memory bus or memory controller, a peripheral or external bus, or a local bus, or combinations thereof, using any of a variety of available bus architectures, including Industry Standard Architecture (ISA), Micro Channel Architecture (MSA), Enhanced ISA (EISA), Intelligent Drive Electronics (IDE), VESA Local Bus (VLB), Peripheral Component Interconnect (PCI), Card Bus, Universal Serial Bus (USB), Advanced Graphics Port (AGP), Firewire (IEEE 1394), and Small Computer System Interface (SCSI). The system memory 2716 may also include a volatile memory 2720 and a nonvolatile memory 2722. The basic input / output system (BIOS), containing the basic routines for transferring information between elements within the computer 2712, such as during start-up, is stored in the nonvolatile memory 2722. As an example, the non-volatile memory 2722 may include a ROM, a programmable ROM (PROM), an electrically programmable ROM (EPROM), an electrically erasable programmable ROM (EEPROM), flash memory, or a non-volatile RAM (e.g., a ferroelectric RAM (FeRAM)).The volatile memory 2720 can also include RAM that acts as external cache memory. By way of example, RAM is available in many forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), SyncLink DRAM (SLDRAM), Direct Rambus RAM (DRRAM), Direct Rambus Dynamic RAM (DRDRAM), and Rambus Dynamic RAM.

[0098] The computer 2712 may further include removable / non-removable and volatile / non-volatile computer storage media. For example, FIG. 27 illustrates disk storage 2724. Also, the disk storage 2724 may include devices such as, for example, a magnetic disk drive, a floppy disk drive, a tape drive, a Jaz drive, a Zip drive, an LS-100 drive, a flash memory card, or a memory stick. Also, the disk storage 2724 may include storage media used independently or in combination with other storage media including, for example, an optical disk drive. The optical disk drive may be, for example, a CD-ROM device, a CD-R drive, a CD-RW drive, or a DVD-ROM drive. To facilitate the connection of the disk storage 2724 to the system bus 2718, a removable or non-removable interface such as an interface 2726 is typically used. Also illustrated in FIG. 27 is software that acts as an intermediary between a user and the basic computer resources in the preferred operating environment 2700. Such software may include, for example, an operating system 2728. Operating system 2728, which may be stored on disk storage 2724, controls and allocates resources for the computer 2712. System applications 2730 take advantage of the resource management provided by operating system 2728 through program modules 2732 and program data 2734, which may be stored, for example, in system memory 2716 or on disk storage 2724. It is noted that the present disclosure may be implemented with various operating systems or combinations of operating systems. A user enters commands or information into the computer 2712 through input devices 2736. Examples of input devices 2736 include a pointing device such as a mouse, a trackball, a stylus, a touch pad, a keyboard, a microphone, a joystick, a game pad, a satellite dish, a scanner, a TV tuner card, a digital camera, a digital video camera, a webcam, and the like.These and other input devices are connected to the processing unit 2714 by the system bus 2718 through interface ports 2738. Examples of interface ports 2738 include serial ports, parallel ports, game ports, USB, etc. The output device(s) 2740 use some of the same types of ports as the input devices 2736. Thus, for example, a USB port may be used to provide input to the computer 2712 and to output information from the computer 2712 to the output device 2740. An output adapter 2742 is shown to illustrate that some output devices 2740, such as monitors, speakers, printers, among other output devices 2740, require their own adapters. The output adapter 2742 includes, for example, video cards and sound cards that serve as a means of connection between the output device 2740 and the system bus 2718. It is noted that other devices or systems of devices or combinations thereof provide both input and output capabilities, such as a remote computer 2744.

[0099] The computer 2712 can operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 2744. The remote computer 2744 can be a computer, a server, a router, a network PC, a workstation, a microprocessor-based device, a peer device or other common network node, and generally can include many or all of the elements described above for the computer 2712. For simplicity, only a memory storage device 2746 is shown with the remote computer 2744. The remote computer 2744 is logically connected to the computer 2712 through a network interface 2748 and then physically connected through a communication connection 2750. The network interface 2748 can include a wired and / or wireless communication network, such as a local area network (LAN), a wide area network (WAN), a cellular network, and the like. LAN technologies include Fiber Distributed Data Interface (FDDI), Copper Distributed Data Interface (CDDI), Ethernet, Token Ring, and the like. WAN technologies include, by way of example, point-to-point links, circuit-switched networks (e.g., Integrated Services Digital Networks (ISDN) and variations thereon), packet-switched networks, and Digital Subscriber Lines (DSL). Communications connection(s) 2750 refers to the hardware / software used to connect network interface 2748 to system bus 2718. Although communications connection(s) 2750 are shown for illustrative purposes internal to computer 2712, they may also be external to computer 2712. By way of example only, the hardware / software for connecting to network interface 2748 may include internal and external technologies such as modems, such as ordinary telephone modems, cable modems, DSL modems, and the like, ISDN adapters, and Ethernet cards.

[0100] The present invention may be a system, method or computer program product, or combination thereof, integrated at any possible level of technical detail. The computer program product may include a computer readable storage medium having computer readable program instructions stored thereon for causing a processor to carry out aspects of the present invention. The computer readable storage medium may be a tangible device capable of holding and storing instructions for use by an instruction execution device. The computer readable storage medium may be, by way of example, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or a suitable combination thereof. More specific examples of computer readable storage media include portable computer diskettes, hard disks, RAM, ROM, EPROM (or flash memory), SRAM, CD-ROM, DVD, memory sticks, floppy disks, mechanically encoded devices having instructions recorded on punch cards or ridge structures in grooves, or the like, and suitable combinations thereof. Computer readable storage devices as used herein should not be construed as ephemeral signals per se, such as electric waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a wave guide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or electrical signals transmitted through wires.

[0101] The computer readable program instructions described herein can be downloaded from a computer readable storage medium to each computer device / processing device. Alternatively, they can be downloaded to an external computer or external storage device via a network (e.g., the Internet, a LAN, a WAN, or a wireless network, or a combination thereof). The network can comprise copper transmission cables, optical transmission fiber, wireless transmission, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface in each computer device / processing device receives the computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium in the respective computer device / processing device. The computer readable program instructions for carrying out the operations of the present invention can be either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or source or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk and C++, and procedural programming languages ​​such as the "C" programming language and similar programming languages. The computer readable program instructions may execute entirely on the user's computer as a stand-alone software package, or partly on the user's computer, or partly on the user's computer and partly on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, including a LAN or WAN, or may be connected to an external computer (e.g., via the Internet using an Internet Service Provider).In some embodiments, electronic circuitry, including, for example, programmable logic circuitry, field programmable gate arrays (FPGAs), programmable logic arrays (PLAs), can execute computer readable program instructions by utilizing state information of the computer readable program instructions to customize the electronic circuitry for carrying out aspects of the present invention.

[0102] Aspects of the present invention are described herein with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present invention. Each block in the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, can be executed by computer-readable program instructions. The computer-readable program instructions can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine. These instructions executed via a processor of such computer or other programmable data processing apparatus create means for performing the functions / operations specified in one or more blocks in the flowcharts and / or block diagrams. The computer-readable program instructions can further be stored in a computer-readable storage medium capable of instructing a computer, programmable data processing apparatus, or other apparatus, or combination thereof, to function in a particular manner. The computer-readable storage medium having instructions stored thereon constitutes a product including instructions for performing aspects of the functions / operations specified in one or more blocks in the flowcharts and / or block diagrams. Also, computer-readable program instructions may be loaded into a computer, other programmable device, or other apparatus and a sequence of operations executed on the computer, other programmable device, or other apparatus to create a computer-implemented process, whereby the instructions executing on the computer, other programmable device, or other apparatus perform the functions / operations identified in one or more blocks in the flowcharts and / or block diagrams.

[0103] The flowcharts and block diagrams in the drawings of the present disclosure illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions for performing a specific logical function. In some other implementations, the functions shown in the blocks may be performed in a different order than the order shown in the figures. For example, two blocks shown in succession may actually be performed substantially simultaneously or in reverse order depending on the functions involved. It should be noted that each block in the block diagram and / or flowchart, and combinations of multiple blocks in the block diagram and / or flowchart, may be performed by a dedicated hardware-based system that performs a specific function or operation, or by a combination of dedicated hardware and computer instructions.

[0104] Although the subject matter has been described above in the general context of computer-executable instructions for a computer program product running on one or more computers, one skilled in the art will appreciate that the present disclosure may also be implemented in combination with other program modules. Program modules generally include routines, programs, components, data structures, etc. that perform particular tasks and / or implement particular abstract data types. Moreover, one skilled in the art will appreciate that the computer-implemented methods of the present invention may be implemented in other computer system configurations. These computer system configurations include computers, portable computing devices (e.g., PDAs and phones), microprocessor-based or programmable consumer or industrial electronic devices, as well as single or multi-processor computer systems, minicomputer devices, mainframe computers, and the like. The illustrated aspects may also be implemented in distributed computing environments where tasks are performed by remote processing devices linked through a communications network. However, some, if not all, aspects of the present disclosure may be implemented on stand-alone computers. In a distributed computing environment, program modules may be stored in both local and remote memory storage devices. For example, in one or more embodiments, computer-executable components may be executed from memory. The memory may include or consist of one or more distributed memory units. As used herein, the terms "memory" and "memory unit" are interchangeable. Furthermore, one or more embodiments described herein may execute code of computer-executable components in a distributed manner, e.g., multiple processors may combine or cooperate to execute code from one or more distributed memory units. As used herein, the term "memory" may encompass a single memory or memory unit in one location, or multiple memories or memory units in one or more locations.

[0105] As used herein, terms such as "component," "system," "platform," "interface," and the like may refer to and / or include computer-related entities or entities related to an operating machine having one or more particular functions. The entities disclosed herein may be either hardware, a combination of hardware and software, software, or software in execution. As an example, a component may be a process running on a processor, a processor, an object, an executable, a thread of execution, a program, or a computer, or a combination thereof. For example, both an application running on a server and the server may be a component. There may be one or more components in a process or thread of execution, or both. And, a component may be localized on one computer, distributed across two or more computers, or both. As another example, each component may execute from various computer-readable media having various data structures stored thereon. These components may communicate via local and / or remote processes, such as by pursuance of signals having one or more data packets (e.g., data from one component interacts with other components via signals within a local system, within a distributed system, or over a network (such as the Internet) with other systems, or a combination thereof). As yet another example, a component may be a device having a particular function realized by mechanical parts operated by electrical or electronic circuits operated by a software or firmware application executed by a processor. In such cases, the processor may be internal or external to the device and may execute at least a portion of the software or firmware application. As yet another example, a component may be a device that realizes a particular function via electronic components without mechanical parts.Here, an electronic component may include a processor or other means for executing software or firmware that provides at least a portion of the functionality of the electronic component. In one aspect, a component may emulate the electronic component via a virtual machine (e.g., within a cloud computing system).

[0106] Furthermore, the term "or" is intended to be used in an inclusive, not exclusive sense. That is, unless otherwise specified or clear from the context, when "X uses A or B," it is intended to mean any of the natural inclusive permutations. That is, when "X uses A," "X uses B," or "X uses both A and B," all of these examples apply to "X uses A or B." Furthermore, the articles "a" and "an" used in this specification and the accompanying drawings should generally be construed to mean "one or more," unless otherwise specified or clear from the context that they are intended to mean singular. Also, in this specification, the terms "example" and "exemplary" are used to mean content that is provided as an example, instance, or illustration. It is to be noted that the subject matter disclosed herein is not limited by such examples. Moreover, any aspect or design described herein as "example" or "exemplary" is not necessarily to be construed as preferred or advantageous over other aspects or designs, and is not intended to exclude equivalent exemplary structures and techniques known to those skilled in the art.

[0107] The term "processor" as used herein can refer to virtually any type of computer processing unit or device, including, for example, a single-core processor, a single processor with software multithreaded execution capabilities, a multi-core processor, a multi-core processor with software multithreaded execution capabilities, a multi-core processor with hardware multithreading techniques, a parallel platform, and a parallel platform with distributed shared memory. Additionally, a processor can refer to an integrated circuit designed to perform the functions described herein, an application specific integrated circuit (ASIC), a digital signal processor (DSP), a field programmable gate array (FPGA), a programmable logic controller (PLC), a complex programmable logic device (CPLD), discrete gate or transistor logic, discrete hardware components, or any combination thereof. Additionally, a processor can utilize nanoscale architectures, such as, for example, molecular and quantum dot-based transistors, switches, gates, etc., to optimize space usage or improve user equipment performance. A processor can also be implemented as a combination of computer processing units. In this disclosure, terms such as "store," "storage," "data store," "data storage," "database," and virtually any other information storage component term related to the operation and functionality of a component, are used to mean a "memory component," an entity embodied in a "memory," or a component that constitutes a memory. It is noted that the memory and / or memory components described herein may be either volatile or non-volatile memory, or may include both volatile and non-volatile memory. By way of example, non-volatile memory may include ROM, programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable ROM (EEPROM), flash memory, or non-volatile RAM (e.g., ferroelectric RAM (FeRAM)).Volatile memory may include RAM, which may function as an external cache memory, for example. By way of example, RAM is available in many forms, such as synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), SyncLink DRAM (SLDRAM), direct Rambus RAM (DRRAM), direct Rambus dynamic RAM (DRDRAM), and Rambus dynamic RAM (RDRAM). Additionally, the memory component in a system or computer-implemented method of the present disclosure is intended to include, but is not limited to, these and any other suitable types of memory.

[0108] The above description includes merely examples of systems and computer-implemented methods. Of course, in describing this disclosure, it is not possible to describe every conceivable combination of components or computer-implemented methods, but those skilled in the art will recognize that many further combinations and permutations of the present disclosure are possible. Furthermore, when terms such as "include," "have," and "possess" are used in the detailed description, claims, appendices, and drawings, such terms are intended to have an inclusive meaning, similar to the interpretation of "comprising" when used as a transitional phrase in the claims.

[0109] Various embodiments of the present invention have been described by way of example, but are not intended to be exhaustive or limited to these embodiments. As will be apparent to those skilled in the art, many modifications and variations are possible without departing from the scope and spirit of each of the described embodiments. The terms used in this specification are selected to best explain the principles of each embodiment, practical applications, or technical improvements to the technology recognized in the market, or to allow those skilled in the art to understand each embodiment disclosed in this specification.

Claims

1. 1. A system including a processor, The processor executes computer-executable components stored on a non-transitory computer-readable medium; The computer executable components include: an entry component that allocates an entry in a table for storing bounds information when an object is allocated in memory; a repurposing component that repurposes unused bits of an object address to store an index to an entry in said table; Including, the system.

2. a check component that performs bounds checking in hardware on load and store instructions by accessing the bounds information using index bits in an address. The system of claim 1 .

3. a propagation component that automatically propagates the index when subsequent object addresses are derived via assignment statements or pointer arithmetic. The system of claim 1 .

4. the checking component checks the bounds of the array; The system of claim 2.

5. the checking component determines whether an array reference is in-bounds or out-of-bounds and mitigates the occurrence of out-of-bounds array references; The system of claim 2.

6. the diversion component tracks a range of accessible memory addresses using unused bits in the object address; The system of claim 1 .

7. the propagation component propagates additional information in unused bits when the object address is copied into an assignment statement; The system of claim 3.

8. the propagation component propagates additional information in unused bits when the object address is passed as an argument to a function call; The system of claim 3.

9. the propagation component propagates additional information in unused bits when the object address is used in an address calculation; The system of claim 3.

10. A guard bit is interposed between the index bit and the address bit in the address. The system of claim 1 .

11. managing the boundary information stored in the table includes making changes to a memory allocation or freeing library function; The system of claim 1 .

12. if an application contains a number of active objects that exceeds the size of the table, or if the number of index bits required to support that number of active objects exceeds the number of allocated index bits, then a subset of the boundary information is stored in an overflow table. The system of claim 1 .

13. a check component that performs bounds checking in hardware on load and store instructions by accessing the bounds information in the subset of bounds information with an address if the address includes index bits that include a value that indicates the overflow table. The system of claim 12.

14. 1. A computer-implemented method, comprising: allocating, by a processor, an entry in a table for storing bounds information when an object is allocated in memory; repurposing unused bits of an object address to store an index to an entry in said table by the processor; A method comprising:

15. performing, by the processor, bounds checking in hardware on the load and store instructions by accessing the bounds information using index bits in the address; The method of claim 14.

16. automatically propagating, by the processor, the index when subsequent object addresses are derived via assignment statements or pointer arithmetic. The method of claim 14.

17. further comprising, by the processor, checking array bounds. The method of claim 15.

18. determining, by the processor, whether the array reference is in bounds or out of bounds; The method of claim 15.

19. and further comprising, by the processor, mitigating occurrences of out of bounds array references.

20. The method of claim 18.

20. and tracking, by the processor, a range of accessible memory addresses using unused bits in the object address. The method of claim 15.

21. and transmitting, by the processor, additional information in unused bits when the object address is copied into the assignment statement. The method of claim 15.

22. and conveying, by the processor, additional information in unused bits when the object address is passed as an argument to a function call. The method of claim 15.

23. and transmitting, by the processor, additional information in unused bits when the object address is used in an address calculation. The method of claim 15.

24. A computer processor comprising: allocating an entry in a table for storing bounds information when an object is allocated; repurposing unused bits of an object address to store an index to an entry in said table; A computer program for executing the following:

Images