Patent Description:
Operating systems, such as WINDOWS, LINUX, MACOS, etc., provide a variety of system service calls that are callable by user-mode processes in order to request services from the operating system-such as to open a file, to request a memory allocation, etc. An operating system maintains at least one system service table (e.g., a system service descriptor table in WINDOWS) within kernel memory. System service tables map system service calls to kernel function addresses.

<CIT> relates to detecting shellcode that modifies IAT entries. On start up of a process, a critical imported functions table including resolved addresses of critical imported functions that an application, such as a host intrusion detection system application depends upon to have data integrity, is dynamically allocated and marked read only to impede modification by malicious code. The critical imported functions are hooked so that execution of a call to a critical imported function is made using a corresponding entry in the critical imported functions table rather than an entry in a current process IAT, which may have been modified by malicious code. The current process IAT is evaluated to determine whether it has changed from an initial start up state, in a way that is indicative of an evasion attempt by malicious code. If an evasion attempt is detected, a notification is provided to a user and/or system administrator. Optionally, protective action is taken, such as saving a copy of the current process IAT to permit later analysis of the change.

<CIT> relates to techniques that allow protecting a computer system from malware, such as viruses and rootkits. A hypervisor configures a hardware virtualization platform hosting a set of operating systems (OS). A memory introspection engine executing at the processor privilege level of the hypervisor dynamically identifies each OS, and uses an protection priming module to change the way memory is allocated to a target software object by the memory allocation function native to the respective OS. The change affects only target objects requiring malware protection, and comprises enforcing that memory pages containing data of the target object are reserved exclusively for the respective object. The memory introspection engine then write-protects the respective memory pages.

the invention is defined by the subject matter of the independent claims.

At least some embodiments described herein are directed to secured system service redirection technology that enables an operating system to securely reroute operating system service calls to verified service call providers that are registered with the operating system. In embodiments, these service call providers are dynamically and securely loaded into the operating system, and offer value-add services such as system call monitoring, system call filtering, system call sandboxing, and the like.

In some aspects, the techniques described herein relate to a method, implemented at a computer system that includes a processor, for securely redirecting a system service routine via a provider service table, the method including: loading a service call provider within an operating system executing in a lower trust security zone, the service call provider including provider metadata indicating a set of system service routines to be redirected to the service call provider; based at least on a call from the operating system to a secure operating system within a higher trust security zone: building a provider service table redirecting a system service routine in the set of system service routines to the service call provider, hardware protecting a memory page associated with the provider service table, and exposing a read-only view of the provider service table to the operating system; associating the provider service table with a user-mode process executing in the lower trust security zone; and based at least on receiving a service call for a particular system service routine from the user-mode process: determining that the provider service table is associated with the user-mode process, identifying the particular system service routine within the provider service table, and directing the service call to the service call provider.

In some aspects, the techniques described herein relate to a computer system for securely redirecting a system service routine via a provider service table, including: a processor; and a hardware storage device that stores computer-executable instructions that are executable by the processor to cause the computer system to: load a service call provider within an operating system executing in a lower trust security zone, the service call provider including provider metadata indicating a set of system service routines to be redirected to the service call provider; based at least on a call from the operating system to a secure operating system within a higher trust security zone: build a provider service table redirecting a system service routine in the set of system service routines to the service call provider, hardware protect a memory page associated with the provider service table, and expose a read-only view of the provider service table to the operating system; associate the provider service table with a user-mode process executing in the lower trust security zone; and based at least on receiving a service call for a particular system service routine from the user-mode process: determine that the provider service table is associated with the user-mode process, identify the particular system service routine within the provider service table, and direct the service call to the service call provider.

In some aspects, the techniques described herein relate to a computer program product including a hardware storage device that stores computer-executable instructions that are executable by a processor to cause a computer system to securely redirect a system service routine via a provider service table, the computer-executable instructions including instructions that are executable by the processor to cause the computer system to: load a service call provider within an operating system executing in a lower trust security zone, the service call provider including provider metadata indicating a set of system service routines to be redirected to the service call provider; based at least on a call from the operating system to a secure operating system within a higher trust security zone: build a provider service table redirecting a system service routine in the set of system service routines to the service call provider, hardware protect a memory page associated with the provider service table, and expose a read-only view of the provider service table to the operating system; associate the provider service table with a user-mode process executing in the lower trust security zone; and based at least on receiving a service call for a particular system service routine from the user-mode process: determine that the provider service table is associated with the user-mode process, identify the particular system service routine within the provider service table, and direct the service call to the service call provider.

