Abstract: A firmware-based mechanism for protecting against physical attacks on ROM areas holding Authenticated Variables. A first hash of contents of at least one Authenticated Variable is created by a computing device's UEFI-compliant firmware and stored in a non-volatile storage location. Subsequently a second hash of contents of the at least one Authenticated Variable is created by the firmware and compared by the firmware to the stored hash to identify unauthorized modifications of the at least one Authenticated Variable occurring after the creation of the first hash.

Abstract: A mechanism for reducing the cost of providing network-based remote platform management by allowing system firmware to communicate with a remote platform administrator or process by sharing a NIC that is also used for normal network traffic is discussed. The dual use of the NIC reduces the cost of remote platform management by removing the need for a secondary controller or CPU core on the computing device that is dedicated to remote management tasks. Additionally, performance in the computing device improves as a byproduct of a CPU core or thread not being dedicated to the management task and instead being available for handling of other tasks.

Abstract: A system firmware agent providing the capabilities of a Baseboard Management Controller (BMC) from within System Management Mode (SMM) is discussed. A virtual BMC provides dedicated communication channels for system firmware, other BMCs in the platform and remote management agents. The virtual BMC may monitor the status of the system, record system events, and control the system state.

Abstract: A computing device equipped with UEFI-compliant firmware is provided with added functionality via an extended firmware interface. The variable interface is called with special parameters, which redirect handling of firmware service calls. Embodiments use authenticated variables to provide security properties to the special interface, use the firmware interface to provide access to diagnostics, and use the firmware interface to provide access to system management.

Abstract: A scalable method of determining in a firmware environment if the rate of occurrence of a detectable specified type of system event that occurs to a system component or discrete functional unit, has met a criteria with respect to a pre-selected threshold. When the meeting of the threshold criteria is detected, a previously defined action associated with the threshold criteria for the particular event can be invoked by the firmware. Embodiments may establish a sliding time-window that includes a currently detected type of system event and extends back a set duration in the past. Any occurrences of the specified event taking place earlier than the established time-window may be discarded while occurrences of the events during the specified time-window are added together with the newly detected event and compared to a threshold value to see if the threshold criteria has been met.

Abstract: A remote control system using a handheld electronic device to remotely control electrical appliances includes a handheld electronic device and a command conversion device. The handheld electronic device uses a command input device to generate operation information. A command recognizing module receives the operation information, and identifies the corresponding home appliance remote control code. A wireless emission module emits a home appliance remote control code, which is received by the command conversion device. The command conversion device determines the infrared execution command corresponding to the home appliance remote control code. The infrared execution command is emitted by the infrared emission module to remotely control home appliances with the infrared remote control function. The handheld electronic device is enabled to provide a variety of different operating modes without significantly increasing the cost of the entire system.

Abstract: A technique for managing a Unified Extensible Firmware Interface (UEFI) Basic Input/Output System (BIOS)-controlled computing device from a separate mobile computing device is discussed.

Abstract: A mechanism that allows firmware for a computing device to be updated in a secure manner by utilizing an update validation procedure included in a ROM image is discussed.

Abstract: A mechanism for firmware to gain control from the operating system of an Advanced Configuration and Power Interface (ACPI)-compliant computing device during sleep-state transitions even if the computing device lacks a dedicated means for such a change to occur is discussed. Embodiments of the present invention report a CPU-only reset register in place of a sleep control register for an ACPI-compliant computing device in which an operating system is attempting a sleep-state transition. A CPU reset value is substituted for a sleep type value in a sleep-state object and written to the CPU-only reset register that was reported instead of the sleep control register thereby triggering a CPU-only reset. Firmware code operating at a known CPU reset vector may perform specified processing and then authorize a transition to the originally requested sleep-state.

Abstract: A mechanism for allowing a user to prove their identity on touch-based devices employing the use of a touch surface in firmware-controlled environments is discussed. The user may prove his or her identity by entering a series of strokes on the touch-based device to form a word or image. Characteristics of the entered strokes such as stroke order and stroke direction are compared to stored stroke characteristics that were gathered from a drawing of the same word or image during a user enrollment process. If the stroke characteristics comparison is acceptable, the user identity is verified.

Abstract: A mechanism for creating secure storage for firmware for a computing device. A designated secure storage area holding firmware that is executable prior to a loading of an operating system for the computing device is created during a build of a ROM image. The creating marks one or more files as requiring encrypted storage and the one or marked files are combined during the build into the designated secure storage area. The designated secure storage area is located outside the ROM image and includes, during the build of the ROM image, a reference to the designated secure storage area in a build of firmware placed in the ROM image. The reference includes a flag indicating a current encrypted status of the designated secure storage area.

