Use memory-protected data

Abstract

This disclosure describes techniques and apparatus directed to using memory protected data (124, 126) in a computing device (102). The techniques include allocating regions (208, 210, 302, 304) of a memory (122) for storing application data (124) and protected data (126). The techniques also include creating a bitmap (130) having bit values ​​corresponding to memory blocks in the allocated regions (208, 210, 302, 304). The one or more bit values ​​can indicate whether the application data (124) and / or the protected data (126) are present in the memory block. The techniques and apparatus can enable efficient use of memory protections such as memory security (e.g., encryption) and memory safety (e.g., use of error correcting codes (ECC)) while allowing for non-contiguous memory allocations and without significant modification to the operating system.

Description

[Background technology]

[0001] background Security and functional safety are important design considerations for computing devices. Computing device designs can improve security using hardware that performs data encryption algorithms, hashing algorithms, anti-rollback counter (ARC) algorithms, for example. Similarly, computing device designs may use hardware that performs error correction code (ECC) algorithms to improve functional safety. Memory protection techniques may generally use protection data to ensure the integrity of application data stored in memory and accessible by the computing device hardware.

[0002] Existing memory protection techniques may impose overhead in terms of memory capacity and / or transaction bandwidth to and from the memory of a computing device. For example, for every 64 bytes of application data that a hashing algorithm must verify, 2 bytes may be consumed to store a hash digest of the memory contents. Similarly, for every 64 bytes of application data that an ECC algorithm must check and / or correct, 2 bytes may be consumed to store an ECC syndrome of the memory contents. In general, the size ratio of application data to protection data may depend on the desired strength of protection.

[0003] In some cases, a computing device design may require increasing the total memory allocation by up to 20% to employ protection data, such as hash digests and / or ECC syndrome data. Thus, incorporating protection data into a computing device without significantly impacting memory performance may be difficult.

[0004] This Background is provided to generally present the contents of the disclosure. Unless otherwise indicated herein, the material described in this section is not admitted, either explicitly or implicitly, to be prior art to the disclosure or the appended claims. Summary of the Invention [Means for solving the problem]

[0005] overview This disclosure describes techniques and apparatus for using memory protection data within a computing device. The described techniques include allocating a region of memory for storing application data and protection data. Such techniques also include creating a bitmap that indicates whether memory blocks within the allocated region contain application data and / or protection data. The techniques and apparatus can reduce memory overhead by reducing memory consumption and / or simplifying memory transactions within the computing device.

[0006] In some aspects, a method performed by a computing device is described that includes allocating a region of memory for storing application data and protection data, and creating a bitmap that includes bit values ​​indicating that the memory block includes at least one of the application data or the protection data. The method also includes protecting the application data with the protection data, the protecting step including using the bit values ​​to indicate that the memory block includes at least one of the application data or the protection data.

[0007] In another aspect, a computing device is described. The computing device includes a memory, a central processing unit (CPU), a protection engine, and a computer-readable storage medium (CRM). The CRM includes one or more modules of executable code that, when executed by the CPU, directs the computing device to perform a number of operations. The operations include calculating an amount of memory for storing application data and protection data, and allocating one or more regions of the memory to provide the calculated amount. The operations also include creating a bitmap of at least a portion of the memory that includes bit values ​​indicating that one or more memory blocks of the allocated region include at least one of the application data or the protection data. The operations further include provisioning the bitmap to the protection engine.

[0008] The accompanying drawings and the following description set forth the details of one or more implementations. Other features and advantages will become apparent from the description, drawings, and claims. This summary is therefore provided to introduce the subject matter that is further described in the detailed description. As such, the reader should not consider the summary to be describing essential features or describing limitations on the scope of the claimed subject matter.

[0009] Apparatus and techniques utilizing memory protection data, including application data and protection data for protecting the application data, are described with reference to the following drawings, in which like numbers are used to refer to like features and components throughout. [Brief description of the drawings]

[0010] [Figure 1] FIG. 1 illustrates an exemplary operating environment including a computing device that uses memory protected data, according to one or more aspects. [Diagram 2] FIG. 2 illustrates example details of a physical address space representing a memory, in accordance with one or more aspects. [Diagram 3] FIG. 11 illustrates other exemplary details of a physical address space representing a memory, according to one or more other aspects. [Figure 4] FIG. 1 illustrates an example system architecture that may use memory protection data, according to one or more aspects. [Diagram 5] FIG. 1 illustrates example details of computations and messages that may be communicated within a computing device using memory protection data, according to one or more aspects. [Figure 6] FIG. 1 illustrates an example methodology for using memory protection data techniques, according to one or more aspects. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] Detailed Description Summary This disclosure describes techniques and apparatus directed to using memory protection data within a computing device. The described techniques include allocating a region of memory for storing application data and protection data and creating a bitmap. The bitmap indicates which memory blocks within the allocated region contain application data and / or protection data. The techniques and apparatus can reduce memory overhead by reducing memory consumption and / or simplifying memory transactions within the computing device.

[0012] The security and functional safety of a computing device often depends on the integrity of the data supporting applications executed by the computing device's CPU. Applications that may require security and / or functional safety include, for example, banking applications, email applications, automobile control applications (e.g., controlling the braking system), etc. The data supporting the applications is typically stored in the computing device's memory, but the computing device may be compromised through mechanisms including malicious hacking, soft errors, and failure due to wear and tear.

