Abstract: A disclosed example method to suspend and resume a device includes: after detecting a low-power suspend mode request, determining a storage performance of the device to store suspend state data; based on the storage performance of the device, setting a suspend flag to indicate a low-power suspend mode to a processor platform; when resuming from the low-power suspend mode, confirming a setting of a resume flag from the processor platform, the resume flag to notify an operating system to resume from the low-power suspend mode; and when the resume flag is set, restoring state data corresponding to an operating system context from a non-volatile dual-purpose system and storage memory.

Abstract: Techniques and computing devices for persistent firmware transfer monitoring and, more specifically, but not exclusively, to a resource filter within a firmware resource monitor configured to persistently store resource information after a boot operation. In one embodiment, for example, an apparatus for persistent firmware transfer monitoring in a computer system comprises at least one memory, at least one processor, and a resource filter comprising logic, at least a portion of the logic comprised in hardware and executed by the processor. The logic to may be configured to receive a list of required resources during a boot operation and receive a list of excluded resources. The resource filter may be further configured to persistently store the list of required resources and the list of excluded resources after the boot operation has completed.

Abstract: Various embodiments are directed to creating multiple device blocks associated with hardware devices, arranging the device blocks in an order indicative of positions of the hardware devices in a hierarchy of buses and bridges, and enabling access to the multiple device blocks from an operating system. An apparatus comprises a processor circuit and storage storing instructions operative on the processor circuit to create a device table comprising multiple device blocks, each device block corresponding to one of multiple hardware devices accessible to the processor circuit, the device blocks arranged in an order indicative of relative positions of the hardware devices in a hierarchy of buses and at least one bridge device; enable access to the device table by an operating system; and execute a second sequence of instructions of the operating system operative on the processor circuit to access the device table. Other embodiments are described and claimed herein.

Abstract: A processor includes an instruction decoder to receive an instruction to perform a machine check operation, the instruction having a first operand and a second operand. The processor further includes a machine check logic coupled to the instruction decoder to determine that the instruction is to determine a type of a machine check bank based on a command value stored in a first storage location indicated by the first operand, to determine a type of a machine check bank identified by a machine check bank identifier (ID) stored in a second storage location indicated by the second operand, and to store the determined type of the machine check bank in the first storage location indicated by the first operand.

Abstract: Technologies for updating firmware in a pre-boot environment include a mobile computing device having a firmware environment and an operating system. In the pre-boot environment, the mobile computing device extracts a firmware update from a capsule previously generated by the operating system and determines a power consumption setting for a hardware component as a function of the firmware update. The mobile computing device configures the hardware component based on the power consumption setting and applies the firmware update in response to configuring the hardware component. The firmware update may include a firmware driver executable in the firmware environment. The hardware component may include a peripheral device or a device controller of the mobile computing device. The mobile computing device may determine a power policy as a function of the firmware update, and determine the power consumption setting as a function of the power policy. Other embodiments are described and claimed.

Abstract: Methods and apparatus to provide isolated execution environments are disclosed. In some examples, the methods and apparatus identify a request from a host application. In some examples, the methods and apparatus, in response to identifying the request from the host application, load a microcode application into memory when excess micro operations exist in a host instruction set architecture, the microcode application being a fragment of code. In some examples, the methods and apparatus execute the microcode application. In some examples, the methods and apparatus, in response to completed execution of the microcode application, unload the microcode application from memory.

Abstract: Methods, systems and storage media are disclosed for enhanced system boot processing that authenticates boot code based on biometric information of the user before loading the boot code to system memory. For at least some embodiments, the bio -metric authentication augments authentication of boot code based on a unique platform identifier. The enhanced boot code authentication occurs before loading of the operating system, and may be performed during a Unified Extensible Firmware Interface (UEFI) boot sequence. Other embodiments are described and claimed.

Abstract: Apparatuses, methods and storage media associated with managing a computing platform in view of an expiration date are described herein. In embodiments, an apparatus may include a computing platform that includes one or more processors to execute applications; and a trusted execution environment that includes a tamper-proof storage to store an expiration date of the computing platform, and a firmware module to be operated in a secure system management mode to regulate operation of the computing platform in view of at least whether a current date is earlier than the expiration date. Other embodiments may be described or claimed.

Abstract: Various configurations and methods for disabling system management mode (SMM) and verifying a disabled status of SMM in a computing system are disclosed. In various examples, SMM may be disabled through a hardware strap, soft-straps, or firmware functions, and the indication of the SMM disabled status may be included in a model specific register (MSR) value accessible to the central processing unit (CPU). Additionally, techniques for verifying whether SMM is disabled in hardware or firmware, preventing access of SMM functionality, and handling secure software operations are disclosed.

Abstract: Various embodiments are generally directed to establishing trust in system management mode. An operating system management mode driver can invoke a system management mode and provide a signature to the system management mode to authenticate the driver with. Additionally, a hash value of the driver can be used to determine whether the driver is authorized to invoke system management mode or particular operations or features of system management mode.

