CN113614703B - Apparatus for core specific memory mapping - Google Patents
Apparatus for core specific memory mapping Download PDFInfo
- Publication number
- CN113614703B CN113614703B CN201980094627.9A CN201980094627A CN113614703B CN 113614703 B CN113614703 B CN 113614703B CN 201980094627 A CN201980094627 A CN 201980094627A CN 113614703 B CN113614703 B CN 113614703B
- Authority
- CN
- China
- Prior art keywords
- core
- mapping table
- cores
- per
- mapping
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000013507 mapping Methods 0.000 title claims abstract description 189
- 230000015654 memory Effects 0.000 title claims abstract description 114
- 238000010295 mobile communication Methods 0.000 claims description 9
- 238000000034 method Methods 0.000 description 13
- 230000008569 process Effects 0.000 description 11
- 230000008901 benefit Effects 0.000 description 9
- 238000012545 processing Methods 0.000 description 9
- 238000010926 purge Methods 0.000 description 6
- 238000013459 approach Methods 0.000 description 4
- 230000006870 function Effects 0.000 description 4
- 238000013519 translation Methods 0.000 description 4
- 238000010586 diagram Methods 0.000 description 2
- 238000004891 communication Methods 0.000 description 1
- 230000008878 coupling Effects 0.000 description 1
- 238000010168 coupling process Methods 0.000 description 1
- 238000005859 coupling reaction Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000009977 dual effect Effects 0.000 description 1
- 238000001914 filtration Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
- G06F12/10—Address translation
- G06F12/1009—Address translation using page tables, e.g. page table structures
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
- G06F12/10—Address translation
- G06F12/1027—Address translation using associative or pseudo-associative address translation means, e.g. translation look-aside buffer [TLB]
Abstract
An apparatus is provided that includes a plurality of cores and a plurality of per-core mapping tables. Each of the plurality of per-core mapping tables includes one or more mapping table entries. Each per-core mapping table is configured to generate a physical memory address based on the virtual memory address and the one or more mapping entries. Each core-per-mapping table is configured to allow a respective one of the plurality of cores to generate the physical memory address based on the one or more mapping table entries and to prevent all remaining ones of the plurality of cores from generating the physical memory address based on the one or more mapping table entries.
Description
Technical Field
Aspects of the disclosed embodiments relate to mobile computing devices, and more particularly to software security within mobile computing devices.
Background
Modern computing devices, such as microprocessors, microcontrollers, and other types of communication enabled mobile computing devices, have a large portion of their state information stored in electronic memory. In general, one or more sub-states or data values may be identified in a global state that control important system functions and are therefore of interest to an attacker. An attacker attempts to identify the location of important information and alter that information to achieve the desired result. For example, an attacker may attempt to alter the level of rights associated with the current user, or bypass filtering altogether. For security reasons, important information cannot be written by its primary address even in a short time. Because an attacker can poll the address to determine when data can be written and then make changes to it. A more secure approach is to make changes to important information through channels that are inaccessible to an attacker.
The traditional approach adopted in the Linus kernel version is to implement a software Fixmap, where Fixmap represents the interval of valid addresses reserved for temporarily mapping existing (possibly already mapped) memories. The attributes of the Fixmap map need not be the same as the master map. For example, the temporary Fixmap map may be writable, while the master map is read-only. However, fixmap is visible to all cores in the multi-core computing device. Thus, one attacked core may utilize the temporary Fixmap map created for the other cores.
Alternatively, memory write protection may be implemented using a virtual machine hypervisor. All software components (including the Linux kernel) must rely on the virtual machine hypervisor to perform any memory write operations within the memory protected area. But this approach requires a compliant virtual machine hypervisor. In addition, since virtual machine managers typically do not know the memory layout of complex kernel data structures, the performance of memory accesses may be degraded.
Some operating system kernels perform dual mapping of memory pages through user space mapping. Unfortunately, user space memory mapping can result in reduced performance due to the necessity to activate and deactivate the alternate writable memory map on the core performing the write operation.
Accordingly, there is a need for an improved method and apparatus that protects sensitive system states without the complexity and overhead of conventional solutions. It is therefore desirable to provide methods and apparatus that address at least some of the problems described above.
Disclosure of Invention
It is an object of the disclosed embodiments to provide an improved method and apparatus that can improve memory security, is easy to use, and has minimal impact on performance. This object is solved by the subject matter of the independent claims. Further advantageous modifications can be found in the dependent claims.
The above and other objects and advantages are achieved in a first aspect by an apparatus comprising a plurality of cores and a plurality of mapping tables per core. One of the plurality of per-core mapping tables includes one or more mapping table entries, the per-core mapping table being configured to generate a physical memory address from a virtual memory address and the one or more mapping table entries. The per-core mapping table is configured to allow a particular one of the plurality of cores to generate the physical memory address based on the one or more mapping entries and to prevent all remaining ones of the plurality of cores from generating the physical memory address based on the one or more mapping entries. The use of per-core mapping tables improves security by preventing the attacked core from utilizing potentially writable mappings in dedicated per-core mapping tables associated with other cores.
In a first possible implementation form of the apparatus according to the first aspect, each of the one or more mapping entries comprises a set of one or more attributes. The one or more attributes are configured to generate or not generate the physical memory address based on a type of memory access being performed. An attribute is included in each mapping entry such that the mapping entry manages memory accesses according to the type of access being performed and such that different per-core mappings have different attributes.
In one possible implementation form of the apparatus, the type of memory access being performed includes one or more of a memory read and a memory write. Memory reads and memory writes are included in the attributes associated with each mapping entry such that the writable mapping exists only for a subset of cores, typically strictly one, and only during write operations, such that the writable mapping is limited to highly secure applications, while allowing broader applications to access only read-only mapping entries.
In one possible implementation form of the apparatus, the one particular core is configured to encode a core ID within the virtual memory address, and each per-core mapping table is configured to generate or not generate the physical memory address based on the encoded core ID. Encoding the core ID in the virtual memory address provides a method for identifying the core attempting to access memory for each core mapping table and ensures that each core mapping table is dedicated for use by the corresponding core.
In one possible implementation form of the apparatus, the per-core mapping table is communicatively coupled to the one particular core by a hardware-based signal. The per-core mapping table is configured to generate or not generate the physical memory address based on a state of the hardware-based signal. Including hardware-based signals provides a way for per-core mapping tables to verify whether a core attempting to access memory is allowed to use the mapping entries in the per-core mapping table.
In one possible implementation form of the apparatus, the memory includes program instructions that, when executed by the one particular core, cause the one particular core to configure a mapping entry of the one or more mapping entries and clear a mapping entry of the one or more mapping entries. Including software routines that manage the per-core mapping table such that the underlying hardware implementation is abstracted and the same standardized software interface is disclosed for all hardware implementations.
In one possible implementation form of the apparatus, the mapping table entry includes one or more attributes and physical memory addresses configured to be associated with the mapping table entry. The configuration attribute and the mapping table entry provide a method for managing the attribute and controlling the address mapping based on the memory access type.
In one possible implementation form of the apparatus, the apparatus comprises one or more enclave mapping tables, wherein each enclave mapping table is associated with a respective group comprising one or more cores of the plurality of cores, the enclave mapping table being configured to generate physical addresses for cores of the group of one or more cores without generating physical addresses for cores not in the group of one or more cores.
In one possible implementation form of the apparatus, the hardware apparatus comprises a mobile communication device. Mobile communication devices must be extremely secure to protect sensitive information and applications stored thereon, and thus may benefit from the increased security provided by per-core mapping tables.
These aspects, other aspects, implementations, and advantages of the exemplary embodiments will become apparent from the embodiments described herein, considered in conjunction with the accompanying drawings. It is to be understood that such description and drawings are for the purpose of illustration only and are not intended as a definition of the limits of the invention; reference should be made to the appended claims for any limitation of the invention. Additional aspects and advantages of the invention will be set forth in the description which follows, and in part will be obvious from the description, or may be learned by practice of the invention. Furthermore, the aspects and advantages of the invention may be realized and obtained by means of the instruments and combinations particularly pointed out in the appended claims.
Drawings
In the following detailed portion of the disclosure, the invention will be explained in more detail with reference to exemplary embodiments shown in the drawings, in which:
FIG. 1 illustrates a block diagram of a computing device provided by aspects of the disclosed embodiments, wherein the computing device is operable to provide a dedicated per-core mapping table for each core;
FIG. 2 illustrates a high level overview of how a virtual address space is mapped to a physical address space using a per-core mapping table provided by the disclosed aspects;
FIG. 3 illustrates a flow chart of a software process provided by aspects of the disclosed embodiments for managing per-core mapping tables;
FIG. 4 illustrates a possible implementation of a per-core mapping table provided by aspects of the disclosed embodiments;
FIG. 5 illustrates another possible implementation of a per-core mapping table provided by aspects of the disclosed embodiments.
Detailed Description
FIG. 1 is a block diagram of a computing device 100 provided by aspects of the disclosed embodiments. The computing device 100 is used to provide a dedicated per-core mapping table 106-0, 106-1 … … 106-n for cores 104-0, 104-1 … … 106-n. As will be discussed further below, including the dedicated per-core mapping tables 106-0, 106-1 … … 106-n for cores 104-0, 104-1 … … 106-n provides a way to improve memory security without adding overhead as in conventional security approaches. The apparatus 100 is suitable for use with general purpose computing devices such as smartphones, tablets, cellphones, laptops, mobile communication devices, networks, and cloud devices, or other computing devices that would benefit from increased memory security.
As shown in fig. 1, the apparatus 100 includes a plurality of cores or processing cores 104. The plurality of cores or processing cores 104 are communicatively coupled with a memory management unit (memory management unit, MMU) 102, wherein the MMU 102 is configured to receive virtual memory addresses 114 and 116 and generate corresponding physical memory addresses 118.MMU 102 is a hardware component. All memory references performed by the multiple cores 104 pass through the MMU 102 where they may be translated from virtual memory addresses 114 and 116 to physical memory addresses 118. As shown in device 100, MMU 102 may be a separate sub-component of device 100. Alternatively, the operations and functions performed by MMU 102 may be built into the same hardware subcomponents that implement the processing core, or distributed in any manner that provides similar functions and operational results, without departing from the spirit and scope of the present disclosure. For example, MMU 102 may be implemented as part of a multi-core CPU, or on the same chip as the multi-core CPU.
Referring to FIG. 1, in one embodiment, the plurality of cores 104 and the plurality of per-core mapping tables 106 are configured such that only a single core 104-0 may access a mapping table entry 124-0 contained in a particular per-core mapping table 106-0 and generate a physical memory address 118 for a given virtual memory address 114 based on the mapping table entry 124-0 to improve memory security. For example, one of the plurality of per-core mapping tables 106, 106-0, includes one or more mapping entries 124-0, and each core mapping table 104-0 is configured to generate the physical memory address 118 from the virtual memory address 114-0 and the one or more mapping entries 124-0. Security is enhanced by configuring the per-core mapping table 106-0 such that only a particular core 104-0 of the plurality of cores 104 generates the physical memory address 118 based on one or more mapping entries 124-0 and preventing all remaining cores 104-1 … … 104-n of the plurality of cores 104 from generating the physical memory address 118 using the mapping entries 124-0.
The device 100 includes a plurality of independent processing units 104 and may be incorporated into a variety of mobile communication devices or other computing devices that may benefit from increased software security. Each of the individual processing units 104-0, 104-1 … …, 104-n is configured to read and execute software or program instructions, referred to herein as cores. Each core 104-0, 104-1 … … 104-n is configured to execute common CPU instructions, thereby enabling the apparatus 100 to execute multiple instructions or threads of execution simultaneously, thereby increasing the overall processing speed of the apparatus 100. Software programs or applications designed to utilize parallel processing techniques may significantly increase processing speed when executed by a multi-core computing device, such as device 100. In one embodiment, the multiple cores 104 are all implemented on the same chip or physical package. Alternatively, multiple cores may be implemented on multiple communicatively coupled physical packages.
In operation, each time program code executed by a core 104-0, 104-1, … …, 104-n needs to access a value stored in memory, the core 104-0, 104-1, … …, 104-n generates a virtual memory address 116. The virtual memory addresses 116 are translated to corresponding physical memory addresses 118 by the shared address translation component 110 within the MMU 102. The shared address translation component 110 generates the physical memory address 118 based on an address translation table 120 maintained by protected code (e.g., code within an operating system kernel or within a virtual machine hypervisor). Each time a page of memory is swapped in and/or out of physical memory, the memory table 120 is maintained accordingly to ensure that virtual address 116 is translated to a corresponding physical memory address 118 containing the desired data item.
An attacker will attempt to identify data items of particular interest in the memory of the executing application and then attempt to alter the data to attack the executing application or the entire computing device, e.g., may locate in the memory storing the rights associated with the currently executing user. From a security perspective, such data can never be written by its primary address, i.e., can never be written by the shared address translation component 110. Otherwise, the attacker would know the location of the desired information, which may be polled to determine when it is writable, even if the information is writable only in a short time.
A more secure solution is to modify the sensitive data through channels that are inaccessible to an attacker. A backup mapping table (e.g., fixmap) may be implemented where only protected code (e.g., an operating system kernel or hypervisor) has access to the backup mapping. One problem with using the backup map is that the backup map may be writable, visible and available to all cores in the system. Thus, an attacked core may utilize the alternate mappings created by other cores and alter the data values in the remapped pages for writing.
The apparatus 100 includes a plurality of per-core mapping tables 106, wherein each of the per-core mapping tables 106-0, 106-1 through 106-n is configured to be dedicated to a single core of the plurality of cores 104, as will be described further below. For example, per-core mapping table 106-0 would only generate physical memory address 118 for core 104-0, and would not generate physical memory addresses for any of the remaining cores 104-1 through 104-n. Malicious applications that attack one of the remaining cores 104-1 through 104-n cannot utilize any dedicated, possibly writable, map 124-0 configured in per-core mapping table 106-0.
The plurality of cores 104 may include any number of more than two cores, such as the n cores shown in the illustrated apparatus 100. The plurality of per-core mapping tables 106 of the same number n are included in the illustrated apparatus 100, providing a single per-core mapping table 106-0, 106-1, and 106-n for the cores 104-0, 104-1, and 104-n, respectively, wherein each per-core mapping table 106-0, 106-1, and 106-n will generate physical memory addresses only for the respective corresponding core 104-0, 104-1, and 104-n, and will not generate physical memory addresses for any other core 104.
Some embodiments include an additional set of mapping tables 126, referred to herein as enclave mapping tables, which create an enclave of cores that share these mapping tables. Each enclave mapping table is associated with an enclave or group of one or more cores and is configured to generate physical addresses 118 only for cores in the associated core enclave. Enclave mapping table 126 receives virtual addresses 114-1 and 114-n from cores 104-1 and 104-n and generates physical address 118. The physical address is generated based on a mapping table entry (not shown) similar to the mapping table entry 124 described above in connection with the per-core mapping table. The enclave mapping table generates physical addresses for all cores belonging to an enclave or group of the associated one or more cores and does not generate physical addresses for any cores not included in the enclave or group of the one or more cores.
When enclave mapping table 126 is defined or configured, enclave mapping table 126 is associated with a group of one or more cores of the plurality of cores 104. These associated cores are authorized to generate physical addresses 118 based on the enclave map. In one embodiment, altering the group of one or more cores associated with the enclave mapping table clears or deletes all mapping table entries in the associated enclave mapping table. In some embodiments, it may also be advantageous to disable the enclave mapping table entirely once the associated enclave of the core is altered. In one embodiment, the enclave mapping table that was disabled remains disabled until the system resets.
Each of the per-core mapping tables 106-0, 106-1, and 106-n includes its own set of one or more mapping table entries 124-0, 124-1, and 124-n, respectively. Each mapping entry is configured to translate or dereference the virtual memory address 114-0, 114-1 … … 114-n to generate a physical memory address. In one embodiment, each mapping table entry also includes a set of one or more attributes that may control physical address generation, e.g., may include attributes that indicate that the mapping table entry is valid only for memory read accesses. Entries marked as read-only accesses do not generate physical addresses for memory write operations and may also be configured to generate processing exceptions that may appropriately alter program execution flow to handle attempts to write to read-only memory locations. Some embodiments may benefit from including an attribute that indicates that the mapping entry is valid only for memory write operations.
A software component may be included in the apparatus 100 that provides a standardized software interface for managing the mapping table entries 124 in the per-core mapping table 106. As will be discussed further below, the per-core mapping table may be implemented by a variety of different hardware configurations. For clarity, numeral 124 is used herein to denote any or all sets of one or more mapping table entries 124-0, 124-1, and 124-n. It is often advantageous to configure the software components such that the underlying hardware implementation is abstracted and the same standardized software interface is disclosed for any underlying hardware implementation. The software component may be adapted to configure the virtual-to-physical mapping table entries 124 in any one of the per-core mapping tables 106 and to purge or delete the virtual-to-physical mapping table entries in any one of the per-core mapping tables 106.
As described above, including multiple per-core mapping tables 106 provides significant advantages over conventional security methods. Having multiple per-core mapping tables 106 avoids continuously creating and destroying memory maps when changing contiguous memory locations, such as when operating on large data structures. Each of the per-core mappings 124-0, 124-1, and 124-n is separate from the shared page table 120 and does not interfere with the actual user space process. The use of per-core mapping table 106 avoids the overhead associated with invoking virtual machine hypervisors or other protected code to manage and maintain highly sensitive memory values. In fact, as described above, when the per-core mapping table is incorporated into the computing device 110, there are no hard requirements on the virtual machine hypervisor or other type of protected code module.
FIG. 2 illustrates a high level overview 200 of how the per-core mapping table is used to map virtual address space to physical address space provided by the disclosed aspects. The cores 202, 204, 206 operate using a virtual address space 250. For purposes of illustration, the overview 200 shows three cores 202, 204, and 206, but those skilled in the art will recognize that any number of two or more cores may be advantageously employed without departing from the spirit and scope of the disclosed embodiments. The MMU 220 then translates the virtual address 250 to generate a physical address 252 corresponding to the actual location in the physical memory in which the values of the operations of the cores 202, 204, 206 are stored.
Virtual address space 250 includes shared memory regions 208 and 218, shared memory regions 208 and 218 being translated by MMU 220 into physical memory regions 224 and 228 based on page tables (e.g., page table 120 described above). All cores 202, 204, and 206 share or have access to the page table. The shared page table allows all cores 202, 204, and 206 to access physical memory such that all cores 202, 204, and 206 use the same access attributes, such as read and/or write accesses.
Cores 202, 204, and 206 also have one or more corresponding private areas within virtual address spaces 210, 214, and 216, respectively. Private areas 210, 214, and 216 are only accessible by single cores 202, 204, and 206, respectively. MMU 220 is operable to map private areas 210, 214, and 216 to corresponding areas of physical memory 226, 230, and 222, as indicated by the different dashed line types connecting virtual address space 150 and physical address space 252.
To aid understanding, physical memory regions 222, 224, 226, 228, and 230 are illustrated as different regions of physical memory. However, dedicated areas of physical memory 222, 226, and 230 may overlap either of shared memory areas 224 and 228 or other dedicated memory areas 222, 226, and 230, as desired. In this way, each core 202, 204, and 208 remaps or accesses the same value in physical memory through different virtual-to-physical mappings, which may have different properties. This allows each core to access the same physical memory value through different mappings, where each mapping may have different properties.
FIG. 3 illustrates a flow chart 300 of a software process for managing per-core mapping tables provided by aspects of the disclosed embodiments. As described above, in some embodiments, it is desirable to provide a standard software interface for managing the per-core mapping table 106. Each of these routines discloses a standardized software interface and performs hardware or implements particular steps for performing desired operations on particular devices, such as device 100 described above.
The configuration software process 350 is used to configure mapping entries in the per-core mapping table. Configuration may be to add new mapping entries or update existing mapping entries as needed, and in embodiments where attributes are associated with mapping entries, may include setting any associated attributes. Configuration software process 350 begins at entry point 302, which in some embodiments may be a standardized entry point, configures mapping table entry 304 in the per-core mapping table, and returns to 306 the calling routine. In some embodiments, it may be advantageous to adjust the configuration software process 350 as needed to configure multiple mapping table entries in one or more per-core mapping tables.
The purge software process 352 is used to purge the mapping table entries in the per-core mapping table. The purge process 352 begins at entry point 308, which in some embodiments may be a standardized entry point, clears the mapping table entry 310 in the per-core mapping table, and returns 312 to the calling process. When needed, a purge process 352 may be provided to purge multiple mapping table entries from multiple per-core mapping tables by a single call purge process 352.
In one embodiment, additional software routines may be provided or existing routines may be modified to read one or more mapping table entries from one or more per-core mapping tables. It should be noted, however, that a routine that includes reading a mapping table entry may present a security risk and may therefore be undesirable in some embodiments.
The dedicated per-core mapping table, such as per-core mapping table 106 described above with reference to FIG. 1, may be implemented in any suitable manner. In one embodiment, a separate space for holding a set of mapping entries associated with each per-core mapping table, means for identifying cores that are undergoing memory access, and a mechanism for handling illegal memory accesses when needed may be included.
FIG. 4 illustrates an implementation form 400 for providing a per-core mapping table provided by aspects of the disclosed embodiments. For clarity, the illustration shown in FIG. 4 includes only a single core 402 of the multi-core device and a plurality of per-core mapping tables for translating virtual memory addresses 414. The single core 402 is suitable as any one of the plurality of cores 104. The plurality of per-core mapping tables 404 is suitable as the plurality of per-core mapping tables 104 described above with reference to FIG. 1.
In operation, when kernel 402 needs to access a memory location, it creates a virtual address 0x0???????????????414 to identify the virtual memory location of interest. To aid understanding, a 16 bit hexadecimal number is used here to represent a virtual address, such as virtual address 0x0???????????????414, where a question mark ("?") is used to represent any hexadecimal number, and unused address bits are represented by the value 0x0 in the higher-order hexadecimal number 414. In one embodiment, the unused address bits may be located anywhere within the virtual address and need not be located at the high order bits depicted in the exemplary embodiment shown in FIG. 4. Those skilled in the art will readily recognize that virtual addresses longer or shorter than the example address 414 with more or fewer unused bits may be advantageously employed without departing from the spirit and scope of the disclosed embodiments.
Core 402 will insert a core ID, e.g., 0x2, in the unused address bits 0x 0. For example, in the virtual address 416 shown, a value of 0x2 is used as the core ID. The full virtual address 416 including core id 0x2 is provided to the plurality of per-core mapping tables 404. Only one per-core mapping table 404-2 of the plurality of per-core mapping tables 404 is configured to generate a physical address 420 for a virtual address 416 that contains a particular core ID 0x2. The remaining per-core mapping tables 404-0, 404-1 … … 404-n will not generate a physical address for the virtual address 416 containing core id 0x2. In an apparatus having a plurality of cores 104 (such as the apparatus 100 described above), each core (104-0) of the plurality of cores 106 will be configured to use a unique core ID. The unique core ID is different from the core IDs used by the remaining cores 104-1 … … 104-n of the plurality of cores 106.
FIG. 5 illustrates another implementation form 500 for providing a per-core mapping table provided by aspects of the disclosed embodiments. For purposes of illustration, in the drawing of FIG. 5, an implementation form 500 is shown using the same single core 402 and multiple per-core mapping tables 404 in conjunction with FIG. 4.
Implementation form 500 includes a signal 514 for communicatively coupling core 402 with corresponding per-core mapping table 404-2. In operation, core 402 indicates via signal 514 that core 402 is accessing a memory location based on virtual address 512 and triggers per-core mapping table 404-2 to generate physical address 420. The signal 514 may be any suitable type of signal based on hardware, or other signal, that may be used to communicatively couple the core 402 to the corresponding per-core mapping table 404-2 and to couple the signal 514 to the corresponding per-core mapping table 404-2, which per-core mapping table 404-2 should generate a physical address. Physical memory address 420 may be generated based on the state of signal 514.
The per-core mapping table 404-2 is configured to selectively generate or not generate the physical address 420 based on the state of the signal 514. The per-core mapping table 404-2 is communicatively coupled to a single particular per-core mapping table. Thus, per-core mapping table 404-2 will generate physical address 420 based only on signal 514 from the corresponding core 402, and none of the remaining per-core mapping tables will generate physical addresses for virtual address 512 created by core 402.
Modern mobile communication devices, such as mobile phones, desktop computers, and tablet computers, are using more and more highly secure applications, such as banking applications and online stores, and so forth, and thus require a high degree of security. Incorporating the per-core mapping tables disclosed herein into mobile communication devices will significantly increase the security of the software execution environment in these devices and will add value to these devices. For example, in one embodiment, the apparatus 100 described above with reference to fig. 1 may be configured as or incorporated into a mobile communication device, thereby creating a mobile communication device with significantly improved software security.
Thus, while there have been shown, described, and pointed out fundamental novel features of the invention as applied to exemplary embodiments thereof, it will be understood that various omissions and substitutions and changes in the form and details of the devices and methods illustrated, and in their operation, may be made by those skilled in the art without departing from the spirit and scope of the invention. Further, it is expressly intended that all combinations of those elements that perform substantially the same function in substantially the same way to achieve the same results are within the scope of the invention. Furthermore, it should be recognized that structures and/or elements shown and/or described in connection with any form or embodiment of the disclosed invention may be incorporated in any other form or embodiment disclosed or described or suggested as a general matter of design choice. Accordingly, the invention is limited only by the scope of the appended claims.
Claims (8)
1. An apparatus for core-specific memory mapping, comprising a plurality of cores and a plurality of per-core mapping tables, wherein one of the plurality of per-core mapping tables comprises one or more mapping table entries, the per-core mapping table configured to generate a physical memory address based on a virtual memory address and the one or more mapping table entries, wherein
The per-core mapping table is configured to allow a respective one of the plurality of cores to generate the physical memory address based on the one or more mapping table entries and to prevent all remaining ones of the plurality of cores from generating the physical memory address based on the one or more mapping table entries;
the respective one of the cores is configured to encode a core ID within the virtual memory address, and each per-core mapping table is configured to generate or not generate the physical memory address based on the encoded core ID.
2. The apparatus of claim 1, wherein each of the one or more mapping entries comprises a set of one or more attributes, wherein each attribute is configured to generate or not generate the physical memory address based on a type of memory access being performed.
3. The apparatus of claim 2, wherein the type of memory access being performed comprises one or more of a memory read and a memory write.
4. The apparatus of any of claims 1-3, wherein the per-core mapping table is communicatively coupled to the respective one core by a hardware-based signal, the per-core mapping table configured to generate or not generate the physical memory address based on a state of the hardware-based signal.
5. A device according to claim 2 or 3, wherein the memory comprises program instructions which, when executed by the respective one core, cause the respective one core to:
configuring a mapping table item in the one or more mapping table items;
and clearing the mapping table items in the one or more mapping table items.
6. The apparatus of claim 5, wherein configuring the mapping table entry comprises configuring the one or more attributes and a physical memory address associated with the mapping table entry.
7. The apparatus of any of claims 1-3, further comprising one or more enclave mapping tables, wherein one of the one or more enclave mapping tables is associated with a respective set of one or more of the plurality of cores; the enclave mapping table is configured to generate physical addresses for cores in the group of one or more cores without generating physical addresses for cores not in the group of one or more cores.
8. An apparatus according to any one of claims 1 to 3, wherein the means for core specific memory mapping comprises a mobile communication device.
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/EP2019/057879 WO2020192925A1 (en) | 2019-03-28 | 2019-03-28 | Apparatus for core specific memory mapping |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113614703A CN113614703A (en) | 2021-11-05 |
| CN113614703B true CN113614703B (en) | 2024-02-09 |
Family
ID=65991837
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201980094627.9A Active CN113614703B (en) | 2019-03-28 | 2019-03-28 | Apparatus for core specific memory mapping |
Country Status (2)
| Country | Link |
|---|---|
| CN (1) | CN113614703B (en) |
| WO (1) | WO2020192925A1 (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11928214B2 (en) * | 2021-08-02 | 2024-03-12 | Dell Products L.P. | Enabling SPI firmware updates at runtime |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1661570A (en) * | 2004-02-26 | 2005-08-31 | 索尼株式会社 | Information processing system, information processing method, and computer program |
| US7249241B1 (en) * | 2004-04-29 | 2007-07-24 | Sun Microsystems, Inc. | Method and apparatus for direct virtual memory address caching |
| CN101042684A (en) * | 2006-03-21 | 2007-09-26 | 国际商业机器公司 | System and method for improving system DMA mapping while substantially reducing memory fragmentation |
| CN101315602A (en) * | 2008-05-09 | 2008-12-03 | 浙江大学 | Method for hardware realization of process internal memory management nucleus |
| CN102411510A (en) * | 2011-09-16 | 2012-04-11 | 华为技术有限公司 | Method and device for mapping service data streams on virtual machines of multi-core processor |
| EP2472412A1 (en) * | 2010-12-31 | 2012-07-04 | Telefonaktiebolaget L M Ericsson (Publ) | Explicitly regioned memory organization in a network element |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9152572B2 (en) * | 2011-12-30 | 2015-10-06 | Intel Corporation | Translation lookaside buffer for multiple context compute engine |
| US9135183B2 (en) * | 2013-03-13 | 2015-09-15 | Samsung Electronics Co., Ltd. | Multi-threaded memory management |
| US10509736B2 (en) * | 2016-07-29 | 2019-12-17 | Advanced Micro Devices, Inc. | Controlling access by IO devices to pages in a memory in a computing device |
-
2019
- 2019-03-28 CN CN201980094627.9A patent/CN113614703B/en active Active
- 2019-03-28 WO PCT/EP2019/057879 patent/WO2020192925A1/en active Application Filing
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1661570A (en) * | 2004-02-26 | 2005-08-31 | 索尼株式会社 | Information processing system, information processing method, and computer program |
| US7249241B1 (en) * | 2004-04-29 | 2007-07-24 | Sun Microsystems, Inc. | Method and apparatus for direct virtual memory address caching |
| CN101042684A (en) * | 2006-03-21 | 2007-09-26 | 国际商业机器公司 | System and method for improving system DMA mapping while substantially reducing memory fragmentation |
| CN101315602A (en) * | 2008-05-09 | 2008-12-03 | 浙江大学 | Method for hardware realization of process internal memory management nucleus |
| EP2472412A1 (en) * | 2010-12-31 | 2012-07-04 | Telefonaktiebolaget L M Ericsson (Publ) | Explicitly regioned memory organization in a network element |
| CN102411510A (en) * | 2011-09-16 | 2012-04-11 | 华为技术有限公司 | Method and device for mapping service data streams on virtual machines of multi-core processor |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113614703A (en) | 2021-11-05 |
| WO2020192925A1 (en) | 2020-10-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11138133B2 (en) | Multi-tenant encryption for storage class memory | |
| CN105373486B (en) | Remapping dynamic memory addresses in a computing system | |
| US11630920B2 (en) | Memory tagging for side-channel defense, memory safety, and sandboxing | |
| US11288213B2 (en) | Memory protection with hidden inline metadata | |
| US10176122B2 (en) | Direct memory access authorization in a processing system | |
| CN108062242B (en) | Computing system for securely executing secure applications in rich execution environments | |
| RU2602793C2 (en) | Method of modifying memory access grants in secure processor environment | |
| US10180913B1 (en) | Secure virtual access for real-time embedded devices | |
| US10303621B1 (en) | Data protection through address modification | |
| US20170308467A1 (en) | Shared memory in a secure processing environment | |
| CN112602060A (en) | Virtual machine registers in a computer processor | |
| US9418220B1 (en) | Controlling access to memory using a controller that performs cryptographic functions | |
| CN106716435B (en) | Interface between a device and a secure processing environment | |
| US9367478B2 (en) | Controlling direct memory access page mappings | |
| US20220180009A1 (en) | Peripheral component interconnect express protection controller | |
| US10331591B2 (en) | Logical-to-physical block mapping inside the disk controller: accessing data objects without operating system intervention | |
| US20160188251A1 (en) | Techniques for Creating a Notion of Privileged Data Access in a Unified Virtual Memory System | |
| CN113614703B (en) | Apparatus for core specific memory mapping | |
| US20200192825A1 (en) | Security for virtualized device | |
| US20190377671A1 (en) | Memory controller with memory resource memory management | |
| US11119941B2 (en) | Capability enforcement controller | |
| CN113168380B (en) | Electronic device and address access method | |
| CN108932205B (en) | Method and equipment for defending RowHammer attack | |
| CN116561824A (en) | Method and apparatus for managing memory in a confidential computing architecture |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |