System and method for secure access to a distributed virtual firmware network drive

An information handling system includes a virtual network access module configured to access a virtual network drive that has a first partition in a local storage resource and a second partition in a remote storage resource. In response to detection of an exception, a processor may trigger an exception handler that directs a service processor to initialize a network stack. The processor initializes a mailbox to transmit a mailbox request to retrieve network configuration settings to be used in the initialization of the network stack. The service processor transmits a request to the processor to initialize the mailbox, and initializes the network stack based on the network configuration settings. Subsequent to the initialization of the network stack, a universal network device interface request may be sent to mount and secure communication with the virtual network drive.

FIELD OF THE DISCLOSURE

The present disclosure generally relates to information handling systems, and more particularly relates to secure access to a distributed virtual firmware network drive.

BACKGROUND

SUMMARY

An information handling system includes a virtual network access module configured to access a virtual network drive that has a first partition in a local storage resource and a second partition in a remote storage resource. In response to detection of an exception, a processor may trigger an exception handler that directs a service processor to initialize a network stack. The processor initializes a mailbox to transmit a mailbox request to retrieve network configuration settings to be used in the initialization of the network stack. The service processor transmits a request to the processor to initialize the mailbox, and initializes the network stack based on the network configuration settings. Subsequent to the initialization of the network stack, a universal network device interface request may be sent to mount and secure communication with the virtual network drive.

DETAILED DESCRIPTION OF THE DRAWINGS

FIG.1illustrates an embodiment of an information handling system100including processors102and104, a chipset110, a memory120, a graphics adapter130connected to a video display134, a non-volatile RAM (NV-RAM)140that includes a basic input and output system/unified extensible firmware interface (BIOS/UEFI) module142, a disk controller150, a hard disk drive (HDD)154, an optical disk drive156, a disk emulator160connected to a solid-state drive (SSD)164, an input/output (I/O) interface170connected to an add-on resource174and a trusted platform module (TPM)176, a network interface180, and a baseboard management controller (BMC)190. Processor102is connected to chipset110via processor interface106, and processor104is connected to the chipset via processor interface108. In a particular embodiment, processors102and104are connected together via a high-capacity coherent fabric, such as a HyperTransport link, a QuickPath Interconnect, or the like. Chipset110represents an integrated circuit or group of integrated circuits that manage the data flow between processors102and104and the other elements of information handling system100. In a particular embodiment, chipset110represents a pair of integrated circuits, such as a northbridge component and a southbridge component. In another embodiment, some or all of the functions and features of chipset110are integrated with one or more of processors102and104.

Memory120is connected to chipset110via a memory interface122. An example of memory interface122includes a Double Data Rate (DDR) memory channel and memory120represents one or more DDR Dual In-Line Memory Modules (DIMMs). In a particular embodiment, memory interface122represents two or more DDR channels. In another embodiment, one or more of processors102and104include a memory interface that provides a dedicated memory for the processors. A DDR channel and the connected DDR DIMMs can be in accordance with a particular DDR standard, such as a DDR3 standard, a DDR4 standard, a DDR5 standard, or the like.

Memory120may further represent various combinations of memory types, such as Dynamic Random Access Memory (DRAM) DIMMs, Static Random Access Memory (SRAM) DIMMs, non-volatile DIMMs (NV-DIMMs), storage class memory devices, Read-Only Memory (ROM) devices, or the like. Graphics adapter130is connected to chipset110via a graphics interface132and provides a video display output136to a video display134. An example of a graphics interface132includes a Peripheral Component Interconnect-Express (PCIe) interface and graphics adapter130can include a four lane (×4) PCIe adapter, an eight lane (×8) PCIe adapter, a 16-lane (×16) PCIe adapter, or another configuration, as needed or desired. In a particular embodiment, graphics adapter130is provided down on a system printed circuit board (PCB). Video display output136can include a Digital Video Interface (DVI), a High-Definition Multimedia Interface (HDMI), a DisplayPort interface, or the like, and video display134can include a monitor, a smart television, an embedded display such as a laptop computer display, or the like.

NV-RAM140, disk controller150, and I/O interface170are connected to chipset110via an I/O channel112. An example of I/O channel112includes one or more point-to-point PCIe links between chipset110and each of NV-RAM140, disk controller150, and I/O interface170. Chipset110can also include one or more other I/O interfaces, including an Industry Standard Architecture (ISA) interface, a Small Computer Serial Interface (SCSI) interface, an Inter-Integrated Circuit (I2C) interface, a System Packet Interface, a Universal Serial Bus (USB), another interface, or a combination thereof. NV-RAM140includes BIOS/UEFI module142that stores machine-executable code (BIOS/UEFI code) that operates to detect the resources of information handling system100, to provide drivers for the resources, to initialize the resources, and to provide common access mechanisms for the resources. The functions and features of BIOS/UEFI module142will be further described below.

Disk controller150includes a disk interface152that connects the disk controller to a hard disk drive (HDD)154, to an optical disk drive (ODD)156, and to disk emulator160. An example of disk interface152includes an Integrated Drive Electronics (IDE) interface, an Advanced Technology Attachment (ATA) such as a parallel ATA (PATA) interface or a serial ATA (SATA) interface, a SCSI interface, a USB interface, a proprietary interface, or a combination thereof. Disk emulator160permits SSD164to be connected to information handling system100via an external interface162. An example of external interface162includes a USB interface, an institute of electrical and electronics engineers (IEEE) 1394 (Firewire) interface, a proprietary interface, or a combination thereof. Alternatively, SSD164can be disposed within information handling system100.

