Patent Description:
Existing memory protection techniques may impact overhead in terms of a capacity of a memory and/or a transaction bandwidth with the memory of the computing device. For example, two bytes for storing a hash digest of memory contents may be consumed for every <NUM> bytes of application data that a hashing algorithm is tasked with verifying. Similarly, two bytes for storing an ECC syndrome of memory contents may be consumed for every <NUM> bytes of application data that an ECC algorithm is tasked with checking and/or correcting. In general, a size ratio of application data to protection data may be dependent on a desired strength of protection.

In some instances, a design of a computing device may require increasing allocations of a total capacity of a memory by up to <NUM>% to employ protection data such as a hash digest and/or ECC syndrome data. It can therefore be challenging to incorporate protection data into a computing device without appreciably impacting memory performance.

<CIT> discloses a method for protecting memory under multi-process execution environment in real-time. The method comprises the steps of: (a) setting an area to be managed by software paging on a memory, dividing the allocated area into pages with the same size, setting a map table by a pointer relative to the divided pages, forming a memory map list structure to each page, and initializing bitmaps of all pages; (b) allocating a free block suitable for a required size by searching free lists and allowing an operating system to allocate a protective memory area to data required to be managed by obtaining the allocated memory from the free lists and returning addresses; (c) removing the allocated protective memory area, forming a free block, which is bigger than the previous free block, by irradiating the bitmaps of the adjacent pages and hanging the free block on a list; (d) checking whether a desc is included in a memory area generated in a p_init() before writing and writing by obtaining the block with the same size as the block from the free lists if an unauthorized task is written by checking whether a task, which is intended to be currently written, is registered through the map table.

<CIT>discloses use of hybrid error correcting code (ECC) techniques. A memory access request having an associated address is received. A memory controller determines whether the address corresponds to a first region of a memory for which ECC techniques are applied or a second region of the memory for which ECC techniques are not applied. The memory access is processed utilizing ECC techniques if the address corresponds to the first region of the memory, a transaction indicator and an execution unit indicator, and processed without utilizing the ECC techniques if the address corresponds to the second region of the memory.

<CIT> discloses a technique for protecting data with an error correction code (ECC). The data is accessed by a processing unit and stored in an external memory, such as dynamic random access memory (DRAM). Application data and related ECC data are advantageously stored in a common page within a common DRAM device. Application data and ECC data are transmitted between the processor and the external common DRAM device over a common set of input/output (I/O) pins.

This background is provided to generally present the context of the disclosure. Unless otherwise indicated herein, material described in this section is neither expressly nor impliedly admitted to be prior art to the present disclosure or the appended claims.

The present disclosure describes techniques and apparatuses for using memory protection data within a computing device. Described techniques include allocating regions of a memory for storing application data and protection data. Such techniques also include creating a bitmap that is indicative of whether memory blocks within the allocated regions include the application data and/or the protection data. The techniques and apparatuses can reduce memory overhead by decreasing memory consumption and/or simplifying memory transactions within the computing device.

In some aspects, a method performed by a computing device is described. The method includes computing an amount of memory for storing application data and protection data, allocating regions of a memory to provide the computed amount for storing application data and protection data and creating a bitmap that includes a bit value indicative that a 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, wherein the protecting includes using the bit value to indicate that the memory block includes at least one of the application data or the protection data.

In other aspects, 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, upon execution by the CPU, direct the computing device to perform multiple operations. The operations include computing an amount of the memory for storing application data and protection data and allocating one or more regions of the memory to provide the computed amount. The operations also include creating a bitmap of at least a portion of the memory that includes bit values indicative that one or more memory blocks of the allocated regions include at least one of the application data or the protection data. The operations further include provisioning the bitmap to the protection engine.

The details of one or more implementations are set forth in the accompanying drawings and the following description. Other features and advantages will be apparent from the description, the drawings, and the claims. Thus, this Summary is provided to introduce subject matter that is further described in the Detailed Description.

The invention is defined in the appended independent claims.

Further preferred embodiments of the invention are defined in the dependent claims.

Apparatuses and techniques that use memory protection data, including application data and protection data for protecting the application data, are described with reference to the following drawings. The same numbers are used throughout the drawings to reference like features and components:.

The present disclosure describes techniques and apparatuses that are directed to using memory protection data within a computing device. Described techniques include allocating regions of a memory for storing application data and protection data and creating a bitmap. The bitmap is indicative of which memory blocks within the allocated regions include the application data and/or the protection data. The techniques and apparatuses may reduce memory overhead by decreasing memory consumption and/or simplifying memory transactions within the computing device.

Security and functional safety of a computing device often rely on the integrity of data supporting an application executed by a CPU of the computing device. Applications that may have security and/or functional safety needs include, for example, a banking application, an email application, an automotive control application (e.g., that controls a braking system), and so on. The data supporting the application is generally stored in a memory of the computing device, which in turn may be compromised through mechanisms that include malicious hacking, soft errors, and failure due to wear and tear.

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

