SECURE PRIVILEGE LEVEL EXECUTION AND ACCESS PROTECTION
The subject disclosure is directed towards using one or more of hardware, a hypervisor, and privileged mode code to prevent system mode code from accessing user mode data and/or running user mode code at the system privilege level, or vice-versa. Also described is (in systems with a hypervisor) preventing non-hypervisor code from running in hypervisor mode or accessing hypervisor-only data, or vice-versa. A register maintained by hardware, hypervisor, or system mode code contains data access and execution polices for different chunks of addressable space with respect to which requesting entities (hypervisor mode code, system mode code, user mode code) have access to or can execute code in a given chunk. When a request to execute code or access data with respect to an address is received, the request is processed to determine to which chunk the address corresponds. The policy for that chunk is evaluated to determine whether to allow or deny the request.
The present application is a continuation of U.S. application Ser. No. 15/369,874, filed Dec. 5, 2016, which is a continuation of U.S. application Ser. No. 13/918,852 filed on Jun. 14, 2013, now U.S. Pat. No. 9,530,000, issued on Dec. 27, 2016, and both are hereby incorporated by reference herein for all intents and purposes.BACKGROUND
Attacks on computer systems are well known. One of the early ways to prevent attacks (as well as to prevent poorly written code from causing problems) was to run user applications in user mode code at a low privilege level, and run system (sometimes referred to as privileged, kernel or supervisor) mode code at a high privilege level.
In general, system mode code running at system privilege level can access virtually any computing resource whereas user mode code cannot. Thus, one common contemporary attack is based upon tricking system mode code via a bug into running user mode code with a system privilege level. Through various exploits such as buffer overflows, the system mode code jumps into or returns to what is actually malicious user mode code that then takes over the flow of execution, with system mode privileges. The attack is based on the concept that while user mode code cannot access system mode data or run in system mode, the converse is not true.
Recent hardware features referred to as Supervisor Mode Access Prevention (SMAP) and Supervisor Mode Execution Prevention (SMEP) attempt to control data and execution access of supervisor mode code. However, these features do not protect against a wide class of attacks, in part because of susceptibility to mistakes in the page tables. Moreover, these features deal with user mode versus supervisor mode, and do not make any distinction for code that runs in hypervisor mode.SUMMARY
This Summary is provided to introduce a selection of representative concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used in any way that would limit the scope of the claimed subject matter.
Briefly, various aspects of the subject matter described herein are directed towards preventing (e.g., via logic such as in hardware or a hypervisor) access and/or execution by code running in another mode or running at a different privilege level. In one aspect, addressable memory space is separated into chunks, with at least some of the chunks associated with policy settings that identify one or more execution capabilities and/or one more access capabilities of the chunks. At least one policy setting indicates whether code in the chunk is executable at a system privilege level or not, or whether data in the chunk is accessible as system mode data or not. A request to execute code or access data is processed, with the request having an indication of a privilege level of the request.
Enforcing whether code execution or data access is allowed for the request is performed, e.g., by enforcement logic in hardware and/or software. Enforcing includes identifying a chunk with which the request is associated, accessing the policy settings to determine the execution or data access capability of the chunk, and allowing or denying the request based upon the privilege level, whether the request is to execute code or access data and the capability of the chunk with which the request is associated.
In one aspect, a hypervisor coupled to guest software includes enforcement logic (implemented in hardware and/or software) configured to prevent other code from executing in another mode or at a higher privilege level than a mode to which a source of the other code corresponds. The enforcement logic evaluates a request from a source related to code execution at an address against execution capability data maintained for chunks of address spaces, to determine whether the address corresponds to a chunk in which the source is allowed to execute code. In one aspect, the enforcement logic is further configured to evaluate a request from a source related to data access at an address against data access information maintained for chunks of address spaces to determine whether the address corresponds to a chunk in which the source is allowed to access data.
In one implementation, code execution and data access policies are enforced at a hypervisor and/or hardware, including by processing a request related to code execution or data access to evaluate a source of the request and an address associated with the request against policy settings. The hypervisor and/or hardware determines whether the request is allowed or denied for the source at the address associated with the request.
The present invention is illustrated by way of example and not limited in the accompanying figures in which like reference numerals indicate similar elements and in which:
Various aspects of the technology described herein are generally directed towards having the CPU software that controls the physical allocation of memory control its own access and execution and the access and execution of software running at lesser privilege levels. Examples of software that controls physical memory allocation comprise a hypervisor that manages virtual machines/virtualization, or the operating system when there is no hypervisor/virtualization.
In one aspect, access/execution is controlled regardless of any inadvertent or overt actions of lesser privilege level software at any time. Examples of this include enforcing user mode software to execute in user mode only with no other access, and system mode software to execute in system mode only with no other access. As a result, even if a bug or other malicious attack attempts to cause system mode software to jump into or return to a user mode address, execution is prevented. Data access may be similarly limited
In one aspect, access/execution of the code is controlled after establishing permitted access. For example, hypervisor code is only able to execute in hypervisor-only mode, with no other access including hypervisor access to other modes. Data read/write access is limited to hypervisor mode only, with no other access to system data or user mode data allowed.
To this end, the hypervisor and/or other system mode (e.g., most-privileged) code links access capabilities to the privilege level, whereby logic (e.g., in hardware and/or in the hypervisor code) controls each type of access separately using existing memory management, e.g., at page granularity. As a result, this scheme has no direct impact on lesser privilege level software, and provides for compatibility with existing architectures with minimal hardware change.
In one aspect, the machine's virtual memory address space is divided into a number of chunks, such as eight, e.g., using three bits of the address space as a chunk identifier (e.g., “tag”) or the like that refers to one of the chunks. Each chunk has attributes defined by the hypervisor/other system mode (e.g., most-privileged) code; e.g., one chunk may be designated for only user mode data pages, another for user mode execution pages. Another chunk may be designated for privileged mode data pages, one for privileged mode execution pages, one for hypervisor mode data pages, one for hypervisor mode execution pages, and so on. Once established, the hypervisor other system mode (e.g., most-privileged) code has the ability to lock these designations (e.g., maintained in one or more machine state registers for the hypervisor to read) until the next reboot.
When memory is allocated, the hypervisor/other system mode (e.g., most-privileged) code allocates space only from the chunk that applies to the requesting entity, e.g., a user execute chunk for user mode code allocation requests. When a request to access memory or execute code comes in, enforcement logic (e.g., in the hypervisor and/or hardware) enforces the designation associated with the request, e.g., system code can only execute in a system mode executable code chunk, hypervisor code can only execute in a hypervisor mode executable code chunk, and so on.
It should be understood that any of the examples herein are non-limiting. For example, a hypervisor is shown as establishing access policies in a virtualized machine, however in a machine without virtualization/a hypervisor, the operating system may perform similar operations. Further, various configurations of chunks and registers are exemplified, but alternative configurations are feasible. As such, the present invention is not limited to any particular embodiments, aspects, concepts, structures, functionalities or examples described herein. Rather, any of the embodiments, aspects, concepts, structures, functionalities or examples described herein are non-limiting, and the present invention may be used various ways that provide benefits and advantages in computer protection in general.
Described herein is dividing the addressable space into chunks, along with the use of a set of one or more registers 112 by the hypervisor to control access to data and/or code execution based upon the requesting entity. For example, when allocating memory space, consider that a guest requests address space for user mode executable code. Using existing verification techniques, if the requesting entity (e.g., the guest operating system for that user mode code) is verified, virtual address space is allocated from a particular chunk that designated as user mode executable code space, with the designation written to and tracked in the register set 112. Note that the register set 112 register set may comprise any accessible storage location that maintains execution and/or data access policy settings that may be evaluated to determine whether a source that makes an execution-related request or data access request is allowed to perform the requested operation.
In one implementation, some number of bits (e.g., three) of each address (e.g., forty bits total) correspond to the chunk designation, e.g., as an chunk identifier (tag) that corresponds to one chunk. This example is generally represented in
Further, note that one or more other chunks allow for other designations, e.g., instead of hypervisor mode execute and hypervisor mode R/W access (no execute), there may be a further distinction of hypervisor mode system privilege level execute, hypervisor mode user privilege level execute, hypervisor mode system data access/no-execute, and/or hypervisor mode user privilege level data access/no-execute designations. Still other designations are feasible, such as to have a chunk for digital rights management (DRM) data, a chunk for just-in-time (JIT) compiled code, and so on.
When the hypervisor 106 receives a code execution request or a data access request from requesting code 224 along with the requested address 226, whether from user mode code, system mode code or hypervisor mode code, the hypervisor 106 knows which entity is making the request and whether the request is directed to data access or to code execution. Note that the hypervisor 106 allocated or otherwise assigned the memory space (e.g., including the upper three bits as exemplified herein) at an earlier time based upon the type of requesting entity. The enforcement logic 107, which may be implemented in hardware and coupled to the hypervisor 106, (and/or may be in the hypervisor 106, shown via the dashed box), evaluates the upper three bits against the register set 112 to determine whether the entity and the type of request is allowed for this chunk. If so, the request is allowed to succeed, otherwise the request is failed.
In one embodiment, the hypervisor 106 initially sets all guest pages in the page table to no-execute via the execute/no-execute bit therein for each page. When a request comes in to execute code, the enforcement logic 107 checks the register to determine if execution is allowed at the corresponding page address for this requester/address, based upon the registry attributes for the type of requester, and either allows or denies the request. If allowed, the enforcement logic 107 also sets the page bit in the page table at that time to “execute” status so that the code may execute.
Note that instead of (or in addition) to a register or the like, it is feasible for the page tables to have one or more additional capability bits that specify data access and code execution according to privilege levels and/or modes. In other words, a programmable set of access designations may be added to the page tables that specify physical allocation of memory; a typical implementation modifies hypervisor page tables and adds additional information to cache, although guest operating system and user page tables, as well as caching, are unaffected.
However, such capability bits are not readily available with existing technologies, and thus existing page table schemes and/or existing hardware architectures need modification to implement such a capability bit set, making a new architecture solution less-than-desirable compared to using an existing architecture. Moreover, as page tables are maintained in main memory, such page table bits are also susceptible to attack or other corruption; in contrast, in one implementation, the register set 112 may be maintained in a processor location (e.g., processor hardware registers/model specific registers/CPU memory not subject to tampering) for additional security.
Moreover, the register set 112 may be locked. More particularly, the hypervisor 106 may write the attributes (e.g., represented by bit values) regarding designation of the chunks to the register set 112, and then lock the register set 112. Once locked, not even the hypervisor 106 can change the locked register set 112 during its operation (the register set remains locked until the next unlock event, which may be a reboot). Note that in a typical usage pattern, the hypervisor 106 sets up and locks the register set 112 as soon as possible after the hypervisor 106 begins running, so that any subsequently executed bugs or errors in hypervisor code cannot change the register set. As a result, a subsequent bug in the hypervisor code cannot be used to exploit the register-based security scheme, for example.
Note that the use of m bits (e.g., three bits) of the address 226 conveniently allows for efficient register lookup by the enforcement logic 107. This scheme results in each virtual chunk being the same size; e.g., with a three-bit identifier, each chunk is one-eighth of the addressable space after subtracting the three tag bits, e.g., 237 bits for a forty bit address. Given the typical amounts of physical RAM used in contemporary devices and the amounts of RAM that typical programs need to address, reducing the addressable space by three bits is not problematic. Indeed, if desired even more bits may be used to allow for more chunk designations without running out of addresses for any type of requestor in a typical computing machine.
Notwithstanding, other schemes may be used, including a scheme having chunks of unequal size. For example, the hypervisor/register may track chunk boundaries as well as the designated capabilities of each chunk. Another scheme (one that basically allows for “chunks” of unequal size by combining chunks) may be to divide the addressable memory space into more chunks than needed for the various types of designation (at the cost of more identifier bits), but give certain chunks the same attributes/capabilities in the register set, with addressable memory allocated from among these same type of chunks accordingly. For example, there may be three chunks designated for “execute user mode only” and only one chunk for “execute hypervisor mode only.” In this way, more chunk granularity is provided (as well as more possible chunk designations), such that an entity such as the hypervisor uses less of the addressable space relative to the addressable space useable by another entity.
As can be readily appreciated, the chunk identifier and register mechanism described herein avoids the need for any changes to existing page tables and/or any changes to the hardware caching of page table information. Pages of memory are assigned a desired chunk as part of their physical address to select the desired access designations. The hypervisor 106 controls these designations, and can lock various ones (or all) until the next reboot.
Note that existing access designations in the CPU architecture continue to operate unaffected, but are overridden by the new designations when the new designations are more restrictive. For example, consider that the execute bit for a page in the page tables allows code execution on that page, but the page is in a chunk that the hypervisor has designated as no execute. The enforcement logic 107, which handles execution-related requests, prevents code execution regardless of the execute bit setting for that page. Among other benefits, this prevents bugs, corruption or errors in the page tables from allowing improper execution.
One example implementation described herein is of a CPU architecture that supports forty (or more) physical address bits in its page tables and memory management hardware. Such architecture provides (at least) one terabyte of addressable space, which is significantly more than the amount of physical memory generally attached to the CPU. In one embodiment, the upper three address bits are used to select one of eight programmable sets of access designations. The remaining (e.g., thirty-seven) bits address the memory space within each set.
As described herein, in one embodiment, identified chunks of the address space are used to select a programmable set of access designations. In one implementation, at least one chunk contains (but is not necessarily limited to) hypervisor code and data. More particularly, the amount of memory used for hypervisor code and data is relatively small, and thus via a particular register 330 (
Note that there may be multiple sets of policies for a chunk or part of a chunk of actual memory. Part of a chunk may have policies, including because a chunk part may encompass the use of page tables to map individual pages of a chunk to different hardware and software (thread) requesters.
In one example implementation, one of the chunk parts is reserved for registers and other non-main memory storage accessible with CPU load and store operations. Accessing non-main memory storage with CPU load and store operations is commonly known as Memory-Mapped IO (MMIO). As described above, the registers alternatively may be in a more secure memory location external to main memory.
Various registers may be present for various purposes, including one for hypervisor access control (ASID zero). For example, in an implementation exemplified in
The hypervisor 106 can lock the state of the thirty-two (32) execution bits, and/or separately lock the thirty-two (32) read/write bits, until the next reset (reboot) if the hypervisor chooses to do so. The register 330 may be initialized to zero by resets, but this is not required.
Another register is for controlling hypervisor execution and read/write access to each of the chunks. For example, if there are eight chunks, a hypervisor-only machine state register with eighteen (18) active bits may be used, as generally represented by the register 440 in
One of the remaining two bits (Lock E) is locks the state of the execution enable bits in the register 330 of
With respect to other (non-hypervisor) access control (ASID non-zero),
Note that at system startup, non-hypervisor code and data may be first loaded into a chunk that allows no execution. If execution is requested, and the enforcement logic 107 (
Step 606 determines whether the request is “OK” according to any number of criteria. For example, space needs to be available to allocate or the request is failed. Moreover, one or more various mechanisms may be used to ensure that the requesting entity is authorized to make the request, e.g., that the guest operating system is from a legitimate source, has not been tampered with, and/or the like. For example, guest code may make a hypercall to the hypervisor, which checks a signature of the caller to authorize the request. If not, step 608 fails the request.
If the request is “OK” according to the one or more evaluation criteria at step 606, then step 610 is executed to allocate the space. The bits that are included in the returned allocation are set to the values that correspond to the request, e.g., an allowed user mode execute allocation request has the bits set to the chunk corresponding to user mode execute allocation as established in the bits within the register set for this chunk, e.g., (1, 0, 0, 0 in the scheme above), that is, Ring 3 execute, Ring 0, 1, 2 no-execute, Ring 3 no read/write, Ring 0, 1, 2 no read-write. Thereafter, via the identifier part of the address, any use of this address is limited by the hypervisor to only Ring 3 (user mode) code execution.
Step 706 represents evaluating whether read/write is allowed by the register settings for this address. If not step 708 denies the request. If so, step 710 allows the request; note that the page table bit may further deny a write.
Step 806 represents evaluating the register settings to determine whether execution is allowed by for this address. If not, step 808 denies the request, such as by clearing one or more page table bits. If so, step 810 sets the bit to one (which may still be cleared to zero via step 602 of
The invention is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to: personal computers, server computers, hand-held or laptop devices, tablet devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
The invention may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, and so forth, which perform particular tasks or implement particular abstract data types. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in local and/or remote computer storage media including memory storage devices.
With reference to
The computer 910 typically includes a variety of computer-readable media. Computer-readable media can be any available media that can be accessed by the computer 910 and includes both volatile and nonvolatile media, and removable and non-removable media. By way of example, and not limitation, computer-readable media may comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can accessed by the computer 910. Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of the any of the above may also be included within the scope of computer-readable media.
The system memory 930 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 931 and random access memory (RAM) 932. A basic input/output system 933 (BIOS), containing the basic routines that help to transfer information between elements within computer 910, such as during start-up, is typically stored in ROM 931. RAM 932 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 920. By way of example, and not limitation,
The computer 910 may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only,
The drives and their associated computer storage media, described above and illustrated in
The computer 910 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 980. The remote computer 980 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 910, although only a memory storage device 981 has been illustrated in
When used in a LAN networking environment, the computer 910 is connected to the LAN 971 through a network interface or adapter 970. When used in a WAN networking environment, the computer 910 typically includes a modem 972 or other means for establishing communications over the WAN 973, such as the Internet. The modem 972, which may be internal or external, may be connected to the system bus 921 via the user input interface 960 or other appropriate mechanism. A wireless networking component such as comprising an interface and antenna may be coupled through a suitable device such as an access point or peer computer to a WAN or LAN. In a networked environment, program modules depicted relative to the computer 910, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation,
An auxiliary subsystem 999 (e.g., for auxiliary display of content) may be connected via the user interface 960 to allow data such as program content, system status and event notifications to be provided to the user, even if the main portions of the computer system are in a low power state. The auxiliary subsystem 999 may be connected to the modem 972 and/or network interface 970 to allow communication between these systems while the main processing unit 920 is in a low power state.Conclusion
While the invention is susceptible to various modifications and alternative constructions, certain illustrated embodiments thereof are shown in the drawings and have been described above in detail. It should be understood, however, that there is no intention to limit the invention to the specific forms disclosed, but on the contrary, the intention is to cover all modifications, alternative constructions, and equivalents falling within the spirit and scope of the invention.
1. A method comprising:
- separating addressable memory space into chunks, in which zero or more of the chunks address the same physical storage in whole or part as another chunk, and in which at least some of the chunks are associated with policy settings that identify one or more execution capabilities or one or more access capabilities of the chunks, or both, and including at least one policy setting that indicates whether code in the chunk is executable at a system privilege level or not, or whether data in the chunk is accessible as system mode data or not, and
- enforcing whether code execution or data access is allowed for a request, in which the request indicates whether the request is to execute code or access data and an indication of a privilege level of the request, including by identifying a chunk with which the request is associated, accessing the policy settings based upon the request to determine the execution or data access capability of the chunk, and allowing or denying the request based upon the privilege level, whether the request is to execute code or access data and the capability of the chunk with which the request is associated.
2. The method of claim 1 further comprising receiving the request by a hypervisor or system mode code, and wherein enforcing whether code execution or data access is allowed for the request is performed by enforcement logic.
3. The method of claim 1 wherein the privilege level of the request corresponds to the system privilege level, wherein the policy settings indicate that the code in the chunk with which the request is associated is not executable at the system privilege level or data in the chunk is not accessible by system mode code, or both, and denying the request.
4. The method of claim 1 further comprising assigning an identifier to each chunk, in which the identifier for a chunk is part of an address within the addressable memory space for that chunk.
5. The method of claim 1 wherein identifying the chunk with which the request is associated comprises determining the chunk from an address associated with the request.
6. The method of claim 1 further comprising (a) writing the policy settings, including writing at least one policy setting that indicates whether the code in the chunk is executable at a user privilege level or not, or whether data in the chunk is accessible as user mode data or not, or both, or (b) writing the policy settings, including writing at least one policy setting that indicates whether the code in the chunk is executable in a hypervisor mode, or whether data in the chunk is accessible as hypervisor mode data or not, or both, or both (a) and (b).
7. The method of claim 1 further comprising subdividing at least one chunk into page structures, and wherein the policy settings includes data that identifies execution capabilities or one more access capabilities of the page structures, or both execution capabilities and one more data access capabilities of the page structures.
8. The method of claim 1 further comprising locking at least part of the policy settings.
9. The method of claim 8 wherein locking at least part of the policy settings comprises locking by hardware or software where the lock or locks are enforced by hardware, or by a hypervisor or higher-privileged software than software that set a particular lock.
10. A system comprising: enforcement logic configured to prevent code from executing in another mode or at a different privilege level than a mode in which the code is intended to execute, and the enforcement logic configured to evaluate a request from a source related to code execution at an address against execution capability data maintained for chunks of address spaces to determine whether the address corresponds to a chunk in which the source is allowed to execute code.
11. The system of claim 10 wherein the enforcement logic is incorporated in hardware or incorporated into a hypervisor or system mode code, or a combination thereof, and wherein the source of the request comprises user mode code, system mode code, or hypervisor mode code.
12. The system of claim 10 wherein the enforcement logic is further configured to evaluate a request from a source related to data access at an address against data access information maintained for chunks of address spaces to determine whether the address corresponds to a chunk in which the source is allowed to access data.
13. The system of claim 10 wherein a subset of bits of the address identifies a chunk of a plurality of equal size chunks to which the address corresponds.
14. The system of claim 10 wherein at least two of the chunks of address spaces are different sizes from one another.
15. The system of claim 10 wherein at least part of the capability data is maintained in a register set in memory or in a processor location.
16. The system of claim 10 wherein the capability data for a chunk includes information that indicates whether chunk code is executable at user privilege level only, at system privilege level only or in hypervisor mode only.
17. The system of claim 10 wherein the capability data for a chunk includes information that indicates whether chunk data is accessible at user privilege level only, at system privilege level only or in hypervisor mode only.
18. One or more computer-readable storage media having computer-executable instructions, which when executed perform steps, comprising enforcing code execution and data access policies at enforcement logic, including processing a request related to code execution or data access to evaluate a source of the request and an address associated with the request against policy settings to determine whether the request is allowed or denied for the source at the address associated with the request.
19. The one or more computer-readable storage media of claim 18 wherein the source of the request comprises system mode code, wherein the address corresponds to a chunk of addressable space designated as user mode only or hypervisor mode only in policy data corresponding to the code execution and data access policies, and wherein enforcing the code execution and data access policies comprises denying the request.
20. The one or more computer-readable storage media of claim 18 wherein the source of the request comprises hypervisor mode code, wherein the address corresponds to a chunk of addressable space designated as user mode only or system mode only in policy data corresponding to the code execution and data access policies, and wherein enforcing the code execution and data access policies comprises denying the request.