Package-based remote firmware update

A method for updating firmware includes receiving, at a device, an updated installation package. The updated installation package includes an updated version of an installation package, which belongs to a set of installation packages stored on the device for installation of firmware on the device. The method further includes updating the set of installation packages by replacing the installation package with the updated installation package. The method further includes installing updated firmware in volatile memory of the device based on the updated set of installation packages. The method further includes storing an image of the updated firmware in nonvolatile storage of the device. Additionally, the method includes, during a boot process, loading the image from the nonvolatile memory of the device onto the volatile memory of the device, to enable running the updated firmware from the volatile memory, and verifying the authenticity of the updated firmware.

TECHNICAL FIELD

Various implementations described herein relate to firmware updates and, more particularly, to firmware updates that are package-based such that firmware installation is divided into numerous combinable installation packages and, further, such that authenticity of the firmware is optionally validatable.

BACKGROUND

Firmware is a type of software that provides low-level control of a hardware device. Typically, to interact with the hardware device, a software application will communicate with the firmware, which will interact with the hardware device as needed to enable the software application to utilize the hardware device. A device's firmware may need to be updated for various reasons, such as for the installation of new features or for fixing a bug. Updating firmware of a device can be performed in various ways. For example, updated firmware can be received via a cable, such as a universal serial bus (USB) cable or an Ethernet cable. For another example, in the case of a remote firmware update, the firmware can be received wirelessly, such as over wireless fidelity (WiFi).

SUMMARY

In one implementation, a method for updating firmware includes receiving, at a device, an updated installation package. The updated installation package includes an updated version of an installation package, which belongs to a set of installation packages stored on the device for installation of firmware on the device. The method further includes updating the set of installation packages by replacing, in the set of installation packages stored on the device, the installation package with the updated installation package. The method further includes installing updated firmware in volatile memory of the device based on the updated set of installation packages including the updated installation package. The method further includes storing an image of the updated firmware in nonvolatile storage of the device. Additionally, the method includes, during a boot process, loading the image of the updated firmware from the nonvolatile memory of the device onto the volatile memory of the device, to enable running the updated firmware from the volatile memory, and attempting to verify the authenticity of the updated firmware.

In another implementation, a system includes a server, which includes a processor and a memory. The processor is configured to execute computer-readable instructions, and the memory is configured to store the computer-readable instructions that, when executed by the processor, cause the processor to perform operations. Such operations include identifying an updated installation package and inserting the updated installation package into a set of installation packages to replace an existing version of the updated installation package. The operations further include installing the set of installation packages, including the updated installation package, to generate a reference firmware. The operations further include generating a signed validation hash based on the reference firmware and providing the updated installation package and the signed validation hash to one or more nodes remote from the server. The one or more nodes utilize the updated installation package to update the one or more nodes.

In yet another implementation, a method for updating a filesystem includes receiving, at a device, an updated installation package. The updated installation package includes an updated version of an installation package, where the installation package belongs to a set of installation packages stored on the device for installation of a filesystem on the device. The method further includes receiving a signed validation hash associated with the filesystem. The method further includes updating the set of installation packages by replacing, in the set of installation packages stored on the device, the installation package with the updated installation package. The method further includes installing an updated filesystem in volatile memory of the device based on the updated set of installation packages, including the updated installation package, and validating the updated filesystem by comparing a hash of the updated filesystem to the signed validation hash. The method further includes storing an image of the updated filesystem in nonvolatile storage of the device. Additionally, the method includes, during a boot of the device, loading the image of the updated filesystem from the nonvolatile memory of the device onto the volatile memory of the device, to enable running the updated filesystem from the volatile memory, and attempting to revalidate the updated filesystem by comparing an updated hash of the updated filesystem to the signed validation hash.

These illustrative aspects and features are mentioned not to limit or define the presently described subject matter, but to provide examples to aid understanding of the concepts described in this application. Other aspects, advantages, and features of the presently described subject matter will become apparent after review of the entire application.

DETAILED DESCRIPTION

Because firmware typically has low-level access to hardware, firmware is a likely target for attackers seeking to misuse a device. A filesystem, which can be implemented as firmware, controls how data is stored on a storage device and retrieved from the storage device. An authentic and uncorrupted filesystem can prevent tampering on the entire device. To guard against malicious attacks, filesystems are often signed for validation purposes. Typically, a filesystem image (i.e., an image of a filesystem) is generated and signed remotely, and the entire signed filesystem image is downloaded wirelessly to a device for a firmware update. Based on the signature, the device can ensure that the filesystem is authentic and uncompromised and can thus utilize the filesystem as is.

However, a signed image of a filesystem can be a large amount of data, and thus, transmitting a signed filesystem image from a remote server to a device requiring an update can be expensive in terms of time and network utilization. If a network over which a filesystem image, or other firmware, is being transmitted is lossy or slow, the transmission can be slow or prone to errors. Further, in a network with limited bandwidth, the transmission can utilize too much bandwidth, which can cause other transmissions over the network to be slow or to fail. As such, it is desirable to reduce the amount of data required to update a filesystem or other firmware, so as to more efficiently provide such updates and to reduce the bandwidth utilized by such updates.

An option for addressing this issue is to divide an installation file for the filesystem into a set of installation packages. In that case, when an update is required, the remote server transmits to the device only the installation packages that require updating to enable installation of an updated version of the filesystem or other firmware. The device can add such installation packages to those already stored on the device and use the resulting combination of installation packages to install the updated version of the filesystem or other firmware. However, this technique has the drawback of losing the ability to verify the authenticity of the filesystem as a whole, because a signed version of the filesystem image, as updated, is not provided for each update.

Another option is to sign each installation package such that each installation package is verifiable, leading to a resulting filesystem that can be presumed to be valid (i.e., authentic and thus uncompromised). However, this technique comes with a significant drawback for a device that runs the filesystem from volatile memory; for instance, the filesystem may be random-access memory (RAM)-based. A memory-based filesystem (e.g., RAM-based) might be used for various reasons. In some cases, for instance, a memory-based filesystem can be multiple times faster with respect to read and write performance than a filesystem based in nonvolatile memory. Because volatile memory does not retain data when power is lost, in the case of such a device, each reboot of the device results in the filesystem being erased. Thus, at each reboot, the installation packages are revalidated, and the filesystem is reinstalled. Installation typically requires decompression of the installation files as well as copying data into place in the volatile memory, and those operations are performed in addition to the act of validating each installation package prior to or during the installation itself.

In some cases, validating installation packages and reinstalling the filesystem can take a significant period of time (e.g., minutes), during which the device is unavailable. For instance, suppose the device is a utility meter configured to measure a resource for billing purposes. If the utility meter requires a reboot after being serviced or for some other reason, the filesystem would need to be reinstalled during the boot process, during which time no resource measurement could take place for a span of minutes, and a service provider thus might be unable to bill accurately for usage during that time. For another example, during the boot process, a communication relay device of the utility meter would be unable to send or receive data for a span of minutes, which could cause a loss of data being transmitted. Thus, it would be desirable to reduce the boot time of the device (e.g., the utility meter) by avoiding installing the filesystem during the boot process.

According to some implementations described in this disclosure, a provider server tasked with updating firmware on one or more nodes maintains a set of installation packages corresponding to the current version of the firmware, such as a filesystem on the nodes. To provide an update to the firmware, the provider server identifies an updated installation package. The updated installation package is an updated version of an old (e.g., obsolete or superseded) installation package, also referred to herein as a current installation package, that is currently included in the set of installation packages. The provider server updates the set of installation packages by replacing the old installation package with the updated installation package, such that the updated set of installation packages now corresponds to an updated version of the firmware. The provider server generates a reference firmware, which may be an image of the updated version of the firmware. The provider server generates a signed validation hash based on the reference firmware and transmits the updated installation packages and the signed validation hash to each node to be updated. A node receives the updated installation package and the signed validation hash. In a local set of installation packages, which is the node's copy of the set of installation packages, the node replaces the old installation package with the updated installation package and installs the updated version of firmware based on the set of installation packages as updated. The node validates (i.e., verifies the authenticity of) the firmware by hashing the updated version and comparing the resulting hash to the signed validation hash. The node saves an image of the updated firmware in nonvolatile storage such that the image will survive powering down, such as in the case of a boot or reboot of the node. Further, upon booting (e.g., rebooting), rather than reinstall the updated firmware, the device copies the image of the firmware to the volatile memory where the firmware was installed. Again, the node validates the updated firmware by hashing the updated firmware and comparing the result to the signed validation hash.

Implementations described herein have advantages over existing techniques of updating firmware, particularly in the case of updating a filesystem configured to run from volatile memory. For instance, implementations described herein enable firmware to be updated as a result of transmitting an updated installation package, rather than transmitting an entire filesystem image. Thus, a remote firmware update requires reduced bandwidth given that an updated installation package is likely to be much smaller than a filesystem image. Further, implementations described herein enable firmware to be validated based on a reference image, such as reference firmware that is stored remotely, that is known to be authentic and uncompromised. As a result, even when firmware runs from volatile memory, the firmware need not be reinstalled upon a boot of the node because a signed validation hash or other form of verification data is provided based on the reference firmware. The device can thus create the firmware only a single time, such that booting the node requires revalidation but not reinstallation, and validation of firmware is typically much faster than reinstallation. Thus, some implementations enable efficient installation that reduces network utilization while also keeping boot time relatively low.