There are also existing techniques for employing protection data with a memory system. Each of these existing techniques, however, has one or more drawbacks that adversely impact computing device performance. A first drawback of existing techniques for using protection data involves introducing additional overhead in terms of a capacity of a memory of the computing device. For example, a technique can entail carving out substantial contiguous memory regions for application data that is to be protected and for the protection data. The large contiguous memory regions cause the memory to be inefficiently used as the operating system of the computing device cannot adequately share the memory among many applications. In an instance of allocating contiguous memory for protection data that may include a hash digest data, ECC syndrome data, and application data, existing contiguous techniques may allocate up to <NUM>% of the overall memory capacity to the protection data alone.

A second drawback of existing techniques for using protection data involves those that do permit fragmented memory allocations to avoid large contiguous carve-out allocations. These techniques, however, inefficiently reserve memory and entail appreciable modifications to operating system memory management procedures. For instance, although the carve-out for the application data may be fragmented in this case, the carve-out for the protection data is oversized to cover the memory system in its entirety (thereby simplifying algorithms that may map application data and/or protection data).

The large size occurs because these techniques reserve sufficient memory to store protection data for all application data that might ultimately be present throughout the memory space, even when the actual amount of application data is likely to be significantly less during operation. The full reservation for the protection data is used by these techniques to locate the protection data for any given application data. Additionally, such techniques rely on modifying the operating system memory management procedures. These modifications include reusing bits that may be reserved in a page table entry to reflect whether application data is protected for a given page, updating the page attribute appropriately during operation, and propagating signals containing memory attributes within the computing device. These techniques, therefore, also may require a nonstandard operating system and complicate the memory management procedures.

A third drawback of existing techniques using protection data involves overhead with regards to a quantity of memory transactions within a computing device. As an example, while executing a memory protection algorithm, a protection engine of the computing device may first access the memory to retrieve ECC syndrome data and then, in a second distinct operation, access the memory to retrieve application data to be checked and corrected. These multiple memory accesses can lead to increases in power consumption and memory latency that both decrease computing performance.

Example implementations in various levels of detail are discussed below with reference to the associated figures. The example implementations include (i) a method that creates a bitmap to indicate one or more memory blocks of allocated memory regions that store application data or protection data, including memory blocks having co-located application data and protection data and (ii) a computing device having a protection engine that utilizes such a bitmap. The allocated memory regions and the memory blocks may have different sizes. For example, an allocated memory region may include multiple memory blocks, which correspond to an example granularity of the bitmap. Alternatively, allocated memory regions and memory blocks may have a common size, such as that of a memory page (e.g., <NUM> kilobytes (4KB) in some systems).

In general, and in contrast to existing techniques which may pre-allocate large blocks of contiguous memory to application or protection data, use of the bitmap allows for a flexible, selectable allocation of fragmentable memory to reduce the memory capacity used when implementing memory protection. Using a bitmap may also obviate changes to a memory manager of an operating system because hardware can identify and manage which memory blocks include application data that is protected or the corresponding protection data with reference to the bitmap. This bitmap additionally enables memory allocations for the protection data to be made as protection data is used, instead of using one over-sized pre-allocation that will likely be underutilized. Furthermore, and in contrast to existing techniques that may require multiple memory accesses across large blocks of contiguous memory, using the bitmap to access memory protection data that is co-located within a given memory block of the fragmented memory can increase speed of operations and reduce power consumption. In combination, the reduction in memory capacity utilization, the ability to independently allocate memory portions for protection, the increase in speed, the reduction in power consumption, and/or the simplification of the memory management processes of the operating system separately and jointly translate into an overall reduction in memory overhead.

The discussion below first describes an example operating environment, followed by example hardware and feature details for using protection data, followed by an example method, and concludes with related example aspects. The discussion may generally apply to a region of a memory having memory blocks and to techniques associated with virtual and/or physical memory addressing. However, for clarity, consistency, and brevity, the discussion is presented in the context of pages of a memory that are accessed using a physical address space (after translation from a virtual address space as appropriate).

<FIG> illustrates an example operating environment <NUM> including a computing device <NUM> using memory data protection techniques. Although illustrated as a laptop computer, the computing device <NUM> can 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 device, and so on.

The computing device <NUM> includes a computer-readable storage medium (CRM) <NUM> and hardware <NUM>. In the context of this discussion, the CRM <NUM> of the computing device <NUM> is a hardware-based storage media, which does not include transitory signals or carrier waves. As an example, the CRM <NUM> 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 so on. The CRM <NUM>, in general, may store a collection of software and/or drivers that are executable by the hardware <NUM>, as is described below.