[0013] There are existing memory protection strategies that can increase data integrity and are effective in improving the security and / or functional safety of applications being executed by a computing device. For example, the hardware of the computing device may perform data encryption, hashing, or ARC algorithms to improve the security of the data. Similarly, the hardware of the computing device may perform ECC algorithms to improve the functional safety of the data. These algorithms generally use the protected data to ensure the integrity of the application data.

[0014] There are also existing techniques for employing protection data in memory systems. However, each of these existing techniques has one or more drawbacks that adversely affect the performance of a computing device. A first drawback of existing techniques for using protection data includes the generation of additional overhead in terms of the capacity of memory of a computing device. For example, a technique may involve carving out a substantially contiguous memory area for application data to be protected and for protection data. A large contiguous memory area results in inefficient memory usage because the operating system of the computing device cannot adequately share memory between many applications. In the case of allocating contiguous memory for protection data, which may include hash digest data, ECC syndrome data, and application data, existing contiguous techniques may allocate up to 20% of the total memory capacity to protection data alone.

[0015] A second drawback of existing techniques for using protection data includes techniques that allow fragmented memory allocations to avoid allocations with large contiguous slices. However, these techniques reserve memory inefficiently and involve significant modifications to the memory management procedures of the operating system. For example, in this case, the slices for application data may be fragmented, but the slices for protection data are oversized to cover the entire memory system (thus simplifying algorithms that may map application data and / or protection data).

[0016] The reason for the large size is that these techniques reserve enough memory to store protection data for all application data that may eventually reside in the entire memory space, even if the actual amount of application data is likely to be significantly less during operation. A complete reservation for protection data is used by these techniques to place the protection data for any given application data. Furthermore, such techniques rely on modifying memory management procedures of the operating system. These modifications include reusing bits that may be reserved in page table entries to reflect whether application data is protected for a given page, appropriately updating page attributes during operation, and propagating signals that include memory attributes within the computing device. Thus, these techniques also require non-standard operating systems and may complicate memory management procedures.

[0017] A third drawback of existing techniques using protection data includes overhead associated with large amounts of memory transactions in a computing device. As an example, during execution of a memory protection algorithm, a protection engine of a computing device may first access memory to retrieve ECC syndrome data, and then, in a second separate operation, access memory to retrieve application data to be checked and corrected. These multiple memory accesses result in increased power consumption and memory latency, both of which can degrade computational performance.

[0018] Exemplary implementations at various levels of detail are described below with reference to associated figures. Exemplary implementations include (i) a method for creating a bitmap to indicate one or more memory blocks of an allocated memory region that stores application data or protection data, including memory blocks that co-locate application data and protection data, and (ii) a computing device having a protection engine that utilizes such a bitmap. The allocated memory region and the memory blocks may have different sizes. For example, the allocated memory region may include multiple memory blocks corresponding to an exemplary granularity of the bitmap. Alternatively, the allocated memory region and the memory blocks may have a common size, such as the size of a memory page (e.g., 4 kilobytes (4 KB) in some systems).

[0019] In contrast to existing techniques that may generally pre-allocate large blocks of contiguous memory to application data or protection data, the use of a bitmap allows for flexible, selectable allocation of fragmentable memory, reducing memory capacity used when implementing memory protection. The use of a bitmap also avoids modifications to the operating system's memory manager, since the hardware can refer to the bitmap to identify and manage which memory blocks contain protected application data or corresponding protection data. Furthermore, the bitmap allows memory allocations for protection data to occur as they are used, instead of using one oversized pre-allocation that is likely to be underutilized. Furthermore, the use of a bitmap to access memory protection data collocated within a given memory block of fragmented memory can improve operating speed and reduce power consumption, as opposed to existing techniques that may require multiple memory accesses across large blocks of contiguous memory. The combination of reduced memory capacity utilization, the ability to independently allocate memory portions for protection, increased speed, reduced power consumption, and / or simplified memory management processes for the operating system, individually and jointly, leads to an overall reduction in memory overhead.

[0020] The following description first describes an exemplary operating environment, followed by details of exemplary hardware and features for using protected data, followed by an exemplary method, and concludes with related exemplary aspects. This description may be applied generally to regions of memory having memory blocks, as well as techniques related to virtual and / or physical memory addressing. However, for clarity, consistency, and brevity, the description is presented in the context of pages of memory accessed using a physical address space (after translation from a virtual address space, if necessary).

[0021] Example Operating Environment 1 illustrates an exemplary operating environment 100 that includes a computing device 102 that employs memory data protection techniques. The computing device 102 is shown as a laptop computer, but may be a desktop computer, a server, a wearable device, an Internet of Things (IoT) device, an entertainment device, an automated driving system (ADS) device, a home automation device, other electronic devices, etc.

[0022] The computing device 102 includes a computer-readable storage medium (CRM) 104 and hardware 106. In the context of this description, the CRM 104 of the computing device 102 is a hardware-based storage medium that does not include a transitory signal or carrier wave. By way of example, the CRM 104 may include one or more of a read-only memory (ROM), a flash memory, a dynamic random access memory (DRAM), a static random access memory (SRAM), a disk drive, a magnetic medium, and the like. The CRM 104 may generally store a collection of software and / or drivers executable by the hardware 106, as described below.

