Patent Description:
This document discloses a method as defined by claim <NUM>, a computer system defined by claim <NUM>, and a computer program product defined by claim <NUM>. In general terms, it describes an example computing system and method that leverages a resource management unit to capture a configuration state of an operating system (OS) executing on a central processing unit (CPU), and to identify malware or vulnerable software to protect the computing system. The resource management unit identifies a fingerprint of a process and compares the fingerprint to a plurality of fingerprints of flagged processes. The flagged processes are indicative of processes, executable files, programs, applications, operating systems, or other software that include executable instructions that have a known vulnerability or have been identified as malware. If the fingerprint of the process matches one of the fingerprints of the flagged processes, then the resource management unit acts to protect the computing system from unwanted effects of the process. By doing so, the resource management unit alleviates the CPU from expending resources to identify the malware or vulnerability and from being impacted by the same.

The computing system includes the CPU, the resource management unit, and memory having instructions that, responsive to execution by the CPU or the resource management unit, cause the resource management unit to capture the configuration state of the operating system to identify malware and vulnerabilities. In other aspects, the computing system includes a hypervisor or virtual machine, and the resource management unit captures the configuration state of the operating system of the hypervisor or virtual machine to identify malware and vulnerabilities.

The details of one or more methods, devices, systems, and procedures for capturing operating system configuration states for offloading tasks to a resource management unit for managing malware and vulnerabilities are set forth in the accompanying drawings and the following description. Other features and advantages will be apparent from the description, drawings, and claims. This summary is provided to introduce subject matter that is further described in the detailed description and drawings. Accordingly, this summary should not be considered to limit the scope of the claimed subject matter.

The details of one or more aspects of a resource management unit for capturing operating system configuration states for managing malware and vulnerabilities are described with reference to the following drawings. The use of the same reference numbers in different instances in the description and the figures may indicate like elements.

This disclosure describes methods and systems for capturing operating system configuration states to offload tasks for managing malware and vulnerabilities to a resource management unit. A computing system leverages a resource management unit, such as a system-on-chip (SoC), to capture a configuration state of an operating system (OS) executing on a central processing unit (CPU) of the computing system. Based on the configuration state of the operating system, the resource management unit identifies a status of a process in the computing system as malware or vulnerable software. The resource management unit identifies a fingerprint of the process, and compares the fingerprint to a plurality of fingerprints of flagged processes. The flagged processes are indicative of processes, executable files, programs, applications, or other software that include executable instructions that have a known vulnerability or have been identified as malware. If the fingerprint of the process matches one of the fingerprints of the flagged processes, then the resource management unit acts to protect the computing system from unwanted effects of the process.

This disclosure generally describes capturing an operating system configuration state with a resource management unit and, based on the captured state, offloading tasks. Various ways in which to offload tasks are described, including processing tasks, memory management, malware and vulnerability management, and dynamically scaling clock rates. While these examples are described in subsections below, these subsections are not intended to limit these examples to being only described in those subsections, their coexistence with other examples, or their independent operation.

Hardware components of a computer system are often configured to assist an operating system or CPU with processing tasks. These processing tasks, however, remain managed by the operating system, which is executed through the CPU. Further, these components impose their own limitations on the operating system and CPU, such as application programming interfaces (APIs) in the form of cyclic buffers, memory mapped input/output (MMIO), shared-memory limitations, and sizing restrictions for swapping memory pages or I/O blocks. These limitations continue to burden the CPU, often causing delay or reduced performance of the computing system, even from a user's perspective. For example, as the operating system manages the system's resources, such as scheduling tasks, pausing execution of a process, allocating memory, swapping memory, starting execution of another process, and so forth, a user's input or expected output in response to that input may be delayed. This may occur even if some of these functions are assigned to, and completed with the help of, additional hardware because the operating system remains responsible for assigning the tasks or executing certain functions related to these hardware components through the CPU, thus burdening the CPU.

In contrast, the resource management unit of this disclosure avoids these limitations by capturing the operating system configuration state, storing it into a database (e.g., memory) associated with or accessible by the resource management unit, identifying from the database a status of resources in the system, and independently processing tasks associated with the resources. This independent processing by the resource management unit effectively alleviates the processor from having to perform the tasks thus improving overall system performance.

Although the described resource management unit can be an SoC, other hardware configurations may similarly be used, either alone or in combination with firmware or software, that provides comparable functionality to the resource management unit of this disclosure.

<FIG> is a block diagram illustrating an example computing system <NUM> having a resource management unit <NUM>, e.g., a system-on-a-chip (SoC) and associated memory <NUM>, as well as a processor <NUM> (e.g., the CPU) and its associated memory <NUM>. The memory <NUM> and <NUM> are computer-readable storage media, and can include various implementations of random-access memory (RAM), read-only memory (ROM), flash memory, cache memory, and other types of storage memory in various memory device configurations, including a shared memory configuration. The memory <NUM> includes the operating system <NUM> and instructions that execute on the processor <NUM>.

The resource management unit <NUM> includes an OS configuration state manager <NUM> configured to capture or obtain (used interchangeably herein) an OS configuration state <NUM> of the operating system <NUM>. The OS configuration state <NUM> reflects a momentary state or status of the operating system at a given point in time. As an example, and for simplicity of this discussion, the OS configuration state <NUM> reflects a status of the operating system upon a resource transaction event <NUM> occurring in the operating system <NUM>. However, other events or times may similarly be selected to capture the OS configuration state.

The OS configuration state manager <NUM> captures and stores the OS configuration state <NUM> into an OS configuration state database (database) <NUM>. The database <NUM> may be located in the memory <NUM> or any other fast memory associated with the resource management unit <NUM>, either fabricated on or as part of the resource management unit or located elsewhere in the computing system <NUM> and accessible by the resource management unit <NUM> via low-latency access. The OS configuration state database <NUM> may be any standard database structure, such as a table, tree, hierarchical, relational (e.g., MySQL, SQLite, Oracle, Sybase), NoSQL or object-oriented scheme, configured to capture indicators of the operating system configuration state as described in this disclosure.

The OS configuration state <NUM> captured into the OS configuration state database <NUM> may include information associated with a process run queue, a process wait queue, active devices, and virtual memory tables. These queues include process data relevant to specific processes in each queue. The process data includes data defining the status of that process as stored in a data structure, such as a process control block or similar structure, as described further below for defining and tracking processes and activity in operating systems. The virtual memory tables define the storage allocation scheme in which a secondary storage <NUM> (e.g., memory) can be addressed as though it were part of the memory <NUM>. Other example aspects of the operating system captured may include process priority data, process run-time remaining, resource scheduling data, resource usage data, memory usage data, memory mapping data, storage management data, active device data, a hypervisor status, a virtual machine (VM) status, a VM guest operating system status, or resources used by the hypervisor or virtual machine. Additional operating system aspects captured may be similar to those identified using an operating system analysis tool, such as a Linux operating system event-oriented observability tool, e.g., "perf. " This allows for tracking performance counters, events, trace points, tasks, workload, control-flow, cache misses, page faults, and other profiling aspects of the operating system to provide a robust reference perspective of the operating system configuration state.