System service tables provided by operating systems map system service calls (service calls) to kernel function addresses. Currently, software vendors (e.g., antivirus, security) wishing to intercept system service calls resort to "hooking" system service tables. This involves modifying system service table(s) in order to direct service calls to function addresses within their own software components, rather than to the kernel function addresses to which they were originally intended by the operating system vendor. This can be unsafe, unsupported, and unsecure to the point where some operating systems take active steps to prevent modification of their system service table(s).

Described herein is secured system service redirection technology that solves the disadvantages of "hooking" system service tables, by enabling an operating system to securely reroute operating system service calls to verified service call providers that are registered with the operating system. Service call providers are dynamically and securely loaded into the operating system, and offer value-add services such as system call monitoring, system call filtering, system call sandboxing, anti-malware monitoring, and the like. Embodiments allow verified service call providers to register alternate service tables within an operating system, and ensure that service calls dispatched through these tables are done so in a secure manner.

It has been a consensus amongst engineers that supporting the redirection of system service calls would be subject to abuse, and therefore poses a significant security risk. These concerns largely stem from difficulties surrounding verification of redirected service call targets, and the prevention of data structure modification critical to supporting the feature. As is described herein, the inventors have overcome these security concerns through the use of virtualization-based security, in order to validate and maintain provider service tables in a tamper-proof manner.

<FIG> illustrates an example computer system <NUM> that facilitates securely redirecting system service routines via provider service tables. As shown, computer system <NUM> includes a variety of computing hardware <NUM>, including one or more processors (including processor <NUM>), memory <NUM> (e.g., main memory, such as random-access memory), and storage <NUM> (e.g., disk storage, ROM). Computing hardware <NUM>, may also include, for example, a network adapter (network <NUM>), a Trusted Platform Module (TPM) <NUM>, etc..

In <FIG>, the computing hardware <NUM> executes a hypervisor <NUM>. The hypervisor <NUM>, in turn, creates at least two security zones (e.g., partitions, virtual machines), including at least a lower-trust security zone (security zone <NUM>), and a higher-trust security zone (security zone <NUM>). In an example, the hypervisor <NUM> implements Virtual Secure Mode (VSM) from MICROSOFT CORPORATION, and each hypervisor-created security zone corresponds to a different Virtual Trust Level (VTL)-e.g., VTL0 for security zone <NUM> and VTL1 for security zone <NUM>. In <FIG>, security zone <NUM> includes a user mode 109a (within which one or more user-mode processes execute, including user-mode process <NUM>) and a kernel mode 109b (within which an OS kernel <NUM> executes), while a secure kernel <NUM> executes within security zone <NUM>. In this particular example, an NT kernel (e.g., OS kernel <NUM>) runs in VTL0 (security zone <NUM>) with user-mode software executing on top of the NT kernel, while a Secure Kernel runs in VTL1 (security zone <NUM>).

The secure kernel <NUM> comprises a memory protector <NUM>, which operates to apply read-only memory protections to allocations from memory <NUM>. In some embodiments, the memory protector <NUM> accomplishes these protections based, at least in part, on a hardware-based memory protection technology, such by managing memory page permissions via use of Second Level Address Translation (SLAT) <NUM> features provided by processor <NUM> and managed by the hypervisor <NUM>. In an example, the memory protector <NUM> implements Hypervisor Code Integrity (HVCI), which is usable to read-only protect memory allocated to the NT kernel (e.g., driver code pages, service tables). For example, the OS kernel <NUM> is shown as comprising services tables <NUM>, the underlying memory pages of which are read-only protected by the memory protector <NUM>.

While computer system <NUM> comprises a standard service table <NUM> (e.g., a system service descriptor table), embodiments allow each of one or more service call providers (e.g., service call provider <NUM>) to provide and register a provider service table <NUM>. Embodiments also ensure that service calls received from user-mode processes (e.g., user-mode process <NUM>) registered to the service call provider <NUM> are dispatched by a dispatcher <NUM> through the provider service table <NUM> (rather than the standard service table <NUM>) in a secure manner.