Network interface180represents a network communication device disposed within information handling system100, on a main circuit board of the information handling system, integrated onto another component such as chipset110, in another suitable location, or a combination thereof. Network interface180includes a network channel182that provides an interface to devices that are external to information handling system100. In a particular embodiment, network channel182is of a different type than peripheral interface172and network interface180translates information from a format suitable to the peripheral channel to a format suitable to external devices.

In a particular embodiment, network interface180includes a NIC or host bus adapter (HBA), and an example of network channel182includes an InfiniBand channel, a Fibre Channel, a Gigabit Ethernet channel, a proprietary channel architecture, or a combination thereof. In another embodiment, network interface180includes a wireless communication interface, and network channel182includes a Wi-Fi channel, a near-field communication (NFC) channel, a Bluetooth or Bluetooth-Low-Energy (BLE) channel, a cellular based interface such as a Global System for Mobile (GSM) interface, a Code-Division Multiple Access (CDMA) interface, a Universal Mobile Telecommunications System (UMTS) interface, a Long-Term Evolution (LTE) interface, or another cellular based interface, or a combination thereof. Network channel182can be connected to an external network resource (not illustrated). The network resource can include another information handling system, a data storage system, another network, a grid management system, another suitable resource, or a combination thereof.

BMC190also referred to as a service processor is connected to multiple elements of information handling system100via one or more management interface192to provide out of band monitoring, maintenance, and control of the elements of the information handling system. As such, BMC190represents a processing device different from processor102and processor104, which provides various management functions for information handling system100. For example, BMC190may be responsible for power management, cooling management, and the like. The term BMC is often used in the context of server systems, while in a consumer-level device a BMC may be referred to as an embedded controller (EC). A BMC included at a data storage system can be referred to as a storage enclosure processor. A BMC included at a chassis of a blade server can be referred to as a chassis management controller and ECs included at the blades of the blade server can be referred to as blade management controllers. Capabilities and functions provided by BMC190can vary considerably based on the type of information handling system. BMC190can operate in accordance with an Intelligent Platform Management Interface (IPMI). Examples of BMC190include an Integrated Dell® Remote Access Controller (iDRAC).

Management interface192represents one or more out-of-band communication interfaces between BMC190and the elements of information handling system100, and can include an Inter-Integrated Circuit (I2C) bus, a System Management Bus (SMBUS), a Power Management Bus (PMBUS), a Low Pin Count (LPC) interface, a serial bus such as a Universal Serial Bus (USB) or a Serial Peripheral Interface (SPI), a network interface such as an Ethernet interface, a high-speed serial data link such as a Peripheral Component Interconnect-Express (PCIe) interface, a Network Controller Sideband Interface (NC-SI), or the like. As used herein, out-of-band access refers to operations performed apart from a BIOS/operating system execution environment on information handling system100, that is apart from the execution of code by processors102and104and procedures that are implemented on the information handling system in response to the executed code.

BMC190operates to monitor and maintain system firmware, such as code stored in BIOS/UEFI module142, option ROMs for graphics adapter130, disk controller150, add-on resource174, network interface180, or other elements of information handling system100, as needed or desired. In particular, BMC190includes a network interface194that can be connected to a remote management system to receive firmware updates, as needed or desired. Here, BMC190receives the firmware updates, stores the updates to a data storage device associated with the BMC, transfers the firmware updates to NV-RAM of the device or system that is the subject of the firmware update, thereby replacing the currently operating firmware associated with the device or system, and reboots information handling system, whereupon the device or system utilizes the updated firmware image.

BMC190utilizes various protocols and application programming interfaces (APIs) to direct and control the processes for monitoring and maintaining the system firmware. An example of a protocol or API for monitoring and maintaining the system firmware includes a graphical user interface (GUI) associated with BMC190, an interface defined by the Distributed Management Taskforce (DMTF) (such as a Web Services Management (WSMan) interface, a Management Component Transport Protocol (MCTP) or, a Redfish® interface), various vendor defined interfaces (such as a Dell EMC Remote Access Controller Administrator (RACADM) utility, a Dell EMC OpenManage Server Administrator (OMSS) utility, a Dell EMC OpenManage Storage Services (OMSS) utility, or a Dell EMC OpenManage Deployment Toolkit (DTK) suite), a BIOS setup utility such as invoked by a “F2” boot option, or another protocol or API, as needed or desired.

In a particular embodiment, BMC190is included on a main circuit board (such as a baseboard, a motherboard, or any combination thereof) of information handling system100or is integrated onto another element of the information handling system such as chipset110, or another suitable element, as needed or desired. As such, BMC190can be part of an integrated circuit or a chipset within information handling system100. An example of BMC190includes an iDRAC, or the like. BMC190may operate on a separate power plane from other resources in information handling system100. Thus BMC190can communicate with the management system via network interface194while the resources of information handling system100are powered off. Here, information can be sent from the management system to BMC190and the information can be stored in a RAM or NV-RAM associated with the BMC. Information stored in the RAM may be lost after power-down of the power plane for BMC190, while information stored in the NV-RAM may be saved through a power-down/power-up cycle of the power plane for the BMC.

Although information handling system100as shown in this disclosure include a BMC190, one of skill in the art will appreciate an EC may perform similar functions as BMC190and may be used in the consumer-level devices also referred to as client type platforms instead of BMC190. Thus, information handling system100may have an EC instead of BMC190be deemed to have an EC instead of BMC190if information handling system100is a client type platform.