For purposes of this disclosure, a process is an instance of a program (e.g., binary program file) in execution on a processor <NUM> (or a core or cores of the processor). A process may be defined by how it is referenced in memory. Examples of a process definition in memory may include elements of text (e.g., compiled program code), data (e.g., global and static variables), heap (e.g., for dynamic memory allocation), stack (e.g., local variables), and information related to program counters and registers. A state of a process (process state) in the operating system may include: (i) a new process being created, (ii) a ready process that has its resources ready but not yet running on the processor, (iii) a running process that is being executed by the processor, (iv) a waiting process that is not running but is waiting for an event to occur or resource to become available, and (v) a terminated process that has completed execution on the processor. Additionally, for each process there is a data structure, referenced as a process control block in this disclosure (e.g., see <FIG>), that stores the process-specific information. The process control block may include data indicative of: (i) the process identification (ID), (ii) the process state, (iii) processor registers and program counter (e.g., for swapping the process in and out of the processor), (iv) processor scheduling information (e.g., priority information), (v) memory management data (e.g., page tables), (vi) accounting data (e.g., processor time consumed, limits), and (vii) input/output status data (e.g., devices used, open files).

The resource management unit <NUM> further includes a resource status manager <NUM> and a resource task manager <NUM>. The resource status manager <NUM> identifies a status of a resource in the computing system, as stored in the database <NUM>, based on the OS configuration state <NUM>. For example, a status of a process is detected by referencing the process control block of that process, thereby detecting the process state, registers, scheduling, priority, memory management, and other process-related information. The resource task manager <NUM> processes a task associated with the status of the resource, as identified by the resource status manager <NUM>, to alleviate the processor <NUM> from performing the task and thereby improving overall performance of the computing system <NUM>. For example, if the process control block indicates a process is in a waiting state and a memory resource is needed, the resource task manager <NUM> processes a task of freeing memory so the process may move from the wait state to the ready state for execution. Although the OS configuration state manager <NUM>, resource status manager <NUM>, and resource task manager <NUM> are shown in the diagram as being stored as executable instructions (e.g., firmware or software) in the memory <NUM>, the same may alternatively be formed in digital logic hardware blocks on the resource management unit <NUM>, or enabled using a combination of firmware, software, and hardware blocks.

A communication manager <NUM> enables communications external to the computing system <NUM>, such as to a networked computing environment, the Internet, or a cloud or multi-cloud network computing environment, generally referred to herein as a network <NUM>. The resource management unit <NUM> and processor <NUM> together form a processor complex in the computing system <NUM>, and the memory <NUM>, <NUM> include data or instructions stored thereon to cause the processor complex <NUM>, <NUM> to perform the methods and functions described throughout this document.

A secondary storage <NUM> provides additional storage (e.g., memory) functionality for the computing system <NUM>. Examples of the secondary storage <NUM> include non-volatile memory, fixed and removable media devices, and any suitable memory device or electronic data storage that maintains executable instructions and/or supporting data. The secondary storage <NUM> can include various implementations of RAM, ROM, or other types of non-volatile memory such as a solid-state drive (SSD) or a hard disk drive (HDD), or combinations thereof. The secondary storage <NUM> may be used for storing software applications or data, or for memory management purposes.

The resource management unit <NUM> may include other components not shown in this example, such as processing units (e.g., central processing units, graphics processing units, artificial intelligence processing units, display processors, video processors), communication units (e.g., modems), input/output controllers, and sensor hubs (see <FIG> for additional examples).

The resource management unit <NUM> and the processor <NUM> communicate using low-latency communication and write transactions, either by way of the resource management unit being implemented on a same integrated circuit die as the processor and its memory <NUM>, or by using a high-speed interface bus <NUM> and data link <NUM>. The high-speed bus <NUM> may be any fast bus standard that creates a seamless interface between the resource management unit <NUM> and the processor <NUM>, such as the Peripheral Component Interconnect Express bus, otherwise known as PCI Express or PCIe, or other similar open or proprietary bus standard with low-latency performance. The resource management unit <NUM> may also have a direct memory access (DMA) channel to the memory <NUM> via the data link <NUM> for transferring data to/from the memory <NUM> without passing it through the processor <NUM>.

In one example, capturing an OS configuration state <NUM> of the operating system <NUM>, in coordination with the OS configuration state manager <NUM> on the resource management unit <NUM>, includes detecting resource transaction events <NUM> indicative of operational status information of the operating system and its managed resources. Examples of resource transaction events include events regarding a process run queue, a process wait queue, process priority data, process run-time remaining, resource scheduling data, resource usage data, active device data, memory usage data, memory mapping data, virtual memory tables, storage management data, a hypervisor status, a virtual machine (VM) status, a VM guest operating system, or resources used by the hypervisor or virtual machine.

In one example, a resource transaction event <NUM> is detected and the OS configuration state <NUM> is captured by using an OS abstraction layer of instructions <NUM>. These instructions <NUM> are executed by the processor <NUM> to push the OS configuration state to the resource management unit <NUM>. Alternatively, or in combination with the abstraction layer, the OS configuration state manager <NUM> on the resource management unit <NUM> is configured to capture or pull the OS configuration state <NUM> upon detecting resource transaction events <NUM>. In some cases these resource transaction events <NUM> are detected through monitoring write transactions to the high-speed bus <NUM> interface and data link <NUM>, such as through API queues and interrupt lines.

The OS configuration state <NUM>, captured via the OS configuration state manager <NUM> in the resource management unit <NUM>, is stored in the OS configuration state database <NUM> associated with the resource management unit memory <NUM> so that the resource status manager <NUM> may identify a status of any particular resource by accessing the database. Examples of resources for which a status may be identified include a process run queue, process wait queue, process priority data, process run-time remaining, resource scheduling data, active device data, memory usage data, memory mapping data, virtual memory tables, storage management data, a hypervisor, a virtual machine (VM), a VM guest operating system, and resources used by the hypervisor or virtual machine.

Based on an understanding of the OS configuration state database <NUM> and its depiction of operating system resources, the resource management unit resource task manager <NUM> processes a task associated with the status of a resource. The resource management unit <NUM> identifies and acts on a resource task in advance of what the processor <NUM> may identify and process. The resource management unit can increase processing priority or performance factors for a specific task, or address a security aspect of the computing system relative to a particular process, or process an overhead management activity of the computing system. All these aspects can result in improved overall system performance and also an improved user's perception of responsive processing. This reduced latency, both real and as perceived by a user, is enabled because the processor <NUM> can focus on user-perceivable activities or other priorities while the resource management unit performs overhead system management work and other processing tasks.

<FIG> is a block diagram illustrating another example of a computing system <NUM> generally including the resource management unit <NUM>, operating system <NUM>, memory <NUM>, and processor <NUM>. However, in this example the computing system <NUM> is configured with a hypervisor <NUM> and virtual machine <NUM> running a guest operating system. Although only one virtual machine is depicted, the computing system <NUM> may include multiple virtual machines and/or guest operating systems as managed by the hypervisor <NUM>.