FIG.1is a diagram of an update system100for updating firmware installed on one or more nodes105, according to some implementations described herein. As shown inFIG.1, the update system100is integrated into a provider server110and is further integrated into one or more nodes105located remotely from the provider server110. In some implementations, the provider server110is in communication with a node105either directly or indirectly, such as via wireless communication such as wireless fidelity (WiFi) or Bluetooth, via a wired connection, or via a combination of networks that may include wired networks, wireless networks, or both. For instance, the wireless communication may be via radio over a wireless mesh network, in which case one or both of the provider server110and the nodes105include a respective radio. In one implementation, to update the firmware on a node105, the provider server110provides a firmware update package120to a firmware update server130, where the firmware update server130includes a radio, which is connected to a wireless mesh network of which the node105is a part. The node105thus downloads the firmware update package120from the firmware update server130over the wireless mesh network, for instance, using radio communication. In another implementation, however, the node105downloads the firmware update package120from the firmware update server130using some other communication technique, such as WiFi, Bluetooth, or a wired connection. It will be understood that the firmware update server130may be connected to the node105and may thus communicate with the node105through one or more of various networks, which may be wired, wireless, or a combination of both.

Each of the provider server110, the nodes105, and the firmware update server130may be implemented as hardware, software, or a combination of hardware and software. In one implementation, for instance, each node105is a computing device, such as a utility meter, and the provider server110is implemented as one or more computing devices remote from the nodes105or is a server application running on a computing device remote from the nodes105. Analogously, the firmware update server130may be one or more computing devices or a server application running on one or more computing devices. In some implementations, the provider server110and the firmware update server130run on a common computing device or set of computing devices and, thus, need not be distinct devices; alternatively, however, the provider server110and the firmware update server130may be implemented as distinct components. For instance, the firmware update server130may provide cloud services of receiving firmware updated packages120from one or more provider servers110and of transmitting firmware update packages120to one or more nodes105.

In some implementations, the provider server110may be configured to generate or otherwise provide firmware update packages120corresponding to various versions and types of firmware. Thus, it will be understood that techniques described herein for providing a firmware update package120can be performed by the provider server110for various different firmware140. In one implementation, however, the provider server110provides firmware update packages120for a certain type of node105(e.g., utility meters), for a certain type of firmware140(e.g., filesystems for use by certain utility meters), or for a certain manufacturer of firmware140. For instance, the provider server110may be owned or managed by a manufacturer or service provider, and thus, firmware update packages120generated by the provider server110may be configured to provide firmware updates from that manufacturer or service provider. Further, in some implementations, the firmware update server130maintains firmware update packages120received from various provider servers110and, thus, for instance, from various manufacturers or service providers. Thus, the provider server110may generate firmware update packages120for certain firmware140, while the firmware update server130may deliver such firmware update packages120received from various provider servers110.

In the example ofFIG.1, only a single node105is shown. However, it will be understood that the single node105is provided for illustrative purposes only and that multiple nodes105may be configured to update their respective firmware140through the update system100. For instance, multiple nodes105may each be configured to download firmware update packages120from the firmware update server130or directly from the provider server110. Further, it will be understood that the operations described herein as performed by a node105may be performed by each such node105according to some implementations.

As shown inFIG.1, some implementations of the provider server110maintain various data related to a current version of firmware140installed on the nodes105, or desired to be installed on the nodes105. For instance, the provider server110may maintain one or more of the following: a package set150, which is a set of installation packages155useable together to install the firmware140; a reference firmware145, which is an image of the firmware140; and verification data160. Specifically, an example of the provider server110maintains the package set150, the reference firmware145, and the verification data160. Generally, in some implementations, the installation packages155are combinable to install the firmware140; the reference firmware145is an image of the firmware140; and the verification data160is useable to verify the authenticity of the firmware140or an image of the firmware140, such as the reference firmware145.

In some implementations, the package set150includes two or more installation packages155combinable to install the firmware140. For instance, the package set150may be combinable to form a single, integrated installation package that is executable (e.g., expandable) to install the firmware140. In some implementations, the provider server110initially gained access to the package set150by generating the package set150(e.g., by generating one or more of the individual installation packages155). Additionally or alternatively, however, the provider server110received the package set150from a trusted source, such as from an administrator. Further additionally or alternatively, the provider server110received an integrated installation package and divided that integrated installation package into the package set150. Techniques exist in the art for dividing an integrated installation package into a package set150, and one or more of such techniques may be used in some implementations of the update system100.

In some implementations, the reference firmware145is an image of the firmware140maintained by the provider server110as a reference. For instance, the provider server110may utilize the package set150to the install the firmware140on the provider server110, thereby generating the reference firmware145. As such, the reference firmware145is presumed to be an authentic version of the firmware140.

The verification data160may be data useable to verify firmware140, including potentially a firmware image, or to verify the package set150, or both. In some implementations, the verification data160includes signed hashes, such as a set of hashes where the set as a whole is signed, or such as a set of hashes that individually signed. Each such hash may be a result of hashing an authentic version of the reference firmware145or of an installation package155. For instance, the verification data160may include a signed validation hash165, which may be a signed hash of the reference firmware145, and a respective signed package hash corresponding to each installation package155, where each such signed package hash is a signed hash of the corresponding installation package155.