Information handling system100can include additional components and additional busses, not shown for clarity. For example, information handling system100can include multiple processor cores, audio devices, and the like. While a particular arrangement of bus technologies and interconnections is illustrated for the purpose of example, one of skill will appreciate that the techniques disclosed herein are applicable to other system architectures. Information handling system100can include multiple CPUs and redundant bus controllers. One or more components can be integrated together. Information handling system100can include additional buses and bus protocols, for example, I2C and the like. Additional components of information handling system100can include one or more storage devices that can store machine-executable code, one or more communications ports for communicating with external devices, and various input and output (I/O) devices, such as a keyboard, a mouse, and a video display.

For purpose of this disclosure information handling system100can include any instrumentality or aggregate of instrumentalities operable to compute, classify, process, transmit, receive, retrieve, originate, switch, store, display, manifest, detect, record, reproduce, handle, or utilize any form of information, intelligence, or data for business, scientific, control, entertainment, or other purposes. For example, information handling system100can be a personal computer, a laptop computer, a smartphone, a tablet device or other consumer electronic device, a network server, a network storage device, a switch, a router, or another network communication device, or any other suitable device and may vary in size, shape, performance, functionality, and price. Further, information handling system100can include processing resources for executing machine-executable code, such as processor102, a programmable logic array (PLA), an embedded device such as a System-on-a-Chip (SoC), or other control logic hardware. Information handling system100can also include one or more computer-readable media for storing machine-executable code, such as software or data.

In many information handling systems, the BIOS/UEFI is capable of operating in pre-boot mode in which the BIOS/UEFI executes certain instructions prior to loading and execution of an operating system. When the information handling system is booted, the BIOS/UEFI may load files stored in an extensible firmware interface (EFI) system partition of a local storage resource to start the operating system and various utilities. Because the EFI system partition may also include a recovery image for the information handling system, during a boot failure, the information handling system may connect to the EFI system partition also referred herein as a local store or a cloud-based store for the recovery image. However, the recovery image restores the information to factory default settings as pre-boot and boot data such as firmware images, BIOS/firmware data, configuration variables, etc. specific to a particular platform are generally not backed up. As such, platform-specific pre-boot and boot settings are lost.

In addition, there may be several scenarios in which connecting to the local store or cloud-based store may not be feasible. For example, the data or the storage device that hosts the local store may be corrupted such that data recovery from the local store may not be possible as formatting or replacing the storage device will wipe the recovery image. In another scenario, the information handling system may not be able to connect to the cloud-based store during the boot failure because of a missing network connection, bad memory, data corruption, etc. In yet another scenario, one of NV-RAM, complementary metal-oxide semiconductor (CMOS), or SPI flash memory device which stores boot variables may be corrupted. Because boot variables stored in the NV-RAM, CMOS, or SPI flash memory device are generally not replicated in the local store or the cloud-based store, the corruption of one or more of the NV-RAM, CMOS, or SPI flash memory device impairs the ability of the information handling system to boot successfully even with access to a recovery image.

Because the current disclosure leverages a secure distributed firmware storage domain wherein platform-specific data such as firmware, software, boot variables, etc. are replicated and/or synchronized to include the latest versions, the current disclosure enables a reliable, safe, and secure way to recover or rollback the information handling system during a boot failure or when a hardware and/or software issue is detected.

FIG.2illustrates a system200for secure runtime access of platform-specific data stored in a virtual firmware network drive also referred to as a virtual network drive or simply virtual drive. System200includes an information handling system205and a virtual drive297. Virtual drive297is a distributed virtual drive which includes a virtual drive local store287and a virtual drive virtual drive virtual drive global store295. Virtual drive local store287which may be an EFI system partition is communicatively coupled with virtual drive global store295by a network292. Information handling system205includes a storage resource285, an SPI flash memory280, and a runtime environment250. Storage resource285includes local store287and a local store290. SPI flash memory280includes a key store282. Runtime environment250may include a runtime stack of BIOS/UEFI260services that may remain accessible while the operating system is executing such as date, time, non-volatile RAM access, etc. Runtime environment250includes an application210, a management services215, an Advanced Configuration and Power Management Interface (ACPI) services225, an ACPI runtime services245, a BIOS/UEFI260, an EC262, an access module265, and a virtual drive access module275. Management services215includes an ACPI module220. ACPI services225includes a protected access module240and a namespace objects230which includes a disk objects235.

Application210may include software applications and/or scripts configured to issue an I/O command also referred to as an I/O request for accessing data in virtual drive297, local store287, and/or virtual drive global store295collectively referred herein as virtual drive297. The data stored in virtual drive297may include platform-specific data for use in recovery or rollback of information handling system205such as firmware, operating system image, and software. Platform-specific data may also include security information, authentication information, boot variables, network profiles, network configuration settings, etc. The platform-specific data stored in virtual drive297may also referred to as recovery data. Application210may issue the I/O request to retrieve, add, delete, and/or update the recovery data stored in virtual drive297at runtime using a variety of interfaces or operating system methods. The I/O request may pass through management services215which may include various technologies such as Windows® management instrumentation (WMI) core for accessing management information including the recovery data. Management services215may include ACPI module220which may be configured to interface with ACPI services225. For example, ACPI module220may include WMI ACPI system modules which are WMI modules that are associated with ACPI system modules for ACPI devices.

ACPI services225includes ACPI methods which may be used to query and configure ACPI devices. The ACPI devices include various low-level system devices such as batteries, thermal zones, and services that are defined in information handling system205's ACPI namespace. The ACPI namespace is a hierarchal namespace that BIOS/UEFI260uses to reference objects such as namespace objects230. Namespace objects230are dynamic and may exist for the duration of an ACPI method execution. As shown, namespace objects230includes disk objects235which include objects associated with storage devices and/or stores such as storage resource285and virtual drive297in particular.

