Managing memory in electronic devices
By creating logical areas of the same size in the smart card and using permission mapping tables, the virtualization problem of multiple operating systems is solved, fast context switching and flexible memory allocation is achieved, and hardware and power consumption is reduced. It is suitable for smart cards with limited capacity Resources and environment.
Patent Information
- Application Number
- CN202010894122.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2019-09-12
- Filing Date
- 2020-08-31
- Publication Date
- 2025-01-07
- Estimated Expiration
- 2040-08-31
AI Technical Summary
The prior art is difficult to realize the complete virtualization of multiple operating systems in smart cards or secure components, especially under limited RAM resources, which cannot achieve fast context switching and flexible memory allocation, and there is a large limitation on chip memory resources.
By creating logical regions of the same size in the logical address space and mapping a subset of continuous logical addresses to the corresponding physical memory areas, using the permission mapping table to determine the access permissions of each logical region, realizing the effectiveness of the physical address Access and memory virtualization.
It realizes fast context switching and flexible memory allocation in smart cards, reduces hardware and power consumption, supports independent updates of multiple operating systems and effective management of memory resources.
Smart Images

Figure CN112486855B_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of memory management, and in particular to a method of managing memory in an electronic device such as a smart card with a security element. The present invention further relates to a controller for managing memory in an electronic device, and to a method of determining a physical address in a physical memory area using such a controller. Background Art
[0002] A "secure element" is a miniature security device that uses, for example, a smart card with tamper-proof countermeasures. It is typically embedded in an operating system (OS) that provides a rich and open execution environment with complex management options, such as installation and management under the control of multiple parties in the application and key domains.
[0003] Secure elements are used in an increasing number of applications in many markets: mobile payments, transport ticketing, phone low-level security functions, mobile network authentication (eUICC), passports, IoT, car access, etc.
[0004] All of these markets and applications have very different security requirements and certification processes and are tied to different ecosystems, so it is becoming increasingly difficult to host all of them on a single operating system while satisfying all participants.
[0005] One possible solution to this problem would be to use multiple independent discrete devices. However, this significantly increases the cost and footprint for the customer.
[0006] Another possible solution is to integrate multiple independent OS in a single device. This requires an underlying "virtualization" system consisting of hardware and software cooperation to prevent interference between OS, while allowing sharing and virtualization of device resources.
[0007] In the context of large computing devices such as PCs, virtualization systems are well known. However, the hardware architecture that supports virtualization in this context is not suitable for the limited resources of smart card devices:
[0008] -Memory is usually divided into relatively large pages (4KB or 8KB), which creates internal fragmentation. This is not a problem for systems with megabytes or gigabytes of memory, but it will be a problem for devices with tens of kilobytes of RAM.
[0009] -Hardware allows any virtual page to be remapped to any physical page, but this requires a relatively large page table. For example, on an ARM Cortex-A processor, the minimum size of a page table is 1KB, and there must be one such table per virtualized OS, which in turn will be a huge drain on resources in a smart card device.
[0010] On the other hand, current embedded processors, such as ARM's Cortex M processor with TrustZone, also provide a certain degree of virtualization for embedded applications. However, the virtualization of the memory system is primitive:
[0011] - No virtual address space, which does not allow building sandboxes for applications and limits the ability to update persistent code and data across multiple components
[0012] - Only a limited number of memory regions can be defined (e.g. only up to 16 regions with 32-byte alignment at significant hardware cost)
[0013] As a result, the default Cortex M TrustZone system is too limited to implement a fully virtualized system of multiple OSes, at least not without many reconfigurations and memory copies during context switches.
[0014] Therefore, there may be a need for a way to manage memory in an electronic device, especially in a smart card or secure element, without the disadvantages and limitations described above. In particular, there may be a need for a way to virtualize memory in an OS in a device with very limited RAM resources such as a smart card, to achieve at least the following advantages:
[0015] - Fast context switching between OSes and between privileged contexts within each OS
[0016] -Flexible allocation of memory to each OS, allowing independent field updates of each OS or part of it
[0017] -Supports multi-OS virtualization through partitioning and restricts access to on-chip memory resources. Summary of the invention
[0018] This need may be met by the subject matter according to the independent claims. Advantageous embodiments of the invention are set forth in the dependent claims.
[0019] According to a first aspect of the present invention, a method for managing memory in an electronic device is provided, the method comprising creating a set of logical areas of equal size in a logical address space, each logical area comprising a plurality of consecutive logical addresses, and mapping a subset of the consecutive logical addresses within each logical area to a set of physical addresses within a corresponding physical memory area, the subset of the consecutive logical addresses comprising a first logical address within the logical area, the first logical address being mapped to a base address within the corresponding physical memory area.
[0020] The first aspect is based on the idea of mapping logical areas of the same size to corresponding physical memory areas of separate sizes, which is performed in a manner that the physical address corresponding to any given logical address (i.e., the physical memory address within the physical memory area) can be identified and accessed with minimal operations. More specifically, since all logical areas are of the same size, it is easy to determine which logical area a given logical address belongs to. In addition, because the first logical address within the logical area is always mapped to the physical base address within the corresponding physical memory area, the physical address can be determined by adding the offset value corresponding to the offset from the first logical address within the logical area to the corresponding physical base address. Therefore, unlike other technologies for memory management that generally require numerous comparators, the method according to this aspect of the present invention allows very efficient access to memory with minimal hardware and power consumption.
[0021] According to an embodiment, the method further comprises creating a permission map associating a permission type to each logical region and each execution context of the plurality of execution contexts.
[0022] The permission mapping allows determining whether a logical region (and thus the corresponding physical memory region) is accessible to a certain execution context. In other words, some execution contexts can access some specific memory regions but not other memory regions. This is a basic function in a virtualization system.
[0023] According to another embodiment, each execution context of the plurality of execution contexts corresponds to one of a plurality of operating systems.
[0024] According to another embodiment, the step of creating a permission mapping includes creating a first permission table, wherein the first permission table indicates, for each logical area, whether the logical area is accessible to each of a plurality of execution contexts, the first permission table further indicating an area type for each logical area, and creating a second permission table, wherein the second permission table indicates, for each area type, whether each of a plurality of permission types is given.
[0025] In other words, the first table contains, for each logical region, an indication of those execution contexts that can access the logical region, and an indication of those execution contexts that cannot access the logical region. In addition, the first permission table indicates a region type for each logical region. In particular, the region type can be used to specify certain types of access permissions to the logical region.
[0026] According to another embodiment, the plurality of permission types include read permission, write permission, execute permission, and privileged permission.
[0027] According to a second aspect of the present invention, there is provided a controller for managing a memory in an electronic device, the controller comprising a memory and a processing unit. The memory comprises a set of logical regions of equal size in a logical address space, each logical region comprising a plurality of continuous logical addresses, and a mapping of a subset of continuous logical addresses in each logical region to a set of physical addresses in a corresponding physical memory region, the subset of continuous logical addresses comprising a first logical address in the logical region, the first logical address being mapped to a base address in the corresponding physical memory region. The processing unit is operable to access the memory and is adapted to determine a physical address corresponding to any logical address based on the logical region and the mapping.
[0028] The second aspect is based on substantially the same idea as the first aspect described above. More specifically, the second aspect relates to a controller utilizing the mapping and structure provided by the method according to the first aspect to determine the physical address corresponding to any logical address.
[0029] The controller comprises a memory and a processing unit. The controller may be a separate unit or an integrated part of other hardware in the electronic device. It should be emphasized that the logical address space does not occupy a large amount of memory. In particular, the logical address space can be stored in a compact manner, for example, as data indicating the number of logical regions, the (uniform) size of the logical regions and the first logical address of the first logical region. These values make it possible to determine the logical address corresponding to any other logical region.
[0030] According to another exemplary embodiment, the processing unit is adapted to determine the physical address by: identifying a logical area containing a logical address; determining an offset of the logical address within the identified logical area relative to a first logical address; identifying a base address within the corresponding physical memory area; and determining the physical address by adding the identified base address and the determined offset.
[0031] Since all logical regions are the same size, the logical region containing the logical address can generally be determined by dividing the logical address by the region size. The offset is determined as the distance (i.e., the difference) between the logical address in the identified logical region and the first logical address. The base address in the corresponding physical memory region is identified by mapping.
[0032] According to another exemplary embodiment, the memory further comprises a permission mapping associating a permission type to each logical region and one or more execution contexts of the plurality of execution contexts, and the processing unit is further adapted to determine the permission type for the selected logical region and the selected execution context.
[0033] The permission mapping allows the processing unit to determine whether a logical region (and thus the corresponding physical memory region) is accessible to a certain execution context. In other words, some execution contexts can access some specific memory regions but not other memory regions. This is a basic function in a virtualized system.
[0034] According to another exemplary embodiment, each execution context of the plurality of execution contexts corresponds to one of the plurality of operating systems.Alternatively or additionally, each execution context may be one of the plurality of processes executed by a single operating system.
[0035] According to a further exemplary embodiment, the permission map comprises, for each logical region, a first permission table indicating whether the logical region is accessible to each of a plurality of execution contexts, the first permission table further indicating a region type for each logical region. The permission map further comprises, for each region type, a second permission table indicating whether each of a plurality of permission types is given, and the processing unit is further adapted to identify a region type corresponding to the selected logical region and to identify a permission type given for the identified region type.
[0036] In other words, the first table contains, for each logical region, an indication of those execution contexts that can access the logical region, and an indication of those execution contexts that cannot access the logical region. In addition, the first permission table indicates a region type for each logical region. In particular, the region type can be used to specify certain types of access permissions to the logical region.
[0037] According to another exemplary embodiment, the plurality of permission types include a read permission, a write permission, an execute permission, and a privileged permission.
[0038] According to a third aspect of the present invention, there is provided a method for determining a physical address in a physical memory area using a controller, the controller comprising a memory, the memory comprising a set of logical areas of equal size in a logical address space, each logical area comprising a plurality of continuous logical addresses. The memory further comprises a mapping of a subset of continuous logical addresses in each logical area to a set of physical addresses in a corresponding physical memory area, the subset of continuous logical addresses comprising a first logical address in the logical area, the first logical address being mapped to a base address in the corresponding physical memory area. The method comprises receiving a logical address; identifying a logical area containing a logical address; determining an offset of the logical address in the identified logical area relative to the first logical address; identifying a base address in the corresponding physical memory area; and determining the physical address by adding the identified base address and the determined offset.
[0039] The third aspect is substantially based on the same idea as the first and second aspects described above. In particular, the third aspect relates to a method corresponding to the operation of the controller according to the second aspect.
[0040] According to an exemplary embodiment, the memory further includes a permission map associating a permission type to each logical region and each execution context of the plurality of execution contexts, and the method further includes determining the permission type for the selected logical region and the selected execution context.
[0041] The permission mapping allows determining whether a logical region (and thus the corresponding physical memory region) is accessible to a certain execution context. In other words, some execution contexts can access some specific memory regions but not other memory regions. This is a basic function in a virtualization system.
[0042] According to another exemplary embodiment, each execution context of the plurality of execution contexts corresponds to one of a plurality of operating systems.
[0043] According to a further exemplary embodiment, the permission mapping includes, for each logical region, a first permission table indicating whether the logical region is accessible to each of a plurality of execution contexts, the first permission table further indicating a region type for each logical region. The permission mapping further includes, for each region type, a second permission table indicating whether each of a plurality of permission types is given. The method further includes identifying a region type corresponding to the selected logical region, and identifying a permission type given for the identified region type.
[0044] In other words, the first table contains, for each logical region, an indication of those execution contexts that can access the logical region, and an indication of those execution contexts that cannot access the logical region. In addition, the first permission table indicates a region type for each logical region. In particular, the region type can be used to specify certain types of access permissions to the logical region.
[0045] According to another exemplary embodiment, the plurality of permission types include a read permission, a write permission, an execute permission, and a privileged permission.
[0046] It should be noted that embodiments of the invention have been described with reference to different subject matters. In particular, some embodiments have been described with reference to method claims and other embodiments have been described with reference to apparatus claims. However, one skilled in the art will appreciate from the foregoing and the following description that, unless otherwise indicated, any combination of features associated with different subject matters, in particular a combination of features of method claims and features of apparatus claims, in addition to any combination of features belonging to one type of subject matter, are also disclosed with this document.
[0047] The aspects defined above and further aspects of the invention will be apparent from the examples of embodiment to be described hereinafter and are explained with reference to the examples of embodiment.The invention will be described in more detail hereinafter with reference to examples of embodiment but to which the invention is not limited. BRIEF DESCRIPTION OF THE DRAWINGS
[0048] Figure 1 A block diagram of a memory controller according to an exemplary embodiment is shown.
[0049] Figure 2 A mapping between a logical address space and a physical memory according to an exemplary embodiment is shown.
[0050] Figure 3 A permission map including two tables according to an exemplary embodiment is shown. DETAILED DESCRIPTION
[0051] The illustration in the drawings is schematically. It should be noted that in different figures, similar or identical elements are provided with the same reference signs or with reference signs which differ only within the first digit.
[0052] Figure 1 A block diagram of a memory controller 100 according to an exemplary embodiment is shown. The controller 100 includes a memory 110, a processing unit 120, an input 130, and an output 140. The memory 110 includes data representing a set of logical regions of equal size in a logical address space, each logical region including a plurality of consecutive logical addresses. The memory 110 further includes data representing a mapping of a subset of consecutive logical addresses within each logical region to a set of physical addresses within a corresponding physical memory region, the subset of consecutive logical addresses including a first logical address within the logical region, the first logical address being mapped to a base address within the corresponding physical memory region. An example of data in the memory 110 is shown in Figure 2 , and will be discussed in further detail below. The processing unit is operable to access the memory (110) and is further adapted to determine the physical address corresponding to any logical address based on the logical regions and the mapping. The logical address is received at input 130 and the determined physical address is output at output 140, preferably together with associated permission data, as will be discussed further below.
[0053] Figure 2A mapping 200 between a logical address space 210 and a physical memory 220 according to an exemplary embodiment is shown. In this exemplary embodiment, the logical address space 210 includes a set of logical regions L#0, L#1, ..., L#254, L#255 of equal size. Furthermore, in this example, the size of each logical region is 512KB. As will be readily appreciated by a skilled person, any number of regions and any region size are possible.
[0054] Thus, in conventional hexadecimal notation, the first logical address of logical region L#0 is 0x0000:0000, the first logical address of logical region L#1 is 0x0008:0000, and so on. Each subset of logical regions (containing the first logical address) is mapped to a corresponding physical memory region P#0, P#1, ... P#255. The size of each physical region thus corresponds to the size of the subset, and can therefore vary between 0 (zero) and 512 KB. The portion of the logical region not contained in the subset is Figure 2 is hatched or shaded. Map 200 contains corresponding links between the first logical address in each logical area and the base address in the corresponding physical memory area. More specifically, the link between the first logical address of L#0, i.e., 0x0000:0000, and the base address of physical memory area P#0 is represented by arrow 201; the link between the first logical address of L#1, i.e., 0x0008:0000, and the base address of physical memory area P#1 is represented by arrow 203; and the link between the first logical address of the next logical area (L#2, not shown), i.e., 0x0010:0000, and the base address of the corresponding physical memory area (P#2, not shown) is represented by arrow 205. Figure 2 In the example of , logical region L##254 is empty, and therefore both arrows 206 and 207 point to the same physical memory address, namely the base address of physical memory region P#255. Arrows 202, 204 and 208 show the corresponding links between the last logical address in logical regions L#0, L#1 and L#255 and the last physical address in physical memory regions P#0, P#1 and P#255, respectively.
[0055] Back to Figure 1 , the processing unit 120 is adapted to determine a physical address corresponding to a logical address received at the input 130 by: identifying a logical region containing the logical address; determining an offset of the logical address relative to the first logical address within the identified logical region; identifying a base address within the corresponding physical memory region; and determining the physical address by adding the identified base address and the determined offset. Thus, again referring to Figure 2, if a logical address 0x000A:0000 is received at input 130, the processing unit determines (by dividing by the size of the logical region) that this address is within logical region L#1 and has an offset relative to the first logical address 0x0008:0000 of this logical region equal to 2:0000 (i.e., 131072 in decimal). Subsequently, once a base address within the corresponding physical memory region P#1 is identified, the physical memory address corresponding to the received logical address is determined by adding the offset to the base address.
[0056] To summarize, the physical memory (such as flash memory or RAM) is first divided into several logical regions located at fixed logical addresses and separated by large unmapped gaps. For example, there may be 256 logical regions, each of a fixed size of 512KB, and located at the following logical addresses:
[0057] - Logical area L#0: 0x0000:0000 to 0x0007:FFFF
[0058] - Logical region L#1: 0x0008:0000 to 0x000F:FFFF
[0059] -…
[0060] - Logical region L#254: 0x07F0:0000 to 0x07F7:FFFF
[0061] - Logical region L#255: 0x07F8:0000 to 0x07FF:FFFF
[0062] Each region may point to real physical memory at the beginning of the region, with the rest of the region being unmapped. For example, if the mapping granularity is equal to 0.5KB, then physical region P#0 may then be configured to contain 100.5KB of the total logical size of 512KB, physical region P#1 may then be configured to contain 23.5KB of the total logical size of 512KB, etc. The granularity may depend on the type of memory (e.g., 16 bytes for RAM and 512 bytes for flash memory).
[0063] The controller hardware 100 "compresses" the logical address into a physical address that corresponds to the actual physical memory, such as Figure 2 In general, the low-order bits of a logical address, such as Figure 2 Bits 0 to 18 in are used to check that the access is within the range of physical addresses assigned to the region, while the high-order bits, e.g. Figure 2 Bits 19 and above in are used to determine which area to access. In other words, the logical address maps to, for example Figure 2The size of the individual physical area or physical address range of P#0, P#1, ... P#255 in the lower bit ( Figure 2 It is limited in bits 0 to 18 in .
[0064] The controller 100 uses an auxiliary RAM or register containing the base physical address of each of the 256 logical regions. The controller applies the following formula to determine the physical address from the logical address:
[0065] - Region number = logical address [26:19]
[0066] -Offset in region = logical address [18:0]
[0067] - Physical address = base address [region number] + offset in region
[0068] Logical regions provide at least the following two advantages:
[0069] Each region can be resized and filled independently of other regions by converting only the memory contents and updating the value of each displacement above the region being resized. While this is a relatively heavy operation, it rarely occurs in a typical secure element operating system, for example only during application installation or system updates. In addition, resizing a region does not change the logical addresses of the existing contents of other regions, which can be used for independent updates of the OS or parts of the OS.
[0070] The logical address space is very regular, which simplifies the permission system: it is actually very fast to determine in hardware which is a region of logical addresses and apply uniform permissions per region. This will be compared to systems where the address space is more "compact" (no gaps), where fine-grained address comparators are needed, for example to achieve a granularity of 32 bytes. This requires many hardware resources, consumes more power and will therefore always have a limited number of permission regions.
[0071] The memory 110 of the controller 100 may further include a permission mapping indicating whether each logical region is accessible to one or more of a plurality of execution contexts, particularly an operating system (OS), and the processing unit 120 may be further adapted to determine whether the selected logical region is accessible to the selected execution context. Figure 3An exemplary permission map including two tables 310, 320 according to such an exemplary embodiment is shown. The first table 310 contains one entry or row for each region with an indication of whether the corresponding region is accessible for each of the execution contexts Ctx0, Ctx1, ... and an indication of the region type. The second table 320 contains one row or entry for each region type with an indication of whether the corresponding region type has a read permission R, a write permission W, an execution permission X, and a privileged permission P. In operation, the controller 100 uses the two tables 310, 320 as follows: For any current execution context (as represented by arrow 312) and a logical address to be checked (as represented by arrow 314), the first table 310 is used to determine whether access is allowed 1 or not allowed 0 for the current execution context. The result is output at 316. In addition, the corresponding region type is identified and output at 318. Subsequently, using the second table 320, the permission type corresponding to the identified region type is identified, that is, it is determined whether each of the read permission R, the write permission W, the execution permission X, and the privileged permission P is given. The result may be output as a four-bit vector at 322. If access is denied in the first table, the vector may have a value of 0000.
[0072] As shown above, the permission system uses two levels of permission tables 310, 320 to allow fast context switching between OSes with limited resource consumption:
[0073] - The first level table (TABLE1 310) provides the following for each region:
[0074] o Whether the region is accessible to a set of "execution contexts", e.g. one context per OS
[0075] o A small token called "region type". For example, the region type can be encoded on 5 bits, which allows up to 32 different region types
[0076] -The second level table (TABLE2 320) provides four permission bits (read, write, execute, privileged) for each region type.
[0077] The described permissions system has several advantages, including:
[0078] - The first table 310 (TABLE 1) is relatively large (about 16 bits per region, i.e. 512 bytes for 256 regions), but only a single copy of the table is needed, since overall access to the logical regions is static and can only be changed when updating the system configuration
[0079] - The second table 320 (TABLE2) is compact (32 x 4 bits = 4 words), which allows fast context switching between OSes: the hypervisor must only reload these four words to context switch the entire memory view of an OS
[0080] - Fine-grained permissions can be assigned only per region type instead of per region, but there are still a relatively high number of region types, and they allow grouping of multiple regions that share the same permissions. For example, all code regions of an OS can share the same region type and still be separated in the logical address space, which allows individual updates to these parts
[0081] -TABLE1 310 allows regions to be accessible to a single context or to multiple contexts, thus supporting private and shared regions
[0082] Furthermore, the described system is suitable for fast hardware implementation because:
[0083] -TABLE2 320 is extremely small and can therefore be implemented entirely in fast trigger registers
[0084] - Extracts of TABLE1 310 may be kept in a fast cache (translation lookaside buffer). This cache needs to be invalidated only when TABLE1 310 changes. When loading TABLE2 320, the contents of the cache are still valid
[0085] - Thanks to the logical region address system, the region number can be quickly determined by extracting a few bits from the logical address (eg bits 26:19).
[0086] The initial motivation for embodiments of the present invention is to build a system with two operating systems in a single device running a single processor core: (1) a secure element OS, which takes care of payment, transportation, and device security applications; and (2) a UICC OS, which implements operations on behalf of the mobile network operator.
[0087] The virtualization system allows for separate authentication of the two OS's and separate updates of the two.
[0088] Another motivation for virtualizing the system is to isolate the implementation of the communication protocol in an OS separate from the implementation of the main OS. It is expected that this will simplify the certification of the JCOP OS, as the communication protocol stack will not need to be certified at the same level as the main JCOP OS.
[0089] Another application of the system is the ability to host a third-party native OS alongside the JCOP. Under the control of the hypervisor, this third-party OS will be able to run in privileged mode, handle interrupts and interact with peripherals.
[0090] It should be noted that the use of terms such as “upper”, “lower”, “left side” and “right side” only refers to the orientation of the corresponding drawings, unless otherwise indicated.
[0091] It should be noted that the term "comprising" does not exclude other elements or steps, and the use of the article "a" or "an" does not exclude a plurality. In addition, elements described in connection with different embodiments may be combined. It should also be noted that the reference numerals in the claims should not be interpreted as limiting the scope of the claims.
Claims
1. A method for managing a memory in an electronic device, characterized in that: The method comprises Creating a set of logical regions of equal size in the logical address space, each logical region comprising a plurality of consecutive logical addresses, and A subset of continuous logical addresses within each logical region is mapped to a set of physical addresses within a corresponding physical memory region, wherein logical regions of the same logical region size are separated from each other by unmapped gaps, and the subset of continuous logical addresses includes a first logical address within the logical region, and the first logical address is mapped to a base address within the corresponding physical memory region.
2. The method according to claim 1, characterized in that Further includes A permission map is created that associates a permission type to each logical region and each execution context in the plurality of execution contexts.
3. The method according to claim 2, characterized in that Each execution context of the plurality of execution contexts corresponds to one of a plurality of operating systems.
4. The method according to claim 2 or 3, characterized in that: Creating the permission map includes creating a first permission table, the first permission table indicating, for each logical region, whether the logical region is accessible to each of the plurality of execution contexts, the first permission table further indicating a region type for each logical region, and A second permission table is created, the second permission table indicating, for each area type, whether each of a plurality of permission types is given.
5. The method according to claim 4, characterized in that The multiple permission types include read permission, write permission, execute permission and privileged permission.
6. A controller (100) for managing a memory in an electronic device, characterized in that: The controller includes A memory (110) comprising A set of logical areas (L#0, L#1, L#254, L#255) of the same size in a logical address space (210), each logical area including a plurality of consecutive logical addresses, and A mapping (200) of a subset of consecutive logical addresses within each logical region to a set of physical addresses within a corresponding physical memory region (P#0, P#1, P#255), wherein logical regions of the same size are separated from each other by unmapped gaps, the subset of consecutive logical addresses comprising a first logical address within the logical region, the first logical address being mapped to a base address within the corresponding physical memory region, and A processing unit (120) is operable to access the memory (110) and is adapted to determine a physical address corresponding to any logical address based on the logical region and the mapping.
7. The controller according to claim 6, characterized in that: The processing unit is adapted to determine the physical address by performing the following operations identifying the logical region containing the logical address, determining an offset of the logical address within the identified logical region relative to the first logical address, identifying the base address within the corresponding physical memory region, and The physical address is determined by adding the identified base address and the determined offset.
8. The controller according to claim 6 or 7, characterized in that: wherein the memory further comprises a permission map that associates a permission type to each logical region and each execution context in the plurality of execution contexts, and The processing unit is further adapted to determine a permission type for the selected logical region and the selected execution context.
9. The controller according to claim 8, characterized in that: The permission mapping includes a first permission table indicating, for each logical region, whether the logical region is accessible to each of a plurality of execution contexts, the first permission table further indicating a region type for each logical region, and a second permission table indicating, for each region type, whether each of a plurality of permission types is given, and The processing unit is further adapted to identify a region type corresponding to the selected logical region and to identify the permission type given for the identified region type.
10. A method for determining a physical address in a physical memory area using a controller, characterized in that: The controller includes a memory, the memory includes a set of logical regions of equal size in a logical address space, each logical region includes a plurality of consecutive logical addresses, and a mapping of a subset of the consecutive logical addresses in each logical region to a set of physical addresses in a corresponding physical memory region, the subset of the consecutive logical addresses including a first logical address in the logical region, the first logical address being mapped to a base address in the corresponding physical memory region, the method including Receive logical address, identifying the logical region containing the logical address, determining an offset of the logical address within the identified logical region relative to the first logical address, identifying the base address within the corresponding physical memory region, and The physical address is determined by adding the identified base address and the determined offset, wherein logical regions of the same logical region size are separated from each other by unmapped gaps.
Citation Information
Patent Citations
Memory system
CN109144888A
Apparatus, system, and method for implementing protected virtual memory subcontexts
CN1924815A
System, method and memory device providing data scrambling compatible with on-chip copy operation
WO2009088920A1