The CRM <NUM> may store one or more modules that include executable code or instructions. For example, the CRM <NUM> may store an application <NUM>, an operating system (O/S) kernel <NUM>, a virtual machine monitor (VMM) <NUM>, and a protection driver <NUM>. The hardware <NUM> may include a CPU <NUM>, a protection engine <NUM>, a memory controller <NUM>, and a memory <NUM>. In some instances, one or more portions of the CRM <NUM> and one or more elements of the hardware <NUM> may be combined onto a single integrated-circuit (IC) device, such as a System-on-Chip (SoC) IC device. In some implementations, the CRM <NUM> can store a collection of drivers, OS modules, or other software that executes on the hardware <NUM>. Thus, this software can include, for example, the application <NUM>, the O/S kernel <NUM>, the VMM <NUM>, and/or the protection driver <NUM>.

Stored within the CRM <NUM>, the application <NUM> may be an application for which security and/or functional safety is desirable. Examples of the application <NUM> include a banking application, a payment application, an email application, an automotive control application (e.g., a braking system application), and so on.

The O/S kernel <NUM> may include executable code that enables elements of the hardware <NUM> within the computing device <NUM> (e.g., the CPU <NUM>, the protection engine <NUM>, or the memory controller <NUM>) to transact data with the memory <NUM> (e.g., to read data from or to write data to the memory). Upon execution, and as part of allocating pages within the memory <NUM> for computing operations, the O/S kernel <NUM> may identify physical addresses of one or more portions of (e.g., pages within) the memory <NUM>. Alternatively, the O/S kernel <NUM> may identify virtual memory addresses and permit another module or physical component (e.g., a virtual memory manager (not explicitly shown), the memory controller <NUM>, or the protection engine <NUM>) to compute the corresponding physical addresses.

The VMM <NUM>, sometimes referred to as a hypervisor, may interact with one or more operating systems within the computing device <NUM>. In some instances, the VMM <NUM> may include executable code to calculate an amount of the memory <NUM> targeted for one or more techniques that use memory protection data.

The protection driver <NUM> may also include executable code. The protection driver <NUM> may enable provisioning data to the protection engine <NUM>, provisioning a bitmap to the protection engine <NUM>, or other communications with the protection engine <NUM>. Such data may include, for example, physical addresses of pages within the memory <NUM> that contain memory protection data, or a bitmap that corresponds to pages within the memory <NUM> that contain memory protection data.

The CPU <NUM> may include logic to execute the instructions or code of the modules of the CRM <NUM>. The CPU <NUM> may include a single-core processor or a multiple-core processor composed of a variety of materials, such as silicon, polysilicon, high-K dielectric, copper, and so on. By executing one or more of the modules (e.g., the application <NUM>, the O/S kernel <NUM>, the VMM <NUM>, the protection driver <NUM>), the CPU <NUM> may direct the computing device <NUM> perform operations using memory protection data.

The protection engine <NUM>, which may communicatively couple to the memory controller <NUM>, may include logic to execute one or more protection algorithms (e.g., data encryption, hashing, ARC, ECC) through transacting (e.g., reading, writing) memory protection data with the memory <NUM>.

In some instances, the protection engine <NUM> may include an on-chip cache. As part of memory protection data techniques, which will be described in greater detail below, the on-chip cache may be used to store a copy of a physical address of a page or a copy of a bitmap, or a copy of a portion of the bitmap. In some instances, storage operations may be dependent on a size of the on-chip cache and/or a cache line size.

The memory <NUM>, which may be formed from an IC device, may include a type of memory such as a dynamic random-access memory (DRAM) memory, a double data-rate DRAM (DDR DRAM) memory, a Flash memory (e.g. NOR, NAND), a static random-access memory (SRAM), and so on. In some instances, the memory <NUM> may be part of a memory module, such as a dual in-line memory module (DIMM). In other instances, the memory <NUM> may be a discrete IC device or embedded on another IC device (e.g., an SoC IC device). In some implementations, the memory <NUM> may include at least a portion of the CRM <NUM>. Additionally or alternatively, at least part of the code or data stored within the CRM <NUM> may be copied into the memory <NUM> for execution or manipulation by the hardware <NUM>.

Memory protection data techniques performed by code or data, which may be at least initially stored in the CRM <NUM>, and the hardware <NUM> may include allocating respective pages of the memory <NUM> for memory protection data (e.g., application data <NUM> that may be associated with the application <NUM> and protection data <NUM> that may include hash digest data, ECC syndrome data, and so on for the corresponding application data <NUM>). In doing so, the CRM <NUM> and the hardware <NUM> may rely on a physical address space <NUM> that maps to physical addresses of pages within the memory <NUM>. In some instances, and in support of the memory protection data techniques, the CRM <NUM> and one or more elements of the hardware <NUM> (e.g. one or more of the CPU <NUM>, the protection engine <NUM>, or the memory controller <NUM>) may manipulate physical addresses of the memory protection data (e.g., application data <NUM> or protection data <NUM>, including both) to combine the memory protection data into a same page. The manipulation may include mapping/remapping addresses, translating physical addresses into a channel, row, bank, or column of the memory <NUM>, and so forth to adjust physical locations of data. In such instances, the manipulation may avoid memory page conflicts.

These techniques may also include allocating respective pages of the memory <NUM> for a bitmap <NUM> and updating one or more corresponding bits of the bitmap <NUM>. The bitmap <NUM> indicates the pages within the memory <NUM> that are allocated for storing the memory protection data (e.g., the application data <NUM> or the protection data <NUM>). For example, algorithms of the VMM <NUM> may create the bitmap <NUM> by associating a bit value of "<NUM>" to physical addresses of the pages of the memory <NUM> that are allocated for storing the memory protection data. In a complementary fashion, algorithms of the VMM <NUM> may associate a bit value of "<NUM>" to physical addresses of other pages of the memory <NUM> that are not allocated for storing the memory protection data. Thus, at least one bit of the bitmap <NUM> may correspond to a memory block of the memory <NUM>. In some cases, the memory block may have a same size as a page of the memory.

The memory protection engine <NUM> may receive a memory transaction command for the application data <NUM> that includes a system view of a physical address of a page of the memory <NUM>. The protection engine <NUM> may then convert the physical address to a manipulated physical address that offsets the physical address of the application data <NUM> with an amount needed for the protection data <NUM>. Using the bitmap <NUM>, the protection engine <NUM> determines that the page stores memory protection data (e.g., one or more of the application data <NUM> and/or the protection data <NUM>) and performs the memory transaction command with the page based on the determination. The bitmap <NUM> maps the system view of the physical addresses of pages to be indicative of whether the page stores memory protection data (e.g., the application data <NUM> and/or the protection data <NUM>).

Memory protection data techniques using the application data <NUM>, the protection data <NUM>, and the bitmap <NUM>, as described in greater detail below, may reduce memory overhead realized as the computing device <NUM> performs functions that ensure security and/or functional safety of the application data <NUM>. This reduction in memory overhead can improve overall efficiency of the computing device <NUM>, e.g., in terms of a more efficient use of the memory <NUM> as well as an increase in overall speed of computations.

<FIG> illustrates example details <NUM> of a physical address space that represents a memory in accordance with one or more aspects. The physical address space may correspond to the physical address space <NUM> that maps physical locations of pages within the memory <NUM> of <FIG>. <FIG> also illustrates that the application data <NUM> and the protection data <NUM> may be co-located (e.g., using "mixed mapping") within one or more pages that are fragmented within the memory <NUM>. In accordance with the example details <NUM> of <FIG>, memory protection data techniques may use less of the memory <NUM> and require fewer transactions, thereby effectuating a reduction in memory overhead, and avoiding necessitating changes to an operating system's memory management procedures.

In general, an architecture of the memory <NUM> may include one or more channel(s) <NUM>. Furthermore, a page within the memory <NUM> may be identified using a physical address <NUM> of the physical address space <NUM>. Elements of the computing device <NUM> of <FIG> (e.g., elements of the CRM <NUM> and the hardware <NUM>) may allocate regions (e.g., data ranges such as pages) of the memory <NUM> to store memory protection data (e.g., the application data <NUM> and/or the protection data <NUM>) using physical address(es) <NUM> of the physical address space <NUM>.

Memory protection data techniques may use pages that are fragmented (e.g., not contiguous) within the memory <NUM>. For example, and as illustrated in <FIG>, a page <NUM> and a page <NUM> may each accommodate a different permutation of the application data <NUM> and the protection data <NUM>. However, as illustrated, the page <NUM> and the page <NUM> are separated by a page <NUM> and, as such, are fragmented.

Memory protection data techniques may also co-locate portions of the application data <NUM> and the protection data <NUM> within one or more pages of the memory <NUM>. Furthermore, transactions associated with co-locating the application data <NUM> and the protection data <NUM> may include interleaving across multiple memory blocks (e.g., pages) and/or one or more channels <NUM> of the memory <NUM>. Application data <NUM> and protection data <NUM> may further be interleaved so that application data <NUM> and corresponding protection data <NUM> may be co-located within a same bank, a same row, and so forth of the memory <NUM>, thereby reducing page conflicts that may arise when accessing the protection data <NUM>.

In some instances, pages of the memory <NUM> that are allocated for the bitmap <NUM> may be contiguous. For example, and as illustrated in <FIG>, page <NUM> and page <NUM> may be allocated for storage of the bitmap <NUM>. As illustrated, page <NUM> and page <NUM> are adjacent to one another and, as such, are contiguous.