ACPI services225also includes protected access module240which may include methods and/or objects to be used by virtual drive access module275to securely access virtual drive297. For example, protected access module240may also include lock/unlock objects for the lock/unlock methods in access module265. BIOS functions in BIOS/UEFI260, which is similar to BIOS/UEFI142, along with the lock/unlock methods via virtual drive access module275may be used to lock/unlock and securely access virtual drive297. BIOS functions in BIOS/UEFI260along with the lock/unlock methods may also be used to retrieve lock/unlock keys from SPI flash memory280and/or key store282. The lock/unlock keys may be one or more of a valid signature, a valid session identification, or a valid certificate to lock/unlock virtual drive297. In one embodiment, the lock/unlock keys may be generated based on a UEFI key such as a platform key and a key exchange key. BIOS/UEFI260may also retrieve various information such as a globally unique identifier (GUID) associated with an object identifier, a method name or identifier associated with the GUID and/or object identifier, etc. The aforementioned retrieved information may be used to identify information handling system205and/or virtual drive access module275. In addition, the aforementioned information may be used to generate a security object like the lock/unlock key, to be used by virtual drive access module275for verification and/or authentication, such as by key exchange, to securely access virtual drive297.

After unlocking virtual drive297, virtual drive access module275may access virtual drive297and perform the I/O request. Virtual drive access module275with BIOS/UEFI260and/or ACPI services225may also verify that the issuer of the I/O request such as application210is authorized to perform the I/O request prior to the verification and/or authentication. The I/O request may be performed via the BIOS runtime services and/or ACPI runtime services. After performing the I/O request, virtual drive access module may lock virtual drive297.

A signature also referred to as a token may be generated based on a public/private key, the UEFI key, or and a hash of the object's GUID, such as the GUID of the firmware, device, application, method or service. The signature may include an expiration time associated with the I/O request. For example, the signature guarantees that the I/O request has not been altered in transit. EC262may be configured to understand the I/O request which may be transmitted as raw L2 packets over mailbox (Mbox) from BIOS/UEFI260. In addition, EC262may be configured to determine if there is a communication channel between virtual drive access module275and virtual drive297. If there is no communication channel, then EC262may be configured to initialize the network stack and establish the communication channel.

Virtual drive access module275may receive the I/O request as raw L2 packets over Mbox and transmit the I/O request as a Universal Network Driver Interface (UNDI) runtime service request. In particular, the I/O request may be transmitted as a UNDI command descriptor block (CDB) command. When the virtual drive access module275digitally signs the UNDI runtime service request, a one-way hash may be added using information handling system205's platform key or a public/private key pair. Upon receipt of the UNDI runtime service request, virtual drive297may decrypt the UNDI runtime service request using a public key. Virtual drive297can then validate and/or authenticate that the UNDI runtime service request is from information handling system205and/or virtual drive access module275in particular. Virtual drive297and virtual drive access module275may utilize a key exchange mechanism for the validation and authentication process to protect virtual drive297from unauthorized access. The key exchange mechanism is performed to ensure that virtual drive297trusts information handling system205and vice versa. If the validation and/or authentication is not successful, then information handling system205is blocked for access by virtual drive297.

ACPI services225may use runtime services or control methods in ACPI runtime services245to perform the I/O request. The control methods may be written in ACPI Source Language (ASL) that are compiled into ACPI Machine Language (AML) and loaded into ACPI namespace. ACPI services225may also use the methods/or object in protected access module240to retrieve keys in key store282and gain access to virtual drive297via virtual drive access module275similar to outlined above.

Local store287, virtual drive global store295, and virtual drive297may be associated with a hidden namespace identifier such as a GUID. The hidden namespace identifier is only known and can only be accessed by virtual drive access module275. Using the hidden namespace identifier allows virtual drive local store287, virtual drive global store295, and virtual drive297to be hidden from the BIOS/UEFI260, the operating system, and the methods associated with the operating system. In addition, access to virtual drive local store287, virtual drive global store295, and virtual drive297may be secured by a digital signature that associated with a firmware image or recovery material GUID. As such, access to virtual drive local store287, global firmware store, and virtual drive297may require use one or more signatures and keys stored in key store282. The signature may be generated based on a public key and hash of the firmware GUID. Thus, the backup and recovery firmware images and recovery material are protected from runtime and pre-boot level vulnerabilities.

BIOS/UEFI260includes functions to invoke device-specific operations, such as BIOS runtime services. For example, if a protected access method is called from WMI, the BIOS runtime services, in turn, may call the lock/unlock methods to check the access privilege and the key supplied by WMI. If the supplied key is valid, then virtual drive297can be unlocked. BIOS/UEFI260may also include other functions to invoke operations associated with the I/O request on virtual drive297through virtual drive access module275. For example, BIOS/UEFI260can invoke a function to read or write data in virtual drive297. To be able to read or write the data, BIOS/UEFI260may call a function in virtual drive access module275to provide secure access to virtual drive297and perform the read or write operation. Virtual drive access module275may return information associated with the read or write operation to BIOS/UEFI260. For example, in a read operation, virtual drive access module275may return the data that was read. In another example, in a write operation, virtual drive access module275may return a status of the write operation, such as success or failure.