The components, functionality, and methods previously discussed with respect to <FIG> perform similarly for managing the hypervisor and virtual machine components included in <FIG>. For example, the OS configuration state manager <NUM> of the resource management unit <NUM> stores the OS configuration state <NUM> into an OS configuration state database <NUM>. The OS configuration state <NUM>, however, may include operating system aspects relating to the hypervisor <NUM> and virtual machine <NUM>. The resource status manager <NUM> again identifies a status of a resource in the computing system, as stored in the database <NUM> based on the configuration state <NUM> of the operating system <NUM>, hypervisor <NUM>, and virtual machine <NUM>. The resource task manager <NUM> processes a task associated with the status of the resource, as identified by the resource status manager <NUM>, to alleviate the processor <NUM> from performing the task, thus improving overall performance of the computing system.

Similar to the aspects discussed in reference to <FIG>, capturing the OS configuration state <NUM> of the operating system <NUM>, the hypervisor <NUM>, and the virtual machine <NUM>, includes obtaining operational status information of the operating system and its managed resources. This information may be obtained by monitoring and detecting the OS resource transaction events <NUM>. Such information may be captured by the resource management unit <NUM> by using virtualization technologies <NUM>, such as single root input/output virtualization (SR-IOV) or multi-root input/output virtualization (MR-IOV), to allow isolation of the bus (e.g., PCIe) by the hypervisor or virtual machine for manageability and performance. Example operational status information of the managed resources may relate to a process run queue, a process wait queue, process priority data, process run-time remaining, resource scheduling data, resource usage data, active device data, memory usage data, memory mapping data, virtual memory tables, storage management data, a hypervisor, a virtual machine, a virtual machine guest operating system, or resources used by the hypervisor or virtual machine.

<FIG> is a conceptual diagram illustrating an example computing system <NUM> as, or integrated into, a computing device <NUM> configured with components and functionality for capturing OS configuration states for offloading tasks to a resource management unit (e.g., a resource management unit <NUM>). The computing device <NUM> is an example computing environment or application for the computing system <NUM> of <FIG>. As some non-limiting examples, the computing device <NUM> may be a mobile phone <NUM>-<NUM>, a tablet device <NUM>-<NUM>, a laptop computer <NUM>-<NUM>, a television/display or desktop or server computer <NUM>-<NUM>, a computerized watch <NUM>-<NUM>, or other wearable device <NUM>-<NUM>, a game controller <NUM>-<NUM>, a networked multimedia or voice assistant system <NUM>-<NUM>, or an appliance <NUM>-<NUM>.

The computing device <NUM> includes the resource management unit <NUM>, the memory <NUM>, and the OS configuration state manager <NUM> configured to capture or obtain the OS configuration state <NUM> of the operating system <NUM> stored in the memory <NUM> and executing on the processor <NUM>. The OS configuration state manager <NUM> of the resource management unit <NUM> stores the OS configuration state <NUM> into an OS configuration state database <NUM> associated with the resource management unit <NUM>. The resource status manager <NUM> identifies a status of a resource in the computing device, as stored in the database <NUM> based on the OS configuration state <NUM>. The resource task manager <NUM> processes a task associated with the status of the resource, as identified by the resource status manager <NUM>, to alleviate the processor <NUM> from performing the task and thereby improving overall performance of the computing device.

The computing device <NUM> also includes communication components <NUM>, input/output components <NUM>, communication interfaces <NUM>, and input/output interfaces <NUM>. These interfaces and components may leverage the memory <NUM> and processor <NUM>, and/or be incorporated into the resource management unit <NUM> to leverage its operations.

The resource management unit <NUM> may also include processing units <NUM>. The processing units <NUM> process computer-executable instructions to perform operations and execute functions of the computing device <NUM>. The processing units <NUM> may include any combination of controllers, microcontrollers, processors, microprocessors, hardware processors, hardware processing units, digital-signal-processors, graphics processors, graphics processing units, video processors, video processing units, and the like.

The memory <NUM> associated with the resource management unit <NUM>, and the memory <NUM>, store information and instructions that are executed by the processor <NUM> and/or processing units <NUM> to perform operations and execute functions. These memories are configured to provide the computing device <NUM> with persistent and/or non-persistent storage of executable instructions (e.g., firmware, recovery firmware, software, applications, modules, programs, functions, and the like) and data (e.g., user data, operational data, scan results) to support execution of the executable instructions. Examples of these memories include volatile memory and non-volatile memory, fixed and removable media devices, and any suitable memory device or electronic data storage that maintains executable instructions and supporting data. These memories can include various implementations of RAM, ROM, flash memory, cache memory, and other types of storage memory in various memory device configurations, or may be a solid-state drive (SSD), a hard disk drive (HDD), or combination thereof. These memories exclude propagating signals.

The communication components <NUM> enable wired and/or wireless communication of device data between the computing device <NUM> and other devices, computing systems, and network <NUM>. The communication components <NUM> can include receivers, transmitters, and transceivers for various types of wired and wireless communications. Communication interfaces <NUM> handle messaging and protocols associated with communications being transmitted and received using the communication components <NUM>.

The input/output components <NUM> provide connectivity to the computing device <NUM>. For example, the input/output components <NUM> may include a user interface device that manages a user interface of the computing device <NUM>, or may provide additional connectivity, beyond just the user interface device. The input/output components <NUM> can also include data interfaces or data input ports for receiving data, including user inputs. The processor <NUM> and/or processing units <NUM> may tailor operations according to input information obtained by the input/output interfaces <NUM> from the input/output components <NUM>. Likewise, based on information obtained by the communication interfaces <NUM> from the communication components <NUM>, the processor <NUM> and/or processing units <NUM> tailor operations according to incoming or outgoing communications.

<FIG> are flow diagrams <NUM>, <NUM> illustrating high-level operations of example methods for capturing operating system configuration states in a computing system for offloading tasks to a resource management unit. The operations of methods <NUM>, <NUM>, and other methods described herein, may be embodied as programming instructions stored on a non-transitory, machine-readable (e.g., computer/processor-readable) medium, such as a RAM or ROM memory or other storage device for execution in a computing device or devices, or may be performed by hardware blocks, or combinations thereof. In some examples, implementing the operations of the methods can be achieved by a processor complex, including a main processor and a resource management unit, reading and executing the programming instructions stored in the memory, and/or functioning in combination with hardware blocks of the resource management unit. In some examples, implementing the operations of the methods can be achieved using a resource management unit such as a system-on-chip (SoC), and/or other hardware components either alone or in combination with programming instructions executable by a processor or processors in a computing device.

The example methods described in this disclosure may include more than one implementation, and different implementations of the methods may not employ every operation presented in the respective flow diagrams, or may employ additional operations not shown. Therefore, while the operations of the methods are presented in a particular order within the flow diagram(s), the order of their presentations is not intended to be a limitation as to the order in which the operations may actually be implemented, or as to whether all of the operations may be implemented. For example, one implementation of the methods might be achieved through the performance of a number of initial operations, without performing subsequent operations, while another implementation of the methods might be achieved through the performance of all of the operations.

Referring now to example method <NUM> of <FIG>, a first operation <NUM> includes posting an operating system resource transaction event in a memory of a computing system responsive to the operating system executing on a processor in the computing system. An operating system transaction event is indicative of when a configuration state of the operating system may be captured because an operating system event is occurring or has occurred. Capturing a configuration state of the operating system includes obtaining operational status information of the operating system and its managed resources. Examples of such resources and operating system operational status information include a process run queue, a process wait queue, process priority data, process run-time remaining, resource scheduling data, resource usage data, active device data, memory usage data, memory mapping data, virtual memory tables, storage management data, hypervisor activity, virtual machine activity, virtual machine guest operating system activity, and other related process and system activities, statuses, and data.

At <NUM>, a resource management unit, such as an SoC, obtains the configuration state of the operating system and stores it in a database (e.g., memory) associated with the resource management unit. For example, the resource management unit <NUM> described above obtains the configuration state by communicating with the processor and memory using low-latency communication and read/write transactions, either by way of the resource management unit being implemented on a same integrated circuit die as the processor and its memory, or by using a high-speed interface bus and data link. The resource management unit may also have a direct memory access (DMA) channel to the memory for transferring data to/from memory without passing it through the processor in the computing system.

At <NUM>, the resource management unit identifies a status of a resource in the computing system based on the operating system configuration state stored in the database, and identifies a task to be performed that is associated with the resource. For example, a status of a process resource in the process run-queue may be identified as a process that is next up for execution time on the processor, and that a memory resource of some number of bytes is needed for the process to execute. As another example, a status of a process resource in the process wait-queue may be identified as one that is waiting for a resource-related event to occur. An example event may be that the process needs a virtual file system (VFS) inode describing a directory in the file system, but that inode may not be in the cache. Because of this, the process must wait for that inode to be fetched from the physical media containing the file system before it can continue executing.