[0023] The CRM 104 may store one or more modules that include executable code or instructions. For example, the CRM 104 may store applications 108, an operating system (O / S) kernel 110, a virtual machine monitor (VMM) 112, and protection drivers 114. The hardware 106 may include a CPU 116, a protection engine 118, a memory controller 120, and memory 122. In some cases, one or more portions of the CRM 104 and one or more elements of the hardware 106 may be combined onto a single integrated circuit (IC) device, such as a system-on-chip (SoC) IC device. In some implementations, the CRM 104 may store a collection of drivers, OS modules, or other software that executes on the hardware 106. Thus, this software may include, for example, the applications 108, the O / S kernel 110, the VMM 112, and / or the protection drivers 114.

[0024] The applications 108 stored within the CRM 104 may be applications for which security and / or functional safety are desired. Examples of applications 108 include banking applications, payment applications, email applications, automobile control applications (e.g., braking system applications), etc.

[0025] The O / S kernel 110 may include executable code that enables elements of the hardware 106 in the computing device 102 (e.g., the CPU 116, the protection engine 118, or the memory controller 120) to transact data with the memory 122 (e.g., read data from or write data to the memory). At runtime, as part of allocating pages in the memory 122 for computing operations, the O / S kernel 110 may identify physical addresses of one or more portions of the memory 122 (e.g., pages in the memory 122). Alternatively, the O / S kernel 110 may identify a virtual memory address and allow another module or physical component (e.g., a virtual memory manager (not explicitly shown), the memory controller 120, or the protection engine 118) to calculate the corresponding physical address.

[0026] The VMM 112, sometimes referred to as a hypervisor, may interact with one or more operating systems in the computing device 102. In some cases, the VMM 112 may include executable code for calculating an amount of memory 122 that is subject to one or more techniques that use memory protection data.

[0027] The protection driver 114 may also include executable code. The protection driver 114 may enable provisioning of data to the protection engine 118, provisioning of bitmaps to the protection engine 118, or other communication with the protection engine 118. Such data may include, for example, physical addresses of pages in memory 122 that contain memory protection data, or bitmaps that correspond to pages in memory 122 that contain memory protection data.

[0028] The CPU 116 may include logic for executing instructions or code of the modules of the CRM 104. The CPU 116 may include a single-core processor or a multi-core processor constructed of various materials such as silicon, polysilicon, high-K dielectrics, copper, etc. The CPU 116 may instruct the computing device 102 to perform operations using the memory protection data by executing one or more of the modules (e.g., applications 108, O / S kernel 110, VMM 112, protection driver 114).

[0029] The protection engine 118 may be communicatively coupled to the memory controller 120 and may include logic for executing one or more protection algorithms (e.g., data encryption, hashing, ARC, ECC) during memory protection data transactions (e.g., reads, writes) with the memory 122.

[0030] In some cases, the protection engine 118 may include an on-chip cache. The on-chip cache may be used as part of the memory protection data techniques described in more detail below to store copies of the physical addresses of pages or copies of the bitmap, or copies of portions of the bitmap. In some cases, the store operations may depend on the size of the on-chip cache and / or the cache line size.

[0031] The memory 122 may be formed from an IC device and may include a type of memory, such as dynamic random access memory (DRAM) memory, double data rate DRAM (DDR DRAM) memory, flash memory (e.g., NOR, NAND), static random access memory (SRAM), etc. In some cases, the memory 122 may be part of a memory module, such as a dual in-line memory module (DIMM). In other cases, the memory 122 may be a separate IC device or embedded on another IC device (e.g., a SoC IC device). In some implementations, the memory 122 may include at least a portion of the CRM 104. Additionally or alternatively, at least a portion of the code or data stored in the CRM 104 may be copied into the memory 122 for execution or manipulation by the hardware 106.

[0032] The memory protection data techniques are implemented by code or data that may be stored at least initially in the CRM 104, and the hardware 106 may include allocating respective pages of the memory 122 for the memory protection data (e.g., application data 124 that may be associated with the application 108, and protection data 126 that may include hash digest data, ECC syndrome data, etc., of the corresponding application data 124). In allocating the pages, the CRM 104 and the hardware 106 may rely on a physical address space 128 that is mapped to the physical addresses of the pages in the memory 122. In some instances, in support of the memory protection data techniques, the CRM 104 and one or more elements of the hardware 106 (e.g., one or more of the CPU 116, the protection engine 118, or the memory controller 120) may manipulate the physical addresses of the memory protection data (e.g., including both the application data 124 or the protection data 126) to combine the memory protection data into the same page. This manipulation may include mapping / remapping addresses to adjust the physical location of the data, translating physical addresses to channels, rows, banks, or columns of memory 122, etc. In such cases, this manipulation may avoid memory page conflicts.

[0033] These techniques may also include allocating respective pages of memory 122 for bitmap 130 and updating one or more corresponding bits of bitmap 130. Bitmap 130 may indicate pages in memory 122 that are allocated to store memory protection data (e.g., application data 124 or protection data 126). For example, algorithms of VMM 112 may create bitmap 130 by associating a bit value of "1" with physical addresses of pages of memory 122 that are allocated to store memory protection data. Complementarily, algorithms of VMM 112 may associate a bit value of "0" with physical addresses of other pages of memory 122 that are not allocated to store memory protection data. Thus, at least one bit of bitmap 130 may correspond to a memory block of memory 122. In some cases, the memory block may have the same size as a page of memory.

[0034] The memory protection engine 118 may receive a memory transaction command for the application data 124 that includes a system view of the physical address of the page of memory 122. The protection engine 118 may then convert the physical address into a manipulated physical address that offsets the physical address of the application data 124 by the required amount to the protection data 126. The protection engine 118 may use the bitmap 130 to determine that the page stores memory protection data (e.g., one or more of the application data 124 and / or the protection data 126) and, based on the determination, execute the memory transaction command with the page. However, the bitmap 130 may instead map the system view of the physical address of the page to indicate whether the page stores memory protection data (e.g., the application data 124 and / or the protection data 126).

