Patent ID: 12236291

DETAILED DESCRIPTION

For purposes of this disclosure, an IHS may include any instrumentality or aggregate of instrumentalities operable to compute, calculate, determine, classify, process, transmit, receive, retrieve, originate, switch, store, display, communicate, manifest, detect, record, reproduce, handle, or utilize any form of information, intelligence, or data for business, scientific, control, or other purposes. For example, an IHS may be a personal computer (e.g., desktop or laptop), tablet computer, mobile device (e.g., Personal Digital Assistant (PDA) or smart phone), server (e.g., blade server or rack server), a network storage device, or any other suitable device and may vary in size, shape, performance, functionality, and price. An example of an IHS is described in more detail below.FIG.1shows various internal components of an IHS configured to implement certain of the described embodiments. It should be appreciated that although certain embodiments described herein may be discussed in the context of a personal computing device, other embodiments may utilize various other types of IHSs.

FIG.1is a diagram depicting certain components of an illustrative IHS100that is operable according to various embodiments for secure use of resources of the IHS100by workspaces operating on the IHS100. In some embodiments, IHS100may be employed to instantiate, manage, and/or terminate a secure workspace that may provide the user of IHS100with access to protected data in an isolated software environment in which the protected data is segregated from: the operating system (OS) of the IHS100, other applications executed by IHS100, other workspaces operating on IHS100and, to a certain extent, the hardware of the IHS. In some embodiments, the construction of a workspace for a particular purpose and for use in a particular context may be orchestrated remotely from the IHS100by a workspace orchestration service, such as described with regard toFIG.2. In some embodiments, portions of the workspace orchestration may be performed locally on IHS100. IHS100may be configured with program instructions that, upon execution, cause IHS100to perform one or more of the various operations disclosed herein. In some embodiments, IHS100may be an element of a larger enterprise system that may include any number of similarly configured IHSs in network communications with each other.

As shown inFIG.1, IHS100includes one or more processors101, such as a Central Processing Unit (CPU), that execute code retrieved from a system memory105. Although IHS100is illustrated with a single processor101, other embodiments may include two or more processors, that may each be configured identically, or that may be configured to support specialized processing functions. Processor101may include any processor capable of executing program instructions, such as an Intel Pentium™ series processor or any general-purpose or embedded processors implementing any of a variety of Instruction Set Architectures (ISAs). In the embodiment ofFIG.1, the processor101includes an integrated memory controller118that may be implemented directly within the circuitry of the processor101, or the memory controller118may be a separate integrated circuit that is located on the same die as the processor101. The memory controller118may be configured to manage the transfer of data to and from the system memory105of the IHS100via a high-speed memory interface105b.

System memory105that is coupled to processor(s)101via memory bus105bprovides processor(s)101with a high-speed memory that may be used in the execution of computer program instructions by processor(s)101. Accordingly, system memory105may include memory components, such as such as static RAM (SRAM), dynamic RAM (DRAM), NAND Flash memory, suitable for supporting high-speed memory operations by processor(s)101. In some embodiments, system memory105may combine both persistent, non-volatile memory and volatile memory. In certain embodiments, system memory105includes secure storage120that may be a portion of the system memory designated for storage of information, such as access policies, component signatures, encryption keys, and other cryptographic information, for use in hosting a secure workspace on IHS100. In such embodiments, a signature may be calculated based on the contents of secure storage120and stored as a reference signature. The integrity of the data stored in secure storage120may then be validated at a later time by recalculating this signature of the contents of the secure storage and comparing the recalculated signature against the reference signature.

IHS100utilizes chipset103that may include one or more integrated circuits that are coupled to processor(s)101. In the embodiment ofFIG.1, processor(s)101is depicted as a set of busses that couple processor101to various hardware components installed in the same motherboard. In some embodiments, all or portions of chipset103may be implemented directly within the integrated circuitry of processor(s)101. Chipset103thus provides processor(s)101with access to a variety of hardware resources. In IHS100, chipset103is illustrated as a single coupling with processor101. However, other implementations may utilize any number of connections to provide the illustrated communication pathways supported by chipset103. In some instances, capabilities supported by processor101are not directly available to workspaces operating on IHS100due to the isolation of these workspaces from certain hardware and software of the IHS.

In certain embodiments, IHS100may include a SPI (Serial Peripheral Interface) flash device175that stores certain data and instructions utilized by processor101. The SPI flash175may be a non-volatile memory device capable of being electrically erased and reprogrammed. SPI flash175may be coupled to processor101over an SPI bus180that supports transfers of blocks of data to and from SPI flash175. In some embodiments, SPI flash175may be divided into various regions, with each region storing different types of instructions and/or data. In certain embodiments, some of the regions of SPI flash175may be provisioned during trusted manufacture of IHS100, such as with boot code, cryptographic keys, firmware reference signatures, and tokens that are used to implement security protocols utilized by IHS100.

As illustrated, processor(s)101may also be coupled to a network controller125, such as provided by a Network Interface Controller (NIC) that is coupled to the IHS100and allows the IHS100to communicate with other systems, such as other IHSs similarly configured to IHS100, via an external network, such as the Internet or a LAN. Network interface device109may provide IHS100with wired and/or wireless network connections via a variety of network technologies, such as wireless cellular or mobile networks (CDMA, TDMA, LTE etc.), WIFI and BLUETOOTH. In some embodiments, network controller125may be instrumented with a controller or other logic unit that supports a sideband management connection185bwith remote access controller155. In some instances, capabilities supported by network controller125are not directly available to workspaces operating on IHS100due to the isolation of these workspaces from certain hardware and software of the IHS.

Chipset103may also support communications with one or more display device(s)115via graphics processor170. In certain embodiments, graphics processor170may be comprised within one or more video or graphics cards or an embedded controller installed as components of the IHS100. Graphics processor170may generate display information and provide the generated information to one or more display device(s)115coupled to IHS100, where display device(s)115may include integrated display devices and/or external display devices coupled to IHS. In certain embodiments, some or all of the functions supported by graphics processor170may be integrated within processor101. The one or more display devices115coupled to IHS100may utilize LCD, LED, OLED, or other thin film display technologies. Each display device115may be capable of touch input such as via a touch controller that may be a component of display device115, graphics processor170, or a separate component of IHS100accessed via bus103. In some instances, capabilities supported by graphics processor170are not directly available to workspaces operating on IHS100due to the isolation of these workspaces from certain hardware and software of the IHS.

In certain embodiments, chipset103may utilize one or more I/O controllers150to access various I/O hardware components such as user input devices and sensors. For instance, I/O controllers150may provide access to user-input devices such as a keyboard, mouse, touchpad, touchscreen and/or other peripheral input devices. User input devices may interface with a I/O controller150through wired or wireless connections. Sensors accessed via I/O controllers150may provide access to data describing environmental and operating conditions of IHS100(e.g., accelerometers, gyroscopes, hinge sensors, rotation sensors, hall effect sensors, temperature sensors, voltage sensors, current sensors, IR sensors, photosensors, proximity sensors, distance sensors, magnetic sensors, microphones, ultrasonic sensors, etc.). In some instances, sensor capabilities supported are not directly available to workspaces operating on IHS100due to the isolation of these workspaces from certain hardware and software of the IHS.

In some embodiments, the data inputs collected by such sensors may be received by sensor hub capable of utilizing this information in determining various physical characteristics of the location and manner in which IHS100is being utilized. For instance, the sensor hub may utilize inertial movement sensors, that may include accelerometer, gyroscope, and magnetometer sensors, and are capable of determining the current orientation and movement of IHS100(e.g., IHS100is motionless on a relatively flat surface, IHS100is being moved irregularly and is likely in transport, the hinge of IHS100is oriented in a vertical direction). In certain embodiments, the sensor hub may also include capabilities for determining a location and movement of IHS100based on triangulation of network signal and based on network information provided by the OS or by a network interface. In some embodiments, the sensor hub may support additional sensors, such as optical, infrared and sonar sensors, that may provide support for xR (virtual, augmented, and/or mixed reality) sessions hosted by the IHS100and may be used by the sensor hub provide an indication of a user's presence near IHS100, such as whether a user is present, absent, and/or facing the integrated display115.