To accomplish the foregoing, computer system <NUM> includes a service call provider manager (provider manager <NUM>). As shown, in embodiments the provider manager <NUM> comprises one or more portions, such as a first portion (i.e., provider manager 112a) within the OS kernel <NUM> and/or a second portion (i.e., provider manager 112b) within the secure kernel <NUM>. <FIG> illustrates example components (e.g., provider loader <NUM>, service table requester <NUM>, service table associator <NUM>, provider unloader <NUM>) of provider manager <NUM>. Each of these components represents example functionality provided by the provider manager <NUM>, and in various embodiments portions of these components exist at one, or both, of provider manager 112a or provider manager 112b. It will be appreciated that the depicted components are presented merely as an aid in describing various embodiments, and that these components are non-limiting to how software and/or hardware might implement various embodiments described herein, or of the particular functionality of the provider manager <NUM>.

In embodiments, the provider loader <NUM> loads a service call provider <NUM> into a memory space of the OS kernel <NUM>. In embodiments, the provider loader <NUM> verifies the security and/or the origin of the service call provider <NUM> prior to loading the service call provider <NUM> into the memory space of the OS kernel <NUM>. As shown, the service call provider <NUM> includes (or is otherwise associated with) security data <NUM>. In embodiments, this security data <NUM> includes one or more of: a signature (e.g., over one or more of: code pages <NUM>, provider metadata <NUM>) from an issuing authority (e.g., a vendor of the OS kernel <NUM>), an indication of a publishing authority (e.g., a vendor of the OS kernel <NUM>, or a verified third party), a signature of a publishing authority, an attested-to security status of the service call provider <NUM>, and the like. In embodiments, verifying the service call provider <NUM> includes the provider loader <NUM> verifying this security data <NUM>.

In embodiments, there are respective portions of the provider loader <NUM> at the provider manager 112a in the OS kernel <NUM> and at the provider manager 112b in the secure kernel <NUM>, such that the OS kernel <NUM> and the secure kernel <NUM> cooperate when loading the service call provider <NUM>. Thus, in embodiments, the security data <NUM> can be at least partially verified by one, or both, of (i) a first portion of the provider loader <NUM> at the provider manager 112a (i.e., within the OS kernel <NUM>), or a (ii) second portion of the provider loader <NUM> at the provider manager 112b (i.e., within the secure kernel <NUM> and security zone <NUM>). It is noted that, when verifying the security data <NUM> by a portion of the provider loader <NUM> at the provider manager 112b, the secure kernel <NUM> can ensure only service call providers that are trusted by the secure kernel <NUM> can be loaded. In embodiments, the provider loader <NUM> also operates to read-only protect code pages <NUM> of the service call provider <NUM> within a memory space of the OS kernel <NUM>. For example, a portion of the provider loader <NUM> at the provider manager 112b interacts with the memory protector <NUM> to read-only protect code pages <NUM>, as they are exposed to the OS kernel <NUM>.

As shown, the service call provider <NUM> includes provider metadata <NUM>. In embodiments, the provider metadata <NUM> defines a set of system service routines as being associated with the service call provider <NUM>. In embodiments, for at least one system service routine in this set, the provider metadata <NUM> indicates a function at the service call provider <NUM> (e.g., within code pages <NUM>) to which the system service routine should be redirected (e.g., via a function address). In embodiments, for at least one system service routine in this set, the provider metadata <NUM> indicates that the system service routine should be handled by the OS kernel <NUM> (even though the service routine is associated with the service call provider <NUM>).

In some embodiments, the set of system service routines associated with the service call provider <NUM> includes all system service routines that are available from the OS kernel <NUM>. In other embodiments, the set of system service routines associated with the service call provider <NUM> is a subset of system service routines, which excludes one or more system service routines that are otherwise available from the OS kernel <NUM>. In some embodiments, any system service routine that is available from the OS kernel <NUM>, and that is not specifically identified in the provider metadata <NUM>, is excluded from the set of system service routines associated with the service call provider <NUM>, such that the exclusion is implicit. In some embodiments, the provider metadata <NUM> expressly specifies one or more system service routines that are available from the OS kernel <NUM>, and that are excluded from the set of system service routines associated with the service call provider <NUM>, such that the exclusion is explicit. In some embodiments, the provider metadata <NUM> defines one or more policies to be applied to any excluded system service routine(s), such as a first policy that calls to such system service routine(s) should be blocked, a second policy that calls to such system service routine(s) should return failure, etc..