In some implementations, the provider server110utilizes the reference firmware145to generate the verification data160. For instance, to generate a signed package hash, the provider server110may apply a hash function to a corresponding installation package155and then sign the resulting hash. Further, for instance, to generate the signed validation hash, the provider server110may hash the reference firmware145, such as by applying a hash function to the reference firmware145, and may sign the resulting hash to create the signed validation hash.

A node105may maintain its own local copy of various data related to the firmware140and, specifically, related to the version of the firmware140installed on the node105. For instance, the node105may maintain one or more of the following (e.g., each of the following): the package set150corresponding to the firmware140; a firmware image170, which is a copy of the firmware140installed on the node105; and verification data160useable to validate the firmware140or the package set150, or both. For instance, the node105may maintain in its nonvolatile storage180each of the package set150, the firmware image170, and the verification data160, such that these elements are retained in the nonvolatile storage180when the node105loses power. The nonvolatile storage180, also referred to herein as nonvolatile memory, may be a hard disk drive, a solid-state drive, NAND flash memory, read-only memory (ROM), or another storage device that retains stored data even when powered down. Generally, the package set150stored on the node105corresponds to the version of the firmware140currently in use by the node105, such that the package set150was used, or could have been used, to install that version of the firmware140. In one example, if a manufacturer or service provider installed an initial version of the firmware140on the node105, then that manufacturer or service provider may have also stored one or more of the package set150, the firmware image170, and the verification data160on the node105, specifically, in the nonvolatile storage180on the node105. Each time the firmware140is updated, as described herein, the node105may update this stored data, such as the package set150, the firmware image170, and the verification data160, to correspond to the firmware140as updated.

In some implementations, the node105installs the firmware140in volatile memory190of the node105. The volatile memory190can be, for instance, random-access memory (RAM) such that the firmware140is RAM-based. In that case, execution of the package set150causes the firmware140to be deployed in the volatile memory190, such that one or more of directories, environment variables, and executables for the firmware140are maintained in and accessed from the volatile memory190. In some implementations, the firmware140is a read-only filesystem such as SquashFS, but alternatively, the firmware140need not be a read-only filesystem and, further, need not be a filesystem at all. When the node105is rebooted, or when the node105otherwise loses power, the firmware140may be erased from the volatile memory190, due to the volatile memory190being unable to retain data when powered down. Additionally or alternatively, however, the firmware140may be installed in the nonvolatile storage180.

As illustrated inFIG.1, the provider server110identifies an updated installation package155, which provides an update to the firmware140. For instance, in one example, an integrated installation package is executable to install an updated version of the firmware140. That integrated installation package has been divided into an updated package set150, where the updated package set150is the same as the package set150(i.e., prior to the update) except that one or more individual installation packages155, including the updated installation package155, have changed. In the example shown inFIG.1, the updated installation package is an updated version of an old installation package155that is currently included in the package set150. Thus, by replacing the old installation package155with the updated installation package155, the package set150is updated and is now executable to install the updated version of the firmware140.

Thus, the provider server110may install the updated package set150to generate an updated reference firmware145, which is an updated image of the firmware140. Given the updated reference firmware145, the provider server110may generate an updated version of the verification data160, such as a signed validation hash165. The provider server110may transmit a firmware update package120to the firmware update server130for delivery to one or more nodes105, where the firmware update package120includes the updated installation package155and the verification data160. In some implementations, the verification data160included in the firmware update package120includes a signed validation hash165for validating the firmware140as well as a signed package hash corresponding to the updated installation package155being provided. If multiple installation packages155are being updated and thus provided in the firmware update package120, then the verification data160may include a respective signed package hash for each such updated installation package155.

In some implementations, a node105downloads the firmware update package120, which may include an updated installation package155and verification data160as described above. The node105may download the firmware update package120from the firmware update server130or, such as in an implementation where no distinct firmware update server130is used, directly from the provider server110. The node105may validate the updated installation package155by using the verification data160. Further, the node105may execute the package set150, as updated, to install an updated version of the firmware140, for instance, to install the updated version of the firmware140in the volatile memory190of the node105. The node105may use the verification data160to validate the firmware140and, specifically, in some implementations, may perform this validation prior to running the firmware140. To update its package set150stored locally, the node105may replace the old installation package155with the updated installation package155in its locally stored package set150in the nonvolatile storage180. Further, in the case of multiple updated installation packages155, for each updated installation packages155in the firmware update package120, the node may replace the respective old installation package155in the package set150with the updated installation package155.