Amounts of the memory <NUM> that are allocated for storing the application data <NUM>, the protection data <NUM>, and the bitmap <NUM> may depend on a size of the memory <NUM> and a selected granularity of fragmentation. As an example, if the memory <NUM> corresponds to a <NUM> Gigabyte (GB) memory and a <NUM> Kilobyte (KB) page size is selected for an allocation granularity, then if one bit corresponds to each available, fragmented page (e.g., one bit per each 4KB page within the available 4GB memory) may be allocated for the bitmap <NUM> (e.g., an amount of 1MB contiguous memory from the available <NUM> GB can be allocated for storing the bitmap <NUM>). Of the remaining available <NUM> GB of memory, and as requests are received, any amount of fragmented memory may be allocated for storing the application data <NUM> or the protection data <NUM> for an application targeted for protection. An amount of fragmented memory may also be allocated for application data of other applications not targeted for protection. No particular large contiguous region needs to be reserved.

In accordance with the illustrations and description of <FIG>, fragmentation of pages allocated to storing the application data <NUM> and the protection data <NUM> may reduce memory overhead by decreasing amounts of the memory <NUM> the computing device <NUM> consumes while performing memory protection data operations. Using example fragmentation techniques as described above, enabling memory data protection (e.g., ECC protection) may allocate 1MB of the memory <NUM> for the bitmap <NUM> and <NUM>. 03MB of the memory <NUM> for the protection data <NUM> (e.g., slightly more than 1MB of the memory <NUM>). In contrast, other techniques that proportionally allocate memory for memory protection data based on a size of the memory <NUM> may allocate 128MB of the memory <NUM> for the protection data.

Techniques described by the <FIG>, in general, reduce memory overhead by decreasing amounts of the protection data <NUM> that the computing device consumes while performing memory protection data operations. Furthermore, and in general, co-locating the application data <NUM> and the protection data <NUM> in respective pages (e.g., in respective channels, banks, or rows) may reduce memory transactions within the computing device <NUM>, leading to further reductions in memory overhead.

<FIG> illustrates other example details <NUM> of a physical address space in accordance with one or more other aspects. The physical address space may correspond to the physical address space <NUM> that represents the memory <NUM> of <FIG>. <FIG> also illustrates an instance where the application data <NUM> and the protection data <NUM> may be separated (e.g., using "separated mapping") across one or more pages that are fragmented within memory <NUM>. In accordance with the example details <NUM> of <FIG>, memory protection data techniques may use less of the memory <NUM>, effectuating a reduction in memory overhead, and avoid necessitating changes to an operating system's memory management procedures.

In general, as previously described in <FIG>, an architecture of the memory <NUM> may include one or more channel(s) <NUM>. Furthermore, a page within the memory <NUM> may be identified using a physical address <NUM> of the physical address space <NUM>. Elements of the computing device <NUM> of <FIG> (e.g., elements of the CRM <NUM> and the hardware <NUM>) may allocate pages of the memory <NUM> to store memory protection data (e.g., the application data <NUM> and/or the protection data <NUM>) in accordance with the physical address space <NUM>. Memory protection data techniques, as described below, may reduce overhead by decreasing memory consumption within the computing device <NUM>.

As illustrated in <FIG>, memory protection data techniques may use pages that are fragmented (e.g., not contiguous) within the memory <NUM>. For example, and as illustrated in <FIG>, page <NUM> and page <NUM> are separated and not contiguous. Accordingly, an operating system can efficiently manage multiple memory allocations from various applications.

However, in contrast to memory protection data techniques described in previous <FIG>, the pages <NUM> and <NUM> do not co-locate the application data and the protection data within a page. For instance, page <NUM> accommodates the application data <NUM> but does not accommodate the protection data <NUM>. Conversely, page <NUM> accommodates the protection data <NUM> but does not accommodate the application data <NUM>. In general, while pages accommodating the memory protection data are fragmented, there is no co-locating the application data <NUM> and the protection data <NUM> within a page in these implementations.

The memory protection data techniques of <FIG> may also use pages that are contiguous within the memory. For example, pages <NUM> and <NUM>, which accommodate the bitmap <NUM>, are contiguous.

Similar to previously described <FIG>, amounts of the memory <NUM> in <FIG> that are allocated for the bitmap <NUM> may depend on a size of the memory <NUM> and a selected granularity of fragmentation. As an example, if the memory <NUM> corresponds to a <NUM> Gigabyte (GB) memory and fragmentation is based on a selected <NUM> Kilobyte (KB) granularity (e.g., fragmented page size), one bit for each available, fragmented page (e.g., one bit per each 4KB page within the available 4GB memory) may be allocated for the bitmap <NUM> (e.g., an amount of 1MB from the available 4GB would be allocated for the bitmap <NUM>). Of the remaining available memory, any amount of fragmented memory may be allocated for storing the application data <NUM> or the protection data <NUM> for various applications that require protection (as well as storing the application data <NUM> of other applications for which memory data protection is not desired) as application requests are received. No particular large contiguous region needs to be reserved.