In embodiments, when loading the service call provider <NUM>, the provider loader <NUM> (e.g., a portion at the provider manager 112b) parses and verifies this provider metadata <NUM>. In embodiments, when parsing/verifying the provider metadata <NUM>, the provider loader <NUM> ensures that any system service routine specified in the provider metadata <NUM> corresponds to a valid system service routine (e.g., provided by the OS kernel <NUM>), that any system service routine specified in the provider metadata <NUM> is permitted to be redirected to a service call provider, that a function identified in the provider metadata <NUM> actually exists in the code pages <NUM>, etc. Notably, embodiments take advantage of the fact that, when loading a driver (e.g., service call provider <NUM>), a driver image mapped in the secure kernel <NUM> can be safely parsed free of any potential modifications made by code running in security zone <NUM> (e.g., due to action of the memory protector <NUM>). This ensures the integrity of the provider metadata <NUM> read during the loading of the service call provider <NUM>.

In embodiments, the service table requester <NUM> initiates a request, from the OS kernel <NUM> to the secure kernel <NUM>, that causes a service table manager <NUM> to build a provider service table (e.g., provider service table <NUM>) on behalf of the service call provider <NUM>, based on the set of system service routines identified in the provider metadata <NUM>, and/or based on a policy defined in the provider metadata <NUM>. In embodiments, there are respective portions of the service table requester <NUM> at the provider manager 112a in the OS kernel <NUM> and at the provider manager 112b in the secure kernel <NUM>, and this request is between these portions of the service table requester <NUM>. In some embodiments, the service table requester <NUM> initiates this request as part of loading the service call provider <NUM> by the provider loader <NUM>. In some embodiments, the service table requester <NUM> initiates this request based on a request by the service call provider <NUM>, after loading of the service call provider <NUM>. In some embodiments, the service table requester <NUM> initiates this request based on a request from user-mode process <NUM>.

In embodiments, the service table manager <NUM> builds the provider service table <NUM> by creating an entry for each system service routine in the set of system service routines associated with the service call provider <NUM>, as defined in the provider metadata <NUM>. In embodiments, each entry in the provider service table <NUM> maps a corresponding system service routine to a function (e.g., specified in the provider metadata <NUM>) within the code pages <NUM> of the service call provider <NUM> (i.e., when redirecting the system service routine to the service call provider <NUM>), or to a function within the OS kernel <NUM> (i.e., when the OS kernel <NUM> is to handle the system service routine). As discussed, in some embodiments, the set of system service routines associated with the service call provider <NUM> is a subset of system service routines, which excludes one or more system service routines that are otherwise available from the OS kernel <NUM>. Thus, in embodiments, the provider service table <NUM> excludes any system service routine available from the OS kernel <NUM> that excluded (either implicitly or explicitly) from the set of system service routines associated with the service call provider <NUM>.

In embodiments, the service table manager <NUM> builds the provider service table <NUM> by creating an entry for at least one system service routine that was implicitly or explicitly excluded from the set of system service routines associated with the service call provider <NUM>. In these embodiments, the service table manager <NUM> configures the entry according to a policy defined in the provider metadata <NUM>, such as a policy to block a corresponding system service routine, to a policy return failure in response to a call to a corresponding system service routine, etc..

In embodiments, the service table manager <NUM> exposes the provider service table <NUM> to the OS kernel <NUM>. In embodiments, the service table requester <NUM> operates to read-only protect memory pages associated with this provider service table <NUM> within security zone <NUM>. For example, a portion of the service table requester <NUM> at the provider manager 112b interacts with the memory protector <NUM> to read-only protect memory pages storing the provider service table <NUM>.

In embodiments, the service table associator <NUM> associates a provider service table (e.g., provider service table <NUM>) exposed to the OS kernel <NUM> with one or more user-mode processes (e.g., user-mode process <NUM>). In embodiments, this association is accomplished by updating a process information data structure to identify the provider service table. For example, <FIG> shows that the OS kernel <NUM> includes one or more process information data structures (e.g., process information structure <NUM>, corresponding to user-mode process <NUM>). In embodiments, the service table associator <NUM> updates process information structure <NUM> to include an identifier of the provider service table <NUM> (e.g., an index of provider service table <NUM> within an array that identifies each service table in services tables <NUM>), and the dispatcher <NUM> uses this process information structure <NUM> to determine the destination of a service call received from user-mode process <NUM>. However, it will be appreciated by one of ordinary skill in the art that many mechanisms for associating a user-mode processes with a provider service table could be utilized. In embodiments, once a provider service table is associated with a user-mode process (e.g., via associating an array index with the user-mode process), the dispatcher <NUM> processes any service calls received from that user-mode process via the associated provider service table (rather than the standard service table <NUM>). Thus, in embodiments, the user-mode process is sandboxed in the service calls that it can make, since it is permitted to make service calls to only system service routines that are included in its associated provider service table.