Chipset103also provides processor(s)101with access to one or more storage devices130. In various embodiments, a storage device130may be integral to the IHS100, or may be external to the IHS100. In certain embodiments, storage device130may be accessed via a storage controller that may be an integrated component of the storage device. Storage device130may be implemented using any memory technology allowing IHS100to store and retrieve data. For instance, storage device130may be a magnetic hard disk storage drive or a solid-state storage drive. In some embodiments, storage device130may be a system of storage devices, such as a cloud drive accessible via network controller125. In some embodiments, storage device130may be instrumented with a controller or other logic unit that supports a sideband management connection185dwith remote access controller155. In some instances, data storage capabilities supported by storage devices130are not directly available to workspaces operating on IHS100due to the isolation of these workspaces from certain hardware and software of the IHS.

IHS100may also include a BIOS (Basic Input/Output System)135component that may include instructions stored in a non-volatile memory that may be accessible by processor101. The BIOS135provides an abstraction layer that allows an operating system of the IHS100to interface with the hardware components of the IHS100. Accordingly, BIOS135provides an abstraction layer to the firmware utilized by various hardware components of IHS100. In some embodiments, BIOS135may be implemented using a dedicated microcontroller coupled to the motherboard of IHS100. In some embodiments, some or all of BIOS135may be implemented as operations of an embedded controller, such remote access controller155. Upon powering or restarting IHS100, processor(s)101may utilize BIOS135to initialize and test various hardware components of the IHS100. Upon successful validation of these hardware components, in some embodiments, BIOS135may also initiate loading of an operating system for use by the IHS100. As illustrated, BIOS135may be instrumented with a controller or other logic unit that supports a sideband management connection185cwith remote access controller155. In certain embodiments, this sideband management connection185cmay be utilized by remote access controller155to identify communication capabilities that are supported by IHS100and that may be used in support of secure communications by workspaces operating on IHS100.

As illustrated, IHS100may also include a power supply unit160that provides the hardware components of IHS100with appropriate levels of DC power. Power inputs received via a power port or via USB ports may be routed to the power supply unit160of IHS100. The power inputs received by power supply unit160may be used in powering the operations of IHS100and in recharging internal batteries of IHS100. In some embodiments, power supply unit160may support power outputs drawn from the internal batteries of IHS100and provided to external devices coupled to IHS100, such as USB devices coupled to USB ports of IHS100. In some embodiments, power supply unit160may provide power to components of IHS100using multiple independent power planes. For instance, as described below, remote access controller155may be powered from a separate power plane from processor101.

As illustrated, IHS100includes a remote access controller (RAC)155that provides capabilities for remote monitoring and management of various aspects of the operation of IHS100. In support of these monitoring and management functions, remote access controller155may utilize both in-band and sideband (i.e., out-of-band) communications with various internal components of IHS100. Remote access controller155may be installed on the motherboard of IHS100or may be coupled to IHS100via an expansion slot provided by the motherboard. As a non-limiting example of a remote access controller, the integrated Dell Remote Access Controller (iDRAC) from Dell® is embedded within Dell PowerEdge™ servers and provides functionality that helps information technology (IT) administrators deploy, update, monitor, and maintain servers remotely.

In some embodiments, remote access controller155may operate from a different power plane from processors101, storage devices130, network controller125and various other components of IHS100, thus allowing the remote access controller155to operate, and management tasks to proceed, while the processing cores of IHS100are powered off. In some embodiments, various BIOS functions, including launching the operating system of the IHS100, may be implemented by the remote access controller155. In some embodiments, the remote access controller155may perform various functions to verify the integrity of the IHS100and its hardware components prior to initialization of the IHS100(i.e., in a bare-metal state).

In some embodiments, remote access controller155may support monitoring and administration of various managed devices101,120,125,130,135of an IHS via a sideband bus interface. For instance, messages utilized in device management may be transmitted using I2C sideband bus connections185a-ethat may be individually established with each of the respective managed devices101,120,125,130,135through the operation of an I2C multiplexer155aof the remote access controller. As illustrated, managed devices125,130,135of IHS100are coupled to the IHS processor(s)101via one or more in-band buses supported by chipset103, where these in-band busses are separate from the I2C sideband bus connections185b-dused for device management. Accordingly, managed devices125,130and135communicate with the operating system of IHS100via in-band buses supported by chipset103, while the sideband buses185b-dare used by managed devices exclusively for communications with remote access controller155.

In certain embodiments, a service processor155dof remote access controller155may rely on an I2C co-processor155cto implement sideband I2C communications between the remote access controller155and managed components101,120,125,130,135of the IHS. The I2C co-processor155cmay be a specialized co-processor or micro-controller that is configured to interface via a sideband I2C bus interface with the managed hardware components101,120,125,130,135of IHS. In some embodiments, the I2C co-processor155cmay be an integrated component of the service processor155d, such as a peripheral system-on-chip feature that may be provided by the service processor155d. Each I2C bus185a-eis illustrated as single line inFIG.1. However, each I2C bus185a-emay be comprised of a clock line and data line that couple the remote access controller155to I2C endpoints101,120,125,130,135on each of the managed components.

As illustrated, the I2C co-processor155cmay interface with the individual managed devices101,120,125,130,135via individual sideband I2C buses185a-eselected through the operation of an I2C multiplexer155a. Via switching operations by the I2C multiplexer155a, a sideband bus connection185a-emay be established through a direct coupling between the I2C co-processor155cand each of the individual managed devices101,120,125,130,135. In providing sideband management capabilities, the I2C co-processor155cmay interoperate with corresponding endpoint I2C controllers that implement the I2C communications of the respective managed devices101,120,125,130,135. The endpoint I2C controllers may be implemented as dedicated microcontrollers for communicating sideband I2C messages with the remote access controller155, or endpoint I2C controllers may be integrated SoC functions of a processor of the respective managed device endpoints101,120,125,130,135.

In some embodiments, remote access controller155may perform various operations in support of the delivery and deployment of workspaces to IHS100. In certain embodiments, remote access controller155may interoperate with a remote orchestration service via the described out-of-band communications pathways that are isolated from the operating system that runs on IHS100. In some embodiments, a network adapter155bthat is distinct from network controller125utilized by the operating system of IHS100may support such out-of-band communications between remote access controller155and a remote orchestration service. Via this out-of-band signaling pathway, remote access controller155may receive authorization information that may be used for secure delivery and deployment of a workspace to IHS100and to support secure communication channels between deployed workspaces and various capabilities supported by IHS100, while still maintaining isolation of the workspaces from the hardware and operating system of IHs100.

In some embodiments, authorization and cryptographic information received by remote access controller155from a remote orchestration service may be stored to secured memory120. As illustrated inFIG.1, in some embodiments, remote access controller155may access secured memory120may via an I2C sideband signaling pathway185abetween I2C multiplexer155aand an I2C communication capability supported by secure memory120. Remote access controller155may support execution of a trusted operating environment that supports secure operations that are used to deploy a workspace on IHS100. In certain embodiments, remote access controller155may calculate signatures that uniquely identify various hardware and software components of IHS100. For instance, remote access controller155may calculate hash values based on instructions and other information used to configure and operate hardware and/or software components of IHS100. For instance, remote access controller155may calculate a hash value based on firmware and on other instructions or settings of a component of a hardware component. In some embodiments, hash values may be calculated in this manner as part of a trusted manufacturing process of IHS100and may be stored in the secure storage I2C as reference signatures used to validate the integrity of these components at a later time. In certain embodiments, a remote orchestration service supporting the deployment of workspaces to IHS100may verify the integrity of the remote access controller155in a similar manner, by calculating a signature of remote access controller155and comparing it to a reference signature calculated during a trusted process for manufacture of IHS100.

In some embodiments, an IHS100may not include all of the components shown inFIG.1. In other embodiments, an IHS100may include other components in addition to those that are shown inFIG.1. Furthermore, some components that are represented as separate components inFIG.1may instead be integrated with other components. For example, in certain embodiments, all or a portion of the operations executed by the illustrated components may instead be provided by components integrated into processor(s)101as systems-on-a-chip.

FIG.2is a diagram depicting illustrative embodiments of methods and system for deployment and management of workspaces on an IHS in a manner that supports secure use of resources of an IHS by workspaces operating on the IHS. For sake of explanation, the workspace lifecycle supported by embodiments has been split into three phases: workspace initialization phase200A, workspace orchestration phase200B, and workspace termination phase200C. During initialization200A, user201operates an IHS100, such as described with regard toFIG.1, within a physical environment202(e.g., any type of environment and its associated context, including physical location, geographic location, location within a particular facility or building, detected networks, time of day, proximity of the user, individuals in the vicinity of IHS100, etc.).

The illustrated method for the workspace lifecycle according to embodiments may be initiated with an action by user201at a user interface that serves as a launch point203for initiating a workspace. In various instances, launch point203may be a corporate launch point provided by an employer of user201, a manufacturer launch point provided by the manufacturer of IHS100, or a third-party launch point provided as a service to user201by a third-party. In various instances, user201may operate IHS100to access a launch point203that is provided in the form of a web portal, a portal application running in the operating system of IHS100, or a special-purpose portal workspace operating on IHS100. In various embodiments, launch point203may be implemented using graphical, textual and/or audio interfaces by which data or other resource may be requested by a user201. In various implementations, launch point203may include Graphical User Interface (GUI) elements, such as icons, that represent different software applications, data sources and/or other resources that the user may select for use via a workspace. As such, launch point203may provide a user with an ability to request initiation of a workspace that process access to software applications and data sources that are available to the user201.

As described in additional detail below, workspaces for providing user201with access to protected data or other resources may operate using a local management agent332that operates on IHS100and is configured to interoperate with workspace orchestration service206. As described, launch point203may be provided in the form of a portal (e.g., a webpage, OS application or special purpose workspace) that includes a user interface that allows user201to request access to managed resources. In some embodiments, launch point203may be hosted by the local management agent332that runs on IHS100and interoperates with remote workspace orchestration service206. Examples of launch point203technologies may include WORKSPACE ONE INTELLIGENT HUB from WMWARE, INC., and DELL HYBRID CLIENT from DELL TECHNOLOGIES INC., among others.

Initialization phase200A begins when user201chooses to launch an application or access a data source that is managed by the workspace orchestration service206. In response to an access request issued by user201(e.g., the user “clicks” on an icon presented by launch point203), at204, local management agent332of IHS100collects initial security context information and productivity context information. In various embodiments, the security context information of a workspace may include attributes indicating a security risk associated with: the data and/or application being requested, a level of risk presented by the user201, the hardware of the IHS100, the logical software environment of IHS100in which a workspace will be deployed, and the physical environment202in which IHS100is currently located. Accordingly, in this disclosure, a “security context” generally refers to data or other information related to a security posture in which a workspace will be deployed and utilized, where the security posture may be based on characteristics of user201, IHS100, the data and/or application to be accessed via the workspace, and/or environment202. In some embodiments, a security context may be quantified as a security risk score in support of evaluations of the level or risk associated with providing user201access to requested data and/or application while using IHS100in the particular context.

In various embodiments, security metrics that may be used in the calculation of a security risk score for a particular security context may include, but are not limited to: a classification of the requested data source and/or application, authentication factors used to identify user201, the location of IHS100, a role or other group classifications associated with user201, validation of networks in use by IHS100, type of network in use by IHS100, network firewall configurations in use by IHS100, indicators of attack (IoA), indicators of compromise (IoC) regarding IHS100or a resource being requested by user201, patch levels associated with the operating system and other applications in use on IHS100, availability of encryption, type of available encryption, access to secured storage, use of attestable hardware by IHS100, and supported degree of workspace isolation by IHS100.

In this disclosure, “productivity context” generally refers to user201productivity associated with a workspace, user201, IHS100, and/or environment202. A “productivity score” generally refers to an index usable to score, quantify, or measure various productivity characteristics of a productivity context. Examples of productivity context information may include, but are not limited to: the hardware of the IHS100that is available for use in support of a workspace, the software of the IHS100that is available for use in support of the workspace, power states of IHS100and/or hardware components of IHS100, maximum clock frequencies of hardware components of IHS100that can currently be supported, maximum operating speeds of software components of IHS100, peripheral devices coupled to IHS100and networks available for use by IHS100in supporting the workspace.

Initial productivity and security targets for a workspace may be calculated, at205, based on the context of user's201actions combined with the productivity and security context in which the workspace will operate. In some cases, at205, a local management agent332operating on IHS100may calculate initial security and productivity targets based upon the collected security and productivity context. In other cases, remote workspace orchestration service206may calculate security and productivity targets for a workspace. In this disclosure, “security target” generally refers to the attack surface presented by a workspace that is created and operated based on a specific workspace definition, while “productivity target” generally refers to the productivity characteristics of a specific workspace definition. Examples of a productivity target characteristics include, but are not limited to: types of data or data sources available to user201within a workspace, latency of the workspace, software applications available within the workspace, responsiveness of the workspace and remaining computational overhead available to the workspace. Attributes that may be used to characterize a security target may include, but are not limited to: a minimum security score for a workspace, a minimum trust score of IHS100, authentication requirements for user201(e.g., how many authentication factors are required, frequency of re-authentication), minimum level of trust in the network utilized by a workspace, required isolation of a workspace from IHS100, the ability to access browser within a workspace, the ability to transfer data between workspaces and the ability to extend a workspace. In some instances, productivity and security targets may also be based on user's201behavioral analytics, IHS100telemetry and/or environmental information that is collected via sensors of IHS100.

In this disclosure, “workspace definition” generally refers to a collection of attributes that describe aspects a workspace that is assembled, initialized, deployed and operated in a manner that satisfies a security target (e.g., the definition presents an attack surface that presents an acceptable level of risk) and a productivity target (e.g., the definition provides a requisite level of access to data and applications with an upper limit on latency of the workspace) in light of the security context (e.g., location, patch level, threat information, network connectivity, etc.) and the productivity context (e.g., performance characteristics of the IHS100, network speed, workspace responsiveness and latency) in which the workspace is to be deployed. A workspace definition may enable fluidity of migration of an instantiated workspace, since the definition supports the ability for a workspace to be assembled on any IHS100that is configured for operation with the workspace orchestration service206.

In specifying capabilities and constraints of a workspace, a workspace definition208may prescribe one or more of: authentication requirements for user201, types of containment and/or isolation of the workspace (e.g., local application, sandbox, docker container, progressive web application (PWA), Virtual Desktop Infrastructure (VDI)), applications that can be executed in the defined containment of the workspace with access to one or more data sources, security components that reduce the scope of the security target presented by the productivity environment (e.g., DELL DATA GUARDIAN from DELL TECHNOLOGIES INC., anti-virus software), the data sources to be accessed and requirements for routing that data to and from the workspace containment (e.g., use of VPN, minimum encryption strength), and workspace capabilities available to independently attach other resources.

In some implementations, workspace definitions may be based at least in part on static policies or rules defined, for example, by an enterprise's Information Technology (IT) personnel. In some implementations, static rules may be combined and improved upon by machine learning (ML) and/or artificial intelligence (Al) algorithms that evaluate historical productivity and security data collected as workspaces are life cycled. In this manner, rules may be dynamically modified over time to generate improved workspace definitions. If it is determined, for instance, that a user dynamically adds a text editor every time he uses MICROSOFT VISUAL STUDIO from MICROSOFT CORPORATION, then workspace orchestration service206may autonomously add that application to the default workspace definition for that user.

Still with respect toFIG.2, during an orchestration phase200B of workspace deployment, at208, the initial security and productivity targets are processed and/or reconciled against resources, IHS capabilities, and cloud services capabilities in order to produce a workspace definition. As described, a workspace definition may specify capabilities and constraints of a workspace, such as: runtime security requirements of the workspace containment (e.g., such as isolation from the OS of IHS100or from certain hardware of IHS100), the use of reference measurements to attest to the integrity of the workspace, applications to be provided for operation within the workspace, aggregation of resources available via the workspace, configurations for accessing data or resources (e.g., required use of a virtual private network (VPN)).

As described in additional detail with regard toFIG.3, the initial workspace definition may then be utilized by an automation engine302of workspace orchestration service206to coordinate the assembly209and instantiation210of a workspace on an appropriate platform (e.g., on the cloud, on IHS201, or some combination of the two) based on the security and productivity contexts in which the workspace will operate. In some embodiments, automation engine302may resolve configuration conflicts between a workspace definition and the user's inputs in the operation of a workspace. In cases where a workspace is cloud-hosted, the automation engine302may assemble and instantiate a remote workspace that may be accessed via a secure connection established via a web browser or other web-based component operating on the IHS100.

At211ofFIG.2, the instantiated workspace is operated by user201and new productivity and security context information related to the behavior or use of data is generated at212. This operation of a workspace may result in a change or new classification of data based upon what user201has done, accessed, and/or created, thus resulting in a change to the security context of the workspace. To the extent the user's behavioral analytics, device telemetry, and/or the environment has changed to a quantifiable degree, these changes in security context may serve as additional input for a reevaluation, at207, of the security and performance targets by automation engine302. Additionally or alternatively, a new workspace context, security target, and/or productivity target may be now measured against the initial targets, and the result may cause automation engine302to produce a new workspace definition at208.

Particularly, if the instantiated workspace(s) have security or productivity parameters that fall outside of a range of the target scores for these parameters such that a difference between an updated context information and the previous context information is scored below a threshold value, automation engine302may generate modifications to an existing workspace and, at210, may deploy an updated workspace according to the modified definition. Conversely, if the difference between an updated context information and the previous context information is scored above a threshold value, automation engine302may generate a new workspace at210. Session data metadata and context may be preserved by data aggregation engine336, and session data may be restored in the new workspace as applicable.

Various conditions may trigger termination of a workspace at213, as part of termination phase200C. In some cases, user action may initiate the termination of a workspace (e.g., user201closes application or browser accessing data). In other cases, termination of a workspace may take place automatically as part of an adjustment in workspace definition (e.g., the workspace is terminated by automation engine302in order to support a new or updated workspace). As part of a termination phase200C of a workspace, various workspace resources of IHS100and/or at workspace orchestration service206may be released.

FIGS.3A and3Bare diagrams depicting illustrative embodiments of a system for deployment and management of workspaces on an IHS300B in a manner that supports secure use of resources of the IHS by workspaces operating on the IHS. The illustrated system includes a workspace orchestration service206that performs various workspace orchestration operations described above, such as: the evaluation of security and productivity targets based upon context information, the calculation of risk scores and other productivity and security metrics based on ongoing collection of context information, the generation of workspace definitions, and the assembly and instantiation of workspaces in accordance with a workspace definition, where the workspaces may be instantiated via a cloud service or an IHS100, such as described with regard toFIG.1and further described with regard toFIG.3B. As described, IHS100may supported deployment and operation of workspaces through the collection of productivity and security context information, the calculation of productivity scores and/or risk scores, the instantiation, execution, and modification of a workspace based upon workspace definitions that are received from workspace orchestration service206.

Workspace orchestration service206and IHS100may be coupled to each other via any suitable network technology and/or protocol which allows workspace orchestration service206to interoperate with IHS100. As described with regard toFIG.1, an IHS100according to embodiments may include a component such as a remote access controller155that may support secure out-of-band communications that are independent from the operating system of IHS100. In some embodiments, such a remote access controller may be configured to utilize such out-of-band communication capabilities to support deployment and operation of workspaces on IHS100and to report changes in context information to the workspace orchestration service206.

As illustrated inFIG.3A, workspace orchestration service206may include a number of sub-components that support deployment and ongoing evaluation and adaptation of workspaces on an IHS100. Embodiments of the workspace orchestration service206may include systems that may support web services306, manufacturer integration317, and analytics323. As illustrated, web services306may, in turn, comprise application services301and user interface (UI) and automation services302. In some embodiments, analytics services323may be configured to receive and process context information from IHS100, both during initial configuration of a workspace and in ongoing support of workspaces, and to provide that information, along with any analytics generated, to context logic303of application services301. Based on information collected during the deployment and ongoing support of workspaces, support assistance intelligence engine (SAIE)324may be configured to generate and/or analyze technical support information (e.g., updates, errors, support logs, etc.) for use in diagnosing and repairing workspace issues. Workspace insights and telemetry engine325may be configured to analyze and/or produce device-centric, historical, and behavior-based data (e.g., hardware measurements, performance measurements, use of features, settings, etc.) resulting from the operation of workspaces. Workspace intelligence326may include an intelligence engine for processing and evaluating context data in order to identify patterns and tendencies in the operation of workspaces and in the adaptation of workspaces based on context changes.