[0035] As described in more detail below, memory protection data techniques using application data 124, protection data 126, and bitmap 130 may reduce memory overhead incurred by computing device 102 as it performs functions to ensure the security and / or functional safety of application data 124. This reduction in memory overhead may improve the overall efficiency of computing device 102, for example, in terms of more efficient use of memory 122 and increased overall computational speed.

[0036] Example Hardware and Functionality Details FIG. 2 illustrates example details 200 of a physical address space representing a memory according to one or more aspects. The physical address space may correspond to physical address space 128 that maps the physical locations of pages in memory 122 of FIG. 1. FIG. 2 also illustrates that application data 124 and protection data 126 may be co-located in one or more fragmented pages in memory 122 (e.g., using a "mixed mapping"). According to the example details 200 of FIG. 2, memory protection data techniques may reduce memory 122 usage and require fewer transactions, thereby realizing reduced memory overhead and avoiding the need for modifications to the memory management procedures of the operating system.

[0037] In general, the architecture of memory 122 may include one or more channels 202. Additionally, pages within memory 122 may be identified using physical addresses 204 of physical address space 128. Elements of computing device 102 of FIG. 1 (e.g., CRM 104 and elements of hardware 106) may allocate regions of memory 122 (e.g., data ranges such as pages) for storing memory protection data (e.g., application data 124 and / or protection data 126) using physical addresses 204 of physical address space 128.

[0038] Memory protection data techniques may use fragmented (e.g., non-contiguous) pages within memory 122. For example, as illustrated in Figure 2, pages 206 and 208 may each contain different permutations of application data 124 and protection data 126. However, as illustrated, pages 206 and 208 are separated by page 210 and are therefore fragmented.

[0039] Memory protection data techniques may also co-locate portions of the application data 124 and the protected data 126 within one or more pages of the memory 122. Additionally, transactions associated with co-locating the application data 124 and the protected data 126 may include interleaving across multiple memory blocks (e.g., pages) and / or one or more channels 202 of the memory 122. The application data 124 and the protected data 126 may further be interleaved such that the application data 124 and corresponding protected data 126 may be co-located within the same bank, same row, etc. of the memory 122, thereby reducing page contention that may arise when accessing the protected data 126.

[0040] In some cases, the pages of memory 122 allocated for bitmap 130 may be contiguous. For example, as illustrated in Figure 2, page 212 and page 214 may be allocated for storage of bitmap 130. As illustrated, page 212 and page 214 are adjacent to one another and therefore contiguous.

[0041] The amount of memory 122 allocated to store application data 124, protection data 126, and bitmap 130 may depend on the size of memory 122 and the fragmentation granularity selected. As an example, if memory 122 corresponds to 4 gigabytes (GB) of memory and a page size of 4 kilobytes (KB) is selected as the allocation granularity, then one bit per available fragmented page (e.g., one bit per each 4 KB page in the available 4 GB memory) may be allocated for bitmap 130 (e.g., a 1 MB contiguous amount of memory of the available 4 GB memory may be allocated to store bitmap 130). When a request is received, any amount of fragmented memory of the remaining available 4 GB of memory may be allocated to store application data 124 or protection data 126 of the application to be protected. A certain amount of fragmented memory may also be allocated for application data of other applications not to be protected. There is no need to reserve a particularly large contiguous area.

[0042] 2, fragmentation of pages allocated for storing application data 124 and protection data 126 can reduce memory overhead by decreasing the amount of memory 122 consumed by computing device 102 while performing memory protection data operations. Using the exemplary fragmentation technique described above, enabling memory data protection (e.g., ECC protection) can allocate 1 MB of memory 122 for bitmap 130 (e.g., slightly more than 1 MB of memory 122) and 0.03 MB of memory 122 for protection data 126. In contrast, other techniques that allocate memory proportionally for memory protection data based on the size of memory 122 might allocate 128 MB of memory 122 for protection data.

[0043] 2 generally reduces memory overhead by reducing the amount of protection data 126 that a computing device consumes while performing memory protection data operations. Additionally, generally, co-locating application data 124 and protection data 126 within respective pages (e.g., respective channels, banks, or rows) reduces memory transactions within computing device 102, which may lead to further reductions in memory overhead.

[0044] 3 illustrates another example detail 300 of a physical address space according to one or more other aspects. The physical address space may correspond to the physical address space 128 representing the memory 122 of FIG. 1. FIG. 3 also illustrates an instance where the application data 124 and the protection data 126 may be separated across one or more fragmented pages in the memory 122 (e.g., using "separate mappings"). According to the example detail 300 of FIG. 3, the memory protection data technique may reduce memory 122 usage, achieving reduced memory overhead and avoiding the need for modifications to the memory management procedures of the operating system.

[0045] In general, as previously described in Figure 2, the architecture of memory 122 may include one or more channels 202. Additionally, pages in memory 122 may be identified using physical addresses 204 of physical address space 128. Elements of computing device 102 (e.g., CRM 104 and elements of hardware 106) of Figure 1 may allocate pages of memory 122 for storing memory protection data (e.g., application data 124 and / or protection data 126) according to physical address space 128. The memory protection data techniques described below may reduce overhead by decreasing memory consumption within computing device 102.