In some implementations, the firmware140is installed in the volatile memory190. In that case, although the node105maintains a firmware image170in the nonvolatile storage180, that firmware image170is not executable in some implementations due to not being located in the installation location, such that, for instance, references in the firmware image170may not necessarily point to the resources such references are expected to point to, due to the firmware image170not being located where it was installed in the volatile memory190. When the node reboots, the firmware140is erased due to being in volatile memory190. Thus, after a reboot, the node105may copy the firmware image170to the volatile memory190and, specifically, for instance, to the storage location in volatile memory190in which the firmware140was installed. As such, the firmware140may be executable from its installation location again. However, the node105may use the verification data160to validate the firmware140prior to running the firmware140after a reboot or other loss of power.

It will be understood that, although this disclosure refers repeatedly to operations performed by the node105in the instance of a reboot, such operations may additionally or alternatively be performed in the case of a boot that is not a reboot. In other words, when the node105is powered on after having been powered off, such operations described herein may be performed, including, for instance, copying the firmware image170from the nonvolatile storage180to the volatile memory190and validating the firmware140.

FIG.2depicts a method200of generating a firmware update package120according to some implementations described herein. Specifically, the firmware update package120may include an updated installation package155and verification data160. It will be understood that the firmware update package120may include multiple updated installation packages155, each of which may be incorporated into the firmware update package120as described herein. In some implementations, this method200or similar is performed by the provider server110to provide the firmware update package120to one or more nodes105to enable the nodes105to update their respective versions of firmware140. It will be understood that the ordering of operations illustrated inFIG.2and described herein is for illustrative purposes only and, further, that the blocks ofFIG.2may be reordered, one or more blocks may be deleted, or additional blocks may be added.

As shown inFIG.2, at block205, the provider server110identifies an updated installation package155for updating firmware140. In one example, the provider server110generates the updated installation package155by dividing an integrated installation package for an updated version of the firmware140into a package set150(i.e., a set of installation packages155), such that the updated installation package155is a member of the set. In that case, the integrated installation package155may have been generated by the provider server110or provided to the provider server110, such as via upload by an administrator. In another example, the provider server110may simply receive the updated installation package155, such as by way of upload by an administrator. It will be understood that various techniques are available for providing the updated installation package155to the provider server110.

At block210, the provider server110updates the package set150stored on the provider server110by replacing an old installation package155, of which the updated installation package is an updated version, with the updated installation package155in the package set150. As such, the package set150has been updated to enable installation of an updated version of the firmware140. In some implementations, regardless of whether there are one or multiple updated installation packages155, the updated installation packages155may make up a subset (e.g., a proper subset) of the package set150, such that not every installation package155need be updated for a firmware update to occur.

At block215, the provider server110installs the package set150, such as by executing the installation packages155to expand the package set150into the updated version of the firmware140. The result of the installation is a reference firmware145, which may be an image of the firmware140, as updated.

At block220, the provider server110generates verification data160based at least on the reference firmware145. In some implementations, the verification data160includes a set of hashes signed by the provider server110. For instance, the set of hashes may be concatenated or otherwise combined, and the combined result may be signed, or each hash may be signed individually. Specifically, the verification data160may include a hash of the reference firmware145, signed to form a signed validation hash165. In this case, to generate the signed validation hash165, the provider server110may input the reference firmware145into a hash function and then sign the output of the hash function. In one implementation, for instance, signing is performed using the Elliptic Curve Digital Signature Algorithm (ECDSA) with a digital signature issued by the Landys+Gyr Signed Authority (LGSA), but it will be understood that other signing techniques or authorities may be used.

Further, the verification data160may include a signed package hash corresponding to the updated installation package155or may include a respective signed package hash corresponding to each installation package155in the updated package set150. In some implementations signed packages hashes for the installation packages155not being updated have been previously generated and are stored on the provider server110or otherwise accessible by the provider server110. To generate a signed package hash for an installation package, such as the updated installation package155, the provider server110may hash the installation package155in question and may sign the resulting hash to thereby form a signed package hash corresponding to the installation package155. Thus, the verification data160may be used to verify the authenticity of the firmware140and of each installation package155in the updated package set150.

At block225, the provider server110transmits a firmware update package120to the firmware update server130. Additionally or alternatively, however, the provider server110may transmit the firmware update package120to one or more nodes105without using the firmware update server130as an intermediary. In either case, such transmission may, but need not, include one or more unicast transmissions. In some implementations, for instance, the provider server110may direct the firmware update package120specifically to the firmware update server130or to one or more nodes105, or additionally or alternatively, the provider server110may broadcast or multicast the firmware update package120, thereby enabling the firmware update server130or one or more nodes105to download the firmware update package120.

The firmware update package120transmitted by the provider server110may include the updated installation package155and the verification data160. In some implementations, the verification data160in the firmware update package120may include the signed validation hash165and may include a signed package hash corresponding to the updated installation packages155, but the verification data160need not include the data needed to verify installation packages155other than the updated installation packages155that are being provided. For instance, if an installation package155is not being changed, then each node105may already maintain verification data160(e.g., signed package hashes) corresponding to such existing installation packages155. Thus, the verification data160in the firmware update package120may include information to validate only items that are being updated, such as the updated installation package155and the firmware140itself.