As illustrated, an application services306system of the workspace orchestration service206may include a UI and automation services302system that may include context logic engine303, classification policy logic304, and condition control engine305. Context logic engine303may support processing of context information in making risk assessments (e.g., evaluating the risk associated with requests by the user against the context of the user's behavior, history of the use of IHS100, capabilities of IHS100, and environmental conditions). For instance, security context information collected by IHS100may be provided to workspace orchestration service206where it may be used by context logic303to calculate a risk score associated with a request for use of a managed data source and/or application. Classification policy304may include administrator and machine-learning defined policies describing risk classifications associated with different security contexts, such as risk classifications associated with specific data, locations, physical environments, IHSs, logical environments, and user actions (e.g., use of high-risk data requires use of a workspace definition suitable for use with a risk score above a specific value). Condition control engine305may include intelligence providing automated decision making for alignment of risk and context. In some cases, condition control engine305may dynamically deploy a solution to address any detected misalignment of risk and context. For instance, upon requesting access to a highly classified data source that results in a significant increase in risk score, the condition control engine may select workspace definition modifications that implement security procedures that are suitable for the higher risk score.

Application services301may include a group of web services306called on by UI and automation services302to support various aspects of the orchestration of workspaces. Particularly, web services306may include application and workspace services307that may assemble and package applications for deployment in a workspace (e.g., an “.msix” file packaged and deployed to a MICROSOFT HYPER-V container). In some embodiments, a workspace definition may be used to specify various such types of workspace deployments that will be used to provide a user with access to an application. Web services306may also include a tenant subscription module308, that performs dynamic configuration of an IHS100for use with the described workspace orchestration services206at the point-of-sale (POS) of the IHS. A license tracking module309may be used to maintain and track license information for software, services, and IHSs. An access control module310may provide top level access controls used in controlling access to data and applications by authorized users. A Unified Endpoint Management (UEM) module311may be configured to support the described orchestration of workspaces on various different IHSs that may be utilized by a particular user.

Web services306that may be used in support of workspaces deployed on IHS100may further include resource provisioning services312for configuring IHS100or a workspace with secrets/credentials necessary to access specific resources (e.g., credentials for use of VPNs, networks, data storage repositories, workspace encryption, workspace attestation, and workspace-to-device anchoring). In some cases, resource provisioning services312may include secrets provisioned to IHS100, such as to secure memory120, as part of a trusted assembly process of IHS100and, in some instances, associated with a unique identifier348of the IHS100. Web services306may also include an authorization/token module313that provides identity functions and may connect to various authentication sources, such as Active Directory. Endpoint registration module314may be configured to register IHSs and/or workspaces in order to track the use of the described workspace orchestration. In some scenarios, a directory services315module may be configured to provide active directory services (e.g., AZURE ACTIVE DIRECTORY from MICROSOFT CORPORATION). Device configuration services316may enable central configuration, monitoring, managing, and optimization of workspaces that in certain contexts may operate remotely from an IHS and may only present the user of the IHS with a user interface that presents an image of the workspace output. In cooperation with resource provisioning services312, device configuration services316may also handle creation of secrets and IHS configuration.

Still referring toFIG.3A, manufacturer integration components317communicate with application services301and client IHS100to provide features that are usable during workspace evaluation and instantiation, where these features may be based upon information available to the manufacturer of IHS100. For instance, certificate authority318may include an entity that issues digital certificates that may be used in validating the authenticity and integrity of the hardware of IHS100. Identity service module or engine319may be configured to manage the user identities, as well as brokering user identification for use of customer directory322. Order entitlement engine320may be used to manage purchased entitlements as well as the associated issued certificates signed by318. Ownership repository321may manage user entitlements associated with IHSs and their ownership and may provide support for users transferring ownership of an IHS and conveying the entitlements associated with that IHS. In certain scenarios, ownership repository321may use this transfer of ownership to decommission the secrets associated with the entitlements embedded in the IHS. Customer directory322may be configured to authenticate and authorize all users and IHSs in a network, such as assigning and enforcing security policies for all IHSs and installing or updating software (in some cases, customer directory322may work in cooperation and/or may be the same as directory services315).

Referring now to IHS100ofFIG.3B, in some embodiments, IHS100may be configured to operate a local management agent332that may operate as a trusted and attestable process of IHS100and that may operate independent from the operating system360of IHS100. In some embodiments, local management agent332may include a workspace engine that instantiates and manages the operation of one or more workspaces331A-N on IHS100. As described, the capabilities of a workspace331A-N may be modified based on detected changes in the productivity and security contexts in which the workspace is operating. Accordingly, the workload(s) in each of the workspaces331A-N may be hosted in full or in part by a cloud resource, a specific server, or locally hosted on IHS100, depending on the context in which the workspace is operating. These allocations of workspace computing for each particular workspace331A-N may be prescribed by the workspace definition that is used to build and operate each workspace. As described, the workspace definition may be created by workspace orchestration service206based upon: context information provided by IHS100, security targets for each workspace331A-N, and/or productivity targets for each workspace331A-N. As described in additional detail below, an individual workspace331A-N may be provided with use of local resources of IHS100via a secure communication mechanism supported by workspace orchestration service206and remote access controller341of IHS100. Utilizing the provided embodiments, such use of local resources by workspaces331A-N may be adapted in response to detected changes in the security context of IHS100.

In some embodiments, local management agent332may be configured to host, launch, and/or execute a workspace hub327that provides a launch point203by which users may initiate workspaces331A-N through the selection of managed data and/or resources. As described, launch point203may be an agent, application, special-purpose workspace or web portal the provides a user interface by which a user may select from a collection of data sources, applications or other managed information or resources that are available to the user of IHS100via the operation of a workspace as described herein. In various embodiments, launch point203may be provided in the form for textual, graphical and/or audio user interfaces that allow a user of IHS100to select available data and/or resources. Workspace hub327may utilize a local environment management module in providing the workspace interface that is presented to the user on IHS100in a consistent manner across workspaces331A-N.

In some embodiments, each instantiated workspace331A-N may be a logical software environment that provides a user with access to requested data or applications, where the environment may be isolated in varying degrees from the hardware and software of IHS100based on the security context and productivity context in which each workspace331A-N is operating. In some instances, the selection of a data source or resource that is available to user via launch point203may result in launching a new workspace331A-N. For instance, if a user launches a browser through selection of an icon displayed by launch point203, a new workspace may be created and launched according to a workspace definition that has been selected for providing the user access to a web browser in the security and productivity contexts in which the request has been made. In a scenario where the user selects a confidential presentation file available from a data source that is provided by launch point203, an additional workspace331A-N may be instantiated with use of a presentation application and with access to the requested presentation file, where this new workspace is created based on a workspace definition that provides appropriate security for access to the confidential presentation. In other instances, a selection of the presentation file by a user may result in the presentation being made available through the existing workspace, in some cases using the existing workspace definition and, in other cases, using a workspace definition that has been modified to support the requested access to the confidential presentation file.

In various embodiments, in order to execute the various operations described herein, local management agent332may include a command monitor that provides instrumentation to receive commands from workspace orchestration service206in support of adaptation of workspaces331A-N based on detected changes in context. Local management agent332may include a telemetry module that may collect and communicate information to the workspace orchestration service206, including reporting changes in context that may warrant adjustments to workspaces331A-N. Local management agent332may also utilize a resource manager module that is configured to manage access to data, network configuration, such as for VPNs and network access, identity information, access control, and resource provisioning services. A security module of local management agent332may be configured to provide various security services. IHS100may include an IHS identification module348that provides a unique, unspoofable identifier that is cryptographically bound to IHS100.

As illustrated inFIG.3B, IHS100includes a remote access controller341that provides capabilities for remote management of IHS100and that provides out-of-band management of various hardware components of IHS100. As indicated inFIG.3B, the remote access controller341operates independently from the operating system360in providing remote management of IHS100. A selected portion of the capabilities of a remote access controller341are illustrated inFIG.3B. As described with regard toFIG.1, a remote access controller341may include a root of trust342capability that is used to evaluate firmware instructions to be used by various hardware components of IHS100against reference signatures for these components, thus validating the firmware in use by these components. In some embodiments, workspace operations supported by workspace orchestration service206may require such root of trust validations by remote access controller341prior to initiating deployment of workspaces to IHS100. In some embodiments, remote access controller341may include a secure object store344for use in storing reference signatures used by root of trust342module. As described with regard toFIG.1, reference signatures utilized by root of trust342module may alternatively or additionally be stored in a secure memory of IHS100. In some embodiments, an IHS attestation343module of remote access controller341may interface with workspace orchestration service205in providing confirmations of root of trust validations of the hardware components of IHS100.

In some embodiments, remote access controller341may also include a secure communications support module350that may be used to facilitate secure communications with workspaces331A-N in providing these workspaces with access to local resources of IHS100that have been registered for use in this manner with workspace orchestration service206. As described in additional detail below, configuration of a local resource for use by a workspace331A-N may include workspace orchestration service206providing remote access controller341with a handle for use in interfacing with an individual workspace331A-N in providing the workspace with a selected local resource of IHS100. As described, an IHS may concurrently support multiple different workspaces331A-N, each operating according to a separate workspace definition. Each workspace331A-N may utilize multiple local resources of IHS100. Each instance of a workspace utilizing a local resource of IHS100may be supported by a separate handle that supports secure communications between a workspace and the remote access controller341. In turn, each handle may include a token and may specify various conditions for the validity of the token, such as a time limit on the validity of a token. The secure communications support module350of the remote access controller341may manage the various handles in use at any one time in providing workspaces331A-N with access to local resources of the IHS. In some embodiments, secure communications support module350may be configured to evaluate the conditions provided in each handle for the validity of the handle's token in order to determine whether to continue providing a workspace with access to the local resource specified by the handle.

As illustrated, each workspace331A-N may include a local resource service335A-N that configures use of available resources of the IHS by a respective workspace. As described in additional detail below, a local resource service355A-N may interoperate with workspace orchestration service206in order to configure a respective workspace331A-N for use of resources of the IHS100that have been registered with the workspace orchestration service206as being available for use by workspaces331A-N. In some instances, such resource of IHS100that are available for use by workspaces331A-N may be identified for workspace orchestration service206by remote access controller341via out-of-band signaling pathways that are independent from operating system360of IHS100, such as described with regard toFIG.1. Once a local resource service355A-N has negotiated use of available IHS resources, workspace orchestration service206may provide a respective local resource service355A-N with a handle that supports a secure means for accessing a local resource of IHS100, as supported by a remote access controller341of the IHS100.

FIG.4is a flowchart describing certain steps of a method, according to some embodiments, for secure use of resources of an IHS by workspaces operating on the IHS.FIG.5is a swim lane diagram describing the operation of certain components of a system according to some embodiments, in configuring secure use of resources of an IHS by workspaces operating on the IHS. As illustrated inFIG.5, embodiments may begin with the initialization of an IHS that is configured according to the embodiments described above. As described, in some embodiments, initialization procedures of an IHS may include validation of instructions utilized by various hardware components of the IHS. For instance, firmware instructions to be loaded by a remote access controller410of the IHS may be used to generate a hash value that is compared to a digital signature stored in a secure memory of the IHS, where the digital signature corresponds to authentic firmware instructions stored for use by the remote access controller during a trusted manufacturing process of the IHS, or during another trusted administrative process. In this same manner, the firmware instructions utilized by various hardware components of the IHS may be successively validated against stored reference signatures in order to iteratively expand a root of trusted hardware components of the IHS. In some embodiments, the firmware instructions of the remote access controller410that are validated in this manner may include instructions used by the remote access controller to determine resources of the IHS that may be utilized by workspaces operating on the IHS and to transmit such local resource information to a remote workspace orchestration service420.

As indicated at425inFIG.4and at510ofFIG.5, once the instructions utilized by the remote access controller410have been validated, the remote access controller may utilize these instructions to communicate with a remote workspace orchestration service420in registering for secure use of IHS resources by workspaces operating on the IHS. In some embodiments, the validated firmware instructions utilized by the remote access controller410may include instructions for securely determining resources of the IHS that may be used by workspaces operating on the IHS and for transmitting a registration of these available IHS resources to the workspace orchestration service420. In such instances, the remote access controller410thus utilizes validated instructions for configuring operation with workspaces and in communicating with the workspace orchestration service420, where these instructions are provided during a trusted process for manufacture of an IHS, or during a trusted administrative process.

At515ofFIG.5, the remote access controller410provides the workspace orchestration service420with a listing of IHS resources that are available for use by workspaces405operating on the IHS. As described, such list of available resources may include capabilities supported by hardware or software components of the IHS, but are not accessible to workspaces405due to their isolation from the underlying hardware and software of the IHS. For instance, available resources may include ACPI (Advanced Configuration and Power Interface) capabilities for querying and configuring power management settings of an IHS. In some instances, available resources may include WMI (Windows Management Instrumentation) capabilities for management of IHSs that operate using a Windows operating system. In some instances, available resources may include use of thread management, memory management or network controller functions that are not accessible by workspaces405due to virtualization of the hardware of the IHS. In some embodiments, available resources may support functions that consolidate services in use by different workspaces405operating on the IHS, such as consolidation of authentication capabilities in use by the workspaces or consolidation of VPN capabilities. Through the use of such consolidated functions, workspaces405may avoid duplicative operations and may also avoid possible inconsistencies that may result from each workspace405utilizing a resource of the IHS in isolation from each other.

As indicated at520ofFIG.5and at430ofFIG.4, in response to receiving a list of available IHS resources, the workspace orchestration service420transmits an authorization token to the remote access controller410. This authorization token may be used to establish secure communications between a workspace and the remote access controller410in providing the workspace with access to the available resources of the IHS. In some embodiments, the authorization token provided to the remote access controller410may be calculated based on a unique identifier of the IHS, such as an identifier provided by an IHS identification348function of IHS, where this unique identifier may be a service tag or other unique code assigned to IHS upon its manufacture. By generating the authorization token based on a unique identifier of IHS, the token is thus bound to that particular IHS such that any attempts to utilize the token by other IHSs are detectable.

In some instances, the identification of available resources by the remote access controller410and the receipt of an authorization token from the workspace orchestration service420is completed upon initialization of the remote access controller410and prior to the user commencing actual use of the IHS. Once the IHS has been initialized and is in use, at525, a workspace may be initialized or reinitialized. In some instances, a workspace may be initialized in response to a user requesting access to a protected resource via a launch point operating on the IHS, such as described with regard toFIG.2. As described with regard toFIGS.3A and3B, an IHS supporting the use of workspaces may operate using a workspace management agent, represented as415inFIG.4, that is used to deploy and manage workspaces operating on the IHS.

In response to a user initiating a request for use of a protected resource through operation of a workspace, at435, the workspace management agent415transmits a request for a workspace for use of the protected resource to the workspace orchestration service420. At440, the workspace orchestration service420generates a workspace definition for generating and operating a workspace that provides the user with access to the protected resource. As described above, a workspace definition may be selected based on factors such as the security context and productivity context of the IHS that will host the workspace, the user making the request and/or the logical and physical environment in which the workspace will operate. Various types of context information may be provided to the workspace orchestration service420as part of the request from the workspace management agent415. Additional context information may be collected by the workspace orchestration service420from the remote access controller410. Based on evaluation of the context information, at445, the workspace orchestration service420transmits the workspace definition and other data for generating a workspace to the workspace management agent415.

Using the received workspace definition, at448, the workspace management agent415instantiates and deploys the workspace405that will provide the user with access to the protected resource. With the workspace410deployed and in use, at450ofFIG.4and at530ofFIG.5, the workspace410registers a request for use of available IHS resources with the workspace orchestration service420. As described with regard toFIG.3B, each workspace331A-N that is configured and deployed according to embodiments may include a local resource service335A-N that is configured to provide a respective workspace with access to local resources of the IHS that are otherwise unavailable due to the isolation of the workspace from all or part of the hardware and software of the IHS. As described, a workspace may provide access to a protected resource within a virtualized logical environment that relies on abstractions from the underlying hardware and the operating system of an IHS, thus isolating the workspace from these local resources of the IHS.

Upon receipt of a registration request from workspace405, at455, the workspace orchestration service420responds by providing workspace405with a list of the available resources of the IHS that are available for use by workspaces, as specified, at425, by the remote access controller410. As indicated inFIG.5, at535, the workspace orchestration service420may validate the registration request received from workspace405. In some embodiments, the workspace405may include a unique identifier in its registration request transmitted to the workspace orchestration service420. In such instances, this unique identifier presented by the workspace405is an identifier that was included in the workspace definition that was generated by the workspace orchestration service420and used to deploy the workspace405. By presenting this unique identifier in its registration request, the workspace orchestration service420may validate that the request originates from an authentic workspace that is operating using a workspace definition generated by the workspace orchestration service420. Once the workspace405has been validated, at540and at455, the workspace orchestration service420provides the workspace405with an authorization token for use in authenticating the workspace405and its use of IHS resources made available via the remote access controller410. In some embodiments, the token provided to the workspace405may be calculated by the orchestration service420based on the unique identifier of the workspace, thus binding the token for use by that particular workspace such that any attempts to utilize the token by other workspaces are detectable.

As indicated at455ofFIG.4and at545ofFIG.5, the workspace orchestration service420also provides the workspace405with the list of IHS resources that have been made available by the remote access controller410for use by workspaces. At550, the workspace405may evaluate the list of available IHS resources against its workspace definition in order to determine the available IHS resources that are compatible with the operating constraints specified by the workspace definition. For instance, a required minimum security score associated with a workspace definition may prohibit the use of certain IHS resources. At460, the workspace405selects from the list of available IHS resources based on compatibility with the workspace definition in order to gain access to IHS capabilities that are not otherwise available to workspace405. At465ofFIG.4and at555ofFIG.5, the workspace405notifies the workspace orchestration service420of its selection from the list of IHS resources that has been made available by the remote access controller420of the IHS.

In response to the selection of an IHS resource by workspace405, at560and as indicated at470, the workspace orchestration service420provides the remote access controller410with a handle to the requested IHS resource, where this handle specifies the IHS resource to be provided, a mechanism for invoking the IHS resource and any constraints that may limit the duration of the workspaces' use of the IHS resource. At565and as indicated at475, this same handle may be provided by the workspace orchestration service420to the workspace405that has requested access to the local IHS resource. In some embodiments, the handle provided by the workspace orchestration service420may specify various aspects of the local IHS resource that is being made available to the workspace405by the remote access controller410. In addition to identifying the resource, the handle may also specify an API (Application Programming Interface) that is to be supported by the remote access controller410for use by the workspace405in invoking the IHS resource. The API included in the handle may specifies as a list of methods that are supported by the remote access controller410, where the specified methods may be identified by a signature that specifies method arguments that must be supplied by the workspace405and responses that will be provided by the remote access controller410. For instance, if the local resource that is selected is use of ACPI power management functions, the API specified in the handle may list a set of method signatures that are supported by the remote access controller410in providing ACPI functionality to workspace405.

In providing a means by which the API included in the handle may be invoked, the handle may also include a reference to an IPC (Inter-Process Communications) resource of the IHS that is to be used in the API communications between the remote access controller410and the workspace405. For instance, the handle may include a pointer to a memory location or data buffer that is to be used in the transmission of data between the remote access controller410and the workspace405. In other instances, the handle may include a reference identifying a socket or pipe by which data maybe transmitted by a workspace405to the remote access controller410and by which responsive data resulting from execution of an API call may be provided to the workspace405by the remote access controller410.

In addition to specifying the API that is supported and a reference to an IPC resource of the IHS, the handle provided by the workspace orchestration service420may also include a token that may be used to specify constraints on the duration of the validity of the handle. In some embodiments, the token included in a handle may be generated based on the token provided to the remote access controller410, which may be based on a unique identifier of the IHS, and may also be generated based on the token provided to the workspace405, which may be based on a unique identifier of the workspace. In this manner, the token included in the handle may be bound to the IHS and to the workspace405such that use of the handle on another IHS or by another workspace is detectable.

In some instances, a token specified in a handle may be valid for the duration of the lifespan of the workspace405. Accordingly, in such instances, no limitations or conditions on the token are specified in the handle. However, in other instances, the validity of a token may be limited according to various conditions specified in the handle. In such instances, the token included in the handle is thus a session token with a limited term of validity. For example, conditions set forth in the handle may specify that the session token is only valid until a certain time. As described with regard toFIG.1, an IHS according to embodiments may include sensors capable of determining whether a user is in proximity to the IHS. In some instances, conditions set forth in the handle may specify that a session token becomes invalid upon detecting that the user of the IHS can no longer be detected in proximity to the IHS. In another example where the IHS is a laptop computer, the conditions set forth in the handle may specify that the session token is only valid until the lid of the laptop is closed. In another example, the conditions set forth in the handle may specify that the session token becomes invalid if the IHS is moved to a different location, or is moved outside of a specific location.

As describe above, a workspace definition may be associated with a security score that is measure based on the security context in which the workspace is deployed. In some embodiments, a session token specified in a handle may be limited based on conditions requiring a minimum security score in order for the token to remain valid. In such embodiments, the workspace management agent415may monitor for changes in the security context of the workspace405. Examples of detected changes in the security context may include a change in the antivirus software in use by the IHS, a change in the network access point used by the IHS, a change in the location of the IHS from a corporate environment to a public location, and/or a change of the individual that is using the IHS. Upon detecting such changes in the security context, a new security score may be calculated for the workspace. If the security score drops below a certain threshold, a session token included in a handle may become invalid.

With the remote access controller410and the workspace405both provided with the handle generated by the workspace orchestration service420, the workspace405may commence use of the selected IHS resource by using the handle to issue commands to the selected IHS resource. Using the provided handle, at570, the workspace405generates a command that invokes the selected resource of the IHS by generating an API call that is specified in the handle. In some embodiments, these API calls may be generated by a local resource service335A-N, as described with regard toFIG.3B, of the workspace405that may be configured to managed operations for requesting and managing use of a local resource on behalf of the workspace405. At575and as indicated at480ofFIG.4, the workspace405transmits the API call to the remote access controller410using the IPC resource that is included in the handle for communications between the remote access controller410and the workspace405. At580, the API call issued via the IPC resource specified in the handle is received by the remote access controller410. As described with regard toFIG.3B, remote access controller410may include a secure communication support module350that is configured to manage communications with workspaces. In particular, this secure communication support module may manage communications with individual workspaces via an IPC resource specified in a handle provided by the workspace orchestration service for communications with that particular workspace.

Upon receipt of an API call from a workspace via the IPC resource, the remote access controller410processes the API call on behalf of the workspace. For instance, if a handle provides a workspace405with access to ACPI resources of an IHS, an API call received according to that handle is processed by the remote access controller410by invoking the corresponding ACPI method of the IHS that may be supported by the BIOS of the IHS, or by the remote access controller410itself. In another example, if the API call is received via an IPC resource corresponding to a handle that provides workspace405with use of thread management functions supported by an IHS, the data received by the remote access controller410via the IPC resource is used to perform thread management functions on behalf of the workspace. Once the operation invoked on behalf of the workspace405has been completed, at585and as indicated at485ofFIG.4, the remote access controller410utilizes the IPC resource provided in the handle to provide the workspace405with a responsive communication specified by the API call made by the workspace. For instance, if an ACPI method requesting the current power state of the IHS has been invoked by the API call received from the workspace405, the response by the remote access controller410relays the current power state back to the workspace via the IPC resource specified in the handle.

According to embodiments of the present disclosure, a cache database362and an associated cache database management interface364may be provided for storing information used by the workspaces331A-N. The cache database362may be used to store files or digital content common to some, most, or all of the workspaces331A-N. For example, the cache database362may be used to store executable files, such as dynamic linked library (DLL) files, application files, or other files including executable code that may be shared among certain workspaces331A-N. As another example, the cache database362may be used to store audio and/or video content that is generated by a first workspace and consumed by a second workspace seamlessly.

cache database management interface364provides an interface for secure communication with the workspace orchestration service206, and may include logic for implementing certain features of the cache database362. In one embodiment, cache database management interface364may implement a cloud caching system where commonly accessed cloud sourced files may be cached to alleviate communication traffic that would otherwise be required each time a workspace311A-N requires access to content from a cloud-based source. In another embodiment, cache database management interface364may implement a user context discovery system for providing contextual continuity for custom workspaces instantiated on different environments based on each user's personal profile. Methods for providing the cloud caching system and user context discovery system will each be described in detail herein below. In one embodiment, cache database362and cache database management interface364may be configured inside of a workspace331A-N so that it can be securely managed by workspace orchestration service206.

According to one embodiment, an BIOS interface agent368may be provided in BIOS135of IHS100. In general, BIOS interface agent368provides a direct interface for communication between the BIOS135along with any associated embedded controllers, and the workspace orchestration service206. In many currently produced IHSs, the BIOS often includes a SMBIOS interface that can be used to read management information produced by the BIOS135of an IHS100. This feature can eliminate the need for the operating system to probe hardware directly to discover what devices are present in the computer. As such, the BIOS interface agent368provide a technique to access characteristics of hardware devices configured in the IHS100as well as to manipulate or otherwise modify those hardware resources. In one embodiment, a secure network connection may be established between the BIOS interface agent368and workspace orchestration service206using the network tunneling service364.

FIG.6is a workflow diagram describing certain steps of one embodiment of an event management method600according to one embodiment of the present disclosure. As will be described in detail herein below, the event management method600may be provided for enabling applications configured in workspaces to obtain event messages generated by the host OS602, the hardware, firmware, or any process configured on the IHS100. Using the event management method600, applications, which are ordinarily isolated from operations outside the workspace, are able to obtain and react to events occurring outside of its workspace in which it is configured.

While workspaces may be useful for isolating an application's operation from outside of the workspace, this isolation may cause certain problems. For example, events often occur for various reasons, such as mouse clicks, keyboard entries, ACPI calls, process failures, notebook IHS lid dosing or opening, changes in power status, and the like. If an application is encapsulated in a workspace, however, it is often inhibited from obtaining information about those events. For example, if an online storage process (e.g., OneDrive) is configured in a workspace, it is often inhibited from obtaining IHS event information (e.g., battery low event) so that it can halt periodic synchronization to the cloud until normal power is restored. Thus, the isolated online storage process can, and often does, exacerbate occasional problem that occur on IHSS.

Within this disclosure, an event may be a hardware, software, firmware, or embedded controller condition that may occur on an IHS. In general, events are often handled by system-level or language-level messages (e.g., system calls) that are used used to convey those events to other processes in the IHS. events may include, for example, such as mouse clicks, keyboard entries, ACPI calls, process failures, notebook IHS lid dosing or opening, changes in power status, and the like. events may also include application-level situations such as “New record inserted in database” or highly digested requests and messages, used in modular programs for communication/requests between various parts of the program. There also exist various event systems at the level of the operating system as well as at various frameworks (ex: MS Windows, JavaScript, .NET, GUI frameworks (e.g., QT), etc.). An event message often includes information about the event, that is, its type, its severity, its source, and may include certain custom parameters, which often depend upon the semantics of the event type.

Referring again toFIG.6, the event management method600involves a host operating system (OS)602, a workspace orchestration service206, a workspace331configured with a workspace interface agent355, an application652, and optionally a kernel interface agent606that may be executed on IHS100. Only one workspace331is shown and described herein for purposes of brevity and clarity of discussion; nevertheless, it should be appreciated that the event management method600may be performed with any quantity and configuration of workspaces331. Additionally, while the workspace331is shown configured with a single application652, it should be appreciated that the workspace331may have any number of applications602that can be managed by the event management method600.

The workspace331may be a software based (e.g., Docker, Snap, etc.) or hardware based (e.g., Vmware, Hyper-V, VirtualBox, etc.). If the workspace331is a hardware based workspace, it may include kernel interface agent606for relaying event messages (e.g., ACPI messages) directly to the kernel of the workspace; otherwise, if the workspace331is a software based workspace, it may be void of any kernel interface agent606.

Steps620-628generally describe an initialization sequence that may be performed each time the event management method600started, such as when the IHS100is initialized (e.g., bootstrapped). Initially at step620, the workspace orchestration service206registers to receive to receive some, most, or all event messages generated by the host OS602. In some embodiments, the workspace orchestration service206may register to receive a certain subset of all event messages generated by either of the host OS602, and/or certain hardware elements of the IHS100(e.g., those described above with reference toFIG.1including BIOS135or an associated embedded controller (EC). Thereafter at step622, the workspace orchestration service206identifies the workspaces331currently in existence on the IHS100, and establishes a connection with those identified workspaces331.

At step624, the workspace orchestration service206communicates with the workspace331, via workspace interface agent355, to gather information about applications604configured in that workspace331, and at step626obtain that information. The information may include event message subscription information about the type of event messages the application may use. For example, if the application includes a Bluetooth communication feature, the event message subscription information may be associated with Bluetooth event messages generated by the IHS100during its use. In general, an event message subscription generally refers to a request that is generated by the application604, typically when it is initially launched, to receive certain types of event messages when they are generated by other processes in the IHS100. As the event message subscription information is obtained from the workspace331for each application604that is configured therein, the workspace orchestration service206caches it in storage for later use at step628. For example, the workspace orchestration service206may cache the event message subscription information in a lookup table so that as event messages are received, the lookup table can be accessed to identify those workspaces331having applications604that are requesting to obtain that information. In some cases, the workspace orchestration service206may also verify the integrity of the workspace331and the applications604configured inside.

Steps630-636generally describe an example software event management process that may be performed by the method600. At step630, the workspace orchestration service206receives a software-based event message from the host OS602. Thereafter at step632, the workspace orchestration service206identifies those workspaces331and/or applications604that have subscribed to receive those event messages. Once the workspaces331and/or applications604are identified, the software-based event message may be sent to each of those workspaces331and/or applications604at step634. The workspace interface agent355then forwards the event message to the application604at step636.

Steps638-644generally describe an example hardware event management process that may be performed by the method600. At step638, the workspace orchestration service206receives a hardware-based event message from the host OS602. For example, the hardware-based event message may be an ACPI message generated by the host OS602in response to a certain event (e.g., lid closing event of a notebook IHS) that has occurred. Thereafter at step640, the workspace orchestration service206identifies those workspaces331and/or applications604that have subscribed to receive those hardware-based event messages. Once the workspaces331and/or applications604are identified, the software-based event message may be sent to each of those workspaces331and/or applications604at step642. The workspace interface agent355then forwards the event message to the kernel interface agent606at step644. Thereafter at step646, the kernel interface agent606communicates with the kernel of the host OS602to process the hardware-based event message by the hardware-based workspace331.

In some embodiments, the kernel interface agent606may include logic for implementing a query/set technique for the emulated firmware of the hardware-based workspace331. For example, the kernel interface agent606may include logic for receiving a query or set messages from either of the host OS602or workspace orchestration service206, taking appropriate action, and responding to the query or set messages. For example, it may be beneficial in certain cases, for either the host OS602or workspace orchestration service206to change certain parameters (e.g., memory capacity allocation, number of processor cores, communication network configuration, etc.) of the firmware in the hardware-based workspace331. Conventional hardware-based workspaces331, however, do not allow these changes to occur while the hardware-based workspace331is running. Embodiments of the kernel interface agent606provide a solution to this problem by enabling ACPI query and set messages to be transferred between the kernel of the hardware-based workspace331and workspace orchestration service206so that these changes can be performed while the hardware-based workspace331is running.

Transferal of query or set messages from the host OS602and/or workspace orchestration service206to the hardware-based workspace331may be performed using steps638-644described above. Conversely, transferal of query or set messages from the hardware-based workspace3331to the host OS602and/or workspace orchestration service206may be performed using steps646-650described herein below.

At step646, the kernel interface agent606performs any actions based on the query or set message received, and send a response to the query or set message at step648to the workspace interface agent355. The workspace interface agent355, in turn, forwards the response message to the workspace orchestration service206at step648. If the query or set message originated from the host OS602, the workspace orchestration service206may then forward the response message to the host OS602at step650.

Each of the software-based event message process, or hardware-based event message process may be repeatedly performed for each event message generated by the host OS602. Nevertheless, when use of the event management method600is no longer needed or desired, the process ends.

AlthoughFIG.6describes an example method that may be performed for managing event messages, the features of the method600may be embodied in other specific forms without deviating from the spirit and scope of the present disclosure. For example, the method600may perform additional, fewer, or different operations than those described in the present examples. As another example, the steps of the method600may be performed by a computing system other than the IHS102, such as via a cloud service as described above.

It should be understood that various operations described herein may be implemented in software executed by processing circuitry, hardware, or a combination thereof. The order in which each operation of a given method is performed may be changed, and various operations may be added, reordered, combined, omitted, modified, etc. It is intended that the invention(s) described herein embrace all such modifications and changes and, accordingly, the above description should be regarded in an illustrative rather than a restrictive sense.

The terms “tangible” and “non-transitory,” as used herein, are intended to describe a computer-readable storage medium (or “memory”) excluding propagating electromagnetic signals; but are not intended to otherwise limit the type of physical computer-readable storage device that is encompassed by the phrase computer-readable medium or memory. For instance, the terms “non-transitory computer readable medium” or “tangible memory” are intended to encompass types of storage devices that do not necessarily store information permanently, including, for example, RAM. Program instructions and data stored on a tangible computer-accessible storage medium in non-transitory form may afterwards be transmitted by transmission media or signals such as electrical, electromagnetic, or digital signals, which may be conveyed via a communication medium such as a network and/or a wireless link.

Although the invention(s) is/are described herein with reference to specific embodiments, various modifications and changes can be made without departing from the scope of the present invention(s), as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of the present invention(s). Any benefits, advantages, or solutions to problems that are described herein with regard to specific embodiments are not intended to be construed as a critical, required, or essential feature or element of any or all the claims.

Unless stated otherwise, terms such as “first” and “second” are used to arbitrarily distinguish between the elements such terms describe. Thus, these terms are not necessarily intended to indicate temporal or other prioritization of such elements. The terms “coupled” or “operably coupled” are defined as connected, although not necessarily directly, and not necessarily mechanically. The terms “a” and “an” are defined as one or more unless stated otherwise. The terms “comprise” (and any form of comprise, such as “comprises” and “comprising”), “have” (and any form of have, such as “has” and “having”), “include” (and any form of include, such as “includes” and “including”) and “contain” (and any form of contain, such as “contains” and “containing”) are open-ended linking verbs. As a result, a system, device, or apparatus that “comprises,” “has,” “includes” or “contains” one or more elements possesses those one or more elements but is not limited to possessing only those one or more elements. Similarly, a method or process that “comprises,” “has,” “includes” or “contains” one or more operations possesses those one or more operations but is not limited to possessing only those one or more operations.