BIOS/UEFI260may also include functions to invoke operations associated with storing, updating, and/or retrieving keys such as public/private and platform keys, signatures, hashes, tokens, etc., collectively referred to herein as security objects, at key store282through access module265. Access module265may be configured to provide secure access to SPI flash memory280and/or key store282. In particular, access module265may include methods to lock and/or unlock SPI flash memory280, key store282or a portion thereof. Access module265may detect whether SPI flash memory280or one of its regions is locked or unlocked. For example, a status register associated SPI flash memory280may be set to read-only when locked. If locked, access module265may unlock SPI flash memory280, key store282, or a portion thereof to prior to accessing the aforementioned to add, retrieve and/or update a security object which may be used to access virtual drive297. Subsequent to the access of SPI flash memory280, key store282, or a portion thereof, access module265may lock SPI flash memory280, key store282, or the unlocked portion.

SPI flash memory280may be a non-volatile computer memory storage medium that is configured to store information used in booting up or in recovering information handling system205such as boot code, boot variables, configuration data, service tag, private/public key pair, the security objects, etc. SPI flash memory280may include security settings for granting read/write permissions for each region of SPI flash memory280such as key store282, flash descriptor, platform data, management engine, etc. SPI flash memory280may be configured to be accessible by lock/unlock methods of access module265at runtime. Key store282may be configured as storage for the security objects such as signatures, tokens, and/or hashes, wherein each one of the aforementioned may be associated with a distinct object and/or GUID and wherein each object and/or GUID corresponds to a firmware, a device, a service, etc.

Virtual drive access module275may be configured to implement a host virtual network drive access (HVNDA) protocol which supports to secure the I/O request which includes an access request to virtual drive297. Virtual drive access module275also includes an integrated local storage drive and network driver to provide access to virtual drive local store287as well as virtual drive local store295to execute the I/O request. The I/O request may be received from the operating system or one of the issuer of an operating system based method such as application210, management services215, ACPI services225, ACPI runtime services245, BIOS/UEFI260, access module265, etc. The I/O request may include an ACPI call to initiate access to virtual drive297, wherein virtual drive access module275may use a UNDI runtime service to access and/or execute the I/O request. The UNDI runtime service may also be used to update the secure access to virtual drive297, such as an update to a security object. The I/O request may be part of performing firmware backup and recovery operations at runtime, pre-boot, or during the boot process. Virtual drive access module275may also be configured to authenticate the access requests and create a secure session for communicating with the operating system or its component.

The firmware backup and recovery operations may be performed using the UNDI API. The various runtime and pre-boot methods such as the firmware backup and recovery operations may be implemented according to the HVNDA protocol such as during boot failure. In addition, the methods implemented to protect against vulnerabilities of operating system based methods such as WMI, ASL, system management mode (SMM), dynamically provisioned access control infrastructure (DACI), etc. to access virtual drive297at runtime may also adhere to the HVNDA protocol. For example, direct access of the aforementioned operating system based methods to virtual drive297is not allowed and is restricted to virtual drive access module275. The HVNDA protocol may also be adhered to in performing various operations such as synchronization or update of the recovery data in virtual drive297at runtime, pre-boot or during the boot process.

Storage resource285or a portion thereof may be communicatively coupled to virtual drive access module275. Storage resource285may include one or more storage devices such as an HDD or an SSD. Although only one storage resource285is depicted inFIG.2, information handling system205may include or may be coupled to a plurality of storage resources. As shown, storage resource285may include a virtual drive local store287and a local store290. Storage drivers associated with storage resource285may have access to local store290but not to virtual drive local store287. In addition, local store290is not included in virtual drive297and is not accessible via network. Virtual drive local store287may be a partition of storage resource285that includes boot loader programs for installed operating system of information handling system205, device driver files for devices in information handling system205that are used by firmware at boot time, system utility programs that are intended to be run before an operating system is boot, configuration data used at boot time, data files such as error logs, etc

Network292may be a network and/or fabric configured to couple information handling system205to virtual drive global store295and/or other information handling systems. Network292may include a communication infrastructure which provides physical connections, and a management layer which organizes the physical connections and information handling systems communicatively coupled to network292. Network292may be implemented as, or maybe part of, a storage area network (SAN), a personal area network (PAN), a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), a wireless local area network (WLAN), a virtual private network, an intranet, the Internet, or any other appropriate architecture or system that facilitates the communication of signals, data and/or messages.

Network292may transmit data via wireless transmissions and/or wire-line transmissions using any storage and/or communication protocol including Fibre Channel, Frame Relay, Asynchronous Transfer Mode (ATM), Internet protocol (IP), other packet-based protocol, SCSI, Internet SCSI (iSCSI), Serial Attached SCSI (SAS), or any other transport that operates with the SCSI protocol, ATA, serial ATA (SATA), ATA packet interface (ATAPI), serial storage architecture (SSA), IDE, and/or any combination thereof. Network292and its various components may be implemented using hardware, software, or any combination thereof.

Virtual drive297may be a distributed virtual drive that includes virtual drive local store287and a cloud-based store, virtual drive global store295for the storage of recovery data. Virtual drive local store287may be accessible pre-boot, at boot-time and at runtime. Virtual drive local store287may be accessible at runtime by the operating system based methods via virtual drive access module275such that the operating system can store certain utilities, tools, and/or data files. In addition, virtual drive local store287may also be accessible at runtime for update of information stored therein such as the configuration data, device driver files, system utility programs, data files, etc. In an embodiment, in which information handling system205adheres to UEFI, virtual drive local store287may include an EFI system partition. Local store290may be a partition in storage resource285that is other than virtual drive local store287. Although storage resource285is depicted to include virtual drive local store287and local store290, storage resource285may include additional stores and/or partitions from additional local and/or network storage resources.