In some embodiments, the service table associator <NUM> operates in response to a request from a user-mode process, or any entity that has write access to the user-mode process (e.g., a parent process, a driver, a service call provider). For example, based on a request from user-mode process <NUM> to the provider manager <NUM>, or based on a request from service call provider <NUM> to the provider manager <NUM>, the service table associator <NUM> associates the user-mode process <NUM> with provider service table <NUM>. Thus, in embodiments, association of a user-mode process with a provider service table is an opt-in process.

In some embodiments, the service table associator <NUM> operates based on a decision by the provider manager <NUM> and/or another component of the OS kernel <NUM>. Thus, in embodiments, association of a user-mode process with a provider service table is compulsory.

In either case, association of a user-mode process with a provider service table is useful for sandboxing that user-mode process (i.e., to limit that process to use of a subset of system service calls that are defined in the associated provider service table), and/or for processing that process' system calls via the service call provider <NUM> (e.g., to provide system call monitoring, system call filtering, system call logging, anti-malware monitoring, etc.).

In embodiments, the provider unloader <NUM> unloads the service call provider <NUM>, including unloading the provider service table <NUM> associated with the service call provider <NUM>. In embodiments, the provider unloader <NUM> unloads the service call provider <NUM> only when there are no user-mode processes associated with the service call provider <NUM>. Thus, in embodiments, an unload request (e.g., by the service call provider <NUM>) is blocked until all processes associated with the service call provider <NUM> have terminated. In embodiments, the provider unloader <NUM> unloads the service call provider <NUM> in order to update the service call provider <NUM>, to remove the service call provider <NUM>, or for other reasons.

Embodiments are now further described in connection with <FIG>, which illustrates a flow chart of an example method <NUM> for securely redirecting a system service routine via a provider service table. In embodiments, instructions for implementing method <NUM> are encoded as computer-executable instructions stored on a computer program product (e.g., a hardware storage device, such as storage <NUM>) that are executable by a processor (e.g., processor <NUM>) to cause a computer system (e.g., computer system <NUM>) to perform method <NUM>.

The following discussion now refers to a number of methods and method acts. Although the method acts may be discussed in certain orders, or may be illustrated in a flow chart as occurring in a particular order, no particular ordering is required unless specifically stated, or required because an act is dependent on another act being completed prior to the act being performed. In <FIG>, acts are shown as being performed within either security zone <NUM> or security zone <NUM>. Additionally, with respect to security zone <NUM>, acts are shown as being performed within either user mode 109a or kernel mode 109b.

Referring to <FIG>, in embodiments, method <NUM> comprises an act <NUM> (within kernel mode 109b of security zone <NUM>) of loading a service call<IMG>provider indicating redirected service routine(s). In some embodiments, act <NUM> comprises loading a service call provider within an operating system executing in a lower trust security zone, the service call provider comprising provider metadata indicating a set of system service routines to be redirected to the service call provider. In an example, the provider loader <NUM> loads service call provider <NUM> within the OS kernel <NUM>, which executes in security zone <NUM>. This service call provider <NUM> includes provider metadata <NUM>, indicating a set of system service routines to be associated with the service call provider <NUM>.

In embodiments, as part of loading the service call provider <NUM> in act <NUM>, the provider loader <NUM> verifies the security data <NUM> contained in the service call provider <NUM>. In embodiments, this verification is accomplished by one, or both, one, or both, of (i) a first portion of the provider loader <NUM> at the provider manager 112a (i.e., within the OS kernel <NUM>), or a (ii) second portion of the provider loader <NUM> at the provider manager 112b (i.e., within the secure kernel <NUM> and security zone <NUM>). Thus, in some embodiments, act <NUM> includes verifying security data associated with the service call provider prior to loading the service call provider. As discussed, in embodiments, the security data <NUM> includes a signature from an issuing authority, an indication of a publishing authority, a signature of a publishing authority, and the like. Thus, in some embodiments of act <NUM>, verifying security data associated with the service call provider comprises verifying at least one of a code signature or a code publisher.

In embodiments, in connection with loading the service call provider <NUM> in act <NUM>, a portion of the provider loader <NUM> within the security zone <NUM> utilizes the memory protector <NUM> to read-only protect code pages <NUM> associated with the service call provider <NUM>. Thus, in some embodiments, act <NUM> includes hardware protecting a code page associated with the service call provider.

