Patent Application
20070143530
The present disclosure relates generally to wireless communications systems, and more particularly, to methods and apparatus for providing a means to update software through wireless updates.
Mobile communication devices include non-volatile memory to persistently store software and data. Updates to the software are sometimes preferred or required to correct errors or to upgrade code already stored in non-volatile memory. These updates are authenticated by the mobile communication device to verify the origin of the incoming software update. Improvements are needed in the methods used to receive and process incoming updates to allow large file size updates to be stored without sacrificing security or memory space.
The subject matter regarded as the invention is particularly pointed out and distinctly claimed in the concluding portion of the specification. The invention, however, both as to organization and method of operation, together with objects, features, and advantages thereof, may best be understood by reference to the following detailed description when read with the accompanying drawings in which:
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 may be exaggerated relative to other elements for clarity. Further, where considered appropriate, reference numerals have been repeated among the figures to indicate corresponding or analogous elements.
In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the invention. However, it will be understood by those skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known methods, procedures, components and circuits have not been described in detail so as not to obscure the present invention.
In the following description and claims, the terms “coupled” and “connected,” along with their derivatives, may be used. It should be understood that these terms are not intended as synonyms for each other. Rather, in particular embodiments, “connected” may be used to indicate that two or more elements are in direct physical or electrical contact with each other while “coupled” may further mean that two or more elements are not in direct contact with each other, but yet still co-operate or interact with each other.
Secure flash memory device 108 includes a flash memory array 114 that is accessed via a microcontroller (μC) 116, which in turn is coupled to the host processor 106. The flash memory array 114 is physically partitioned into a plurality of flash memory blocks, as is known in the art. In turn, the flash memory blocks are logically partitioned into code blocks and data blocks. A binary image 118 corresponding to the device's firmware is stored in the code blocks, which begins at a boot block 120. Add-on applications (e.g., downloaded carrier applications that were not included with the mobile device) may also be stored in the code blocks. For use herein, the code corresponding to such add-on applications is referred to as software, while the code supporting basic device operations is referred to a firmware. The data blocks are generally used to store application (firmware and software) data. As employed herein, the data blocks are used to provide storage corresponding to a flash file system 140 that operates in a manner similar to a conventional disk file system.
The memory blocks in the flash memory array 114 also include a modification block 122 and a patch block 124. Although these two blocks are shown as separate blocks for illustrative purposes, it will be understood that under a typical implementation the flash memory blocks on the secure flash memory device 108 will be physically grouped as a single array of memory blocks. The secure flash memory device 108 further includes a RAM 126 coupled to the microcontroller 116.
In one embodiment, the secure flash memory device 108 includes components to support security measures with respect to firmware updates. These components include a random number generator (RNG) 128, an RSA (Rivest, Shamir, and Adelman) engine 130, and a secure hash algorithm (SHA-1) block 132.
The firmware (e.g. the binary image 118) on the mobile device 100 may be updated during ongoing operations. One technique that may be employed for this purpose is to perform an over the air (OTA) transfer of an entire update firmware image to a mobile device targeted for an update. However, this generally requires transfer of a large file, which both consumes bandwidth and requires adequate spare storage available on the device being updated. Rather than transferring an entire file, the service provider 102 may generate a diff file, which contains portions of update code and instructions for updating an existing binary image to an updated binary image. This is schematically depicted in
After being authenticated (if authentication is performed), data corresponding to the diff file is written to the flash file system 140 and patch block 124, as shown in block 304. This is facilitated via execution of an update application 136 on the host processor 106, which has previously been retrieved from the secure flash memory device 108 and loaded in RAM 110. During this process, various diff file entries are written to flash memory blocks in the flash file system 140, while corresponding pointers to those diff file entries are written to patch block 124, as described below in further detail with reference to
In a block 306, the secure flash memory device is “disconnected” from host processor 106. Rather than physically disconnecting the secure flash memory device 108 from the host processor 106, the interface 142 (e.g., address and data bus lines) between the secure flash memory device 108 and the host processor 106 are operatively disabled to facilitate the disconnection operation. The process is completed in a block 308, wherein the information in the patch block 124 and flash file system 140 are processed using the microcontroller 116 to update the systems firmware and/or software. This operation is described in further detail below with reference to
With reference to
The remaining operations illustrated in
As discussed above, pointers to diff file entries are to be written to the patch block 124. Accordingly, the patch block 124 is first erased in a block 404. In a block 406, the workspace area in the flash file system 140 to be employed to facilitate the update is defined. An initial active data block in the flash file system 140 is then selected and copied into a write buffer 138 in the RAM 126, as depicted in a block 408. This operation replicates an image of the active data block. Notably, since the image is now in the RAM 126, individual bits in the data block corresponding to the image may be switched.
In a block 410, the diff file is parsed for diff entry sets. As shown in
Turning back to
Once the free block is located, the diff entry set is written to the free block in the corresponding image in write buffer 138. A pointer to the base address of the sub-block and the length of the diff entry set is then generated in a block 416, and a corresponding pointer entry is appended to the end of existing data in patch block 124, as depicted in a block 418. Further details of this are discussed below with reference to
In a decision block 420 a determination is made to whether the current entry is the last entry to add to the active data block. For example, a search of the active data block image in write buffer 138 might be performed to verify whether or not the active data block is effectively full. If the active data block is not full, and more entries can be added, the logic loops back to start loop block 412 to perform the operations of blocks 414, 416, and 418 on the next diff entry set. However, if the active data block is full, a new active data block will need to be used to store additional diff entry sets. Accordingly, the active data block in the flash file system 140 is updated in a block 422 by writing the updated image in write buffer 138 first to modification block 122, and then back to the data block from which the image was originally copied. In accordance with flash update techniques, this will involve erasing the entire block, and the writing a copy of the updated image to the data block.
Once the data block has been updated, a new active data block from among the remaining data blocks in the flash file system 140 is selected in a block 424, and an image of the new active data block is copied into the write buffer 138 in a block 426. The foregoing operations are then repeated until all of the diff entry sets have been processed in a similar manner.
Further details of the diff entry set storage and patch block pointers are illustrated in
During the update active data block operation of block 422 of
The reason for the foregoing write sequence is so that there will always be at least one image in the flash memory array that is valid, such that a full recovery can be made from any state in the event of a power failure. For example, if a power failure occurs while the updated image is being written to the write buffer 138 or the updated image is being written to the modification block 122, the process is simply started over from the last successful point that is marked.
As discussed above, in some embodiments an authentication operation is performed to authenticate the update package or the diff file. One embodiment of an authentication process is shown in
The update patch and signed patch hatch is then returned via a message 608 to the mobile device 100, where the information will be authenticated and stored. Prior to loading the updated patch in the flash memory array, the mobile device 100 verifies the authenticity of the file using a public key it previously received that is stored in a one time program (OTP) block 610. The public key is used to verify the digital signature of the patch hash to determine if the file originated from a trusted source (in this case, the service provider 102). An RSA decryption operation is performed by RSA engine 130 using the public key on the patch hatch to yield a first hash, which is stored in a hash register 1. Meanwhile, the random number 602 generated by the mobile device 100 and sent to the service provider 102 is read from random number register 605 and appended to the update patch to form a comparison manifest. An SHA-1 hash is then performed on this manifest by SHA-1 block 132, with the result stored in a hash register 0. The data in the hash registers 0 and 1 are then compared to determine if the values match. If the value match, the update is authenticated, and the update procedure continues. Otherwise if the values do not match, the update procedure is halted.
Different security keys may be used for different types of updates. For example, device firmware is generally more important than add-on carrier applications, because the mobile device 100 may not function if a malicious firmware update is installed (while installation of an errant carrier application would merely mean that the application wouldn't work). Even more important is the boot block of a firmware update.
As illustrated in
Once the update has been written to the flash file system 140 and patch block, the remaining code image update phase of the update process may be performed. As discussed above with reference to blocks 306 and 308 of
With reference to the flowchart of
As depicted by start and end loop blocks 806 and 830, the operations shown between these end loop blocks are then performed for each pointer entry in patch block 124. In a block 808, the corresponding diff entry set pointed to by the current patch block pointer is located in the flash file system 140. As depicted by start and end loop blocks 810 and 814 and block 812, for each diff entry in the set, the code portion in the entry is applied to corresponding existing code in the active code block to effect the delta (change) for the code portion. Next, in a block 816, the pointer entry is zeroed to mark progress for the update. A determination is then made in a decision block 818 to whether the current entry is the last entry to add to the active code block. If not, the logic loops back to start block 806 to process the pointer.
If the current entry is the last entry to add to the active code block, then the active code block is to be updated. This begins in a block 820, wherein the write buffer image is written to modification block 122. The active code block is then erased, and the image in modification block 122 is written to the active code block, as depicted in a block 822. The modification block is then erased in a block 824, and the next active code block is identified in a block 826 in a manner similar to that used to identify the first active code block in block 802 above. An image of the new active code block is then copied to write buffer 138 in a block 828, and the process is returned to start loop block 806 to process the next patch block pointer.
When all of the pointer entries in patch block 124 have been successfully processed, the firmware or software image in the code blocks has been successfully updated. Accordingly, the patch block is erased in a block 832 to complete the update process.
As before, this portion of the update process is performed in a manner that provides a full recovery from any failure state, such as that caused by a power failure (in the case of a mobile device, typically the battery would become discharged) or other anomaly. Furthermore, since the progress is tracked by marking the patch block pointers, an update process can be restarted from the point at which a failure occurs. Finally, by using a microcontroller that is separate from the mobile device's host processor, the update can be performed entirely by the intelligent flash chip.
The operation discussed herein may be generally facilitated via execution of appropriate firmware or software embodied as code instructions on the host processor and microcontroller, as applicable. Thus, embodiments of the invention may include sets of instructions executed on some form of processing core or otherwise implemented or realized upon or within a machine-readable medium. A machine-readable medium includes any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computer). For example, a machine-readable medium can include an article of manufacture such as a read only memory (ROM); a random access memory (RAM); a magnetic disk storage media; an optical storage media; and a flash memory device, etc. In addition, a machine-readable medium may include propagated signals such as electrical, optical, acoustical or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.).
While certain features of the invention have been illustrated and described herein, many modifications, substitutions, changes, and equivalents will now occur to those skilled in the art. It is, therefore, to be understood that the appended claims are intended to cover all such modifications and changes as fall within the true spirit of the invention.