[0046] As illustrated in Figure 3, memory protection data techniques may use fragmented (e.g., non-contiguous) pages in memory 122. For example, as illustrated in Figure 3, page 302 and page 304 are separate and non-contiguous. Thus, the operating system can efficiently manage multiple memory allocations from various applications.

[0047] 2 above, pages 302 and 304 do not co-locate application data and protection data within the page. For example, page 302 contains application data 124 but not protection data 126. Conversely, page 304 contains protection data 126 but not application data 124. Typically, pages containing memory protection data are fragmented, but in these implementations, application data 124 and protection data 126 are not co-located within the page.

[0048] 3 may also use contiguous pages in memory, for example pages 306 and 308 containing bitmap 130 are contiguous.

[0049] As with FIG. 2 above, the amount of memory 122 in FIG. 3 allocated for bitmap 130 may depend on the size of memory 122 and the selected fragmentation granularity. As an example, if memory 122 corresponds to 4 gigabytes (GB) of memory and fragmentation is based on a selected 4 kilobyte (KB) granularity (e.g., fragmented page size), then one bit per available fragmented page (e.g., one bit per each 4 KB page in the available 4 GB memory) may be allocated for bitmap 130 (e.g., an amount of 1 MB of the available 4 GB would be allocated for bitmap 130). When an application request is received, any amount of fragmented memory may be allocated from the remaining available memory to store application data 124 or protection data 126 of various applications requiring protection (and to store application data 124 of other applications for which memory data protection is not desired). There is no need to reserve a particularly large contiguous region.

[0050] 3, fragmentation of pages allocated to store application data 124 and protection data 126 can reduce memory overhead by reducing the amount of memory 122 consumed by computing device 102 while performing memory protection data operations. Although not shown as such in FIG. 2 or FIG. 3, some computing device implementations may include both features. Thus, a computing device may include some memory allocations that collocate application data 124 and protection data 126 and other memory allocations that separate application data 124 and protection data 126 into different pages, channels, banks, or rows.

[0051] 4 illustrates an example system architecture 400 that may implement techniques that use memory protected data. System architecture 400 may be an architecture that uses elements of CRM 104 and hardware 106 of FIG.

[0052] 4 may include an SoC IC device 402. The SoC IC device 402 may be formed of logic and memory integrated circuits that perform one or more functions of the hardware 106 (e.g., may execute logic for the CPU 116, protection engine 118, and / or memory controller 120) and / or store data with the CRM 104 (e.g., store the applications 108, O / S kernel 110, VMM 112, and / or protection drivers 114). As shown, one or more internal buses 404 may communicatively couple the operating elements of the SoC IC device.

[0053] The system architecture 400 may also include a memory module 406. The memory module 406 may include a memory integrated circuit that performs one or more functions of the hardware 106 (e.g., stores memory protection data in the memory 122). For example, the memory module 406 may include a dual in-line memory module (DIMM) with one or more components including the memory 122 attached, or the memory may be implemented using package-on-package (PoP) low power double data rate (DDR) (LP-DDR) memory. As part of the system architecture 400, an external memory bus 408 (e.g., edge connector, socket, conductive traces) may communicatively couple the memory 122 of the memory module 406 to the memory controller 120 of the SoC IC device 402.

[0054] In general, system architecture 400 may support various operations directed to using memory protection data. For example, system architecture 400 may support operations including calculating an amount of memory 122 directed to store application data and protection data (e.g., application data 124 and protection data 126 of FIGS. 1-3), allocating pages of memory 122 (e.g., one or more of pages 206 and 208 of FIG. 2, or one or more of pages 302 and 304 of FIG. 3) to provide the calculated amount, creating a bitmap of memory 122 (e.g., bitmap 130 of FIGS. 1-3), and provisioning the bitmap to protection engine 118.

[0055] Although system architecture 400 includes an SoC IC device 402 and a memory module 406, many different arrangements of the CRM 104 and elements of hardware 106 are possible. For example, in contrast to a configuration that includes an SoC IC device 402 and a memory module 406, the CRM 104 and elements of hardware 106 may use various combinations of individual IC dies and / or components, system-in-package (SIP), etc., which may be distributed across at least one printed circuit board (PCB) located in different portions of a server rack, etc.

[0056] 5 illustrates example details 500 of operations performed by and messages communicated within a computing device using memory protection data techniques according to one or more aspects. A CPU of a computing device (e.g., CPU 116 of computing device 102 of FIG. 1 ) may perform operations (e.g., calculations) and transactions through execution of code of modules stored in CRM 104 of FIG. 1 , including applications 108, O / S kernel 110, VMM 112, and / or protection drivers 114. For simplicity, in the following description of FIG. 5 , references to a module performing an operation or communicating a message should be understood to correspond to the computing device performing an operation or communicating a message as a result of the CPU executing instructions stored in the module.

[0057] In message 502, application 108 communicates an application memory target to VMM 112. Message 502 is an application memory target message and may include a parameter indicating an amount of memory intended for application data (e.g., a first amount of memory 122 intended for storing application data 124 of FIG. 1 by the computing device).

[0058] At operation 504, the VMM 112 determines an amount of memory intended for storing protection data based on the requested application data (e.g., calculates a protection data amount). For example, parameters included in message 502 may indicate to the VMM 112 that the application data should be protected. If it is determined that the application data should be protected, the VMM 112 may calculate additional memory intended for protection data (e.g., a second amount of memory 122 intended for storing protection data 126 of FIG. 1 by the computing device). The VMM 112 may then sum the amounts (e.g., combine the first amount intended for application data 124 with the second amount intended for protection data 126) to determine a total amount of memory (e.g., calculated memory protection data amount) intended for the computing device to store memory protection data (e.g., store application data 124 and protection data 126).