In accordance with the illustrations and description of <FIG>, fragmentation of pages allocated to storing the application data <NUM> and the protection data <NUM> may reduce memory overhead by decreasing amounts of the memory <NUM> the computing device <NUM> consumes while performing memory protection data operations. Although not so depicted in <FIG> or <FIG>, some computing device implementations may include features of both. Thus, a computing device may include some memory allocations that co-locate application data <NUM> and protection data <NUM> and other memory allocations that separate application data <NUM> and protection data <NUM> into different pages, channels, banks, or rows.

<FIG> illustrates an example system architecture <NUM> that may perform techniques using memory protection data. The system architecture <NUM> may be an architecture that uses elements of the CRM <NUM> and the hardware <NUM> of <FIG>.

The system architecture <NUM> of <FIG> may include an SoC IC device <NUM>. The SoC IC device <NUM> may be formed with logic integrated circuitry and memory integrated circuitry that performs one or more functions of the hardware <NUM> (e.g., may execute logic of the CPU <NUM>, the protection engine <NUM>, and/or the memory controller <NUM>) and/or stores data with the CRM <NUM> (e.g., store the application <NUM>, the O/S kernel <NUM>, the VMM <NUM>, and/or protection driver <NUM>). As illustrated, one or more internal bus <NUM> may communicatively couple operative elements of the SoC IC device.

The system architecture <NUM> may also include a memory module <NUM>. The memory module <NUM> may include memory integrated circuitry to perform one or more functions of the hardware <NUM> (e.g., store memory protection data in the memory <NUM>). For example, the memory module <NUM> may include a dual in-line memory module (DIMM) populated with one or more components that include the memory <NUM>, or the memory may be realized using package on package (PoP) low power double data rate (DDR) (LP-DDR) memory. As part of the system architecture <NUM>, an external memory bus <NUM> (e.g., edge connectors, sockets, electrically conductive traces) may communicatively couple the memory <NUM> of the memory module <NUM> to the memory controller <NUM> of the SoC IC device <NUM>.

In general, the system architecture <NUM> may support a variety of operations directed to using memory protection data. For instance, the system architecture <NUM> may support operations that include computing an amount of the memory <NUM> that is targeted for storing application data and protection data (e.g., the application data <NUM> and the protection data <NUM> of <FIG>), allocate pages of the memory <NUM> to provide the computed amount (e.g., one or more of the pages <NUM> and <NUM> of <FIG> or one or more of the pages <NUM> and <NUM> of <FIG>), create a bitmap of the memory <NUM> (e.g., the bitmap <NUM> of <FIG>), and provision the bitmap to the protection engine <NUM>.

Although the system architecture <NUM> includes the SoC IC device <NUM> and the memory module <NUM>, many different arrangements of elements of the CRM <NUM> and the hardware <NUM> are possible. For instance, as opposed to an arrangement including the SoC IC device <NUM> and the memory module <NUM>, elements of the CRM <NUM> and the hardware <NUM> may use a variety of combinations of discrete IC die and/or components, system-in-packages (SIPs), and so on which may be distributed across at least one printed circuit board (PCB), disposed in different portions of a server rack, and so forth.

<FIG> illustrates example details <NUM> of operations performed by and messages communicated within a computing device using memory protection data techniques in accordance with one or more aspects. A CPU of the computing device (e.g., the CPU <NUM> of the computing device <NUM> of <FIG>) may effectuate the operations (e.g., computations) and transactions through execution of code of the modules stored in the CRM <NUM> of <FIG>, including the application <NUM>, the O/S kernel <NUM>, the VMM <NUM>, and/or the protection driver <NUM>. For brevity, it is to be understood that in the following description of <FIG>, reference to a module performing an operation or communicating a message corresponds to the computing device performing the operation or communicating the message as a result of the CPU executing instructions stored within the module.

At message <NUM>, the application <NUM> communicates an application memory target to the VMM <NUM>. The message <NUM>, an application memory target message, may include parameters that indicate an amount of a memory targeted for application data (e.g., a first amount of the memory <NUM> that is targeted by the computing device to store the application data <NUM> of <FIG>).

At operation <NUM>, the VMM <NUM> determines an amount of the memory that is targeted to store protection data (e.g., computes a protection data amount) based on the requested application data. For example, parameters included in message <NUM> may indicate to the VMM <NUM> that the application data is to be protected. Upon determining that the application data is to be protected, the VMM <NUM> may compute additional memory that is targeted for protection data (e.g., a second amount of the memory <NUM> is targeted by the computing device to store the protection data <NUM> of <FIG>). The VMM <NUM> may then sum the amounts (e.g., combine the first amount targeted for the application data <NUM> and the second amount targeted for the protection data <NUM>) to determine a total amount of memory targeted (e.g., the computed memory protection data amount) for the computing device to store the memory protection data (e.g., store the application data <NUM> and the protection data <NUM>).

At message <NUM>, the VMM <NUM> communicates to the O/S kernel <NUM>. The message <NUM>, a protection request message, includes a request to the O/S kernel <NUM> to allocate the memory protection data amount.

