Abstract: A mobile device operating system pools any available entropy. The resulting entropy pool is stored in device memory. When storing entropy in memory, preferably memory addresses are randomly allocated to prevent an attacker from capturing entropy that might have already been used to create a random number. The stored entropy pool provides a readily-available entropy source for any entropy required by the operating system or device applications. Then, when a cryptographic application requests a true random number, the operating system checks to determine whether the pool has available entropy and, if so, a portion of the entropy is provided to enable generation (e.g., by a TRNG) of a true random number that, in turn, may then be used for some cryptographic operation. After providing the entropy, the operating system clears the address locations that were used to provide it so that another entity cannot re-use the entropy.

Abstract: An approach is provided that receives and processes a software change package. The software change package includes changes to an installed software product. Change metadata corresponding to the changes included in the software change package is also received. Support data corresponding to the software change package is also received with the support data includes evaluation data that corresponds to the software change package. The evaluation data being data that was gathered from other customer installations of an upgraded software product that previously installed the software change package. Customer configuration data items are retrieved and the customer configuration data items are analyzed along with the received change metadata and the received support data in order to generating an upgrade risk map.

Abstract: A mobile device operating system pools any available entropy. The resulting entropy pool is stored in device memory. When storing entropy in memory, preferably memory addresses are randomly allocated to prevent an attacker from capturing entropy that might have already been used to create a random number. The stored entropy pool provides a readily-available entropy source for any entropy required by the operating system or device applications. Then, when a cryptographic application requests a true random number, the operating system checks to determine whether the pool has available entropy and, if so, a portion of the entropy is provided to enable generation (e.g., by a TRNG) of a true random number that, in turn, may then be used for some cryptographic operation. After providing the entropy, the operating system clears the address locations that were used to provide it so that another entity cannot re-use the entropy.

Abstract: An approach is provided that receives and processes a software change package. The software change package includes changes to an installed software product. Change metadata corresponding to the changes included in the software change package is also received. Support data corresponding to the software change package is also received with the support data includes evaluation data that corresponds to the software change package. The evaluation data being data that was gathered from other customer installations of an upgraded software product that previously installed the software change package. Customer configuration data items are retrieved and the customer configuration data items are analyzed along with the received change metadata and the received support data in order to generating an upgrade risk map.

Abstract: An approach is provided that receives a user action directed at a first windowed application that is executing in a windowing operating system. The first windowed application is displayed on a display using a first set of display attributes. In response to receiving the user action, user preferences are retrieved that correspond to the first windowed application. The user preferences reference a second windowed application that runs in the windowed operating system. The second windowed application is displayed on the display using a second set of display attributes. One or more actions corresponding to the second windowed application are identified based on the retrieved user preferences. These identified actions are executed on the second windowed application and result in a change to the second set of display attributes which causes in a change in an appearance of the second windowed application.