[0059] In message 506, the VMM 112 communicates with the O / S kernel 110. Message 506 is a protection request message and includes a request to the O / S kernel 110 to allocate an amount of memory protection data.

[0060] At operation 508, O / S kernel 110 allocates a first set of pages of memory for memory-protected data. This allocation is effective to provide to the computing device or reserve within the computing device an amount of memory intended for the computing device to store memory-protected data. As part of allocating the first set of pages of memory, O / S kernel 110 may create a list of physical addresses (e.g., a list of physical addresses 204 from physical address space 128) that correspond to fragmented pages in memory (e.g., one or more of pages 206 and 208 of FIG. 2, or one or more of pages 302 and 304 of FIG. 3).

[0061] In message 510, O / S kernel 110 communicates with VMM 112. Message 510 may be a protection address message and may include a list of physical addresses of a first set of pages that are allocated for the computing device to store memory protection data.

[0062] In operation 512, the VMM 112 calculates an amount of memory to be reserved for the bitmap (e.g., the third amount of memory 122 targeted for bitmap 130 of FIGS. 1-3). The amount of memory targeted for the bitmap may depend on the size of memory 122 and the fragmentation granularity in the memory (e.g., amount of memory blocks, such as number of available pages). The amount of memory for the bitmap may also be based on the amount of bits per memory block. For example, if more than two states (e.g., more than just protected and unprotected) or additional information for the memory blocks (e.g., type or kind of protection) are kept in the bitmap, each memory block may correspond to 2 bits, 5 bits, etc. of the bitmap. Each bit or at least one bit each may correspond to a memory block of the memory.

[0063] In message 514, VMM 112 communicates with O / S kernel 110. Message 514 is a bitmap request message and includes a request to O / S kernel 110 to allocate an amount of memory intended for the computing device to store the bitmap. In some cases, the bitmap request message may include a parameter indicating that the allocation should be from a contiguous region of memory rather than a fragmented region of memory. A physically contiguous memory allocation can simplify the operation of memory controller 120 when accessing bitmap 130.

[0064] At operation 516, O / S kernel 110 allocates a second set of pages of memory for the bitmap. This allocation is effective to provide to the computing device or reserve within the computing device an amount of memory intended for the computing device to store the bitmap. As part of allocating the pages of memory, O / S kernel 110 may allocate a contiguous region of memory (e.g., one or more of pages 212 and 214 of FIG. 2, or one or more of pages 306 and 308 of FIG. 3) based on parameters included in the bitmap request message.

[0065] In message 518, O / S kernel 110 communicates with VMM 112. Message 518 may be a bitmap address message and may include the physical addresses of the second set of pages allocated for the computing device to store the bitmap.

[0066] In operation 520, the VMM 112 may create a bitmap (e.g., bitmap 130). In creating the bitmap, the VMM 112 may associate one or more bit values ​​with the physical addresses received through message 510 to indicate pages in which memory protection data may be stored. Unlike applications 108, which may use virtual addressing techniques, the VMM 112 may create the bitmap using physical addresses to enable use by a memory controller (e.g., memory controller 120 of FIG. 1) that can operate on physical memory addresses.

[0067] In message 522, the VMM 112 communicates with the protection driver 114. The message 522 is a bitmap message and includes or provides a reference to the bitmap. Communicating the bitmap to the protection driver 114 may enable the protection driver 114 to provision the bitmap and / or physical addresses of pages allocated for memory protection data to a protection engine (e.g., the protection engine 118 of FIG. 1). This may include, in some cases, writing the bitmap and / or physical addresses to an on-chip cache of the protection engine. The protection engine may then perform memory protection techniques including transacting the memory protection data and executing one or more memory protection algorithms.

[0068] 5 illustrates a combination of modules in a CRM of a computing device that performs a set of operations (e.g., computations) and message exchanges that support memory-protected data techniques, the combination of modules and set of operations may be performed in part or in whole using other combinations of modules and / or computing resources. In some cases, the other combinations of modules may not be part of the computing device (e.g., may be included in a separate CRM that is part of a server communicatively coupled to the computing device 102).

[0069] Exemplary Methods 6 illustrates an example method 600 for using memory protection data techniques according to one or more aspects. In some cases, method 600 may be performed by a computing device using the aspects of Figures 1-5. The operations described may be performed with other operations, in alternative orders, in a fully or partially overlapping manner, etc.

[0070] At operation 602, a computing device (e.g., CPU 116 executing code of O / S kernel 110 as illustrated at operation 508 in FIG. 5 ) allocates a region of memory (e.g., memory 122) for storing application data and protection data (e.g., application data 124 and protection data 126). In some cases, allocating the region of memory may include allocating pages that are fragmented in memory (e.g., pages 206, 208, 302, or 304 of memory 122). In other cases, allocating the region of memory may include allocating pages from a contiguous memory region (e.g., pages 306 and 308 of memory 122).