In embodiments, in connection with loading the service call provider <NUM> in act <NUM>, the provider loader <NUM> verifies the provider metadata <NUM> (e.g., to ensure that any system service routine specified in the provider metadata <NUM> corresponds to a valid system service routine, to ensure that any system service routine specified in the provider metadata <NUM> is permitted to be redirected to a service call provider, to ensure that a function identified in the provider metadata <NUM> actually exists in the code pages <NUM>, etc.). Thus, in some embodiments of act <NUM>, loading the service call provider includes the secure operating system verifying the provider metadata.

Referring again to <FIG>, in embodiments, method <NUM> also comprises an act <NUM> (within security zone <NUM>) of building a provider service table<IMG>redirecting system service routine(s) to the service call provider. In some embodiments, act <NUM> comprises, based at least on a call from the operating system to a secure operating system within a higher trust security zone, building a provider service table redirecting a system service routine in the set of system service routines to the service call provider. In an example, based on a call from a portion of the provider loader <NUM> in provider manager 112a to portion of the provider loader <NUM> in provider manager 112b, the service table manager <NUM> creates the provider service table <NUM>, comprising one or more entries requested by the provider metadata <NUM>.

In embodiments, for at least one system service routine, the provider metadata <NUM> indicates a function at the service call provider <NUM> (e.g., within code pages <NUM>) to which the system service routine should be redirected. Thus, in some embodiments, building the provider service table includes generating a first service table entry referencing a first function within the service call provider. In embodiments, for at least one system service routine, the provider metadata <NUM> indicates that the system service routine should be handled by the OS kernel <NUM>. Thus, in some embodiments, building the provider service table includes generating a second service table entry referencing a second function within an operating system kernel.

Referring again to <FIG>, in embodiments, method <NUM> also comprises an act <NUM> (within security zone <NUM>) of hardware protecting the provider service table. In some embodiments, act <NUM> comprises, based at least on a call from the operating system to a secure operating system within a higher trust security zone, hardware protecting a memory page associated with the provider service table. In an example, the service table requester <NUM> operates to read-only protect one or more memory pages associated with provider service table <NUM>, when those memory page(s) are exposed to the OS kernel <NUM>. For example, a portion of the service table requester <NUM> at the provider manager 112b interacts with the memory protector <NUM> to read-only protect memory page(s) storing the provider service table <NUM>.

Referring again to <FIG>, in embodiments, method <NUM> also comprises an act <NUM> (within security zone <NUM>) of exposing a read-only view of the provider service table. In some embodiments, act <NUM> comprises, based at least on a call from the operating system to a secure operating system within a higher trust security zone, exposing a read-only view of the provider service table to the operating system. In an example, the service table manager <NUM> exposes the provider service table <NUM> to the OS kernel <NUM> via one or more read-only protected memory pages.

Technical effects of acts <NUM>-<NUM> include enabling a service call provider <NUM> to securely initiate creation a provider service table <NUM> that can be used securely direct service calls from a user-mode process to the service call provider <NUM>, without "hooking" or otherwise modifying a standard service table <NUM> (e.g., a system service descriptor table).

Referring again to <FIG>, in embodiments, method <NUM> also comprises (within kernel mode 109b of security zone <NUM>) an act <NUM> of associating the provider service table with a user-mode process. In some embodiments, act <NUM> comprises associating the provider service table with a user-mode process executing in the lower trust security zone. In an example, the service table associator <NUM> associates the user-mode process <NUM> with the provider service table <NUM>.

As discussed, a user-mode process may be associated with a provider service table on an opt-in basis (e.g., based on the user-mode process, or any entity that has write access to the user-mode process, making a request to the provider manager <NUM>). For example, method <NUM> is shown as potentially comprising an act <NUM> (within user mode 109a of security zone <NUM>) of sending an opt-in request. Thus, in some embodiments of act <NUM>, the provider service table is associated with the user-mode process based on the operating system receiving a call from the user-mode process requesting to opt-in to use of the service call provider.

As discussed, a user-mode process may be associated with a provider service table on a compulsory basis (e.g., based on a decision by the OS kernel <NUM>). Thus, in some embodiments of act <NUM>, the provider service table is associated with the user-mode process based on the operating system determining that the user-mode process will use the service call provider.

