Abstract: In one embodiment, an application module 114 may adjust a synchronization scheme 306 based on the operational state of a computing device 110. An operating system 112 may determine an operational state for a computing device 110. The operating system 112 may assign a synchronization allotment 304 to the application module 114 based on the operational state. A synchronization engine 116 of the application module 114 may implement a synchronization scheme 306 based on the synchronization allotment 304.

Abstract: Protecting secured boot secrets while starting an operating system. Embodiments include identifying that a second operating system is to be started to replace a first operating system, and loading code of the second operating system in a protected portion of the system memory. The protected portion of the system memory is then unprotected, and processor state is set to initiate execution of the code of the second operating system, while using one or more secured boot secrets that were stored in the protected portion of the system memory by the first operation system to attest a security status of the second operating system. The portion of the system the memory is re-protected, including preventing access to the portion of the system memory by the second operating system.

Abstract: Controlling background activity in a computing device or system during a low-power mode is described. In some example techniques, when a computing device or system is in a low power mode, a determination is made whether to block one or more trigger events from causing an activation of one or more respective background task operations. Based at least in part on the determination, at least one trigger event may be allowed to cause an activation of a respective background task operation during the low power mode.

Abstract: Among other things, one or more techniques and/or systems are provided for controlling resource access for background tasks. For example, a background task created by an application may utilize a resource (e.g., CPU cycles, bandwidth usage, etc.) by consuming resource allotment units from an application resource pool. Once the application resource pool is exhausted, the background task is generally restricted from utilizing the resource. However, the background task may also utilize global resource allotment units from a global resource pool shared by a plurality of applications to access the resource. Once the global resource pool is exhausted, unless the background task is a guaranteed background task which can consume resources regardless of resource allotment states of resource pools, the background task may be restricted from utilizing the resource until global resource allotment units within the global resource pool and/or resource allotment units within the application resource pool are replenished.

Abstract: Protecting secured boot secrets while starting an operating system. Embodiments include identifying that a second operating system is to be started to replace a first operating system, and loading code of the second operating system in a protected portion of the system memory. The protected portion of the system memory is then unprotected, and processor state is set to initiate execution of the code of the second operating system, while using one or more secured boot secrets that were stored in the protected portion of the system memory by the first operation system to attest a security status of the second operating system. The portion of the system the memory is re-protected, including preventing access to the portion of the system memory by the second operating system.

Abstract: Protecting secured boot secrets while starting an operating system. Embodiments include starting a first operating system using a trusted computing base, protecting a portion of the system memory to prevent access to the portion of the system memory by the first operating system, and storing secured boot secrets in the protected portion of the system memory. Based at least on identifying that a second operating system is to be started to replace the first operating system, embodiments include configuring one or more memory data structures, including code of the second operating system, in the protected portion of the system memory. The protected portion of the system memory is unprotected, while mitigating attacks on the portion of system memory, and processor state is set to execute the code of the second operating system. The second operating system starts using the secured boot secrets stored in the portion of the system memory.

Abstract: Protecting secured boot secrets while starting an operating system. Embodiments include starting a first operating system using a trusted computing base, protecting a portion of the system memory to prevent access to the portion of the system memory by the first operating system, and storing secured boot secrets in the protected portion of the system memory. Based at least on identifying that a second operating system is to be started to replace the first operating system, embodiments include configuring one or more memory data structures, including code of the second operating system, in the protected portion of the system memory. The protected portion of the system memory is unprotected, while mitigating attacks on the portion of system memory, and processor state is set to execute the code of the second operating system. The second operating system starts using the secured boot secrets stored in the portion of the system memory.

Abstract: In one embodiment, an application module 114 may adjust a synchronization scheme 306 based on the operational state of a computing device 110. An operating system 112 may determine an operational state for a computing device 110. The operating system 112 may assign a synchronization allotment 304 to the application module 114 based on the operational state. A synchronization engine 116 of the application module 114 may implement a synchronization scheme 306 based on the synchronization allotment 304.

Abstract: One or more systems and/or techniques are provided for background task management. A background manager may receive a notification from a background task that the background task is waiting for an event, and may also receive a waitable object from the background task, where the waitable object is used by the background task to wait for the event. Responsive to the waitable object not being triggered within a period of time, the background manager may implement a power management policy for a computing device hosting the background task.

Abstract: In one embodiment, an application module 114 may adjust a synchronization scheme 306 based on the operational state of a computing device 110. An operating system 112 may determine an operational state for a computing device 110. The operating system 112 may assign a synchronization allotment 304 to the application module 114 based on the operational state. A synchronization engine 116 of the application module 114 may implement a synchronization scheme 306 based on the synchronization allotment 304.

Abstract: Controlling background activity in a computing device or system during a low-power mode is described. In some example techniques, when a computing device or system is in a low power mode, a determination is made whether to block one or more trigger events from causing an activation of one or more respective background task operations. Based at least in part on the determination, at least one trigger event may be allowed to cause an activation of a respective background task operation during the low power mode.