Virtual drive global store395, which is similar to virtual drive local store287, maybe a partition in a cloud-based storage resource. The size of virtual drive global store395may also be configured by an administrator during setup. By default, virtual drive global store395may be set to 1 GB. If not configured, virtual drive global store295may be set to a particular size by default. Each partition in the cloud-based storage resource may be associated with a platform. As such, virtual drive global store395may be mapped or associated with information handling system205. In another embodiment, virtual drive global store295may be associated with virtual drive297which may then be associated with information handling system205.

FIG.3illustrates a system300for a secure boot time access to platform-specific data stored in a virtual drive. System300includes an information handling system305and a virtual drive397which includes a virtual drive local store365and a virtual drive global store395. Virtual drive local store365and virtual drive global store395may be communicatively coupled by a network390. Information handling system305is similar to information handling system205. Virtual drive397is similar to virtual drive297while virtual drive local store365is similar to virtual drive local store287and virtual drive global store395is similar to virtual drive global store295. In addition, local store370is similar to local store290while network390is similar to network292. Information handling system305includes a boot-time environment310, a storage resource360, and an SPI flash memory375. Boot-time environment310includes a BIOS/UEFI315, a protected access module320, a firmware management module325, an EC345, a virtual drive access module350, and an EC proxy network module355. One of skill may appreciate that information handling system205may include a BMC instead of EC345. Similarly, information handling system205may include a BMC proxy network module instead of EC proxy network module355. BIOS/UEFI315is similar to BIOS/UEFI260. Protected access module320is similar to protected access module240. EC345is similar to BMC190. Virtual drive access module350is similar to virtual drive access module275. SPI flash memory375may be a flash memory device associated with EC345and is similar to SPI flash memory280. SPI flash memory375includes firmware area380and network firmware area385. Firmware management module325includes a firmware synchronization module330, a key access module335, and a firmware update module340.

Firmware management module325may be configured to perform firmware updates and firmware synchronization between the virtual drive local store365and virtual drive global store395. Firmware update module340may update the firmware at virtual drive global store395when a new firmware version is released at an update service or repository such as Windows Update, Dell Drivers & Downloads site, etc. In addition, firmware management module325may be configured perform firmware update initiated a user such as via an interface. After the update, the latest firmware images at virtual drive397applicable to information handling system305is mapped accordingly.

Firmware synchronization module330may be configured to synchronize recovery data, between virtual drive local store365and virtual drive global store395. Firmware synchronization module330may also be configured to synchronize boot variables in the NV-RAM, the CMOS, and the SPI flash memory device to virtual drive local store365and/or virtual drive global store395during the boot process. The synchronization may be performed based on a default or a pre-defined configuration setting which may be set by an administrator. In one embodiment, the synchronization of the recovery data and/or the boot variables may be performed based on a triggering event at pre-boot or during the boot process, at runtime or at shutdown. For example, the synchronization process may be initiated by firmware synchronization module330once it determines that access to a network is available during the boot process. Firmware synchronization module330may be configured to detect the update to the firmware and synchronize the updated firmware between virtual drive global store395and virtual drive local store365, wherein the firmware version in virtual drive global store395will be the same firmware version in virtual drive local store365. Firmware synchronization module330may be configured to determine an ideal time to perform the synchronization. For example, firmware synchronization module330when information handling system305is idle or below a certain performance or utilization threshold for a certain length of time. The runtime ACPI network procedures utilize the HVNDA protocol to synchronize the recovery data.

In another embodiment, the configuration setting may be set to synchronize the recovery material at certain intervals, such as daily or weekly. In yet another embodiment, the triggering event may be an update that includes as an addition, deletion, and/or a change to the recovery data stored in either virtual drive local store365or virtual drive global store395. The synchronization process may synchronize the recovery data from the store where the triggering event was detected to the other store. For example, if the update to the recovery data is detected at virtual drive global store395, firmware synchronization module330may synchronize the recovery material from virtual drive global store395to virtual drive local store365.

Key access module335may be configured to add, update and/or retrieve a security object that may be used by BIOS/UEFI315, protected access module320, firmware management module325, EC345, EC proxy network module355, and virtual drive access module350in authenticating access to virtual drive397and/or SPI flash memory375. For example, the security object may be used to establish trust between virtual drive access module350and virtual drive397. The security object may also be used to establish trust between one or more components of information handling system305such as BIOS/UEFI315, protected access module320, EC345, EC proxy network module355and SPI flash memory375. The security object may be retrieved from a key store at SPI flash memory375. The key store may be similar to key store282ofFIG.2. Key access module335may determine the security object based on a GUID, an object identifier, etc. associated with the method, the service and/or the device such as a storage resource360or virtual drive297or its partition. Key access module335may create a secure domain using the security object to perform a method, service, or access the device synchronize, update, recover, rollback, etc. a firmware, a recovery data and/or information handling system305. Key access module335may create the secure domain with virtual drive access module350, EC proxy network module355, and/or EC345.

EC345, which is similar to BMC190ofFIG.1, may be configured to initiate a recovery process information handling system305during an exception such as a boot failure. For example, EC345may re-initialize the network stack allowing virtual drive access module350to access and mount virtual drive397and continue the boot process and/or perform recovery of information handling system305. EC proxy network module355includes functions and features to access SPI flash memory375during the exception as directed by EC345. The functions and features may be implemented using UNDI, Simple Network Protocol (SNP), or Managed Network Protocol (MNP).

Network firmware area385may include proxy network profiles associated with information handling system305. The network profiles include security and network settings. In addition, network firmware area385may include network drives, firmware, proxy network details, and/or configuration settings that may be used to initialize a network interface in the absence of operating system network drivers. For example, network firmware area385may include an UNDI driver. Network firmware area385may also include firmware to instantiate virtual drive access module350. In addition, network firmware area385may also include recovery drivers which may be used during failover and/or recovery of information handling system305.