FIG.3depicts a communications flow of the provider server110in generating a firmware update package120, according to some implementations described herein. The description below follows this communication flow from left to right. Although the example ofFIG.3illustrates that two installation packages155a,155bare being updated and that the firmware140being updated is a filesystem, it will be understood that these details are provided for illustrative purposes only. It will be understood that the firmware140need not be a filesystem and that one or multiple installation packages155may be updated in a firmware update package120configured for updating the firmware140.

The provider server110may maintain a server record305including the current package set150aand reference filesystem310, where the reference filesystem310may be an image of the filesystem corresponding to the current package set150a. Thus, in this example, prior to incorporating an update, the server record305includes a current package set150aand a current version of the reference filesystem310, which are in the process of being updated as shown inFIG.3.

When updated installation packages155c,155dare introduced, the provider server110inserts the updated installation packages155c,155dinto the current package set150a, replacing current installation packages155a,155bthat are the respective current versions of the updated installation packages155c,155d. The result is an updated package set150b. As also shown inFIG.3, in some implementations, the provider server110installs the updated package set150b, as updated, to produce a reference filesystem310, which may be an image of the filesystem, as updated. Based on the reference filesystem310, the provider server110may generate a signed validation hash165, or other information for validating the filesystem, for inclusion in the verification data160. The provider server110may also generate a signed package hash (not shown) for inclusion in the verification data160to enable validation of the updated installation packages155c,155d. The provider server110may transmit to the firmware update server130a firmware update package120including the updated installation packages155c,155dand the signed validation hash165.

As shown inFIG.3, the provider server110may update its server record305based on the updated installation packages155c,155dand the updated verification data160. In other words, the updated installation packages155c,155dmay be maintained in the server record305, specifically, in the updated package set150b, in place of the old installation packages155a,155b. Further, the verification data160in the server record305may be updated by inclusion of the signed validation hash165as well as inclusion of a respective signed package hash for each updated installation package155c,155din lieu of the signed package hash for the respective current installation package155a,155b.

FIG.4depicts a method400of updating firmware140on a node105, according to some implementations described herein. In some implementations, this method400or similar is performed by a node105to update the firmware140running on the node105. It will be understood that the ordering of operations illustrated inFIG.4and described herein is for illustrative purposes only and, further, that the blocks ofFIG.4may be reordered, one or more blocks may be deleted, or additional blocks may be added.

As shown inFIG.4, at block405, the node105receives a firmware update package120. For instance, the node105may receive the firmware update package120by downloading the firmware update package120directly from the provider server110, or the node105may receive the firmware update package120indirectly from the provider server110by downloading the firmware update package120from the firmware update server130. The firmware update package120may include an updated installation package155(e.g., potentially multiple updated installation packages155) and verification data160. The updated installation package155may be an updated version of an old installation package155that is included in the package set150currently being maintained on the node105. The verification data160may include, for instance, a signed validation hash165to enable validation of the firmware140and a signed package hash for validation of the updated installation package155.

In one example, the firmware140being updated is a filesystem that includes code and applications. An image of the filesystem itself can be quite large, and thus, implementations described herein can reduce network traffic by avoiding transmission of an entire filesystem image. Rather, an embodiment of the node105need only download verification data160and one or more updated installation packages155, which are only a portion of the data needed for installation, to update its firmware140as described herein.

At block410of the method400, the node105updates the package set150stored on the node105by replacing the old installation package155with the updated installation package155. In some implementations, the old installation package155may be discarded (e.g., deleted). Alternatively, however, the old installation package155may be saved in case the node105needs to restore its firmware140to a prior version or for another reason. In some implementations, regardless of whether there are one or multiple updated installation packages155, the updated installation packages155may make up a subset (e.g., a proper subset) of the package set150, such that not every installation package155need be updated based on the firmware update package120.

At block415, the node105installs the firmware140based on the updated package set150. For instance, the node105executes (e.g., expands or unpacks) the package set150to generate the executable firmware140. The node105may install the firmware140in volatile memory190of the node105, such that the firmware140runs from the volatile memory190.

At block420, the node105validates the firmware140through the use of the verification data160. For instance, the node hashes the firmware140as installed on the node105and compares the resulting hash to the signed validation hash165in the verification data160. If the hash of the firmware140as installed matches the signed validation hash165, which is presumed valid due to being signed, then the node105deems the firmware to be valid.

In some implementations, the node105utilizes device-mapper-verity (dm-verity), or some other validation tool, to validate the firmware140. The validation tool provides transparent validation as part of the boot process to ensure that the node105is booted with validated firmware140. This transparent validation may include hashing the firmware140and comparing the resulting hash to the signed validation hash165in the verification data160. When dm-verity or a similar validation tool is used, the node105may reboot responsive to installation of the firmware140, and the validation of the firmware140may occur as part of the boot up process. It will be understood, however, that various validation techniques may be used, and reboot need not be a requirement for validation to occur.

