Patent Application
20240004629
This disclosure generally relates to information handling systems, and more particularly relates to providing computer software updates via one or more decentralized blockchain networks.
As the value and use of information continues to increase, individuals and businesses seek additional ways to process and store information. One option is an information handling system. An information handling system generally processes, compiles, stores, and/or communicates information or data for business, personal, or other purposes. Because technology and information handling needs and requirements may vary between different applications, information handling systems may also vary regarding what information is handled, how the information is handled, how much information is processed, stored, or communicated, and how quickly and efficiently the information may be processed, stored, or communicated. The variations in information handling systems allow for information handling systems to be general or configured for a specific user or specific use such as financial transaction processing, reservations, enterprise data storage, or global communications. In addition, information handling systems may include a variety of hardware and software resources configured to process, store, and communicate information and may include one or more computer systems, data storage systems, and networking systems.
Client machines, whether consumer or Enterprise, are notified of software updates using a decentralized, peer-to-peer blockchain infrastructure. Any software update is written to a blockchain's block of data and distributed to blockchain nodes associated with a blockchain network. A smart contract, executed by any of the blockchain nodes, causes the corresponding blockchain node to notify specific client machines of the block of data recording the software update. The client machines contact the blockchain node and request the software update written to the block of data. The blockchain node retrieves and sends the software update written to the block of data. When the client machines receive the software update from the blockchain node, the client machines apply or install the software update to improve their computer functioning.
It will be appreciated that for simplicity and clarity of illustration, elements illustrated in the Figures have not necessarily been drawn to scale. For example, the dimensions of some of the elements are exaggerated relative to other elements. Embodiments incorporating teachings of the present disclosure are shown and described with respect to the drawings presented herein, in which:
The use of the same reference symbols in different drawings indicates similar or identical items.
The following description in combination with the Figures is provided to assist in understanding the teachings disclosed herein. The following discussion will focus on specific implementations and embodiments of the teachings. This focus is provided to assist in describing the teachings, and should not be interpreted as a limitation on the scope or applicability of the teachings.
Chipset 110 represents an integrated circuit or group of integrated circuits that manages data flow between processors 102 and 104 and the other elements of information handling system 100. In a particular embodiment, chipset 110 represents a pair of integrated circuits, such as a north bridge component and a south bridge component. In another embodiment, some or all of the functions and features of chipset 110 are integrated with one or more of processors 102 and 104. Memory 120 is connected to chipset 110 via a memory interface 122. An example of memory interface 122 includes a Double Data Rate (DDR) memory channel, and memory 120 represents one or more DDR Dual In-Line Memory Modules (DIMMs). In a particular embodiment, memory interface 122 represents two or more DDR channels. In another embodiment, one or more of processors 102 and 104 include memory interface 122 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. Memory 120 may 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 adapter 130 is connected to chipset 110 via a graphics interface 132, and provides a video display output 136 to a video display 134. An example of a graphics interface 132 includes a peripheral component interconnect-express interface (PCIe) and graphics adapter 130 can 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 adapter 130 is provided on a system printed circuit board (PCB). Video display output 136 can include a digital video interface (DVI), a high definition multimedia interface (HDMI), DisplayPort interface, or the like. Video display 134 can include a monitor, a smart television, an embedded display such as a laptop computer display, or the like.
NV-RAM 140, disk controller 150, and I/O interface 170 are connected to chipset 110 via I/O channel 112. An example of I/O channel 112 includes one or more point-to-point PCIe links between chipset 110 and each of NV-RAM 140, disk controller 150, and I/O interface 170. Chipset 110 can 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 (SPI), a Universal Serial Bus (USB), another interface, or a combination thereof. NV-RAM 140 includes BIOS/EFI module 142 that stores machine-executable code (BIOS/EFI code) that operates to detect the resources of information handling system 100, 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/EFI module 142 will be further described below.
Disk controller 150 includes a disk interface 152 that connects the disc controller 150 to HDD 154, to ODD 156, and to disk emulator 160. Disk interface 152 may include 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 emulator 160 permits a solid-state drive (SSD) 164 to be connected to information handling system 100 via an external interface 162. An example of external interface 162 includes a USB interface, an IEEE 1394 (Firewire) interface, a proprietary interface, or a combination thereof. Alternatively, SSD 164 can be disposed within information handling system 100.
I/O interface 170 includes a peripheral interface 172 that connects I/O interface 170 to add-on resource 174, to TPM 176, and to network interface device 180. Peripheral interface 172 can be the same type of interface as I/O channel 112, or can be a different type of interface. As such, I/O interface 170 extends the capacity of I/O channel 112 when peripheral interface 172 and the I/O channel are of the same type, and the I/O interface translates information from a format suitable to the I/O channel to a format suitable to the peripheral channel 172 when they are of a different type. Add-on resource 174 can include a sound card, data storage system, an additional graphics interface, another add-on resource, or a combination thereof. Add-on resource 174 can be on a main circuit board, a separate circuit board or an add-in card disposed within information handling system 100, a device that is external to the information handling system, or a combination thereof.
Network interface device 180 represents a network communication device disposed within information handling system 100, on a main circuit board of the information handling system, integrated onto another element such as chipset 110, in another suitable location, or a combination thereof. Network interface device 180 includes a network channel 182 that provides an interface to devices that are external to information handling system 100. In a particular embodiment, network channel is of a different type than peripheral channel 172 and network interface device 180 translates information from a format suitable to the peripheral channel to a format suitable to external devices. In a particular embodiment, network interface device 180 includes a host bus adapter (HBA), a host channel adapter, a network interface card (NIC), or other hardware circuit that can connect the information handling system to a network. An example of network channel 182 includes an InfiniBand channel, a fiber channel, a gigabit Ethernet channel, a proprietary channel architecture, or a combination thereof. Network channel 182 can 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.
The information handling system 100 may include a baseboard management controller (BMC). The BMC is connected to multiple elements of information handling system 100 via one or more management interface to provide out of band monitoring, maintenance, and control of the elements of the information handling system. As such, BMC represents a processing device different from processors 102 and 104, which provides various management functions for information handling system 100. In an embodiment, BMC may be responsible for granting access to a remote management system that may establish control of the elements to implement power management, cooling management, storage management, and the like. The BMC may also grant access to an external device. In this case, the BMC may include transceiver circuitry to establish wireless communications with the external device such as a mobile device. The transceiver circuitry may operate on 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, another cellular based interface, or a combination thereof. A mobile device may include Ultrabook, a tablet computer, a netbook, a notebook computer, a laptop computer, mobile telephone, a cellular telephone, a smartphone, a personal digital assistant, a multimedia playback device, a digital music player, a digital video player, a navigational device, a digital camera, and the like.
The term BMC may be 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 embedded controllers included at the blades of the blade server can be referred to as blade management controllers. Out-of-band communication interfaces between BMC and elements of the information handling system may be provided by management interface that may 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 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 system 100, that is apart from the execution of code by processors 102 and 104 and procedures that are implemented on the information handling system in response to the executed code.
In an embodiment, the BMC implements an integrated remote access controller (iDRAC) that operates to monitor and maintain system firmware, such as code stored in BIOS/EFI module 142, option ROMs for graphics interface 130, disk controller 150, add-on resource 174, network interface 180, or other elements of information handling system 100, as needed or desired. In particular, BMC includes a network interface that can be connected to a remote management system to receive firmware updates, as needed or desired. Here BMC receives 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.
BMC utilizes 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 BMC, an interface defined by the Distributed Management Taskforce (DMTF) (such as Web Services Management (WS-MAN) interface, a Management Component Transport Protocol (MCTP) or, Redfish interface), various vendor defined interfaces (such as Dell EMC Remote Access Controller Administrator (RACADM) utility, Dell EMC Open Manage Server Administrator (OMSS) utility, Dell EMC Open Manage Storage Services (OMSS) utility, Dell EMC Open Manage Deployment Toolkit (DTK) suite), representational state transfer (REST) web API, 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, BMC is included on a main circuit board (such as a baseboard, a motherboard, or any combination thereof) of information handling system 100, or is integrated into another element of the information handling system such as chipset 110, or another suitable element, as needed or desired. As such, BMC can be part of an integrated circuit or a chip set within information handling system 100. BMC may operate on a separate power plane from other resources in information handling system 100. Thus BMC can communicate with the remote management system via network interface or the BMC can communicate with the external mobile device using its own transceiver circuitry while the resources or elements of information handling system 100 are powered off or at least in low power mode. Here, information can be sent from the remote management system or external mobile device to BMC and 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 BMC, while information stored in the NV-RAM may be saved through a power-down/power-up cycle of the power plane for the BMC.
These hardware and software resources (e.g., drivers, BIOS, firmware, and software applications) often require software updates to resolve performance, operability, and/or compatibility issues. However, computer users, whether consumers or corporate enterprise customers, often fail to update their computers.
In a typical usage case, information handling system 100 represents an enterprise class processing system, such as may be found in a datacenter or other compute-intense processing environment. Here, there may be hundreds or thousands of other enterprise class processing systems in the datacenter. In such an environment, the information handling system may represent one of a wide variety of different types of equipment that perform the main processing tasks of the datacenter, such as modular blade servers, switching and routing equipment (network routers, top-of-rack switches, and the like), data storage equipment (storage servers, network attached storage, storage area networks, and the like), or other computing equipment that the datacenter uses to perform the processing tasks.
Errors may be difficult to diagnose and to debug. Pre-boot errors (such as hardware errors occurring during a power-on self-test operation) are conventionally detected by the BIOS 142. In order to diagnose and to debug these pre-boot hardware errors, a more complex software stack (such as an operating system or OS) is required. A large and memory-intensive operating system, in other words, must be executed to diagnose and to debug problem issues such as network connectivity, GPU errors, MKTME-based errors, VPN, RADIUS Authentication (MS-CHAP), and other hardware-based errors. The conventional BIOS 142 lacks capabilities to resolve pre-boot errors.
Remote diagnosis is also challenging. Remote OS install and OS recovery on a bare metal computer machine may be accomplished using cloud-based service support (such as Dell's BIOSConnect platform that allows BIOS to connect to an HTTP backend and load an image). A bare metal computer machine refers to a computer executing instructions stored or written to logic hardware without the intervening operating system. However, the inventors have realized that a bare metal computer machine launching BIOSConnect over a VPN network is difficult to repeatedly accomplish. The BIOS 142 must include a network software stack for network connectivity, which is complex and time consuming to develop.
Exemplary embodiments utilize the blockchain network 200 to deploy the software update 204. The software update 204 is written to the block 210 of data. When the block 210 of data is distributed across the blockchain network 200, each blockchain node 206 receives the software update 204 written to the block 210 of data. Because each blockchain node 206 stores an electronic copy of the block 210 of data, each blockchain node 206 also stores the software update 204 written to the block 210 of data. The blockchain network 200 has thus dispersed and distributed many copies (perhaps hundreds or even thousands) of the software update 204.
Programmatic actions may then be executed. Once the software update 204 is published to the blockchain 208, the block 210 of data and the software update 204 may be deployed to every blockchain node 206 and stored to its corresponding memory 120 (illustrated in
The blockchain network 200 thus deploys the software update 204. As
The client device 202 may also “pull” the software update 204. When the blockchain node 206 obtains the software update 204, the blockchain node 206 may send a software update notification 218 to the network address (e.g., Internet Protocol address) associated with the client device 202. The software update notification 218 may be routed via the blockchain network 200 and/or a communications network 220 (such as Internet). When the client device 202 receives the software update notification 218, the update software application 216 instructs the client device 202 to retrieve the software update 204. The client device 202, for example, may send a software update request 222 via the blockchain network 200 and/or the communications network 220 to the network address (e.g., Internet Protocol address) associated with the blockchain node 206. The software update request 222 may specify the appropriate API 214 for requesting the software update 204 written to the block 210 of data. The blockchain node 206, in response to receiving the software update request 222, reads/retrieves the software update 204 and generates a software update response 224 including or specifying the software update 204. The blockchain node 206 sends the software update response 224 (via the blockchain network 200 and/or the communications network 220) to the network address associated with the client device 202. When the client device 202 receives the software update response 224, the update software application 216 instructs the client device 202 to apply, download, and/or install the software update 204. The client device 202 is thus updated with the latest software version or configuration for best performance, user experience, security, operability, and any other factor.
Conventional update schemes are ineffective, costly, and prone to failure. As the reader likely understands, the information handling system 100 (such as the client device 202 and/or the blockchain node 206) may require software updates. These software updates (e.g., drivers, BIOS, firmware, and software applications), however, are conventionally based on a centralized model. That is, software updates are stored by one (1), or perhaps a few, networked servers. The conventional, centralized, network server downloads the software update to all clients. That is, conventional schemes utilize a “pull” or “poll” operation in which the client device 202 requests the software updates. If a software update is available, the centralized network server delivers the software update from one (1), or perhaps a few, fixed network locations. However, as the reader may know, many users fail to select scheduled “auto-updates” for their devices. Indeed, it is estimated that over 75% of users fail to enable the “auto-update” feature for software. Simply put, the “auto-update” feature is ineffective. Moreover, because the conventional centralized update scheme may serve hundreds, thousands, or even millions of clients, the centralized network server may be quickly overwhelmed by repeated update requests. The centralized network server bogs down in performance and may even incur a hardware failure. The conventional centralized scheme is also exceptionally expensive, as the software updates must be routed via multiple different Content Delivery Networks (“CDNs”). Each CDN charges fees per download packet traffic, and urgent delivery of critical software updates incurs added network routing costs. The conventional update schemes are ineffective, costly, and prone to failure.
Exemplary embodiments also greatly reduce costs. Because the blockchain nodes 206 are geographically dispersed as network end points, fewer Content Delivery Networks are required. That is, once approximate geographic and/or network locations associated with the client device 202 and the blockchain nodes 206 are known, exemplary embodiments may select the blockchain node 206 sharing the same Content Delivery Network and/or the same/similar geographic location. Should the client device 202 and the blockchain node 206 be accessible via a single, common communications network 220, for example, only a single network provider need be paid to route and deliver the software update 204. Multiple Content Delivery Networks may thus be avoided, especially when a single network provider and/or CDN can establish a communications routing path from a particular (closest) blockchain node 206 to the client device 202. Moreover, once approximate geographic and/or network locations associated with the client device 202 and the blockchain nodes 206 are known, exemplary embodiments may select which of the blockchain nodes 206 is best suited to provide the software update 204, in order to reduce the number of CDNs utilized, to utilize CDNs offering better/advantageous routing/delivery terms/costs, to reduce network packet traffic/delay/congestion in the blockchain network 200, or to achieve any other networking/performance goal.
Exemplary embodiments further improve computer functioning. The decentralized, peer-to-peer blockchain-based software update scheme (illustrated in
Exemplary embodiments further improve computer functioning. Many computer security vulnerabilities are exploited or attacked prior to an execution of an operating system (such as the well-known family of the MICROSOFT® WINDOWS® graphical operating systems). Conventional update schemes are thus conducted after the operating system boots/executes. Conventional update schemes may thus be too late to apply pre-OS fixes for security vulnerabilities from getting exploited. Exemplary embodiments, instead, may be implemented in an embedded, “light-weight” operating system installed by an OEM computer manufacturer. The embedded OS executes prior to a boot operation and may thus be updated prior to execution.
The smart contract 212 may be executable code that runs on the blockchain 208. The smart contract 212 has programming statements representing or specifying what, when, and how machines are notified of the software update 204. The smart contract 212 may also define the network location/resource from where the software update 204 is retrieved. Whatever the terms specified by the smart contract 212, the smart contract 212 may automatically execute once predetermined logical rules, conditions, or code is satisfied. The smart contract 212 may thus be expressed in a programming language. Smart contracts are generally known, so this disclosure will not dwell on the known aspects.
As
Cryptographic proofs may be recorded. When the blockchain node 206 sends the software update 204 to any client machine (such as the consumer client device 202), the blockchain node 206 may generate a cryptographic proof. The cryptographic proof proves that the software update was sent to the client machine. As a simple example, the blockchain node 206 may generate the cryptographic proof by concatenating and hashing a binary combination of the software update 204 with a unique identifier associated with the client device 202. The blockchain node 206 may then write/record the cryptographic proof to the blockchain 208. Similarly, the blockchain node 206 may generate a cryptographic proof that the software update 204 was sent to the Enterprise server node 252 by concatenating and hashing a binary combination of the software update 204 with a unique identifier associated with the Enterprise server node 252. The blockchain node 206 may then write/record the cryptographic proof to the blockchain 208. The Enterprise server node 252 may generate a cryptographic proof that the software update 204 was sent to the Enterprise commercial client device 250 by concatenating and hashing a binary combination of the software update 204 with a unique identifier associated with the Enterprise commercial client device 250. The Enterprise server node 252 may then write/record the cryptographic proof to the Enterprise blockchain network 254.
Although only a few exemplary embodiments have been described in detail herein, those skilled in the art will readily appreciate that many modifications are possible in the exemplary embodiments without materially departing from the novel teachings and advantages of the embodiments of the present disclosure. Accordingly, all such modifications are intended to be included within the scope of the embodiments of the present disclosure as defined in the following claims. In the claims, means-plus-function clauses are intended to cover the structures described herein as performing the recited function and not only structural equivalents.
Devices, modules, resources, or programs that are in communication with one another need not be in continuous communication with each other, unless expressly specified otherwise. In addition, devices, modules, resources, or programs that are in communication with one another can communicate directly or indirectly through one or more intermediaries.
The above-disclosed subject matter is to be considered illustrative, and not restrictive, and the appended claims are intended to cover any and all such modifications, enhancements, and other embodiments that fall within the scope of the present invention. Thus, to the maximum extent allowed by law, the scope of the present invention is to be determined by the broadest permissible interpretation of the following claims and their equivalents, and shall not be restricted or limited by the foregoing detailed description.