[0071] At operation 604, a computing device (e.g., CPU 116 executing code of VMM 112 as illustrated in operation 520 of FIG. 5) creates a bitmap (e.g., bitmap 130). The created bitmap includes bit values ​​indicating that a memory block includes at least one of application data or protection data. The memory block is included in at least one of the allocated regions (e.g., the memory block corresponds to or is included in pages 206, 208, 302, or 304). The bitmap may include multiple bits, each having at least one bit value. A given memory block of the allocated memory region respectively corresponds to at least one bit value of the multiple bits of the bitmap.

[0072] In operation 606, the computing device (e.g., protection engine 118 executing a protection algorithm) protects the application data using the protection data. Protecting the application data includes using bit values ​​of a bitmap to indicate that a memory block (e.g., of at least one allocated region) contains at least one of application data or protection data. In some cases, such as when the application data and protection data are co-located, the memory block may contain both application data and protection data.

[0073] In some cases, method 600 may further include storing the application data and the protection data by placing the application data and the protection data in separate regions of the allocated region (e.g., placing application data 124 in page 302 and protection data 126 in page 304 as illustrated in FIG. 3). The separate regions may be fragmented regions of memory (e.g., page 302 and page 304 are fragmented pages separated by one or more pages allocated to at least one other application).

[0074] In instances where the application data and protection data are located in separate regions, the physical address of a first region containing the protection data (e.g., physical address 204 of page 304 containing protection data 126) may be determinable using one or more offsets from the physical address of a second region containing the application data (e.g., physical address 204 of page 302 containing application data 124). Such offsets may be fixed or may be determinable based on the size of the allocated region, the size ratio of application data 124 to protection data 126 (e.g., 2 bytes of protection data 126 for every 64 bytes of application data 124), etc.

[0075] In other cases, method 600 may further include storing the application data and the protection data by co-locating the application data and the protection data within at least one allocated region, which may be a fragmented region of memory (e.g., co-locating application data 124 and protection data 126 within page 206 as illustrated in FIG. 2). An allocated region may be a fragmented region of memory (e.g., a block of memory such as page 206, which is a fragmented page).

[0076] In cases where the application data and protection data are co-located, co-locating the application data and protection data may include interleaving the application data and protection data across multiple memory blocks and / or channels (e.g., channel 202) of the memory including respective banks or rows of memory.

[0077] In general, for the aforementioned example variations of method 600, protecting the application data may include executing one or more algorithms using the protection data and the application data (e.g., execution by protection engine 118 of the algorithm). Examples of such algorithms include an error correcting code (ECC) algorithm, an anti-rollback counter (ARC) algorithm, a data encryption algorithm, or a hashing algorithm.

[0078] The foregoing description describes methods related to reducing memory overhead of a computing device using memory protected data. Aspects of these methods may be implemented in hardware (e.g., fixed logic circuitry), firmware, software, or any combination thereof. As an example, one or more operations described in method 600 may be performed by a computing device having one or more processors and a CRM. In such cases, the processor in conjunction with the CRM may include fixed or hard-coded circuitry, finite state machines, programmed logic, etc., that perform one or more operations.

[0079] Additionally, these techniques may be implemented using one or more of the entities or components shown in Figures 1-5, which may be further divided, combined, etc. These figures thus illustrate some of the many possible systems or apparatuses in which the described techniques may be employed. The entities and components in these figures generally represent all or part of software, firmware, hardware, devices or networks, or combinations thereof.

[0080] Additional Examples Example 1: A method performed by a computing device, the method including the steps of allocating multiple regions of memory, at least one of the allocated regions for storing application data and protection data; creating a bitmap including bit values ​​indicating that a memory block contains at least one of the application data or the protection data, at least one of the allocated regions including the memory block; and protecting the application data with the protection data, the protecting step including using the bit values ​​of the bitmap to indicate that the memory block contains at least one of the application data or the protection data.

[0081] Example 2: The method of Example 1, further comprising storing the application data and the protection data by placing the application data and the protection data in separate areas of the allocated regions, the separate areas comprising fragmented areas of memory.

[0082] Example 3: The method of example 2, wherein the physical address of the first separate region that includes the protection data is determinable using one or more offsets based on the physical address of the second separate region that includes the application data.

[0083] Example 4: The method of Example 1, further comprising storing the application data and the protection data by co-locating the application data and the protection data within the allocated area.

[0084] Example 5: The method of example 4, wherein co-locating the application data and the protection data within the allocated region includes interleaving the application data and the protection data across multiple memory blocks.

[0085] Example 6: The method of example 4, wherein co-locating the application data and the protection data within the allocated region includes interleaving the application data and the protection data across multiple memory blocks.

[0086] Example 7: The method of any one of examples 1 to 6, wherein the memory block corresponds to a page of memory.

[0087] Example 8: The method of any one of Examples 1 to 7, wherein the step of protecting the application data includes performing at least one of an error correcting code (ECC) algorithm, an anti-rollback counter (ARC) algorithm, a data encryption algorithm, or a hashing algorithm using the protection data and the application data.

[0088] Example 9: A computer-readable storage medium comprising computer-executable instructions that, when executed by a computing device, cause the computing device to perform a method according to any one of the preceding claims.

[0089] Example 10: A computing device comprising one or more central processing units and the computer-readable storage medium of Example 9.

[0090] Example 11: A computing device comprising a memory, a central processing unit, a protection engine, and a computer-readable storage medium, the computer-readable storage medium storing one or more modules of executable code which, when executed by the central processing unit, instructs the computing device to perform operations of calculating an amount of memory for storing application data and protection data, allocating one or more regions of the memory to provide the calculated amount, creating a bitmap of at least a portion of the memory, the bitmap including bit values ​​indicating that one or more memory blocks of the allocated region contain at least one of application data or protection data, and provisioning the bitmap to the protection engine.

