Abstract:
Protection entries and techniques for providing fine granularity computer memory protection are described herein. A method of protecting a computer memory may include separating or parsing the computer memory, containing data or code, into blocks and creating protection entries for each block. The protection entries optionally include a reference field for identifying a block of memory, and a protection field for specifying one or more levels of access to the identified block of memory. The protection entries may then be used to pass messages between various system entities, the messages specifying one or more levels of access to the one or more blocks of memory or code.

Description:
BACKGROUND 
     Computers malfunction or crash when a program corrupts the random access memory (RAM) that is being used by another program. Memory corruption may be caused, for example, by one computer program overwriting a memory segment being used by another computer program. Memory may also be corrupted by computer viruses. To reduce the risk of memory corruption and computer viruses, computer operating systems typically employ “system pages” and “protection rings” to protect the memory being used by different computer programs. Operating systems also protect process memory through the use of “process private pages” which reduce the risk of one process corrupting memory in another process. 
     System pages and process private pages prevent processes from interfering with the memory spaces that belong to the system and other processes by employing a separate address for each memory space. However, each process sees the entire address space as being uniquely assigned to it. To ensure that processes do not interfere with one another, operating systems typically maintain page tables that map the memory spaces virtual address to its corresponding physical address. 
     A protection ring represents a layer of privilege within the computers architecture. The protection rings are arranged in a hierarchy from the most privileged and trusted ring (i.e., operating system kernel ring, hypervisor ring) to the least privileged and trusted ring (i.e., process or application ring). The inner ring “Ring 0” for the kernel or “Ring −1” for a hypervisor has the most privileges and interacts most directly with the physical hardware (i.e., CPU and memory). Special gates between the rings allow the outer rings (e.g., Rings, 1, 2, and 3) to access an inner ring&#39;s resources (e.g., Rings −1, 0, and 1) in a defined manner. Controlling or gating access between the rings improves security by preventing programs from one ring or privilege level from misusing the memory intended for another program. 
     Modern computer operating systems have linear addressing schemes in which each process has a virtual address space, typically referred to as “process private pages.” A page of computer memory is typically 4K bytes or larger in size. In comparison, most data structures range in size from a few bytes to a few hundred bytes. Accordingly, the memory protection techniques employed by current operating systems have relatively coarse granularity. 
     Although system pages and protection rings are routinely used to provide memory protection, they have significant disadvantages when concurrent or simultaneous processing is performed. For example, programs are typically allowed to share memory only if the memory region resides at a virtual address that is mapped to each processes&#39; address space. Moreover, coarse granularity protection which operates at the page level (e.g., typically 4K bytes) is inefficient given that the most data structures only are a few bytes in size. Lastly, transferring control between software modules is burdensome since accesses to entire pages of memory are typically involved and the page may contain data in which protection should not be changed. 
     Accordingly, there is a need for an improved method for providing fine granularity memory protection without the burden of additional inter-process communication, the inefficiency of coarse granularity memory protection, and the burden of transferring control to entire pages of memory. 
     SUMMARY 
     Protection entries and techniques for providing fine granularity computer memory protection are described herein. 
     In one implementation, a method for protecting computer memory may include separating or parsing computer memory or code into blocks and creating protection entries for each block. The protection entries may comprise a reference field for identifying the block of memory or code, and a protection field for specifying one or more levels of access to the block of memory or code. The protection entries may then be used to pass messages between various system entities. The protection entries or messages may specify one or more levels of access to one or more blocks of memory which may contain data or code. 
     In another implementation, a protection entry for implementing computer memory protection may include a reference field for identifying a portion of computer memory that is being protected and an access protection field for controlling access to that portion of computer memory. 
     Other message structures and methods according to other embodiments will become apparent to one with skill in the art upon review of the following drawings and detailed description. It is intended that all such additional message structures and methods be included within this description, be within the scope of the present disclosure, and be encompassed by the accompanying claims. 
     This summary is not intended to identify the essential features of the claimed subject matter, nor is it intended to determine the scope of the claimed subject matter. 
    
    
     
       BRIEF DESCRIPTIONS OF THE DRAWINGS 
       The disclosure is made with reference to the accompanying figures. In the figures, the left most reference number identifies the figure in which the reference number first appears. The use of the same reference numbers in different figures indicates similar or identical terms. 
         FIG. 1  depicts an illustrative protection entry for implementing fine granularity memory protection. 
         FIG. 2  illustrates how a computer system may create the protection entries. 
         FIG. 3  depicts an illustrative hierarchal arrangement of protection entries. 
         FIG. 4  illustrates how the protection entries may be arranged in a hierarchical manner. 
         FIG. 5  illustrates a protection entry with inherited access rights loosing those rights when it completes its task. 
         FIG. 6  illustrates a lower level entry updating its access rights from pass through to delegated access if a higher level entity completes or gives up access. 
         FIG. 7  illustrates how protection entries may protect blocks of computer memory with various sizes. 
         FIG. 8  illustrates message passing between two threads in a single application. 
         FIG. 9  illustrates message passing between two applications within a single memory space. 
         FIG. 10  illustrates message passing between two tasks by employing a run-time layer message. 
         FIG. 11  illustrates the access rights that lower and higher level processes may grant and acquire. 
     
    
    
     DETAILED DESCRIPTION 
     The present disclosure generally relates to computer memory protection, and more specifically to protection entries and methods for providing fine granularity memory protection. 
     Computer operating systems typically execute several processes simultaneously by switching between processes. However, as more processes are executed by a computer operating system the individual processing period becomes shorter or the delay between executing processes becomes longer. To overcome these issues, current computers may employ multiple computer processors. Multi-core processors combine two or more computer processors into a single socket, thus providing faster processor speeds, enhanced thermal management, and more efficient packaging. However, as the number of processor cores increase, much more concurrent processing occurs as additional requests are processed simultaneously. Specifically, software entities such as application programs, run-time layers, operating systems, and hypervisors are executed concurrently as processes are executed concurrently. 
     Current computer programs could greatly benefit from fine granularity data protection since data structures could be passed between various system entities such as processes, applications, runtime layers, operating systems and hypervisors. Moreover, fine granularity data protection also ensures that various data requests are synchronized between the system entities. 
     The protection entries and the methods of implementing them, provide the capability to move data within and between various processes (e.g., applications, run-time layers, operating systems, hypervisors, to name a few), provide increased security for the multiple applications running in a single address space, allows data to pass through an entity without the entity accessing the data, and allows data to be shared among various entities within a software system, yet only allow a single entity at a time access to the data. In summary, these protection entries enable concurrent computer processing with improved data integrity, software reliability and security. 
     Protection Entries for Enabling Fine Granularity Data Protection 
     In general, the fine granularity memory protection decouples memory protection from virtualization, allowing protection domains to vary in size, as well as allowing memory protection to be provided in both physical and virtual memory. Fine granularity protection also allows ownership or access rights to data or code to be associated with a system entity or address space. Finally, fine granularity protection allows access protection in terms of read access, write access, execute access, pass-through access, inherited access, delegated access, exclusive access, shared access, or a combination of these. 
       FIG. 1  illustrates an illustrative protection entry  100  for implementing fine granularity data protection. The last eight bits define the level of access protection  102  assigned or provided to a block of computer memory which could contain data or code. The first three bits define read access “R”  104 , write access “W”  106 , and execute access “E”  108 . If the read bit  104  is set, the entity is allowed to read the data in the block of computer memory. If the write bit  106  is set, the entity is allowed to write to the block of computer memory. Finally, if the execute bit  108  is set, the entity is allowed to execute its process using the code in the memory block. 
     The next five protection bits denote whether access is allowed to “pass-through” “P”  110  to another process, whether access was inherited “I”  112  from another process, whether access can be delegated “D”  114  to another process, and whether a process has exclusive access “El”  116  or shared access “Sh”  118 . 
     If a lower level process gives “pass-through” “P”  110  access to a higher level process, access to the block of memory is defined by the entities other protection bits (i.e., read, write, execute). For example, if the pass-through bit “P”  110  is set, and the read  104 , write  106 , and execute  108  bits are not set, then the lower level system entity (e.g., hypervisor, operating system, application, run-time, task) transfers access to another entity, but cannot access the data itself. 
     IF a higher level entity “inherits” “I”  112  access from a lower level entity, the lower level entity retains access to the block of memory, and the higher level entity gains access to the block of memory, again limited by its own protection bits. 
     If a lower level entity “delegates” “D”  114  its access to a higher level entity (e.g., another task), the lower level entity loses delegate access to the block of memory and the higher level entity gains or acquires delegate access based on its protection bits. It should be appreciated that inherited access  112  and delegated access  114  are mutually exclusive. To illustrate, an entity which delegates its access, transfers that delegate access to another entity with access to the block of memory determined by the protection bits. In contrast, an entity with pass-through access continues to have access to the block of memory, limited only by its own access limits. 
     An entity with “exclusive” “El”  116  access to a block of memory is the only entity with write access to that block of memory. For example, an entity with exclusive access is the only entity that has exclusive access to that block of memory and may modify it, and its access is limited by its own access provisions. It should be appreciated that exclusive access is provided without the requirement of locks or other methods of enforcing autonomy. Moreover, exclusive access eliminates the need for synchronization among entities or address spaces. In contrast, an entity with “shared” “Sh”  118  access to a block of memory shares its access to that block of memory with the other entities that also have shared access. The table of  FIG. 11  illustrates the various access rights that lower and higher level system entities may grant and acquire from one another. 
     A protection entry  100  also makes it possible to protect multiple contiguous blocks of computer memory. For example, if the desired protection granularity is a cache line (i.e., 64 bytes), multiple cache lines can be grouped together to share the specified protection. The grouping field  120  defines the number of continuous memory blocks that are being protected. For example, if the grouping is “1”, the protection entry applies to a single memory block. Similarly, if the grouping is “8”, the protection applies to eight memory blocks. The size of the memory block is determined by multiplying the granularity of the memory block (e.g., 64 bits) by the number of memory blocks (e.g., 8) to determine that 512 bits of data are being protected. 
     The type field  122  defines the type of reference that is being associated with the protection entry  100  (i.e., address, handle, other object, etc.). Specifically, the type field  122  could designate an address (value=1), a handle (value=2), or other object (value=3). In this example, the type field  122  is a “2” and accordingly the reference field  128  corresponds to a handle. 
     The memory domain field  124  identifies a locality or coherency range of memory. For example, when system memory is fully cache coherent, such as cc-NUMA, the memory domain specified locality is the NUMA node that is referenced by the protection entity. Locality information allows the system to optimize its performance by using memory on the same node on which the process is running. In the case where system memory is not fully cache coherent, the memory domain may be used to identify which references maintain coherency. Coherency domains allow the use of memory that is restricted to a subset of processors with through physical accessibility or through hardware cache consistency restrictions. 
     The protection identification field (Protection ID)  126  identifies a particular protection domain associated with the reference field  128 . A protection domain memory model allows code and data resources to be encapsulated in a protected environment. Such an environment is less rigid and allows for a system that can operate processes and tasks between how an operating system kernel ordinarily operates (without protection) and how applications traditionally operate (with full protection). 
     As noted previously, the reference field  128  specifies an address, a handle, or other object which the protection entity  100  corresponds. If the type field  122  specifies an “address” (i.e., value=1), the reference field  128  specifies the protection entries starting address. Alternatively, if the type field  122  specifies a “handle” (i.e., value=2), the handle is associated with one or more tasks, processes, threads, or other construction. Moreover, the handle could specify a protection ID  126  and be automatically transferred between handles as necessary. Finally, if the type field  122  specifies “other object” (i.e., value=3), the reference field  128  corresponds to an abstraction other than a handle. For example, in  FIG. 1  the type field  122  is a “2” and accordingly the reference field  128  is associated with a handle. 
     Finally, it should be appreciated that the bit layout, as well as the number of bits, could vary based on the specific implementation, as well as the computers&#39; hardware and software requirements. For example, the illustrative protection entry  100  is a single byte in size (i.e., 64 bits), however it could just as easily be 32 bits, 256 bits, or any other size based on the specific implementation. 
     Creation of Protection Entries 
     When a computer system is initialized, the protection entries associated with the one or more hypervisor(s), operating system(s), application(s), run time(s), and task(s) are not enabled. Accordingly, the lowest level entry (i.e., hypervisor, operating system, application, or other initialization entry) creates the initial protection entries and provides an interface to use the protection entry mechanism. 
       FIG. 2  illustrates how protection entries may be created for a variety of processes. When the computer system is booted up (i.e., started), it gives the lowest level entry (i.e., hypervisor) overall control of the memory space, at block  202 . The hypervisor, if present, then grants itself “full access” by setting its protection ID bit to “1”, at block  204 . Full access allows the hypervisor to set its own access protection bits and retain access to the entire block of memory. The hypervisor then creates one or more operating system entries, as well as other protection entries (e.g., application, run-time, and task) at block  206 , and allocates its entire memory space to the operating system, at block  208 . 
       FIG. 3  illustrates a hierarchal arrangement of protection entries  300 . In  FIG. 3 , the operating system protection entry&#39;s (operating system)  304  protection ID bit of is set to “2”, and the operating system  304  has access to the same block of memory as the hypervisor protection entry  302  (e.g., grouping=128). 
     Referring back to  FIG. 2 , the hypervisor then changes its access to pass through access (i.e., pass through “P”=1), at block  210 . This allows the hypervisor to move data to or from various devices as requested by the operating system. However, based on the hypervisor&#39;s access protection bits it does not have access to the data (i.e., read, write, and execute bits are set to “0”). 
     The operating system may then allocate a portion of its memory space to the application, at block  212 . For example, in  FIG. 3  the application protection entry (application)  306  has been assigned delegated access  214  (i.e., delegation bit “D”=1), and the operating system  304  retains pass through access  216  (i.e., pass through bit “P”=1). As previously noted, pass through access allows the operating system  304  to access the block of memory, however its access is restricted based on its access protection settings. 
     The application may then assign the run-time inherited access (i.e., inherited access bit=1) and other access rights as necessary, at block  218 . For example, in  FIG. 3 , the application  306  has granted the run-time  308  shared, read access (i.e., read “R” and shared “Sh” bits). 
     The run-time may then create one or more sub-task entries with the access rights it has been granted, at block  220 . Referring again to  FIG. 3 , the run-time  308  has granted task  310  inherited access  222  (i.e., inherited access bit=1), along with read, write, and exclusive access (i.e., read “R”, write “W”, and exclusive “El” bits=1). Note that protection entries with delegated access (i.e., application  306 ) can be determined by tracing the entries with inherited access up the hierarchy. 
     It should be appreciated that the protection entries and the method in which they were created are exemplary and that other protection entries and other methods of creating them may be employed. 
     Hierarchical Arrangement of Protection Entries 
     Once a protection entry has been created, it then may be arranged or organized in a hierarchical manner, thereby creating sub-protection domains within a single process or system entity (e.g., run-time layers, operating systems, hypervisor layers). 
       FIG. 4  illustrates a group of protection entries that have been arranged in the aforementioned hierarchical manner. In this example, the hypervisor protection entry (hypervisor)  302  and operating system protection entry (operating system)  304  have been assigned pass through access  402  to a specific block of memory (i.e., pass through bit “P”=1). Specifically, the hypervisor  302  and operating system  304  have granted the application protection entry (application)  306 , run-time protection entry (run-time)  308 , and task protection entry (task)  310  access to at least a portion of the block of memory that they control. The application  306  has delegate access  404  to the block of memory (i.e., delegated bit “D”=1). Meanwhile, the run-time  308  has inherited access  406  (i.e., inherited bit “I”=1) from the application  306 . Finally, task  310  has exclusive access  408  to the block of memory (i.e., exclusive “E”=1), which grants it exclusive access to the data found within the block of memory. 
     When a system entity completes its task(s) or no longer requires access to its assigned block of memory, the entity may give up its access. For example, when task  310  with exclusive access completes its task; the application  306 , which previously delegated  404  access to the task  310  regains or reacquires access to the block of memory. Conversely, when application  306  with delegated access  404  completes its task; the run-time  308 , which inherited access  406  from the application  306 , can delegate access to a new task or application. 
       FIG. 5  illustrates how an entity with inherited access rights “I” loses its rights when it completes its task(s). First, the entity must have inherited its access rights, at block  502 . Specifically, the inherited access protection bit must be set to “1.” Then, the entity must have completed all of its task(s) or otherwise given up access, at block  504 . If the entity has completed its task(s) or otherwise given up access, the inherited access rights are lost and the entry no longer has access to the memory block, at block  506 . Conversely, if the entry has not completed its tasks nor given up access, the entry maintains its inherited access rights, at block  508 . 
       FIG. 6  illustrates how a lower level entity (e.g., operating system) updates its access rights from pass through access “P” to delegated access “D” if a higher level entity (e.g., application) with delegated access completes its task(s) or otherwise gives up access. First, the higher level entity must have delegated access, at block  602 . Specifically, the delegated access protection bit must be set to “1.” Then, the higher level entity must have completed its task(s) or otherwise given up access via a free or other return operation, at block  604 . If the entry has completed its task(s) or given up access, the lower level entities pass through access rights are replaced with delegated access rights, at block  606 . Alternatively, if the higher level entry has not completed its tasks nor given up access, the lower level entry maintains its pass through access, at block  608 . Once the lower level entry has acquired delegated access, it regains access to the memory block and the ability to manage it. 
     Protection entries may also employ different memory groupings or be implemented in varying granularities. Protection entries can be implemented in systems where memory is organized in pages, and they can be implemented in systems without a page organization structure. Moreover, the memory blocks associated with a protection entry can be split or joined with other memory blocks, since fine granularity memory protection does not need to be associated with an entire block of memory. 
       FIG. 7  illustrates a hierarchical arrangement of protection entries with various memory groupings  700 . In this example, the hypervisor protection entry (hypervisor)  702  and operating system protection entry (operating system)  704  both have groupings of 128 continuous memory blocks, which corresponds to a block size of 8,192 bytes (i.e., 128 blocks×64 bytes per block). The application protection entry (application)  706  has been granted access to 4 memory blocks, which corresponds to a block size of 256 bytes. Meanwhile, the run-time protection entry (run-time)  708  has been granted access to 2 memory blocks, which corresponds to a block size of 128 bytes. Finally, the task protection entry (task)  710  has been granted access to 1 memory block, which corresponds to a block size of 64 bytes respectfully. However, the memory groupings for the various system entities may vary based on hardware and software requirements of the particular computer processor, computing system, computer network, or computing environment. 
     It should be appreciated that the protection entries and the memory groupings are exemplary and that other protection entries and memory groupings may be employed. 
     Message Passing 
     Fine granularity memory protection allows the ownership or access to blocks of memory containing data or code, to be transferred among system entities (i.e., applications, run-time layers, operating systems, hypervisors, to name a few). Moreover, fine granularity memory protection allows ownership or access rights to be exclusive or shared among entries or address spaces. 
     One area where fine granularity data protection provides a benefit is in the passing of messages between threads of execution, or simply “threads.” For example, where several threads exist within a single process and two of those threads want to exchange data while ensuring that no other threads interfere. Current process-visible address space models cannot isolate the data. Instead, all the threads within the process can access all the data. However, by creating protection entries for both threads the data can be isolated. 
       FIG. 8  illustrates message passing between two threads in a single process or application. In this example, two task protection entries  804 ,  806  share the same block of memory as the application protection entry (application)  802  (i.e., grouping=256 bytes). The application  802  has delegated, shared, read only access respectfully (i.e., read access “R”, delegated access “D”, and shared access “Sh”=1), while the producer task entry (producer task)  804  has inherited, shared, read, and write access (i.e., read access “R”, write access “W”, inherited access “I”, and shared access “Sh”=1) and the consumer task entry (consumer task)  806  has inherited, shared, access but no read or write access (i.e., inherited access “I”, and shared access “Sh”=1). Since the producer task  804  has shared, read and write access it is only allowed to read, modify, and write to the block of memory and the consumer task  806  has shared, but no read or write access to the block of memory, and therefore cannot read, modify or write to the block of memory until the memory block has been passed to it. 
     Once a message, contained in the memory block, is passed between the producer task protection entry (producer task)  808  and consumer task protection entry (consumer task)  810 . The consumer task  810  acquires read and write access while the producer task  808  looses its read and write access to the memory. Accordingly, the producer task  808  has inherited, shared, access, but is not able to read, modify, or write to the block of memory (i.e., inherited access “I”, and shared access “Sh”=1). While the consumer task  810  has inherited, shared, read, and write access, and is able to read, modify, and write to the block of memory (i.e., read access “R”, write access “W”, inherited access “I”, and shared access “Sh”=1). 
       FIG. 9  illustrates a series of protection entries which are configured to perform message passing between two applications that reside in a single memory space. The first application protection entry  902  has a block size of 64 bytes (i.e., grouping of 1×64 bytes), an address of 16384 (i.e., 256×64 bytes), and a protection domain of 36 (i.e., protection ID bit=36). The second application protection entry  908  also has a block size of 64 bytes, and an address of 16384; however, its protection domain is 37. The run-time protection entry  904  runs on behalf of both applications  902 ,  908 , therefore its protection bits are set at 36 and 37, respectfully. 
     Since tasks are generally part of an application, they typically share the same protection bits as the application. In this example, the first application protection entry  902  and first task protection entry  906  share protection bit  36 , while the second application protection entry  908  and second task protection entry  910  share protection bit  37 . 
       FIG. 10  illustrates message passing between two tasks by employing a run-time message. The first task  906  makes a run-time call to transfer a message to the second task  910 , at block  1008 . The run-time layer  904  then makes an application program interface (API) call to set its protection domain, at block  1010 . Since the run-time  904  is a superset of the first application  902  and the second application  908 , its protection ID bits are 36 and 37, respectfully. The run-time  904  then makes an API call to transfer message ownership to the second task  910 , at block  1012 . In one embodiment, the access of the first task  906  is reduced to read only, pass through access, and the second task  910  is given delegated, exclusive read and write access (see  FIG. 9 ). In an alternate embodiment the first task  906  relinquishes its access to the memory block. The run-time  904  then notifies the second task  910  of the message that needs to be processed, at block  1014 . If the second task  910  is not already running, the message alerts it that a message is available for processing. 
     As part of the second tasks  910  activation process, the protection ID bits are set through task switching code or via an express command. The second task  910  then receives the message from the run-time layer  904  and receives exclusive access to the memory block, at block  1016 . Then the second task  910  makes a run-time call to return the completed message to the first task  906 , at  1018 . The run-time layer  904  then makes an API call to return message ownership to the first task  906  and reverts back to its initial protection configuration (i.e., read only, pass through access) before returning to the first task  906 , at block  1020 . The first task  906  receives exclusive access to the block of memory block and the second task  910  relinquishes its access, at block  1022 . Finally, the first task  906  makes a run-time call to drop its exclusive access to the message, at which point the run-time layer  904  makes an API call to drop exclusive access to the memory area, at block  1024 . 
     It should be appreciated that the protection entries shown and described are exemplary and other means of message passing between protection entries may be used. 
     Although protection entries and methods for providing fine granularity memory protection have been described in language specific to certain features or methodological acts, it is to be understood that the disclosure is not limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms of implementing the disclosure.