Abstract: Embodiments related to automatically adjusting wireless network settings based upon utilization of a wireless network link by applications are disclosed. For example, one disclosed embodiment provides a method of adjusting a wireless networking setting for a wireless network link. The method includes monitoring data flow through a network interface controller to collect, for each of one or more applications running on the computing device and communicating over the wireless network link, flow performance data comprising information regarding an amount of data flow arising from the application. The method also includes monitoring link data comprising information regarding data being sent and received over the wireless network link, and based upon the flow performance data and the link data, controlling a network interface controller to adjust the wireless networking parameter to change a configuration of the network link.

Abstract: Controlling background activity in a computing device or system during a low-power mode is described. In some example techniques, when a computing device or system is in a low power mode, a determination is made whether to block one or more trigger events from causing an activation of one or more respective background task operations. Based at least in part on the determination, at least one trigger event may be allowed to cause an activation of a respective background task operation during the low power mode.

Abstract: Among other things, one or more techniques and/or systems are provided for controlling resource access for background tasks. For example, a background task created by an application may utilize a resource (e.g., CPU cycles, bandwidth usage, etc.) by consuming resource allotment units from an application resource pool. Once the application resource pool is exhausted, the background task is generally restricted from utilizing the resource. However, the background task may also utilize global resource allotment units from a global resource pool shared by a plurality of applications to access the resource. Once the global resource pool is exhausted, unless the background task is a guaranteed background task which can consume resources regardless of resource allotment states of resource pools, the background task may be restricted from utilizing the resource until global resource allotment units within the global resource pool and/or resource allotment units within the application resource pool are replenished.

Abstract: Controlling background activity in a computing device or system during a low-power mode is described. In some example techniques, when a computing device or system is in a low power mode, a determination is made whether to block one or more trigger events from causing an activation of one or more respective background task operations. Based at least in part on the determination, at least one trigger event may be allowed to cause an activation of a respective background task operation during the low power mode.

Abstract: A stream processing execution engine evaluates development-time performance characteristic estimates in combination with run-time parameters to schedule execution of stream processing software components in a stack of a stream processing application that satisfy a defined performance criterion in a heterogeneous hardware device. A stream processing application includes a stack of interdependent stream processing software components. A stream processing execution engine evaluates one or more performance characteristics of multiple computational resources in the heterogeneous hardware device. Each performance characteristic is associated with performance of a computational resource in executing a computational-resource-dependent instance of a stream processing software component. The stream processing execution engine schedules within the run-time environment a computational resource on which to execute a computational-resource-dependent instance of one of the stream processing software components.

Abstract: In one embodiment, an application module 114 may adjust a synchronization scheme 306 based on the operational state of a computing device 110. An operating system 112 may determine an operational state for a computing device 110. The operating system 112 may assign a synchronization allotment 304 to the application module 114 based on the operational state. A synchronization engine 116 of the application module 114 may implement a synchronization scheme 306 based on the synchronization allotment 304.

Abstract: The disclosure describes a method for programming applications for embedded systems such as sensor nodes. In an embodiment, this comprises writing embedded system applications in a high-level language such as C# or Java using a software development framework which includes a set of tools and class libraries. The class libraries contain pre-written code to carry out tasks which may be required of an embedded system. The class libraries may be extended following identification of a need for a particular function in an embedded system. Developed applications may be subsequently stored on the embedded system but executed on a gateway computing device which interacts with the embedded system. This means that the application(s) can be executed without requiring the presence of a virtual execution system located on the embedded system while allowing a high-level programming model for application programmers.

Abstract: Methods for ad-hoc trust establishment using visual verification are described. In a first embodiment, a visual representation of a shared data is generated on two or more devices and the visual representations generated can be visually compared by a user. This method can be used to verify that the correct devices are involved in a negotiation, when pre-existing trust relationships do not exist between the devices. The visual representation may, for example, comprise a picture with a number of different elements, each representing a part of the shared data. In another embodiment, a method of secure key exchange is described in which, before sharing the keys, the parties exchange information which encapsulates the key. This information can be used subsequently to check that a party has not changed the key that they are using and prevents a man in the middle attack.

Abstract: Embodiments related to automatically adjusting wireless network settings based upon utilization of a wireless network link by applications are disclosed. For example, one disclosed embodiment provides a method of adjusting a wireless networking setting for a wireless network link. The method includes monitoring data flow through a network interface controller to collect, for each of one or more applications running on the computing device and communicating over the wireless network link, flow performance data comprising information regarding an amount of data flow arising from the application. The method also includes monitoring link data comprising information regarding data being sent and received over the wireless network link, and based upon the flow performance data and the link data, controlling a network interface controller to adjust the wireless networking parameter to change a configuration of the network link.