Abstract: A method for automatically generating and launching application software through a single entry point of a store platform provides a continuous service for automatically generating and launching APP through an APP store platform providing application software (APP). After users briefly describe and/or input information, the APP store platform can automatically generate an APP product and directly launch the APP product thereon. The store platform can further launch APP products to other external APP store platforms. Accordingly, a convenient service with continuity and coherence for automatically generating and launching APP products can be provided.

Abstract: An image guided method for installing application software has the steps of using an electronic device to capture an image associated with an application software (App), comparing the captured image with data in an image database, generating installing information of the App based on the comparison result, and displaying the installing information on the electronic device to guide a user to install the App in the electronic device. Therefore, when the user takes the electronic device to capture an image or an icon associated with the App, the user receives the installing information of the App through the image comparison process and installs the App in the electronic device conveniently.

Abstract: A mechanism for making increased amounts of firmware available to a computer pre-boot is discussed. To increase the amount of firmware available pre-boot, a design decision is made during the build process as to which segments of the firmware need to be placed on the ROM part and which segments of the firmware can be located elsewhere. The segments of the firmware that are stored remotely from the ROM are referred to as “virtual ROM modules”. Each of the virtual ROM modules is assigned a generated unique identifier, and a “message digest” is constructed for each module using an algorithm such as MD5 or SHA-1. In the software build of the ROM image, the message digest-unique identifier pair created for each Virtual ROM module is used as a logical pointer for the virtual module. Additionally, a search path variable is placed into the ROM image in non-volatile storage. The search path provides for one or more locations in which to look for the Virtual ROM modules, and may be updated at a later point in time.

Abstract: Firmware in a UEFI-compliant computing device is used to administer and alter a Secure Boot process for the computing device while continuing to provide protection from unauthorized third-party code.

Abstract: A mechanism for controlling the execution of Option ROM code on a Unified Extensible Firmware Interface (UEFI)-compliant computing device is discussed. A security policy enforced by the firmware may be configured by the computing platform designer/IT administrator to take different actions for different types of detected expansion cards or other devices due to the security characteristics of Option ROM drivers associated with the expansion card or device. The security policy may specify whether authorized signed UEFI Option ROM drivers, unauthorized but signed UEFI Option ROM drivers, unsigned UEFI Option ROM drivers and legacy Option ROM drivers are allowed to execute on the UEFI-compliant computing device.

Abstract: A method for performing a quick boot and a general boot at a basic input output system (BIOS) stage is described. A computer is powered on. An embedded controller firmware or a BIOS determines whether a quick boot key is pressed. If the quick boot key is not pressed, a boot flag is changed from Quick Boot to General Boot. If the quick boot key is pressed, the BIOS determines whether the boot flag is set to Quick Boot. If it is determined that the boot flag is set to Quick Boot, an initialization of drivers preset by the quick boot is performed, and uninitialized drivers are initialized at a stage when an operating system is started. If it is determined that the boot flag is set to General Boot, an initialization of all drivers is performed.

Abstract: A mechanism for allowing firmware in a UEFI-compliant device to implement the UEFI specification driver signing and Authenticated Variable elements while at the same time protecting the system security database holding the library of approved keys and lists of allowed and forbidden programs from unauthorized modifications is discussed.

Abstract: A mechanism for creating secure storage for firmware for a computing device. A designated secure storage area holding firmware that is executable prior to a loading of an operating system for the computing device is created during a build of a ROM image. The creating marks one or more files as requiring encrypted storage and the one or marked files are combined during the build into the designated secure storage area. The designated secure storage area is located outside the ROM image and includes, during the build of the ROM image, a reference to the designated secure storage area in a build of firmware placed in the ROM image. The reference includes a flag indicating a current encrypted status of the designated secure storage area.

Abstract: A mechanism for creating and accessing a secure storage area for firmware that stores a “Virtual ROM” module reference or pointer in the actual ROM that includes a unique identifier for the virtual ROM module to be retrieved is discussed. The actual ROM image also contains a generated unique identifier for the whole machine. In retrieving a Virtual ROM module, both the module identifier and the machine identifier are used. Once retrieved, the module is validated using a message digest stored in the Virtual ROM module reference. If required, the Virtual ROM module is then decrypted using a secret key that is stored elsewhere in the actual ROM. Updates to the Virtual ROM module are made in memory by pre-boot code. At a point in time when these updates are complete, the Virtual ROM module is written back out to the location from which it was retrieved.