As discussed, in some embodiments, the association of a provider service table with a user-mode process is accomplished by updating a data structure associated with the user-mode process (e.g., process information structure <NUM>) to identify the provider service table (e.g., via an array index). Thus, in some embodiments of act <NUM>, associating the provider service table with the user-mode process executing in the lower trust security zone comprises updating a data structure associated with the user-mode process to include an identifier of the provider service table. Technical effects of act <NUM> include configuring an OS kernel <NUM> to direct systems calls received from a user mode process to a provider service table <NUM>, rather than to a standard service table <NUM>.

After associating a provider service table (e.g., provider service table <NUM>) with a user-mode process (e.g., user-mode process <NUM>), the dispatcher <NUM> uses this provider service table when handling service calls from this user-mode process. Thus, in <FIG>, method <NUM> also comprises an act <NUM> (within user mode 109a of security zone <NUM>) of sending a service call (e.g., by the user-mode process <NUM>), and an act <NUM> (within kernel mode 109b of security zone <NUM>) of determining that a provider service table is associated with the user-mode process. In some embodiments, act <NUM> comprises, based at least on receiving a service call for a particular system service routine from the user-mode process, determining that the provider service table is associated with the user-mode process. In an example, the user-mode process <NUM> sends a service call to the OS kernel <NUM>. The OS kernel <NUM>, in turn, uses the dispatcher <NUM> to process the service call, and the dispatcher <NUM> determines that provider service table <NUM> is associated with the user-mode process <NUM>.

As mentioned, in some embodiments, the association of a provider service table with a user-mode process is accomplished by updating a data structure associated with the user-mode process to include an identifier of the provider service table. Thus, in some embodiments of act <NUM>, determining that the provider service table is associated with the user-mode process comprises identifying the provider service table within the data structure associated with the user-mode process.

Referring again to <FIG>, in embodiments, method <NUM> also comprises an act <NUM> (within kernel mode 109b of security zone <NUM>) of identifying a particular service routine. In some embodiments, act <NUM> comprises, based at least on receiving a service call for a particular system service routine from the user-mode process, identifying the particular system service routine within the provider service table. In an example, the dispatcher <NUM> identifies a system call routine entry within that provider service table <NUM> that corresponds to the service call.

Referring again to <FIG>, in embodiments, method <NUM> also comprises an act <NUM> (within kernel mode 109b of security zone <NUM>) of directing the service call to the service call provider. In some embodiments, act <NUM> comprises, based at least on receiving a service call for a particular system service routine from the user-mode process, directing the service call to the service call provider. In an example, when the system call routine entry identified in act <NUM> maps to a function within service call provider <NUM>, the dispatcher <NUM> dispatches the service call to that function.

Technical effects of acts <NUM>-<NUM> include direction of a service call through a provider service table <NUM> to a service call provider <NUM>, rather than through a standard service table <NUM> to standard kernel routines.

In some embodiments, the system call routine entry identified in act <NUM> maps to a function within the OS kernel <NUM>. In these embodiments, the dispatcher <NUM> dispatches the service call to the OS kernel <NUM>. In other embodiments, the system call routine entry identified in act <NUM> is configured to according to a policy defined in the provider metadata <NUM>, such as to block, to return failure, to both block and return failure, etc. In these embodiments, the dispatcher <NUM> applies the policy (e.g., by blocking and/or by returning failure).

Although not expressly illustrated, in some embodiments of method <NUM>, the method also comprises and act of unloading the service call provider, such as in response to a request from service call provider <NUM>. In these embodiments, the provider unloader <NUM> unloads service call provider <NUM>, as well as provider service table <NUM>. In embodiments, this unloading includes the provider unloader <NUM> determining that the service call provider is to be unloaded. In embodiments, this unloading also includes, based on determining that the service call provider is to be unloaded, the provider unloader <NUM> ensuring that no user-mode process is opted-in to use of the service call provider. In embodiments, this unloading includes, after ensuring that no user-mode process is opted-in to use of the service call provider, the provider unloader <NUM> unloading the service call provider and remove the provider service table.

Accordingly, the secured system service redirection technology described herein enables an operating system to securely reroute operating system service calls to verified service call providers that are registered with the operating system. Service call providers are dynamically and securely loaded into the operating system, and offer value-add services such as system call monitoring, system call filtering, system call sandboxing, anti-malware monitoring, and the like. Embodiments allow verified service call providers to register alternate service tables within an operating system, and ensure that service calls dispatched through these tables are done so in a secure manner, all while leveraging virtualization-based security in order to validate and maintain provider service tables in a tamper-proof manner.

Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the described features or acts described above, or the order of the acts described above.