At operation <NUM>, the O/S kernel <NUM> allocates a first set of pages of the memory for the memory protection data. The allocation is effective to provide to the computing device, or to reserve within the computing device, the amount of the memory targeted for the computing device to store the memory protection data. As part of allocating the first set of pages of the memory, the O/S kernel <NUM> may create a listing of physical addresses (e.g., a listing of physical addresses <NUM> from the physical address space <NUM>) corresponding to fragmented pages within the memory (e.g., one or more of the pages <NUM> and <NUM> of <FIG> or one or more of the pages <NUM> and <NUM> of <FIG>).

At message <NUM>, the O/S kernel <NUM> communicates to the VMM <NUM>. The message <NUM>, a protection addresses message, may include the listing of the physical addresses of the first set of pages allocated for the computing device to store the memory protection data.

At operation <NUM>, the VMM <NUM> computes an amount of the memory to be reserved for a bitmap (e.g., a third amount of the memory <NUM> targeted for the bitmap <NUM> of <FIG>). The amount of the memory targeted for the bitmap may be dependent on a size of the memory <NUM> and a fragmentation granularity (e.g., a quantity of memory blocks, such as a number of available pages) within the memory. The amount of memory for the bitmap may also be based on a quantity of bits per memory block. For example, if more than two states (e.g., more than a protected state and a not protected state) or if additional information (e.g., a type or kind of protection) for a memory block is to be retained in the bitmap, each memory block may correspond to <NUM> bits, <NUM> bits, and so on of the bitmap. Each bit or each at least one bit can respectively correspond to a memory block of the memory.

At message <NUM>, the VMM <NUM> communicates to the O/S kernel <NUM>. The message <NUM>, a bitmap request message, includes a request to the O/S kernel <NUM> to allocate the amount of memory targeted for the computing device to store the bitmap. In some instances, the bitmap request message may include a parameter that indicates the allocation is to be from a contiguous region of the memory instead of fragmented regions of the memory. A physically contiguous memory allocation can simplify operation of the memory controller <NUM> when accessing the bitmap <NUM>.

At operation <NUM>, the O/S kernel <NUM> allocates a second set of pages of the memory for the bitmap. The allocation is effective to provide to the computing device, or to reserve within the computing device, the amount of the memory targeted for the computing device to store the bitmap. As part of allocating the pages of the memory, the O/S kernel <NUM> may allocate a contiguous region of the memory (e.g., one or more of the pages <NUM> and <NUM> of <FIG> or one or more of the pages <NUM> and <NUM> of <FIG>) based on the parameter being included in the bitmap request message.

At message <NUM>, the O/S kernel <NUM> communicates to the VMM <NUM>. The message <NUM>, a bitmap addresses message, may include physical addresses of the second set of pages allocated for the computing device to store the bitmap.

At operation <NUM>, the VMM <NUM> may create a bitmap (e.g., the bitmap <NUM>). In creating the bitmap, the VMM <NUM> may associate one or more bit values to the physical addresses received through message <NUM> to indicate pages that are enabled to store the memory protection data. Unlike the application <NUM> which may use virtual addressing techniques, the VMM <NUM> may create the bitmap using the physical addresses to enable use by a memory controller (e.g., the memory controller <NUM> of <FIG>), which can operate on physical memory addresses.

At message <NUM>, the VMM <NUM> communicates with the protection driver <NUM>. The message <NUM>, a bitmap message, includes the bitmap or provides a reference to a bitmap. Communicating the bitmap to the protection driver <NUM> may enable the protection driver <NUM> to provision the bitmap and/or the physical addresses of the pages that are allocated for memory protection data to a protection engine (e.g., the protection engine <NUM> of <FIG>). This may, in some instances, include writing the bitmap and/or the physical addresses to an on-chip cache of the protection engine. The protection engine may subsequently perform memory protection techniques that include transacting the memory protection data and executing one or more memory protection algorithms.

Although the example details <NUM> of <FIG> illustrates a combination of modules within the CRM of the computing device performing a series of operations (e.g., computations) and messaging exchanges in support of memory protection data techniques, the combination of modules and the series of operations may be performed in part, or in whole, using other combinations of modules and/or computing resources. In some instances, the other combinations of modules may not be part of the computing device (e.g., may be included in another CRM that is part of a server communicatively coupled to the computing device <NUM>).

<FIG> illustrates an example method <NUM> using memory protection data techniques in accordance with one or more aspects. In some instances, the method <NUM> may be performed by a computing device using the aspects of <FIG>. The described operations may be performed with other operations, in alternative orders, in fully or partially overlapping manners, and so forth.