At <NUM>, the resource management unit processes the task associated with the status of the resource to alleviate the processor from performing that task and to improve the performance of the computing system. For example, in the context described above (that of a task needing a memory resource of some number of bytes of memory), the resource management unit may execute the task of making that memory resource available, such as by swapping out memory, so that sufficient memory is available when the process is actually executed again on the processor. As another example, in the context described above regarding the wait-queue waiting for an inode to be fetched, the resource management unit may execute the task to fetch the inode in advance of when the operating system and processor may be able to do it. This allows processes to avoid waiting to execute relative to if they had waited for the processor (not the resource management unit device's processor) to fetch the inode. Other examples include the resource management unit modifying processing priority or performance factors for a specific process, addressing a security aspect of the computing system relative to a particular process, and processing other overhead management activities of the computing system.

Referring now to <FIG>, example method <NUM> depicts additional details for capturing operating system configuration states for offloading tasks to a resource management unit in a computing system. At <NUM>, an operating system stored in a memory executes on a processor in a computing system. At <NUM>, during execution of operating system instructions, the operating system posts a resource transaction event to memory indicative of a resource event occurring and a new configuration state of the operating system. As an example, an abstraction layer of the operating system software posts resource transaction event data indicative of, for example, a process execution status, resource usage and scheduling, memory usage and mapping, hypervisor status, virtual-machine status, and/or any other transaction event that the operating system is managing for the computing system.

At <NUM>, a resource management unit communicates with the processor and memory via a low-latency communication data link. Such low-latency communication data link may be a high-speed bus (e.g., PCIe) or via cache if the resource management unit is implemented on a same integrated circuit die as the processor. At <NUM> the resource management unit obtains (e.g., captures) the configuration state of the operating system and stores it to a database associated with the resource management unit. Note that after a transaction event is posted <NUM>, a return execution flow arrow <NUM> in the diagram illustrates that the operating system continues executing on the processor <NUM>, even while the resource management unit communicates <NUM> with the memory and processor. This allows the operating system to continue performing its operations, even while the resource management unit is performing its functions <NUM>, <NUM>, <NUM>, for overall improved system performance.

At <NUM>, the resource management unit identifies a status of a resource from the database based on the configuration state of the operating system. For example, a status of a resource may be identified as a process that needs additional time to execute, or a process that will need to access certain I/O resources that need to be retrieved from storage, or a process that may pose a security issue if executed, or a process or system that may benefit from modifying a clock rate/signal frequency for a clocked component.

At <NUM>, the resource management unit processes a task associated with the status of the resource. For example, memory is swapped in advance so the process waiting next in queue has sufficient memory available when it begins to execute on the processor as described above, or a resource is fetched as described above, or additional memory is allocated for the process waiting next in queue, or a potential security issue is resolved concerning a process, or a component signal frequency is adjusted to meet processing demands. This awareness of a resource status enables the resource management unit to act on a task in advance of when the processor or operating system may eventually perform the task.

After the task is processed for the resource at <NUM>, execution control returns, at <NUM>, to allow the resource management unit to identify <NUM> a status of a next resource from the database as needed, and process another task <NUM> that is associated with that next resource. This processing is repeated as needed for resources identified in the database. As this resource status identification <NUM> and task processing <NUM> is performed by the resource management unit, the operating system continues executing <NUM> and posting resource transaction events <NUM>, and the resource management unit continues communicating <NUM> with the processor and memory and capturing <NUM> a configuration state of the operating system and storing it in the database. This example method of capturing operating system configuration states for offloading tasks from a processor in a computing system to a resource management unit provides overall improved computing system performance.

<FIG> is a block diagram illustrating an example OS configuration state <NUM> in a memory <NUM> of a computing system <NUM> as captured by a resource management unit <NUM> into a memory <NUM> and a database <NUM>. Similar to the discussion with respect to <FIG>, the computing system <NUM> generally includes the resource management unit <NUM>, the memory <NUM>, the operating system <NUM>, and the main processor <NUM>. This example depicts operational status information in the memory <NUM> for exemplary resources as indicative of the OS configuration state <NUM> at a time that a resource transaction event is detected (e.g., the resource transaction event <NUM>). In this example, OS configuration state <NUM> also depicts a process control block <NUM> representative of a status of an example process in the process run queue or wait queue as described above in reference to <FIG>. Although only a single process control block is depicted, a process control block exists for each process in the process run queue and wait queue. Upon detecting the resource transaction event <NUM>, the OS configuration state <NUM> is copied <NUM> (pushed or pulled) into the OS configuration state database <NUM> on the resource management unit <NUM>. Although the diagram illustrates an example OS configuration state identifying a number of example resources, other operating system configuration state resources, resource references, or status indicators may similarly be referenced, identified, and captured by the resource management unit <NUM> into the database <NUM> in coordination with the OS configuration state manager <NUM>.

With the database <NUM> having the OS configuration state <NUM>, the resource management unit <NUM> may then process a task associated with a status of any given resource identified in the database to improve the performance of the computing system. For example, the resource management unit <NUM> may increase processing priority or performance criteria for a specific process, or address a security aspect of the computing system relative to a particular process, or process an overhead management activity of the computing system, or modify a signal frequency of a clocked component. An example of processing an overhead management activity, such as memory allocation or data fetch, is described above in reference to <FIG> and further below in reference to <FIG>. Having the resource management unit process each of these tasks results in improved overall system performance and may also improve a user's perception of responsive processing in the computing system because the processor <NUM> can focus on user perceivable activities or other needed activities while the resource management unit <NUM> performs the overhead system management work.

<FIG> is a block diagram illustrating the example computing system <NUM> configured for capturing operating system configuration states by a resource management unit for dynamically scaling clock rates. Dynamically scaling clock rates or clock frequency (used interchangeably herein) of clocked components in a computing system achieves benefits including performance boost, power optimizations, thermal dynamic constraints, and reduced processing time. Enabling a resource management unit, rather than a CPU, to dynamically scale clock rates in the system responsive to operating system configuration states, enables more-responsive and relevant scaling to active events, and avoids the CPU wasting resources on scaling tasks so that it may address other computing system operations.

The operating system <NUM> executes on the processor <NUM> from the memory <NUM>, and upon detecting an OS transaction event <NUM>, the OS configuration state <NUM> is captured <NUM> by the OS configuration state manager <NUM> of the resource management unit <NUM> and stored into the OS configuration state database <NUM> of the memory <NUM>. For simplicity and drawing space limitations, only two example operating system resources are shown in the OS configuration state <NUM> and the database <NUM>, a process run queue and a process wait queue, although other OS configuration state resources, status indicators, or data may similarly be represented, referenced, identified, and captured by the resource management unit <NUM> into the database <NUM>.

With the process run queue and process wait queue resources represented in the database <NUM>, the resource management unit resource status manager <NUM> may then identify the status of a specific resource <NUM> in those queues and process a task <NUM> associated with the specific resource to improve the performance of the computing system. In this example, the resource status manager <NUM> identifies the status of a process resource from the run queue in the database <NUM> that indicates it requires or would benefit from modifying the clock rate for a clocked component in the computing system. The benefits include to maintain or improve performance of the process, overall system performance, power usage, or thermal dynamics of the computing system <NUM>. In one example, the status of the process resource is identified by referencing the process control block. Factors in the process control block considered may include the process state, scheduling information, memory management data, and accounting data that indicates significant processing time is needed or consumed or that significant memory is needed. By knowing the status of the process, such as when it is going to execute, the resources it needs, and the status of other resources in the computing system, the resource management unit may dynamically scale clock rates accordingly. Modifying the clock rate may include modifying a performance of the processor or access speed of the memory to address load operating conditions, performance, power consumption, thermal dynamics in the computing system, or combinations thereof.

With the captured OS configuration state available <NUM> that identifies the status of the process, and optionally with other process related metrics available, the resource management unit <NUM> can identify processing needs and clock-rate modification benefits in advance of what the operating system <NUM> may actually detect and execute on the processor <NUM>. For example, the OS configuration state, along with associated process metrics or a detected or assigned process score representing process metrics, can show that (i) the identified process needs more memory resources than normal, (ii) the process requires processor intensive activity, (iii) the process may work with reduced memory resources or reduced processor activity, (iv) a particular core in the processor <NUM> or a memory bank in the memory <NUM> may be powered down (e.g., clock rate terminated) for a short time, or (v) a hypervisor or virtual machine requires increased or reduced processor activity or memory usage for improved overall system performance.

Where it is determined by the resource status manager <NUM> that a clock rate of a clocked component in the computing system, such as the processor <NUM> or the memory <NUM>, may be modified to improve aspects of the process or the computing system <NUM>, then the resource task manager <NUM> initiates the task of modifying the clock rate for the relevant clocked component. In this depicted example, based on information identified about a process in the OS configuration state database <NUM>, the resource task manager <NUM> may modify a clock rate <NUM> for a clock <NUM> which modifies the clock rate signal <NUM> to the memory <NUM>. Similarly, in this depicted example, the resource task manager <NUM> may modify the clock rate <NUM> for a clock <NUM> which modifies the clock rate signal <NUM> to the processor <NUM>. The resource task manager <NUM> may similarly modify the clock rate <NUM> to any number of other clocks in the system <NUM> to modify the clock rate signal of other respective clocked components not shown in this example (e.g., a graphics processing unit (GPU), MMU, bus, specific memory bank).

To determine whether a process or the overall system may benefit from modifying the clock rate, any number of factors relating to the process, its process control block, and the OS configuration state <NUM> may be considered including, for example, memory usage, memory need, scheduling, process run queue, process wait queue, process priority data, process run-time remaining data, process scheduling data, hypervisor status, virtual-machine status, or combinations thereof. Alternatively, or in combination, processing metrics associated with a process (process metrics) may be considered that are indicative of resources used and system metrics associated with execution of the process. Process metrics may be captured, assigned a score, and stored in the database <NUM>, or the score may be detected or obtained if it was previously assigned to the process. Process metrics may be captured and obtained by monitoring the process during execution on the processor <NUM> or, if available, retrieved from the database <NUM> or a storage resource <NUM> external to the computing system <NUM> and accessible via communication manager <NUM> and the network <NUM>.

Process metrics that reflect resources used and related processing data may be obtained by using an operating system analysis tool, such as a Linux operating system event-oriented observability tool, e.g., "perf. " This allows for tracking performance counters, events, trace points, tasks, workload, control-flow, cache misses, page faults, and other profiling aspects of the operating system. Metrics of the process that are captured using an observability or profiling tool, or obtained from the external storage resource <NUM>, are maintained in the database <NUM> for the resource status manager <NUM> to reference in determining whether modifying a clock rate of a component may be advantageous for the process or system overall. Modifying the clock rate based on process metrics may be advantageous in any number of events including, for example, increasing the clock rate for the memory <NUM> if the process score or metrics indicate that the process requires heavy memory usage, or increasing the clock rate for the processor <NUM> if the process score or metrics indicate that the process requires heavy processing, or reducing the clock rate for the processor to reduce thermal issues if the process score or metrics indicate heavy processing that creates increased thermal issues.

Because the process score represents the processing metrics associated with the process, it enables the resource status manager <NUM> to quickly and easily identify whether the process or the system would benefit from modifying a clock rate of a clocked component. The score also enables the resource status manager <NUM> to easily compare the process with scores of other processes in the system. A score may be obtained from the external storage resource <NUM> if the process is one that has been previously associated with a score. For example, a process that represents a game played by users on a computing device may be assigned a score relative to its known processing metrics as used in other computing devices or systems. That score may then be stored in the external storage resource <NUM> as associated with that particular process and leveraged by the resource management unit <NUM> to quickly and easily determine benefits of modifying clock rates for the process in the computing system <NUM>.

The resource task manager <NUM> may also detect other scores associated with other process statuses stored in the OS configuration state database <NUM>, or assign other scores to those other processes based on processing metrics detected, or obtain other scores of other processes from the storage resource <NUM>, all representative of processing metrics associated with those other processes and resources used by those processes. The resource task manager may then compare the process score to the scores of the other processes to determine if, when, and how to modify clock rates for clocked components in the computing system <NUM> for improved system performance.

For example, the process score may be compared with respect to a score of another process, or to a combination of scores of multiple other processes in the process run queue, and in an event that the score of the other process or a combined score of the multiple other processes meets a given threshold indicative for modifying the clock rate of the component, then the clock rate of that component may be modified. As one example, if the process score is weighted very heavy on processor usage, and there are no other process scores in the process run queue that are weighted processor heavy, then the resource task manager <NUM> may not need to modify the clock rate for the process. On the other hand, if there are other process scores that are weighted processor heavy in the process run queue, then the resource task manager <NUM> may increase the clock rate for the process relative to the processor <NUM>, the memory <NUM>, or other clocked component.

<FIG> illustrates an example method <NUM> for capturing operating system configuration states by a resource management unit for dynamically scaling clock rates. At <NUM>, the resource management unit captures a configuration state of the operating system in memory that is executing on the processor in the computing system, and stores the configuration state to a database associated with the resource management unit. At <NUM>, the resource management unit identifies from the database a status of a process resource in the computing system based on the configuration state of the operating system. In this example for dynamically scaling clock rates, the process may be a process in a run queue waiting to execute on the processor, or a process in the wait queue that has partially executed but is paused and waiting for an event to occur before beginning to execute again.

The resource management unit examines the process status to determine whether the process or the computing system would benefit from modifying a clock rate of a clocked component in the computing system, such as the processor or memory, to maintain or improve performance of the process, overall system performance, power consumption, or thermal dynamics of the computing system. For example, the resource management unit examines the process control blocks of processes in the run queue or wait queue. If a process state, scheduling information, memory management data, and/or accounting data indicate significant processing time still needed or consumed, or significant memory needed, then the processor clock rate or memory clock rate may be increased by the resource management unit to address the need. Another example, at <NUM>, is for the resource management unit to detect whether a process score is associated with the process. The process score represents overall processing metrics associated with the process, and resources used by the process in the computing system and operating system, or in another computing system and operating system external to the computing system with the resource management unit. The process score enables the resource management unit to easily identify whether the process or the system would benefit from modifying a clock rate of a clocked component.

If a process score is not detected <NUM> in association with the process, then a process score may be obtained <NUM> from an operating system profiling tool or an external storage resource. While the process is executing in the computing system the process score may be calculated or obtained using standard operating system profiling tools known for tracking performance counters, events, trace points, tasks, workload, control-flow, cache misses, page faults, and other profiling aspects of the operating system. Alternatively, the process score may be obtained from an external storage resource.

At <NUM>, if the OS configuration state or process score meets a threshold, then the resource management unit modifies the clock rate <NUM> for a clocked component associated with the process or otherwise beneficial to the computing system. If the threshold is not met, then execution control returns <NUM> for the resource management unit to identify <NUM> a status of another process resource in the computing system.

To determine whether an OS configuration state meets the threshold <NUM> for modifying the clock rate, factors associated with the process status are considered including, for example, memory usage, memory need, scheduling, process run queue, process wait queue, process priority data, process run-time remaining data, process scheduling data, hypervisor status, virtual machine status, or combinations thereof. On the other hand, the process score allows the resource management unit to easily compare it to a threshold score <NUM>, or to compare it with scores of other processes in the system to determine if an overall threshold score is met <NUM>. Scores of other processes in the system may be obtained or calculated from a profiling tool while the other processes execute in the computing system, or from an external storage resource if those other processes have been previously associated with a score. If the OS configuration state and/or process score meets the threshold <NUM>, then the resource management unit modifies the clock rate <NUM> for respective clocked components in the computing system, and execution control returns <NUM> to identify <NUM> a status of another process and act on it.

Modifying the clock rate based on the operating system configuration state, process status, and metrics may be advantageous in any number of events. For example, increasing the clock rate for memory may occur if the metrics suggest that the process requires heavy memory usage, or increasing the clock rate for the processor, or a hypervisor or virtual machine may occur if the metrics suggest that any requires heavy processing. On the other hand, reducing the clock rate for the processor may occur to reduce thermal dynamics if the metrics suggest heavy processing that typically creates increased thermal issues, or even terminating a clock rate briefly may occur in certain components if the metrics suggest no activity in those components.

<FIG> is a block diagram illustrating an example computing system <NUM> configured with a resource management unit <NUM> for capturing operating system configuration states and managing memory swapping. The operating system <NUM> executes on the processor <NUM> from the memory <NUM>. Upon detecting an OS transaction event <NUM>, the OS configuration state <NUM> is captured <NUM> by the OS configuration state manager <NUM> of the resource management unit <NUM> and stored into the OS configuration state database <NUM> of the memory <NUM>. For simplicity of discussion and drawing limitations, only two example operating system resources are shown in the database <NUM>, a process run queue and a process wait queue, although other operating system configuration state resources, status indicators, or data may similarly be represented, referenced, identified, and captured by the resource management unit <NUM> into the database <NUM>.

With the process run queue and process wait queue resources represented in the database <NUM>, in this example the resource management unit resource status manager <NUM> identifies a process from the run queue in the database <NUM> that requires a swap of memory resources <NUM> associated with the process to maintain or improve overall system performance. The process status and resources associated with the process, or relative to the process, such as identified in the process control block, are identified from the OS configuration state <NUM> of the operating system <NUM> as stored in the database <NUM> by considering any number of aspects. For example, aspects may include memory usage, memory need, secondary memory usage, scheduling, process run queue, process wait queue, process priority data, process run-time remaining data, process scheduling data, status of a hypervisor or virtual machine, or combinations thereof.

The term memory swapping may refer to copying an entire process address space out to a swap device, such as the secondary storage <NUM>, or back, as a single event. And the term paging may refer to copying, in or out, one or more same-size blocks of the address space, at a much finer grain, such as <NUM> bytes per block, referred to as a page-size. However, for simplicity of discussion in this disclosure, paging and swapping will be used interchangeably to reference the copying of memory content to or from the secondary storage <NUM>.

With the captured OS configuration state available in the database <NUM>, the resource management unit <NUM> can identify memory swapping requirements for a process in advance of what the operating system will detect and execute on the processor <NUM>, thus avoiding memory page faults and improving computing system performance. For example, the OS configuration state can show that the identified process requires more memory resources to execute than what is currently available in the memory <NUM>, or the process recently completed execution and doesn't require the memory resources. The resource status manager <NUM> reviews the process in the database <NUM> to see if it is a good candidate for swapping, e.g., if it has pages that can be swapped in, or discarded from, memory, considering factors such as aging, whether or not the page is locked in memory, or whether the page is shared in memory.

When the resource status manager <NUM> determines that the process requires memory content <NUM> to be swapped in, or may be swapped out, the resource task manager <NUM> executes the memory swap <NUM> between the memory <NUM> and the secondary storage <NUM>. If the process needs more memory to execute than what is available in the memory <NUM>, then the resource management unit <NUM> may move other memory content out to the secondary storage <NUM> that is not needed for execution at the current time, and the resource management unit swaps in content from the secondary storage <NUM> that is needed for the process to execute. On the other hand, if the process has completed execution and doesn't need to use the memory content <NUM>, then the resource management unit <NUM> may move the memory content <NUM> out to the secondary storage <NUM> to free up the memory <NUM>.

In another example, the memory content <NUM> is swapped between the memory <NUM> and the secondary storage <NUM> using a variant size of the memory content without a page-size calculation or page-size processing of the content. For example, rather than using a standard set page-size (e.g., <NUM>, <NUM> or <NUM> bytes) to swap the memory content <NUM>, thereby requiring multiple processing tasks of swapping the multiple pages, and potentially using memory less efficiently, the resource management unit <NUM> may swap the memory content <NUM> out to the secondary storage <NUM> in a specific amount needed, either some or all of the memory content <NUM>, or swap it into the memory <NUM> in the specific amount needed, in one data-stream swap. For example, if the size of memory that needs swapping is <NUM>, then the resource management unit <NUM> swaps <NUM>. Thus, there is no need to process the swap using a traditional page-size calculation or multi-staged page-processing activity to swap some or all of the memory content <NUM>.

This memory management and swapping can be performed because the resource management unit has an understanding of the OS configuration state <NUM> and, for example, since both wait queues and scheduling priorities are known, the resource management unit knows what memory each process will use, what memory is free, how much memory is needed to be swapped, how much memory will be needed by a next process in the run queue to execute, and other factors that guide usage of the memory for improved performance in the computing system. The resource management unit <NUM> can, using its own direct memory access (DMA) and without pausing the processor <NUM>, pre-swap pages for each process before it runs, in the order the process will consume those pages (e.g., using stack and heap pointers for predicting this) and in case there is insufficient memory <NUM> for those pages. The resource management unit also knows the last process that was executed on the processor <NUM>, and which has the most time left until it is back to a running state, so the resource management unit can evict that last process pages to make more room in the memory <NUM> for other processing needs.

Similarly, in the context of a hypervisor <NUM> or virtual machine <NUM> running in the computing system <NUM>, this memory management processing by the resource management unit <NUM> for the hypervisor and virtual machine improves their effectiveness, e.g., the hypervisor swapping out or migrating virtual machines. The resource management unit knows which virtual machine will run the latest, and which will be scheduled next, so the resource management unit can fetch the virtual machine to the memory <NUM> when needed and swap it back to secondary storage after it is done executing, making the hypervisor more effective.

<FIG> illustrates an example method <NUM> for capturing operating system configuration states by a resource management unit in a computing system for managing memory swapping. At <NUM>, the resource management unit captures a configuration state of the operating system executing on the processor in the computing system, and stores the configuration state to a database (e.g., memory) associated with the resource management unit. At <NUM>, the resource management unit identifies from the database a status of a process resource in the computing system, as may be referenced in the process control block, based on the configuration state of the operating system. As an example, the process may be a process in a run queue but waiting to execute on the processor, or a process that has partially executed but is paused and waiting in the wait queue for an event to occur before beginning to execute again.

In this example, the resource management unit identifies a process from the run queue in the database as requiring to swap memory resources to maintain process execution or improve system performance. The status of the process, and resources associated with the process or relevant to the process, are identified from the configuration state of the operating system by considering factors such as its memory usage, memory need, secondary memory usage, scheduling, process run queue, process wait queue, process priority data, process run-time remaining data, process scheduling data, hypervisor or virtual machine activity, or combinations thereof.

At <NUM>, if it is determined that a memory swap is not required, then execution control returns <NUM> to identify another process <NUM>. If is determined <NUM> that the process requires memory swapped based on the captured operating system configuration state, then the resource management unit determines a memory swap size <NUM>. In this example, the memory swap size is based on the variant size of the content to be swapped in the memory for improved system performance and efficient memory usage. Given the captured operating system configuration state, the resource management unit knows the details of the process and other system activities so that it can perform the memory swap based on the variant size of the content, rather than having to perform standard set page-size transfers of the content.

At <NUM>, the memory content is swapped to or from a secondary storage using, in this example, a swap size based on the variant size of the memory content without using a set page-size limitation. For example, the resource management unit may swap the memory content out to secondary storage, or swap it into the memory from secondary storage, in one data-stream swap using the actual size of the memory content, rather than a set page-size, thereby avoiding multiple processing tasks of swapping multiple pages. After the memory content is swapped <NUM>, execution control returns <NUM> to identify a status of another process <NUM>.

While the resource management unit is processing all these functions of capturing the operating system configuration state <NUM>, identifying a process that may require a memory swap <NUM>, determining whether a memory swap is required <NUM>, determining the memory swap size <NUM>, and then actually swapping the memory content <NUM>, the operating system separately and in parallel continues executing its operations on the processor.

<FIG> is a block diagram illustrating an example computing system <NUM> according to the present disclosure configured to capture operating system configuration states with a resource management unit <NUM> for detecting and managing malware and software vulnerabilities. The operating system <NUM> is executing on the processor <NUM> from the memory <NUM>, and upon detecting an operating system transaction event <NUM>, the OS configuration state <NUM> is captured <NUM> by the OS configuration state manager <NUM> of the resource management unit <NUM> and stored into the OS configuration state database <NUM> of the memory <NUM>. For simplicity of discussion and drawing space limitations, only two example operating system resources are shown in the database <NUM>, a process run queue and a process wait queue, although other operating system configuration state resources, data, or status indicators <NUM> may similarly be represented, referenced, identified, and captured by the resource management unit <NUM> into the database <NUM>.

With the process run queue and process wait queue resources represented in the database <NUM>, the resource management unit may then identify the status of a resource <NUM> and process a task <NUM> associated with the resource to improve the performance of the computing system. In this example, the resource management unit resource status manager <NUM> identifies a first process from the run queue in the database <NUM> as ready to be executed (e.g., by referencing the process control block). Prior to execution of the first process, a fingerprint of the first process is identified (e.g., generated) <NUM> by the resource task manager <NUM> to subsequently compare to a plurality of fingerprints of flagged processes <NUM> stored in the memory <NUM>. In other aspects, the fingerprint of the first process is identified at multiple points in time, such as before, during, and/or immediately after execution, to capture a potential rolling (e.g., changing) fingerprint of the process.

For this disclosure, a fingerprint represents one or more aspects, characteristics, schemes, traits, or perspectives that identify the process or its binary or source files. For example, the fingerprint may relate to, or be generated from, (i) the binary program file of the process, (ii) the source program file of the process, (iii) a perspective of the process in memory while the process executes (e.g., as the process code may dynamically morph in memory while executing, including rolling or scattered execution changes in memory such as from a code segment to a data segment), and/or (iv) a perspective of the process in memory, or its binary file, or its source file, or some combination thereof, as generated by a machine learning algorithm. Accordingly, a single process may have multiple fingerprints, and the multiple fingerprints may be linked for association purposes.

The fingerprint of the first process may be identified by executing a hash function on the first process (e.g., by executing a hash function on the binary program file or source program file of the first process, or on code or data of the process as it exists in memory for execution by the processor. For example, a rolling hash function may be applied where the process data is hashed in a window that moves through the data, or a Rabin fingerprinting scheme may be applied using polynomials. The fingerprint may also be identified by passing the first process though a search filter, such as a regular expression (e.g., regex or regexp) engine. This may be accomplished by applying the search filter to the (i) binary program file of the process, (ii) source program file of the process, (iii) code or data of the process as it exists in memory, and/or (iv) data, memory or devices the process is accessing. Such regular expression functionality may be applied recursively, or iteratively, using varying parameters to progressively narrow the scope and results. The fingerprint generation method simply aligns with the fingerprint generation method of the plurality of fingerprints of flagged processes <NUM> stored in the memory <NUM> of the resource management unit so that an accurate comparison may be made.

The plurality of fingerprints of flagged processes <NUM> are indicative of processes, executable files, programs, applications, operating systems, or other software that include executable instructions or are binary program files that have a known vulnerability or have been identified as malware. Examples of malware may be in the form of a virus, trojan, worm, adware spyware, or ransomware, or any software that is specifically designed to disrupt, damage, or gain unauthorized access to or control of the computing system, or to steal or corrupt data. A vulnerability is any weakness in the software or in the operating system that may be exploited to disrupt, damage, or gain unauthorized access to or control of the computing system, or compromise or cause unintended behavior of the computing system.

The fingerprints of the flagged processes <NUM> may be obtained periodically (meaning occasionally or continuously as system parameters allow) by the resource task manager <NUM> from an external storage <NUM> through the resource management unit communication manager <NUM> and the network <NUM>. The external storage <NUM> may be a database on a local network external to the computing system, or a database located in a remote computing environment, such as a cloud computing environment or multi-cloud environment, accessed via the Internet. The external storage <NUM> maintains a list of fingerprints of known malware and vulnerable software. The resource management unit accesses the external storage <NUM> periodically to update its own memory of fingerprints of flagged processes <NUM>.

The resource management unit <NUM> compares the fingerprint of the first process <NUM> to the fingerprints of the flagged processes <NUM> stored in the memory <NUM> of the resource management unit. Alternatively, or in combination with comparing to the fingerprints of the flagged processes <NUM> stored in the memory <NUM>, the resource management unit may compare the fingerprint of the first process to the fingerprints of the flagged processes as stored in the external storage <NUM>.

If there is not a match of the fingerprint of the first process <NUM> to any of the fingerprints of the flagged processes <NUM>, then no action is taken, and the resource management unit <NUM> and the processor <NUM> continue executing their normal commands and functions. However, if there is a match of the fingerprint of the first process <NUM> to at least one of the fingerprints of the flagged processes <NUM>, then the first process is recognized as malware or a vulnerable process, as the case may be, and the resource task manager <NUM> takes action to protect the computing system from unwanted effects of the first process. Such action may include any number of separately actionable or coordinated events between the resource management unit, the processor, and/or the operating system to protect the computing system. For example, such action may include notifying a user of the computing system, prohibiting execution of the first process, suspending scheduling of the first process, limiting execution of the first process, stopping execution of the first process, archiving the first process in a secure vault, removing the first process completely, stopping certain processing in the computing system, or combinations thereof.

While the resource management unit is processing all these described functions of capturing the OS configuration state <NUM> and managing malware and vulnerabilities, the operating system <NUM> separately and in parallel continues executing its operations on the processor <NUM>. This leaves the processor and operating system unburdened by the activities of the resource management unit unless a vulnerable process or malware is detected and acted on.

<FIG> illustrates an example method <NUM> according to the present disclosure for a resource management unit, such as a SoC, to capture operating system configuration states of an operating system executing on a processor in a computing system, and to detect and manage a vulnerable process or malware in the computing system. At <NUM>, a plurality of fingerprints of flagged processes are stored to a memory of the resource management unit. The flagged processes are indicative of processes, executable files, programs, applications, operating systems, or other software that include executable instructions that have a known vulnerability or have been identified as malware. The plurality of fingerprints of the flagged processes may be obtained periodically from an external storage which maintains a list of fingerprints of known malware and vulnerabilities. The resource management unit accesses the external storage periodically to update its own memory of fingerprints of flagged processes.

At <NUM>, the resource management unit obtains a configuration state of the operating system executing on the main processor in the computing system, and stores the configuration state to a database associated with the resource management unit. At <NUM>, the resource management unit identifies from the database a status of a first process resource in the computing system based on the configuration state of the operating system. As an example, the first process may be a process in a run queue but waiting to execute on the processor, or a process that has partially executed but is paused and waiting in the wait queue for an event to occur before beginning to execute again.

At <NUM>, the resource management unit identifies a fingerprint of the first process. The fingerprint may be identified, for example, by executing a hash function on the first process to generate a fingerprint, or by passing the first process through a search filter, or some combination thereof. Multiple fingerprints of the first process may also be identified (e.g., generated), at different points in time relative to execution, and linked for association with the process.

At <NUM>, the resource management unit compares the fingerprint of the first process to the fingerprints of the flagged processes stored in the memory of the resource management unit. Alternatively, or in combination with comparing to the fingerprints of the flagged processes stored in the memory, the resource management unit may compare the fingerprint of the first process to the fingerprints of the flagged processes as stored in the external storage.

If there is not a match <NUM> of the fingerprint of the first process to any of the fingerprints of the flagged processes, then execution control returns <NUM> for the resource management unit to repeat the steps of identifying another process <NUM>, identifying a fingerprint <NUM>, and comparing the fingerprint <NUM> to fingerprints of flagged processes. If there is a match <NUM> of the fingerprint of the first process to one of the fingerprints of the flagged processes, then the first process is recognized as malware or a vulnerable process, as the case may be, and the resource management unit takes action <NUM> to protect the computing system from unwanted effects of the first process. Such action may include any number of actions as described above in reference to <FIG>.

Notably, while the resource management unit is processing all these functions depicted in the method <NUM>, and also while the resource management unit repeats processing these functions against different process resources identified in the computing system based on capturing the configuration state of the operating system, the operating system separately and in parallel continues executing its operations on the processor in the computing system for overall improved computing system performance.

Claim 1:
A method of managing a computing system (<NUM>; <NUM>), the method comprising:
capturing (<NUM>; <NUM>; <NUM>), by a resource management unit (<NUM>) and into a first memory (<NUM>), a configuration state (<NUM>) of an operating system (<NUM>) by obtaining operational status information of the operating system and its managed resources, the operating system being located in a second memory (<NUM>), the operating system (<NUM>) executing on a processor (<NUM>) of the computing system (<NUM>; <NUM>);
identifying (<NUM>; <NUM>; <NUM>), by the resource management unit, a first process in the first memory (<NUM>) based on the configuration state of the operating system (<NUM>);
identifying (<NUM>), by the resource management unit and based on the identifying of the first process, a first fingerprint (<NUM>) of the first process;
comparing (<NUM>), by the resource management unit, the first fingerprint (<NUM>) to a first plurality of fingerprints of flagged processes (<NUM>); and
responsive to the comparing, in an event of identifying a match of the first fingerprint (<NUM>) with at least one of the first plurality of fingerprints of flagged processes (<NUM>), acting (<NUM>) to protect the computing system from unwanted effects of the first process.