Embodiments of the present invention may comprise or utilize a special-purpose or general-purpose computer system that includes computer hardware, such as, for example, one or more processors and system memory, as discussed in greater detail below. Such computer-readable media can be any available media that can be accessed by a general-purpose or special-purpose computer system. Computer-readable media that store computer-executable instructions and/or data structures are computer storage media. Computer-readable media that carry computer-executable instructions and/or data structures are transmission media. Thus, by way of example, and not limitation, embodiments of the invention can comprise at least two distinctly different kinds of computer-readable media: computer storage media and transmission media.

Computer storage media are physical storage media that store computer-executable instructions and/or data structures. Physical storage media include computer hardware, such as RAM, ROM, EEPROM, solid state drives ("SSDs"), flash memory, phase-change memory ("PCM"), optical disk storage, magnetic disk storage or other magnetic storage devices, or any other hardware storage device(s) which can be used to store program code in the form of computer-executable instructions or data structures, which can be accessed and executed by a general-purpose or special-purpose computer system to implement the disclosed functionality of the invention.

Further, upon reaching various computer system components, program code in the form of computer-executable instructions or data structures can be transferred automatically from transmission media to computer storage media (or vice versa). For example, computer-executable instructions or data structures received over a network or data link can be buffered in RAM within a network interface module (e.g., a "NIC"), and then eventually transferred to computer system RAM and/or to less volatile computer storage media at a computer system.

Those skilled in the art will appreciate that the invention may be practiced in network computing environments with many types of computer system configurations, including, personal computers, desktop computers, laptop computers, message processors, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, tablets, pagers, routers, switches, and the like. As such, in a distributed system environment, a computer system may include a plurality of constituent computer systems.

A cloud computing model can be composed of various characteristics, such as on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service, and so forth. A cloud computing model may also come in the form of various service models such as, for example, Software as a Service ("SaaS"), Platform as a Service ("PaaS"), and Infrastructure as a Service ("IaaS"). The cloud computing model may also be deployed using different deployment models such as private cloud, community cloud, public cloud, hybrid cloud, and so forth.

Some embodiments, such as a cloud computing environment, may comprise a system that includes one or more hosts that are each capable of running one or more virtual machines. During operation, virtual machines emulate an operational computing system, supporting an operating system and perhaps one or more other applications as well. In some embodiments, each host includes a hypervisor that emulates virtual resources for the virtual machines using physical resources that are abstracted from view of the virtual machines. The hypervisor also provides proper isolation between the virtual machines. Thus, from the perspective of any given virtual machine, the hypervisor provides the illusion that the virtual machine is interfacing with a physical resource, even though the virtual machine only interfaces with the appearance (e.g., a virtual resource) of a physical resource. Examples of physical resources including processing capacity, memory, disk space, network bandwidth, media drives, and so forth.

Claim 1:
A computer system (<NUM>) for securely redirecting a system service routine via a provider service table (<NUM>), comprising:
a processor (<NUM>); and
a hardware storage device (<NUM>, <NUM>) that stores computer-executable instructions that are executable by the processor to cause the computer system to:
load (<NUM>) a service call provider (<NUM>) within an operating system (<NUM>) executing in a lower trust security zone (<NUM>), the service call provider comprising provider metadata (<NUM>) indicating a set of system service routines to be redirected to the service call provider;
based at least on a call from the operating system to a secure operating system (<NUM>) within a higher trust security zone (<NUM>):
build (<NUM>) a provider service table (<NUM>) redirecting a system service routine in the set of system service routines to the service call provider,
hardware protect (<NUM>) a memory page associated with the provider service table, and
expose (<NUM>) a read-only view of the provider service table to the operating system executing in the lower trust security zone, wherein the building, the hardware protecting and the exposing are performed within the higher trust security zone;
associate (<NUM>) the provider service table with a user-mode process (<NUM>) executing in the lower trust security zone, wherein the associating is performed within the lower trust security zone; and
based at least on receiving a service call for a particular system service routine from the user-mode process:
determine (<NUM>) that the provider service table is associated with the user-mode process,
identify (<NUM>) the particular system service routine within the provider service table, and
direct (<NUM>) the service call to the service call provider, wherein the determining, the identifying and the directing are performed within the lower trust security zone.