At operation <NUM>, the computing device (e.g., the CPU <NUM> executing code of the O/S kernel <NUM> as illustrated in operation <NUM> of <FIG>) allocates regions of a memory (e.g., the memory <NUM>) for storing application data and protection data (e.g., the application data <NUM> and the protection data <NUM>). In some instances, allocating the regions of the memory may include allocating pages that are fragmented within the memory (e.g., pages <NUM>, <NUM>, <NUM>, or <NUM> of the memory <NUM>). In other instances, allocating the regions of the memory may include allocating pages from a contiguous memory region (e.g., the pages <NUM> and <NUM> of the memory <NUM>).

At operation <NUM>, the computing device (e.g., CPU <NUM> executing code of the VMM <NUM> as illustrated in operation <NUM> of <FIG>) creates a bitmap (e.g., the bitmap <NUM>). The created bitmap includes a bit value that is indicative that a memory block includes at least one of the application data or the 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, page <NUM>, <NUM>, <NUM>, or <NUM>). The bitmap can include multiple bits having at least one bit value apiece. A given memory block of an allocated memory region respectively corresponds to at least one bit value of the multiple bits of the bitmap.

At operation <NUM>, the computing device (e.g., the protection engine <NUM> executing a protection algorithm) protects the application data using the protection data. Protecting the application data includes operations that use the bit value of the bitmap to indicate that the memory block (e.g., of the at least one allocated region) includes at least one of the application data or the protection data. In some cases, like if the application data and the protection data are co-located, the memory block may include both the application data and the protection data.

In some instances, the method <NUM> may further include storing the application data and the protection data by locating the application data and the protection data within separate regions of the allocated regions (e.g., locating the application data <NUM> in the page <NUM> and the protection data <NUM> in the page <NUM>, as illustrated in <FIG>). The separate regions may be fragmented regions of the memory (e.g., the page <NUM> and the page <NUM> are fragmented pages that are separated by one or more pages allocated to at least one other application).

In the instances in which the application data and the protection data are located within separate regions, a physical address of a first region including the protection data (e.g., a physical address <NUM> of the page <NUM> including the protection data <NUM>) may be determinable using one or more offsets from a physical address of a second region including the application data (e.g., a physical address <NUM> of the page <NUM> including the application data <NUM>). Such offsets may be fixed, determinable based on size of the allocated regions, a size ratio of the protection data <NUM> to the application data <NUM> (e.g., <NUM> bytes of the protection data <NUM> for every <NUM> bytes of the application data <NUM>), and so on.

In other instances, the method <NUM> may further include storing the application data and the protection data by co-locating the application data and the protection data within the at least one allocated region that may be a fragmented region of the memory (e.g., co-locating the application data <NUM> and the protection data <NUM> within the page <NUM> as illustrated in <FIG>). The one allocated region may be a fragmented region of the memory (e.g., a memory block like the page <NUM>, which is a fragmented page).

In the instances in which the application data and the protection data are co-located, co-locating the application data and the protection data may include interleaving the application data and the protection data across multiple memory blocks and/or channels (e.g., the channel(s) <NUM>) of the memory, including across respective banks or memory rows thereof.

In general, and for the aforementioned example variations of the method <NUM>, protecting the application data may include executing (e.g., the protection engine <NUM> executing) one or more algorithms that use the protection data and the application data. Examples of such algorithms include an error correction code (ECC) algorithm, an anti-rollback counter (ARC) algorithm, a data encryption algorithm, or a hashing algorithm.

The preceding discussion describes methods relating to using memory protection data to reduce memory overhead of a computing device. 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 <NUM> may be performed by a computing device having one or more processors and a CRM. In such an instance, the processor in conjunction with the CRM may encompass fixed or hard-coded circuitry, finite-state machines, programmed logic, and so forth that perform the one or more operations.

Furthermore, these techniques may be realized using one or more of the entities or components shown in <FIG>, which may be further divided, combined, and so on. Thus, these figures illustrate some of the many possible systems or apparatuses capable of employing the described techniques. The entities and components of these figures generally represent software, firmware, hardware, whole or portions of devices or networks, or a combination thereof.

Claim 1:
A method (<NUM>) performed by a computing device (<NUM>), the method (<NUM>) comprising:
computing (<NUM>) an amount of memory (<NUM>) for storing application data (<NUM>) and protection data (<NUM>);
allocating (<NUM>; <NUM>) at least one region (<NUM>, <NUM>, <NUM>, <NUM>) of a memory (<NUM>) to provide the computed amount, the at least one allocated region (<NUM>, <NUM>, <NUM>, <NUM>) for storing application data (<NUM>) and protection data (<NUM>);
creating (<NUM>; <NUM>) a bitmap (<NUM>) including a bit value indicative that a memory block includes at least one of the application data (<NUM>) or the protection data (<NUM>), the at least one allocated region (<NUM>, <NUM>, <NUM>, <NUM>) including the memory block; and
protecting (<NUM>) the application data (<NUM>) with the protection data (<NUM>), including using the bit value of the bitmap (<NUM>) to indicate that the memory block includes at least one of the application data (<NUM>) or the protection data (<NUM>).