At block425, the node105updates its local record of the firmware140. More specifically, the node105may store the verification data160(e.g., the signed validation hash as well as a signed package hash for the updated installation package155) in the nonvolatile storage180of the node105, and the node105may store a firmware image170of the firmware140, as newly updated, in the nonvolatile storage180as well. Thus, when the node105reboots or otherwise loses power, up-to-date versions of the following are retained: the set of installation packages; the verification data160including information to validate the firmware140and optionally to validate the package set150; and the firmware image170.

In some implementations, if validation of the firmware140is performed during the boot process, then the firmware image170may be stored in the nonvolatile storage180prior to rebooting the node105. In other words, block425of the method400may occur before block420. In that case, the firmware image170may be copied back to volatile memory190as part of the boot process to enable validation of the firmware140.

At some point after the update of the firmware140as described above, the node105may lose power. For instance, the node105may be rebooted for troubleshooting purposes or to enable servicing the node105. At block430of the method400, such a reboot of the node105occurs. At block435, responsive to the reboot, the node105loads the firmware image170from the nonvolatile storage180to the volatile memory190to enable running the firmware140from the volatile memory190; in other words, the node105may copy the firmware image170from the nonvolatile storage180to the installation location of the firmware140in the volatile memory190. As described above, if the firmware140runs from volatile memory190, as in this example, the firmware140was erased when the node105loses power, and thus, copying the firmware image170back to the volatile memory190enables the firmware140to run from its installation location. At block440, also responsive to the reboot, the node105attempts to revalidate the firmware140. For instance, as described above, the node105may hash the firmware140and compare the resulting hash to the verification data160, specifically, to the signed validation hash165in the verification data160.

It will be understood that block435and block440can be performed in the order described above, block440can be performed prior to block435, or block435and block440can be performed in parallel. For instance, when block435is performed prior to block440, such that the firmware140has been copied to the volatile memory190prior to validation, the node105may try to validate the firmware140based on the installed firmware140in the volatile memory190. For instance, the node105may utilize dm-verity or a similar tool to load the firmware140and securely boot the node105based on validation of the firmware140with the verification data160during the boot process. However, when block440is performed prior to block435, such that the firmware140has not been copied to the volatile memory190prior to the validation, the node105may attempt to validate the firmware140based on the firmware image170stored in the nonvolatile storage180. For instance, the firmware image170may be hashed and the resulting hash compared to the verification data, specifically, for instance, to the signed validation hash165in the verification data.

In some implementations, although the package set150corresponding to the current version of the firmware140is stored on the node105, the node105does not utilize the installation packages155during the reboot process or, more specifically, to reload the firmware140and validate the firmware140. Rather, installation of each version of the firmware140based on the package set150need occur only a single time. After a power loss (e.g., during a reboot), the firmware140need not be reinstalled from the package set150, due to having saved the firmware image170in the nonvolatile storage180, thus enabling to the node105to copy that firmware image170back to the volatile memory190from which the firmware140runs. Typically, copying the firmware image170and validating the firmware140takes less time than installing the firmware140from the package set150would take. Thus, implementations described herein decrease the boot up time of the node105.

As shown inFIG.4, at decision block445of the method400, the node105determines whether validation of the firmware140succeeds. If the validation succeeds (i.e., if the firmware was verified as authentic), then at block450, the node105continues its boot process and the firmware140runs from the volatile memory190.

However, if the validation fails, then the method400proceeds to block455. In that case, the firmware140has been deemed unauthentic, which could mean potential corruption or malware, so the node105does not run the firmware140in some implementations. Although the boot process may be incomplete and the firmware140is not running, in some implementations, the node105has access to a set of services deemed critical or safe. For instance, the node105may be able to reinstall the firmware140from the package set150or to use at least one communication device (e.g., a radio) to contact the firmware update server130. Thus, at block455, the node105reinstalls the firmware140based on the package set150stored in the nonvolatile storage180. At decision block460, the node105then determines whether the firmware140, as newly installed, is validatable. If the node105is able to validate the firmware140, then the method400proceeds to block450, where the node105completes the boot process and runs the firmware140. However, if validation fails again, then at block465, the node105performs further troubleshooting activities.

For instance, the node may attempt to validate the various installation packages155in the package set150to determine whether the problem is with an installation package155. If validation succeeds (i.e., if all the installation packages are deemed authentic), then the node105sends an error notification. In that case, the installation packages155appear authentic, but the firmware140is invalid in some manner, and the node105is apparently unable to fix the problem with the firmware140by way of a new installation, which has already been attempted. However, if validation of the installation packages155fails, then the node105may seek one or more replacement installation packages155based on a determination that the problem lies with the installation packages155. For instance, the node105may request, from the firmware update server130or from the provider server110, a replacement for each installation package155whose validation failed, and the firmware update server130or the provider server110may send such replacement responsive to the request. If validation of an installation package155fails even after its replacement from the firmware update server130, then the node may send a notification of an error.

