Absolute Software Corporation

Kinglite Holdings Inc.

Phoenix Technologies Ltd.

Eugene Khoruzhenko

Philip B Gardner

Stephen E Jones

James Leonard Mortensen

Jeffrey Michael Bush

Multiple binary images stored in the firmware of an electronic device are written to the device's configuration tables during booting of the device, where one of the binary images is a manager binary. During booting, the manager binary is saved to the file system of the operating system such that it automatically executes upon completion of booting. The manager binary then deploys the other binary images.

Binary image publication by firmware

A mailbox mechanism is used for communication of secure messages from a server to the firmware of a device. Mailbox content provided by the server is authenticated in a driver execution environment of the device, using reboots across the communication sessions, and then stored in secure storage. The communication sessions include first receiving a signed server key, and then receiving a message from the server that is based on a hash of a nonce generated by the device.

Secure firmware interface

Measurements of a device's firmware are made regularly and compared with prior, derived measurements. Prior measurements are derived from a set of identical firmware measurements obtained from multiple devices having the same make, model and firmware version number. The firmware integrity status is reported on a data and device security console for a group of managed endpoints. Alerts about firmware changes, which may be potential attacks on the firmware, are given automatically.

Firmware integrity check using silver measurements

Multiple binary images stored in the firmware of an electronic device are written to the device's configuration tables during booting of the device, where one of the binary images is a manager binary. During booting, the manager binary is saved to the file system of the operating system such that it automatically executes upon completion of booting. The manager binary then saves the other binary images to the OS file system, such that they also execute automatically.

Firmware publication of multiple binary images

Techniques for selectively permitting a device to boot an operating system. Before any operating system is loaded on the device, a BIOS component analyzes a set of files residing on the device to create state data that describes a current state of the set of files. This enables the state data to identify whether any files have been unexpectedly modified or are outdated. The BIOS component attempts to send the state data to a server over a network. The BIOS component then determines whether to permit the device to boot the operating system based on whether the network was detected and on the contents of any response, sent by the server, responsive to the state data.

Promoting a secure operating environment through oversight and provisioning of BIOS activity

In a method of building a firmware component to execute a sequence of instructions in a device having a computer, a plurality of build files is processed to form a set of buildable statements of hardware policy. The buildable statements are decoded to form a Configuration Manager namespace. Contents of the Configuration Manager namespace are linked to a UEFI compatible kernel program having a Configuration Manager capability. Alternatively, a data stream representing the contents of the Configuration Manager namespace is encoded to form a Configuration Manager database readable by the UEFI compatible kernel program at a run-time. A plurality of UEFI device driver programs and the UEFI compatible kernel program are linked to form the firmware component.

Policy description technique in UEFI firmware

Methods, systems and program products provide platform customization in building of Unified Extensible Firmware Interface based Personal Computer firmware, typically but not essentially as BIOS. Provision is made for a conceptual matrix of Board module, Silicon (or chipset) modules together with core and foundation modules; this supersedes prior approaches that are often based on hierarchical (or inverse hierarchy) structured source codes. A Platform module resides architecturally between Silicon and Board modules. By largely removing the Platform module found in previously developed solutions and introducing a Board module OEM, customizations are separated from actual platform code (and also from core functions). This allows the customization footprint to be much smaller thus easing the programming efforts of porting products to reflect hardware development.

Board module for providing alternative board functions which are not called by UEFI compatible programs for driving platform service in silicon components

Growing community of inventors

Redmond, WA, United States of America

Eugene Khoruzhenko