[0091] Example 12: A computing device as described in Example 11, wherein the protection engine includes logic configured to receive a memory transaction command including a physical address, the physical address corresponding to a memory block within an allocated region of memory, the logic further configured to use the bitmap to determine that the memory block stores at least one of application data or protection data, and based on the determination, execute the memory transaction command using the memory block.

[0092] Example 13: A computing device as described in Example 11 or Example 12, wherein the protection engine is configured to access the application data and / or the protection data stored in the memory via the memory controller.

[0093] Example 14: A computing device according to any one of Examples 11 to 13, wherein one or more elements of hardware of the computing device are configured to manipulate addresses to combine application data and protection data in the same region.

[0094] Example 15: The computing device of any one of Examples 11 to 14, wherein the memory includes double data rate random access memory (DDR RAM).

[0095] Example 16: A computing device described in any one of Examples 11 to 15, wherein the central processing unit, the protection engine, and the computer-readable storage medium storing one or more modules of executable code are included on a system-on-chip (SoC) integrated circuit device.

[0096] Example 17: A computing device according to any one of Examples 11 to 16, wherein the protection engine includes an on-chip cache configured to store at least a copy of the bitmap.

[0097] Although implementations have been described with apparatus and methods that enable the use of memory-protected data in a manner that reduces memory overhead on a computing device, the subject matter of the appended claims is not necessarily limited to the particular features or methods described. Rather, the particular features and methods are disclosed as example implementations for using memory-protected data in a manner that reduces memory overhead on a computing device.

Claims

1. A method (600) performed by a computing device (102), the method (600) comprising: allocating (602) a plurality of regions (208, 210, 302, 304) of a memory (122), at least one allocated region (208, 210, 302, 304) for storing application data (124) and protection data (126); creating (604) a bitmap (130) including bit values ​​indicating that a memory block contains at least one of said application data (124) or said protection data (126), said at least one allocated region (208, 210, 302, 304) including said memory block; and protecting (606) the application data (124) with the protection data (126), the protecting step including using the bit value of the bitmap (130) to indicate that the memory block contains at least one of the application data (124) or the protection data (126).

2. 2. The method of claim 1, further comprising storing the application data and the protection data by locating the protection data in a first region of the allocated plurality of regions and locating the application data in a second region of the allocated plurality of regions different from the first region, the first and second regions comprising fragmented regions of the memory.

3. 3. The method of claim 2, wherein the physical address of the first region containing the protection data is determinable using one or more offsets based on the physical address of the second region containing the application data.

4. The method of claim 1 , further comprising storing the application data and the protection data by co-locating the application data and the protection data within an allocated area.

5. 5. The method of claim 4, wherein co-locating the application data and the protection data within the allocated region comprises interleaving the application data and the protection data across multiple memory blocks.

6. 5. The method of claim 4, wherein co-locating the application data and the protection data within the allocated region comprises interleaving the application data and the protection data across multiple channels of the memory.

7. 7. The method of claim 1, wherein the memory block corresponds to a page of the memory.

8. 8. The method of claim 1, wherein protecting the application data includes performing at least one of an error correcting code (ECC) algorithm, an anti-rollback counter (ARC) algorithm, a data encryption algorithm, or a hashing algorithm using the protection data and the application data.

9. A computer program (104) comprising computer executable instructions (108, 110, 112, 114), which when executed by a computing device (102) causes the computing device (102) to perform a method according to any one of claims 1 to 8.

10. one or more central processing units (116); A computer readable storage medium (104) storing the program according to claim 9; A computing device (102) comprising:

11. A computing device (102), A memory (122); A central processing unit (116); A protection engine (118); and a computer-readable storage medium (104) storing one or more modules of executable code (108, 110, 112, 114) that, upon execution by the central processing unit (116), cause the computing device (102) to: An operation of calculating (504) an amount of said memory (122) for storing application data (124) and protection data (126); an act of allocating (508) one or more regions (208, 210, 302, 304) of said memory (122) to provide said calculated amount; an act of creating (520) a bitmap (130) of at least a portion of the memory (122), the bitmap including bit values ​​indicating that one or more memory blocks of the allocated region (208, 210, 302, 304) contain at least one of the application data (124) or the protection data (126); Provisioning the bitmap (130) to the protection engine (118). The computing device (102) is instructed to execute the following:

12. The protection engine includes logic, the logic comprising: configured to receive a memory transaction command including a physical address, the physical address corresponding to a memory block within the allocated region of the memory; The logic further comprises: using the bitmap to determine that the memory block stores at least one of the application data or the protection data; The computing device of claim 11 , configured to execute the memory transaction command using the memory block based on the determining.

13. The computing device of claim 11 or 12, wherein the protection engine is configured to access the application data and / or the protection data stored in the memory via a memory controller.

14. 14. A computing device according to claim 11, wherein one or more elements of hardware of the computing device are configured to manipulate addresses to combine the application data and the protection data in the same area.

15. 15. The computing device of claim 11, wherein the memory comprises double data rate random access memory (DDR RAM).

16. 16. The computing device of claim 11, wherein the central processing unit, the protection engine, and the computer-readable storage medium storing the one or more modules of executable code are comprised on a system-on-chip (SoC) integrated circuit device.

17. 17. The computing device of claim 11, wherein the protection engine includes an on-chip cache configured to store at least a copy of the bitmap.

Images