Firmware area380may include firmware, drivers, software, etc. for booting information handling system305. The firmware may include system BIOS, NIC firmware, USB firmware, etc. Each of the contents of firmware area380and network firmware area385may be associated with a GUID. On the other hand, each of the component of information handling system305and virtual drive397, virtual drive local store365, and/or virtual drive global store395may be associated with a corresponding object identifier. EC345and/or EC proxy network module355may retrieve the content of firmware area380and network firmware area385network profiles based on the object identifier and/or the GUID.

During the boot process, the recovery drivers may be loaded to EC345storage and/or the memory cache associated EC345from network firmware area385. EC345may also synchronize network firmware area385with virtual drive397such that when the recovery driver is updated at network firmware area385, an event is generated that triggers EC345to load the updated recovery driver to its storage and/or memory cache. If a failover happens, EC345pushes the recovery drivers to EC proxy network module355. In addition, EC345may use EC proxy network module355to retrieve the proxy network profiles from network firmware area385and initialize the network interface which allows information handling system305to connect to network390and virtual drive397. EC345may also use EC proxy network module355to retrieve and load firmware associated with virtual drive access module350. After loading the firmware, EC proxy network module355may initialize virtual drive access module350. EC345or EC proxy network module355may transmit the network profiles to virtual drive access module350. EC345may also retrieve other data such as firmware, software, boot variables, etc. associated with information handling system305from firmware area380.

Virtual drive access module350may be configured to mount and access virtual drive397using the network profiles and firmware received from EC345and/or EC proxy network module355. Virtual drive access module350may also be configured to re-initialize a network stack based on the network profiles, firmware, and configuration settings. Once the network stack is re-initialized, virtual drive access module350can access the virtual drive global store395. The virtual drive access module350can also access virtual drive local store365. The boot process can then use the recovery data in virtual drive global store395and virtual drive local store365to successfully boot or recover information handling system205.

FIG.4illustrates a system400for mounting a virtual drive during a boot failure of an information handling system. System400is a more detailed illustration of re-initializing a host network stack utilizing network proxy profiles and configuration settings. This allows a UEFI system operation to potentially use the services of a UEFI runtime driver such as an UNDI driver to provide basic network connectivity in boot scenarios where the operating driver for the network interface controller is not available such as during a boot failure. The basic network connectivity allows mounting a remote network store associated with a virtual drive to continue the boot process or for recovery. System400may also include loading firmware associated with HVNDA protocol and initialize a virtual drive access module providing access to the virtual drive. System400includes information handling system405, which is similar to information handling system305ofFIG.3, virtual drive425which is similar to virtual drive397ofFIG.3, and a network470which is similar to network390ofFIG.3. Information handling system405includes a processor410, an exception handler415, an EC proxy network module420, an EC network proxy455, a virtual drive local store435and a network interface460. One of skill in the art will appreciate, that information handling system405may have a BMC proxy network module instead of EC proxy network module420and BMC network proxy instead of EC network proxy455.

When a failure occurs, such as a boot failure, processor410may trigger hardware or software exception. Exception handler415may be configured to direct the operation of information handling system405in the event of the exception. The exception may be associated with a particular argument that directs exception handler415as to how to proceed in handling the exception, such as to start a failover and/or recovery process if recovery is possible or to halt processing of the information handling system405if recovery is not possible. In a particular embodiment, exception handler415may be configured to direct EC proxy network module420to initialize EC network proxy455, which includes sending an L2 packet440to processor410. L2 packet440includes instructions to initialize the Mbox interface.

Once the Mbox interface is initialized, a communication channel480is established which is used by processor410to send an Mbox command445to retrieve network proxy configuration450. Network proxy configuration450may be used by processor410to initialize network interface460and establish a communication channel490. Processor410may also establish a communication channel485. Communication channel490allows processor410to talk to virtual drive global store475via network470. Processor410may also leverage EC network proxy455to establish a communication channel485and communicate with virtual drive local store435included in storage resource430. EC network proxy455may also include recovery drivers which may be used at the failover and/or the recovery.

Network interface460which similar to network interface180ofFIG.1may include any suitable system, apparatus, or device operable to serve as an interface between information handling system405, network470, other information handling systems or network. Network interface460may enable information handling system405to communicate using any suitable transmission protocol and/or standard such as Peripheral Component Interconnect Express (PCIe). As network interface460which includes a NIC provides connectivity to network470this enables access to virtual drive425or virtual drive global store475.

The current disclosure increases the level of data protection and access control of the recovery data while increasing its availability during boot recovery or at runtime by leveraging a virtual drive that is distributed between a local store and a cloud-based store. The recovery data is synchronized between the local store and the cloud-based store which allows the recovery data in either store to include the latest information. Because the recovery is specific to the platform, the information handling system is not just restored to the default factory settings but to the latest platform settings by providing a “hot” standby for recovery data and/or recovery image. The current disclosure may be used to recover firmware, recovery data, and/or the information handling system. For example, if the boot process of the information handling system fails, the information handling system can recover the boot failure and continue with the boot process. In addition, the information handling system is restored to its last known good state by automatically connecting to the virtual firmware store.

I/O requests to access virtual drive425may be passed to a virtual network access module that controls access to the virtual drive via protected access module and secure access module. For example, a host virtual network access module may use a public/private key exchange mechanism to access virtual drive425. The private key may be “owned” by a firmware of the BIOS/UEFI with the corresponding public key passed to virtual drive425by processor410or the virtual drive access module as a variable in the I/O request. Another private key may be “owned” by information handling system410, processor410, and/or the virtual drive access module with its corresponding public key passed as another variable in the I/O request as well.

