Abstract: Described are examples for enabling low privileged application to access secure system resources. A request from an application executing at a second privilege level can be received by a broker service executing at a first privilege level, where the request corresponds to accessing secure system resources. It can then be determined whether the application has a defined capability for accessing the secure system resources, whether the application has a protected status, and/or whether a user account associated with executing the application is part of a certain group of user accounts. Based on these determinations, access to the secure system resources can be provided to the application by the broker service.

Abstract: Aspects of the technology disclosed herein related to a distributed architecture for securely delivering AI models and/or training data sets to client devices for local use. The distributed includes a licensing server that controls access to and decryption of the models. The licensing server controls the distribution of licensing packages for the different models delivered by the distribution server. The client device transmits a license request to the licensing server. The licensing request may include device-level details about the client device itself, and such details may be provided in a secure, trusted manner, such as through a hardware root of trust (HROT) of the client device. If the details in the license request satisfy the security requirements for the model, a license package for the model is delivered to the client device. The license package includes a license for the model and a decryption key for the model.

Abstract: The techniques disclosed herein enable a guest operating system (OS) to access and use a media processing component configured on a host OS. The guest OS provides, via an API, a request to create an instance of the media processing component (e.g., a codec, an encryption/decryption component, a DRM component). In association with the request, the guest OS allocates space in memory for media data that is to be processed by the instance of the media processing component configured on the host OS. The guest OS stores the input media data in the allocated memory and provides, via the API, reference(s) to locations of the allocated memory. The reference(s) to the locations of the allocated memory enable the host OS to retrieve the input media data and process the input media data using the instance of the media processing component configured on the host OS.

Abstract: Aspects of the technology disclosed herein related to a distributed architecture for securely delivering AI models and/or training data sets to client devices for local use. Model creators are able to provide encrypted versions of their models to a centralized server that in turn distributes copies of the encrypted models to a plurality of distribution servers. When a request for a particular model is received from a client device, the best-suited distribution server is identified to deliver the model. The distributed architecture further includes a licensing server that controls access to and decryption of the models. The licensing server controls the distribution of licensing packages for the different models delivered by the distribution server.

Abstract: Examples of the present disclosure describe systems and methods for providing a protection level-based mechanism for securing an AI model. In examples, a request to distribute an AI model to a client device is received. A license specifying at least one protection level for one or more portions of the AI model is identified at a licensing server. The hardware and/or software capabilities of the client device are evaluated to determine whether the client device is configured to support the protection level specified by the license for the AI model. If the client device is configured to support the protection level, the AI model is retrieved from an AI model distribution server and provided to the client device.

Abstract: Aspects of the technology disclosed herein related to a distributed architecture for securely delivering AI models and/or training data sets to client devices for local use. The distributed includes a licensing server that controls access to and decryption of the models. The licensing server controls the distribution of licensing packages for the different models delivered by the distribution server. The client device transmits a license request to the licensing server. The licensing request may include device-level details about the client device itself, and such details may be provided in a secure, trusted manner, such as through a hardware root of trust (HROT) of the client device. If the details in the license request satisfy the security requirements for the model, a license package for the model is delivered to the client device. The license package includes a license for the model and a decryption key for the model.

Abstract: Examples of the present disclosure describe systems and methods for providing control of input, output, and processing of an AI model. In examples, a request to execute an AI model implemented by a client device is received, where the AI model is associated with one or more licenses that specify a protection level that is applied to one or more portions of the AI model during the AI model runtime. In response to the request, the AI model is translated to a first set of commands in an intermediate language. The first set of commands is translated into a second set of commands for a hardware device of the client device. The second set of commands is translated into microcode that is executable by the hardware device. The hardware device then executes the microcode to generate an output in furtherance of the request.

Abstract: The techniques disclosed herein enable a guest operating system (OS) to access and use a media processing component configured on a host OS. The guest OS provides, via an API, a request to create an instance of the media processing component (e.g., a codec, an encryption/decryption component, a DRM component). In association with the request, the guest OS allocates space in memory for media data that is to be processed by the instance of the media processing component configured on the host OS. The guest OS stores the input media data in the allocated memory and provides, via the API, reference(s) to locations of the allocated memory. The reference(s) to the locations of the allocated memory enable the host OS to retrieve the input media data and process the input media data using the instance of the media processing component configured on the host OS.

Abstract: The techniques disclosed herein enable a guest operating system (OS) to access and use a media processing component configured on a host OS. The guest OS provides, via an API, a request to create an instance of the media processing component (e.g., a codec, an encryption/decryption component, a DRM component). In association with the request, the guest OS allocates space in memory for media data that is to be processed by the instance of the media processing component configured on the host OS. The guest OS stores the input media data in the allocated memory and provides, via the API, reference(s) to locations of the allocated memory. The reference(s) to the locations of the allocated memory enable the host OS to retrieve the input media data and process the input media data using the instance of the media processing component configured on the host OS.