Abstract: A non-volatile random access memory (NVRAM) is used in a computer system to provide instant responses to sleep state transitions. The computer system includes a processor coupled to an NVRAM, which is accessible by the processor without passing through an I/O subsystem. The NVRAM is byte-rewritable and byte-erasable by the processor. In response to a request to enter a powered sleep state, the computer system converts the powered sleep state into a powered-off sleep state with system memory context stored in the NVRAM. The powered sleep state is defined as a state in which power is supplied to volatile random access memory in the computer system, and the powered-off sleep state is defined as a state in which power is removed from the volatile random access memory. In response to a wake event, the computer system resumes working state operations using the system memory context stored in the NVRAM.

Abstract: Technologies for fast low-power startup include a computing device with a processor having a power management integrated circuit. The computing device initializes platform components into a low-power state and determines, in a pre-boot firmware environment, the battery state of the computing device. The computing device determines a minimum-power startup (MPS) configuration that identifies platform components to be energized and determines whether the battery state is sufficient for the MPS configuration. If sufficient, the computing device energizes the platform components of the MPS configuration and boots into an MPS boot mode. In the MPS boot mode, the computing device may execute one or more user-configured application(s). If the battery state is sufficient for normal operation, the computing device may boot into a normal mode. In the normal mode, the user may configure the MPS configuration by selecting features for the future MPS boot mode. Other embodiments are described and claimed.

Abstract: Systems and methods may provide for identifying a runtime behavioral pattern of an application and detecting an anomaly in the runtime behavioral pattern. In addition, a security event may be triggered in response to the anomaly. In one example, the anomaly is detected with regard to one or more of a library call count, a library call type, a library call argument configuration or a library call timing associated with a runtime operation of the application.

Abstract: In one embodiment, a method is provided that may include one or more operations. One of these operations may include, in response, at least in part, to a request to store input data in storage, encrypting, based least in part upon one or more keys, the input data to generate output data to store in the storage. The one or more keys may be authorized by a remote authority. Alternatively or additionally, another of these operations may include, in response, at least in part, to a request to retrieve the input data from the storage, decrypting, based at least in part upon the at least one key, the output data. Many modifications, variations, and alternatives are possible without departing from this embodiment.

Abstract: Disclosed herein are cloud-based machine learning systems and methods for monitoring networked devices to identify and classify characteristics, to infer typical or atypical behavior and assign reputation profiles across various networked devices, and to make remediation recommendations. In some embodiments, a cloud-based machine learning system may learn the typical operation and interfacing of a plurality of reputable devices that are known to be free from malicious software and other threats. In some embodiments, a cloud-based machine learning system may learn the typical operation and interfacing of a device, and may identify atypical operations or interfaces associated with that device by comparing the operations and interfaces to those of a plurality of networked devices or to those of a defined standard reference device.

Abstract: Disclosed herein are distributed ledger systems and methods for efficiently creating and updating a query optimized distributed ledger. In particular, the present disclosure introduces methods and apparatuses for efficiently updating indexes when new blocks are added to the distributed ledger by using snapshots of data and appending new snapshot tables and indexes to previous snapshot tables and indexes.

Abstract: In one example, a system for accessing services comprises a processor to detect a change in a topology of the system and request configuration data or a firmware image stored in secure storage of a wireless credential exchange or EEPROM, wherein the configuration data indicates an authorized stackable topology map for the system. The processor can also determine the change in the topology is allowed based on the authorized stackable topology map and execute an internet or local based service comprising a modification based on the change to the topology of the system, the service with the modification to be executed in response to a transmission of the change to the service.

Abstract: A device with support for blockchain-based boot tracking comprises at least one processor, non-volatile storage responsive to the processor, and at least one boot module in the non-volatile storage. The boot module, when executed by the processor, enables the device to generate a measurement of the boot module, generate an internal ledger transaction based on the measurement of the boot module, and send the internal ledger transaction to a remote device. In addition, the boot module enables the device to (a) receive an external ledger transaction from the remote device, wherein the external ledger transaction is based on a measurement for a boot module of the remote device; (b) in response to receiving the external ledger transaction, verify the external ledger transaction; and (c) in response to verifying the external ledger transaction, add the external ledger transaction to a boot audit blockchain. Other embodiments are described and claimed.

Abstract: Methods and apparatus related to performance of telemetry, data gathering, and failure isolation using non-volatile memory are described. In one embodiment, a Non-Volatile Memory (NVM) controller logic stores data in a portion of an NVM device. The portion of the NVM device is determined based at least in part on a type or an identity of a sender of the data. Also, the data is encrypted in accordance with a public key provided by the sender. Other embodiments are also disclosed and claimed.

Abstract: Methods, apparatuses and storage medium associated with migration between processors by a computing device are disclosed. In various embodiments, a portable electronic device having an internal processor and internal memory may be attached to a dock. The dock may include another processor as well other memory. The attachment of the dock to the portable electronic device may cause an interrupt. In response to this interrupt, a state associated with the internal processor may be copied to the other memory of the dock. Instructions for the computing device may then be executed using the other processor of the dock. Other embodiments may be disclosed or claimed.