FIG.5depicts a communication flow of a node105when installing the firmware140based on an updated installation package155, according to some implementations described herein. The description below follows this communication flow from left to right. Although the example ofFIG.5illustrates that two installation packages155c,155dare being updated and that the firmware140being updated is a filesystem510, it will be understood that these details are provided for illustrative purposes only. It will be understood that the firmware140need not be a filesystem510and that one or multiple installation packages155may be updated in a firmware update package120configured for updating the firmware140.

As shown inFIG.5, in some implementations, a node105maintains in its nonvolatile storage180a node record505including a current package set150acorresponding to a current version of a filesystem510running from the volatile memory190of the node105. In this example, the node105downloads from the firmware update server130a firmware update package120that includes updated installation packages155c,155dand verification data160, such as a signed validation hash165and a respective signed package hash for validating each updated installation package155c,155d. The node105updates the current package set150astored in the node record505by inserting the updated installation packages155c,155dinto the current package set150ain place of the respective current installation packages155a,155bthat are the respective current versions (i.e., being updated) of the updated installation packages155c,155d. The node105installs the updated filesystem510based on the updated package set150bincluding the updated installation packages155c,155dand then validates the updated filesystem510with the verification data160.

In this example, the node105initially maintains, in its node record505in nonvolatile storage180, a current version (i.e., being updated) of a filesystem image515copied from the installed filesystem510prior to the update, a current package set150acorresponding to the installed filesystem510prior to the update and thus configured to enable installation of the filesystem510as installed prior to the update, and verification data160for validating the current version of the filesystem510prior to the update. Given that the filesystem510has been updated, the node105may update this record505accordingly. Thus, to update the record505, the node105may replace an existing signed validation hash165in the record with an signed validation hash165received in the firmware update package120and may replace an existing filesystem image515in the record505with an updated filesystem image515copied from the newly installed and thus newly updated filesystem510. As described above, in some implementations, the signed validation hash165and the filesystem image515are maintained for use in reestablishing the filesystem510in the volatile memory190after the node105loses power, while the updated package set150bis maintained for use during a future update to the filesystem510or to reinstall the filesystem510for troubleshooting or other purposes.

FIG.6depicts a diagram of a node105, specifically a utility meter600, according to some implementations described herein. For instance, the utility meter600may be a water meter, a gas meter, or another type of meter that measures consumption of a resource610. A utility meter600such as that shown may act as a node105configured to install and utilize firmware140as described herein. More specifically, for instance, the firmware140may be a filesystem510of the utility meter600. Although this disclosure refers to implementations described herein being embodied in a utility meter600, it will be understood by one skilled in the art that implementations are not limited to utility meters600. Rather, for instance, a node105may be a collector, a gateway, or another computing device other than a utility meter600.

As shown inFIG.6, an example utility meter600measures consumption of a resource610occurring on a premises620. To this end, the utility meter600may include a metrology engine605, which detects a signal indicating use of the resource610and, based on that signal, determines use of the resource610on the premises620. The utility meter600may further include a processing unit630, a volatile memory190, a nonvolatile storage180, and a communication device such as a radio660. For instance, the utility meter600may use the radio660to download a firmware update package120from the firmware update server130or from the provider server110as described herein. The processing unit630, the volatile memory190, the nonvolatile storage180, and the radio660may be in communication with one another and with the metrology engine605by way of a system bus670. Although the processing unit630, the volatile memory190, and the nonvolatile storage180are shown and described herein as being distinct components, it will be understood that this distinction is for illustrative purposes only and does not limit the scope of this disclosure. For instance, the processing unit630, the volatile memory190, and the nonvolatile storage180may be integrated together into a single chip, such as a microcontroller unit.

In some implementations, the operations of a node105described herein, such as installing firmware140, validating firmware140, and running firmware140, are embodied as program instructions stored in a computer-readable medium, such as the nonvolatile storage180or the volatile memory190of the utility meter600. In some implementations, the computer-readable medium is a non-transitory computer-readable medium. The processing unit630may execute the program instructions to implement operations as described herein.

The features discussed herein are not limited to any particular hardware architecture or configuration. A computing device can include any suitable arrangement of components that provide a result conditioned on one or more inputs. Suitable computing devices include multipurpose microprocessor-based computer systems accessing stored software (i.e., computer-readable instructions stored on a memory of the computer system) that programs or configures the computing system from a general-purpose computing apparatus to a specialized computing apparatus implementing one or more aspects of the present subject matter. Any suitable programming, scripting, or other type of language or combinations of languages may be used to implement the teachings contained herein in software to be used in programming or configuring a computing device.