Abstract: Methods and devices for identifying available applications for use with hardware of a computer device may include generating an application request with at least one device identification and a hardware identification to determine available applications. The methods and devices may include transmitting the application request to a remote application store. The methods and devices may include receiving, from the remote application store, an available application list with one or more applications having application relationship metadata that identifies compatible usage with the at least one hardware identification. The methods and devices may include presenting the available application list on a display of the computer device.

Abstract: Various systems and methods for capability access management are disclosed herein. In one example, a system includes a memory and a processor to send a signed custom capability description (SCCD) received from a first vendor to the memory for storage. The system may send an application received from a second vendor to the memory for storage. The system attempts to match the application to an authorization listing of the SCCD, where the application can be modified to allow access to a previously inaccessible custom capability in response to the application matching the authorization listing of the SCCD.

Abstract: Described are examples for enabling low privileged application to access secure system resources. A request from an application executing at a second privilege level can be received by a broker service executing at a first privilege level, where the request corresponds to accessing secure system resources. It can then be determined whether the application has a defined capability for accessing the secure system resources, whether the application has a protected status, and/or whether a user account associated with executing the application is part of a certain group of user accounts. Based on these determinations, access to the secure system resources can be provided to the application by the broker service.

Abstract: Methods and devices for identifying available applications for use with hardware of a computer device may include generating an application request with at least one device identification and a hardware identification to determine available applications. The methods and devices may include transmitting the application request to a remote application store. The methods and devices may include receiving, from the remote application store, an available application list with one or more applications having application relationship metadata that identifies compatible usage with the at least one hardware identification. The methods and devices may include presenting the available application list on a display of the computer device.

Abstract: Described herein is a system for driver execution. A driver is loaded in a first domain with the driver controlling an associated device. In response to a request from the driver, the driver companion is loaded in a second domain different than the first domain, the second domain comprising a secure environment. The driver companion communicates with the associated device. Communications between the driver and the driver companion are managed (e.g., by an operating system framework). In response to a request from the driver, the driver companion is unloaded.

Abstract: Methods and devices for identifying available applications for use with hardware of a computer device may include generating an application request with at least one device identification and a hardware identification to determine available applications. The methods and devices may include transmitting the application request to a remote application store. The methods and devices may include receiving, from the remote application store, an available application list with one or more applications having application relationship metadata that identifies compatible usage with the at least one hardware identification. The methods and devices may include presenting the available application list on a display of the computer device.

Abstract: Methods and devices for identifying available applications for use with hardware of a computer device may include generating an application request with at least one device identification and a hardware identification to determine available applications. The methods and devices may include transmitting the application request to a remote application store. The methods and devices may include receiving, from the remote application store, an available application list with one or more applications having application relationship metadata that identifies compatible usage with the at least one hardware identification. The methods and devices may include presenting the available application list on a display of the computer device.

Abstract: Techniques described herein enable the implementation of a secure driver framework. In one example, a method includes managing an unsecure operating system execution environment comprising a first user mode and a first kernel mode. The method can also include managing a secure execution environment comprising a second user mode and a second kernel mode, and executing a secure driver within the second user mode of the secure execution environment in response to a system call from an unsecure driver in the first kernel mode or the first user mode, wherein the secure driver enables the unsecure driver to communicate with a secure device. Furthermore, the method can include providing one or more system services of the second kernel mode to the secure driver.

Abstract: Described herein is a system for driver execution. A driver is loaded in a first domain with the driver controlling an associated device. In response to a request from the driver, the driver companion is loaded in a second domain different than the first domain, the second domain comprising a secure environment. The driver companion communicates with the associated device. Communications between the driver and the driver companion are managed (e.g., by an operating system framework). In response to a request from the driver, the driver companion is unloaded.

Abstract: Various systems and methods for capability access management are disclosed herein. In one example, a system includes a memory and a processor to send a signed custom capability description (SCCD) received from a first vendor to the memory for storage. The system may send an application received from a second vendor to the memory for storage. The system attempts to match the application to an authorization listing of the SCCD, where the application can be modified to allow access to a previously inaccessible custom capability in response to the application matching the authorization listing of the SCCD.

Abstract: Techniques described herein enable the implementation of a secure driver framework. In one example, a method includes managing an unsecure operating system execution environment comprising a first user mode and a first kernel mode. The method can also include managing a secure execution environment comprising a second user mode and a second kernel mode, and executing a secure driver within the second user mode of the secure execution environment in response to a system call from an unsecure driver in the first kernel mode or the first user mode, wherein the secure driver enables the unsecure driver to communicate with a secure device. Furthermore, the method can include providing one or more system services of the second kernel mode to the secure driver.