FIG.5shows a method500for access to recovery data stored in the virtual drive at runtime. Method500may be performed by one or more components ofFIG.2. Method500typically starts at block505where the method receives and I/O request associated with a virtual drive. The I/O request may be issued by one of operating system based methods such as WMI, ASL, system management mode (SMM), dynamically provisioned access control infrastructure (DACI), etc. In addition to not having access to the virtual drive, the issuer of the I/O request does not know the existence nor how to access the virtual drive because the virtual drive namespace is hidden from the issuer of the I/O request.

The method proceeds to block510, wherein the method determines object identifiers and/or GUIDs associated with the I/O request and one or more components of information handling system, and/or the virtual drive. For example, the method may determine the GUIDs of the partitions associated with the virtual drive. The method proceeds to block515where the method may also determine and retrieve authentication information which includes one or more security objects associated with the I/O request and/or the virtual drive. The security objects may be retrieved from non-volatile memory storage device such as a SPI flash memory device.

The method proceeds to block520where the method performs the validation and/or authentication process such as the key exchange mechanism with the virtual drive. The authentication process may be a mutual authentication between the virtual drive and the information handling system. The security object may be used to authenticate the I/O request, the virtual drive, the information handling system or a component thereof such virtual drive access module, the BIOS/UEFI, etc. A platform key may be used in the key exchange mechanism to determine if the information handling system is trusted and/or authorized by the virtual drive to perform the I/O request. The information handling system may use a public key to determine if it is communication with the correct virtual drive. The method proceeds to decision block525where the method determines if the authentication is successful. If the authentication is successful, then the “YES” branch is taken and the method proceeds to block530. If the authentication is not successful, then the “NO” branch is taken and the method ends.

At block530, the method unlocks the virtual drive. The method may use a particular security object to unlock the virtual drive. After unlocking the virtual drive, the method proceeds to block535where the method mounts the virtual drive which allows access to the virtual drive. The method proceeds to block540where the method executes the I/O request. After execution of the I/O request, the method proceeds to block545where the method locks the virtual drive. The method may transmit a result to the issuer of the I/O request. Afterwards, the method ends.

FIG.6illustrates a method600for establishing connection to a virtual drive during an exception such as a boot failure. Method600may be performed by one or more components ofFIG.3andFIG.4. Method600re-initializes or initializes the network interface using the EC network proxy configuration settings. Once the network interface is initialized, method600connects to the virtual drive which provides a local drive access during failure scenarios. The method may utilize a pre-boot UNDI CDB which is in a raw network format to mount and secure communication to the remote storage device that hosts the virtual drive when the host network driver is not available such as during boot failure. The platform key may be used along with a firmware's GUID such as the GUID of the BIOS/UEFI to generate a digital signature that may be used to sign the UNDI request. The CDB included in each UNDI request provide services that allow the UNDI to access a network interface, network, and the remote storage device subsequent to a successful authentication. For example, the CDB may include a one byte operation code followed by command specific parameters such as the address of the remote storage device, a service action which contains a code value identifying a function to be performed at the virtual drive, and a length of the data to be transferred usually in number of blocks.

Method600typically starts at block605where a software or hardware failure also referred to as an exception is detected during the boot process. The method proceeds to block610where an exception handler is triggered by the exception. The exception handler is configured to load the EC proxy network module. The method proceeds to decision block615where the method determines whether the Mbox is initialized. If the Mbox is initialized, then the “YES” branch is taken and the method proceeds to block625. If the Mbox is not initialized, then the “NO” branch is taken and the method proceeds to block620. At block620, the method that is the EC proxy network module transmits an L2 packet to the host processor. The L2 packet may include instructions for the host processor to retrieve the EC network proxy configuration and/or initialize the Mbox. After the Mbox is initialized, at block625, the host processor transmits an Mbox command to retrieve the EC network proxy configuration details. The Mbox command is transmitted in raw L2 packet format. The EC network proxy details may be retrieved from a SPI flash associated with the EC. The EC network proxy details may include configurations of the information handling system and the virtual drive including username, password, and public keys.

The method proceeds to block630where the method, that is the EC, initializes the host network services using the retrieved EC network proxy configuration details. Once the host network service is initialized, the method, that is the host processor, at block635mounts the virtual drive. The host processor may mount the virtual drive as directed by the EC. In one embodiment, the EC may send raw L2 packets to the host processor to mount the virtual drive. The host processor may translate the L2 packets into a SCSI command and send the SCSI command to the remote storage device that hosts a remote drive associated with the virtual drive and treats the virtual drive as a locally attached storage. The host processor may also send SCSI commands to a local storage device that hosts the local drive associated with the virtual drive. The host processor may send the SCSI commands in UNDI CDB format.

The method proceeds to block640where the information handling system recovers from the exception and the boot process continues from the virtual drive. Thus, the host can perform boot recovery even during a local storage corruption without a reboot or download of an operating system image. The mounted firmware drive has a filesystem like interface wherein the firmware modules. The filesystem like interface also supports a catalogue and Firmware Over-The-Air (FOTA). In another embodiment, if the remote drive cannot be mounted and the local drive is not corrupted, the boot process proceeds from the local drive.

AlthoughFIG.5, andFIG.6show example blocks of method500and method600in some implementation, method500and method600may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted inFIG.5andFIG.6. Additionally, or alternatively, two or more of the blocks of method500and method600may be performed in parallel. For example, block530and block535of method500may be performed in parallel.