CN115599407B - Firmware burning method, firmware burning system and memory storage device - Google Patents
Firmware burning method, firmware burning system and memory storage device Download PDFInfo
- Publication number
- CN115599407B CN115599407B CN202211507872.8A CN202211507872A CN115599407B CN 115599407 B CN115599407 B CN 115599407B CN 202211507872 A CN202211507872 A CN 202211507872A CN 115599407 B CN115599407 B CN 115599407B
- Authority
- CN
- China
- Prior art keywords
- file
- program
- memory
- entity unit
- abstract
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 64
- 230000005055 memory storage Effects 0.000 title claims abstract description 50
- 230000006870 function Effects 0.000 claims abstract description 49
- 230000008569 process Effects 0.000 claims description 27
- 238000010586 diagram Methods 0.000 description 10
- 238000012937 correction Methods 0.000 description 8
- 230000006872 improvement Effects 0.000 description 8
- 238000005516 engineering process Methods 0.000 description 6
- 238000013478 data encryption standard Methods 0.000 description 5
- 238000012545 processing Methods 0.000 description 5
- 238000012795 verification Methods 0.000 description 4
- 238000007726 management method Methods 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 238000013461 design Methods 0.000 description 2
- 230000002093 peripheral effect Effects 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 1
- 210000004556 brain Anatomy 0.000 description 1
- 238000013523 data management Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/61—Installation
- G06F8/63—Image based installation; Cloning; Build to order
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/14—Handling requests for interconnection or transfer
- G06F13/16—Handling requests for interconnection or transfer for access to memory bus
- G06F13/1668—Details of memory controller
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
- G06F21/105—Arrangements for software license management or administration, e.g. for managing licenses at corporate level
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Abstract
The invention belongs to the technical field of storage, and provides a firmware burning method, a firmware burning system and a memory storage device, wherein the method comprises the following steps: after the bootstrap file and the function library file are written into the read-only memory, performing a first hash operation on the bootstrap file and the function library file to obtain a first digest; acquiring a second abstract from the program head of the bootstrap file, judging whether the first abstract is consistent with the second abstract, and if so, writing a business program file into the memory module; restarting the memory storage device after writing a business program file into the entity unit, and judging whether a starting address of the business program file can be addressed from the read-only memory; if yes, the firmware burning operation is finished, and the successful completion of the firmware burning is indicated. This ensures the safe reliability of the firmware burned into the memory storage device.
Description
Technical Field
The present invention relates to the field of storage technologies, and in particular, to a firmware burning method, a firmware burning system, and a memory storage device.
Background
Existing computers and electronic devices typically include one or more microcontrollers that can be considered the "brain" of these devices. Firmware (Firmware) is a set of electronic instructions (electronic instruction set) stored inside the microcontroller that, by executing the set of electronic instructions, the microcontroller can generate set control signals to effect operational control of the device. Optionally, the microcontroller in the electronic watch tracks time and processes alarm clock and bell sound required by the user by executing firmware; the microcontroller in the mobile phone provides a user interface, mobile phone transmission/reception protocols, audio processing, etc. by executing firmware.
Since the firmware directly defines the operating logic of the device, once the firmware is in error, the firmware can bring a great threat to the operation of the device. In order to avoid the error of the firmware in the burning process, in the prior art, after the device receives the firmware, the device can perform CRC check on the firmware, and compare the calculated check result with the received CRC check result. If the comparison does not pass, the firmware is refused to run.
Although the above manner can solve the problems of data defect loss and the like in the firmware transmission process to a certain extent, the scheme cannot solve the problem that the firmware is maliciously modified or maliciously replaced, and optionally, a third party maliciously modifies the firmware and the CRC check result at the same time, so that the device may not recognize the fact that the newly input firmware has been maliciously tampered.
Based on this, how to improve the security of firmware in the burning process is a technical problem to be solved by those skilled in the art.
Disclosure of Invention
The invention aims to solve the technical problem that the existing firmware burning mode cannot meet the firmware reliability requirement in the firmware burning process of a memory storage device, and provides a firmware burning method, a firmware burning system and the memory storage device.
The technical scheme of the invention for solving the technical problems is that a firmware burning method is provided and is applied to a memory storage device, wherein the memory storage device comprises a memory controller and a memory module, and the memory controller comprises a read-only memory and a buffer memory; the memory module comprises a plurality of entity units, and the firmware burning method comprises the following steps:
writing a bootstrap file and a function library file into the read-only memory;
reading the bootstrap file and the function library file into the buffer memory, and executing first hash operation on the bootstrap file and the function library file to obtain a first digest;
obtaining a second digest from a program head of the bootstrap file, wherein the second digest is generated by executing first hash operation on the bootstrap file and the function library file by an upper computer, and the second digest is written into the read-only memory along with the bootstrap file and the function library file;
Responsive to the first digest being consistent with the second digest, writing a business program file into the memory module;
restarting the memory storage device after writing a business program file into the memory module, and judging whether a starting address of the business program file can be addressed from the read-only memory;
if yes, the firmware burning operation is finished, and the successful completion of the firmware burning is indicated.
As a further improvement of the present invention, after writing the boot program file and the function library file into the read-only memory, the method includes:
judging whether the boot program file can be loaded from the read-only memory;
if yes, reading the bootstrap file and the function library file into the buffer memory, and executing first hash operation on the bootstrap file and the function library file to obtain a first abstract;
if not, writing the bootstrap program file and the function library file into the read-only memory until the bootstrap program can be successfully loaded.
As a further improvement of the present invention, the writing of the business program file into the memory module includes:
receiving ciphertext data of the business program file from an upper computer, and
Acquiring a first key from a program head of the bootstrap file, and decrypting ciphertext data of the service program file by using the first key to obtain plaintext data of the service program file;
and after the plaintext data of the service program file is successfully obtained, writing the plaintext data of the service program file into a memory module.
As a further improvement of the present invention, the writing of the plaintext data of the business program file into the memory module includes:
writing a program main body file of the service program file into a first entity unit, and writing a program head file of the service program file into a second entity unit, wherein the physical address of the first entity unit is different from the physical address of the second entity unit.
As a further improvement of the present invention, the writing the program header file of the service program file into the second entity unit includes:
and writing the starting address of the business program file into the second entity unit, wherein the physical address of the second entity unit is generated through the first address in the read-only memory.
As a further improvement of the present invention, comprising:
writing the program main body file of the service program file into a first entity unit, and writing the program header file of the service program file into a second entity unit;
reading a third abstract from the second entity unit, wherein the third abstract is generated by performing a second hash operation on a program header file of the service program file by an upper computer, and the third abstract is written into the second entity unit along with the program header file of the service program file;
reading the program header file of the service program file in the second entity unit into the buffer memory, and executing a second hash operation on the program header file of the service program file to obtain a fourth abstract;
judging whether the third abstract is consistent with the fourth abstract, if so, judging that the program header file of the business program file burnt into the second entity unit is complete;
if the program head files are inconsistent, judging that the program head files of the business program files burnt into the second entity unit are incomplete, and writing the program head files of the business program files into the second entity unit again.
As a further improvement of the present invention, comprising:
after judging that the program header file of the business program file burnt into the second entity unit is complete;
reading a fifth abstract from the second entity unit, wherein the fifth abstract is generated by performing a third hash operation on a program main body file of the service program file by an upper computer, and the fifth abstract is written into the second entity unit along with the program main body file of the service program file;
reading the program main body file of the service program file in the first entity unit into the buffer memory, and executing a third hash operation on the program main body file of the service program file to obtain a sixth abstract;
judging whether the fifth abstract is consistent with the sixth abstract, if so, judging that the program main body file of the business program file burnt into the first entity unit is complete, and ending the burning of the business program file;
if the program main files are inconsistent, judging that the program main files of the business program files burnt into the first entity unit are incomplete, and re-writing the program main files of the business program files into the first entity unit.
As a further improvement of the present invention, the method further comprises:
and in the process of writing the business program file into the memory module, performing read protection on the entity unit in which the business program file is being written.
As a further improvement of the present invention, the method further comprises:
and after the business program file is written into the memory module, performing write protection on the first entity unit and the second entity unit.
The invention also provides a firmware burning system, which comprises an upper computer and a memory storage device, wherein,
the upper computer performs first hash operation on the bootstrap file and the function library file to generate a second abstract, and the second abstract is stored at a program head of the bootstrap file;
the upper computer encrypts plaintext data of a service program file by using a first key through a first encryption algorithm, and stores the first key at a program head of the bootstrap program file;
the upper computer carries out second hash operation on the program header file of the service program file to generate a third abstract, and the third abstract is stored at the program header of the service program file;
And the upper computer performs a third hash operation on the program main body file of the service program file to generate a fifth abstract, and stores the fifth abstract at the program head of the service program file.
The invention also provides a memory storage device, which is characterized by comprising a memory controller, wherein the memory controller is used for executing the firmware burning step.
The invention has the following beneficial effects: the method comprises the steps of dividing a firmware file, firstly burning a bootstrap file and a function library file into a read-only memory of a memory controller in the process of burning the firmware into a memory storage device, and then burning a service program file into a memory module after the successful verification of the burning of the bootstrap file and the function library file. This may increase the success rate of firmware burning, especially for large batches of memory storage devices 12. Compared with the read-only memory, the price of the memory module is relatively low, the boot program file and the function library file with small files are burnt into the read-only memory, and the business program file with larger files is burnt into the memory module, so that the firmware can be also suitable for the memory storage device of the read-only memory with small capacity, and the cost of the memory storage device can be effectively saved. And encrypting the service program file by using a symmetric encryption algorithm or an asymmetric encryption algorithm, so that the file is ciphertext data in the burning process. Specifically, the cipher text data of the service program file and the decrypted secret key are separately burnt, so that the safety and reliability in the firmware burning process are further improved. Furthermore, after the service program file is decrypted and written into the memory module, hash operation is performed twice, and the program head and the program main body of the service program file are respectively checked. This further ensures the safe reliability of the firmware burned into the memory module or memory storage. Only after the 2 passes of the verification, the firmware burning operation is ended. This ensures the safe reliability of the firmware burned into the memory module or memory storage.
Drawings
Fig. 1 is a schematic diagram of a firmware burning system according to an embodiment of the invention;
FIG. 2 is a block diagram of a memory controller according to an embodiment of the present invention;
FIG. 3 is a schematic diagram of a boot loader of a firmware file according to an embodiment of the present invention;
FIG. 4 is a schematic diagram of a business program of a firmware file according to an embodiment of the present invention;
FIG. 5 is a flowchart of a firmware burning method according to an embodiment of the present invention;
FIG. 6 is a diagram illustrating a physical address distribution of service firmware stored in a memory module according to an embodiment of the present invention.
Detailed Description
The present invention will be described in further detail with reference to the drawings and examples, in order to make the objects, technical solutions and advantages of the present invention more apparent. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the invention.
Fig. 1 is a schematic diagram of a firmware burning system 10 according to an embodiment of the present invention. Referring to fig. 1, a firmware burning system 10 includes a host computer 11 and a memory storage device 12. The host computer 11 may be any type of computer system. Optionally, the method comprises the step of. The host computer 11 can be a notebook computer, a desktop computer, a smart phone, a tablet computer, an industrial computer, a game console, a digital camera, and other electronic systems. The memory storage device 12 is used for storing data from the host computer 11. Alternatively, the memory storage 12 may comprise a solid state disk, a USB flash drive, a memory card, or other type of non-volatile storage. The host computer 11 may be electrically connected to the memory storage device 12 via a serial advanced technology attachment (Serial Advanced Technology Attachment, SATA) interface, a high-speed peripheral component interconnect (Peripheral Component Interconnect Express, PCI Express), a universal serial bus (Universal Serial Bus, USB) or other type of interconnect interface. Accordingly, the host computer 11 may store data to the memory storage device 12 and/or read data from the memory storage device 12.
Memory storage device 12 may include a connection interface 121, a memory module 122, and a memory controller 123. The connection interface 121 is used to connect the memory storage device 12 to the host computer 11. Alternatively, the connection interface 121 may support connection interface standards such as SATA, PCI Express, or USB. The memory storage device 12 may communicate with the host computer 11 via the connection interface 121.
The memory module 122 is used to store data. The memory module 122 may include a rewritable nonvolatile memory module. The memory module 122 includes an array of memory cells. The memory cells in the memory module 122 store data in the form of voltages. Alternatively, the memory module 122 may include a single-Level memory Cell (Single Level Cell, SLC) NAND-type flash memory module, a Multi-Level Cell (MLC) NAND-type flash memory module, a three-Level memory Cell (Triple Level Cell, TLC) NAND-type flash memory module, a Quad-Level Cell (QLC) NAND-type flash memory module, or other memory modules having similar characteristics.
The memory controller 123 is connected to the connection interface 121 and the memory module 122. The memory controller 123 may be used to control the memory storage device 12. Optionally, the memory controller 123 may control the connection interface 121 and the memory module 122 for data access and data management. Alternatively, the memory controller 123 may include a Central Processing Unit (CPU), or other programmable general purpose or special purpose microprocessor, digital signal processor (Digital Signal Processor, DSP), programmable controller, application specific integrated circuit (Application Specific Integrated Circuits, ASIC), programmable logic device (Programmable Logic Device, PLD), or other similar device or combination of devices.
In one embodiment, memory controller 123 is also referred to as a flash memory controller. In one embodiment, the memory module 122 is also referred to as a flash memory module. The memory module 122 may receive a sequence of instructions from the memory controller 123 and access the memory unit according to the sequence of instructions.
FIG. 2 is a block diagram illustrating a memory controller according to an embodiment of the present invention. Referring to fig. 2, the memory controller 123 includes a memory control circuit 204, a host interface 202, a memory interface 206, a read only memory 208 (ROM, PROM, EPROM, OTPROM, EEPROM), a buffer memory 210 (DRAM or SRAM), and an encryption/decryption circuit 212.
The memory control circuit 204 is used for controlling the overall operation of the memory controller 123. Specifically, the memory control circuit 204 has a plurality of control commands, and the control commands are executed to perform operations such as writing, reading and erasing data when the memory storage device 12 is in operation. The following description of the operation of the memory control circuit 204 is equivalent to the description of the operation of the memory controller 123.
In the present embodiment, the control instructions of the memory control circuit 204 are operated in firmware. Specifically, the firmware code includes a bootstrap code (BootLoaderCode), a function library code, and a business program code. At the host computer 11, the source codes of the boot program, the function library, and the business program are compiled via an editor to generate binary files, and then the respective binary files are written from the host computer 11 into the memory storage device 12, which operation is called firmware burning (operable by a burner). Specifically, the codes of the boot strap program and the function library are burned into the rom 208, and the control instructions of the memory control circuit 204 are stored in the specific area of the memory module 122 in the form of business codes. In particular, the memory control circuit 204 may also include a microprocessor unit. When the memory controller 123 is enabled, the microprocessor unit executes the boot program to load the code of the service program stored in the memory module 122 into the buffer memory 210. The microprocessor unit then runs the code of these business programs in conjunction with the function library to perform the operations of writing data to the memory storage device 12 or reading data from the memory storage device 12, and performing wear leveling, garbage collection, and bad block management on the memory storage device 12. In other words, the code of the service program is an algorithm code for realizing the service core of the memory storage device 12.
The host interface 202 is electrically connected to the memory control circuit 204 and is used for receiving and identifying the commands and data transmitted by the host computer 11. That is, the commands and data transmitted from the host 11 are transmitted to the memory control circuit 204 through the host interface 202. In this embodiment, the host interface 202 is compliant with the SATA standard. However, it must be understood that the present invention is not limited thereto, and the host interface 202 may also be compatible with PATA standard, IEEE 1394 standard, PCI Express standard, USB standard, SD standard, UHS-I standard, UHS-II standard, MS standard, MMC standard, eMMC standard, UFS standard, CF standard, IDE standard, or other suitable data transfer standard.
The memory interface 206 is electrically connected to the memory control circuit 204 and is used to access the memory module 122. That is, the data to be written into the memory module 122 is converted into a format acceptable to the memory module 122 through the memory interface 206. Specifically, if the memory control circuit 204 is to access the memory module 122, the memory interface 206 transmits a corresponding instruction sequence. Alternatively, these instruction sequences may include a write instruction sequence that indicates write data, a read instruction sequence that indicates read data, an erase instruction sequence that indicates erase data, and a corresponding instruction sequence for indicating various memory operations (optionally, changing read voltage levels or performing garbage collection operations, etc.). These sequences of instructions are optionally generated by memory control circuitry 204 and transferred to memory module 122 through memory interface 206. These instruction sequences may include one or more signals, or data, on a bus. Such signals or data may include instruction code or program code. Optionally, in the sequence of read instructions, information such as the read identification code, memory address, etc. is included.
In this embodiment, the memory controller 123 may perform single-frame (single-frame) encoding for data stored in the same physical programming unit, or may perform multi-frame (multi-frame) encoding for data stored in a plurality of physical programming units. Depending on the encoding algorithm employed, the memory controller 123 may encode the data to be protected to generate a corresponding error correction code and/or error checking code.
Further, the buffer memory 210 is electrically connected to the memory control circuit 204 and is used for temporarily storing data and instructions from the host 11 or data from the memory module 122.
Further, the encryption/decryption circuit 212 is electrically connected to the memory control circuit 204 and is used for implementing the encryption/decryption function of the memory controller 123. Specifically, the encryption and decryption circuit 212 may be a circuit module preset with various algorithms such as symmetric, asymmetric, hash, and the like. Further, when the memory controller 123 has an encryption/decryption instruction, the encryption/decryption circuit 212 responds to the encryption/decryption instruction of the memory control circuit 204, and inputs the corresponding encryption/decryption code in the function library from the read-only memory 208, inputs the parameter corresponding to the encryption/decryption code into the encryption/decryption circuit 212, and the encryption/decryption circuit 212 performs encryption/decryption processing according to the input and outputs an encryption/decryption result.
In one embodiment, the memory controller 123 further includes an error checking and correction circuit 214 and a power management circuit 216. The power management circuit 216 is electrically connected to the memory control circuit 204 and is used to control the power of the memory storage device 12. The error checking and correcting circuit 214 is electrically connected to the memory control circuit 204 and is used for performing error checking and correcting operations to ensure the correctness of the data.
Specifically, when the memory control circuit 204 receives a write command from the host 11, the error checking and correcting circuit 214 generates a corresponding error correction code (error correcting code, ECC) and/or error checking code (error detecting code, EDC) for the data corresponding to the write command, and the memory control circuit 204 writes the data corresponding to the write command and the corresponding error correction code and/or error checking code into the memory module 122. Then, when the memory control circuit 204 reads data from the memory module 122, the error correction code and/or the error check code corresponding to the data are read at the same time, and the error check and correction circuit 214 performs an error check and correction operation on the read data according to the error correction code and/or the error check code.
Further, in order to secure and improve the security and reliability of the boot Code (BootLoader Code), the function library Code, and the business program Code, which are burned from the host computer 11 into the memory storage device 12. In the embodiment of the present application, source codes of the bootstrap code, the function library code and the business program code are compiled at the upper computer 11 via an editor to generate a binary file. Thus, the firmware files in the present embodiment include a bootstrap file 302, a function library file 304, and a business program file 306.
Further, as shown in fig. 3, fig. 3 is a schematic diagram of a boot file 302 of the firmware. The bootstrap file 302 includes a program header 3022 of the bootstrap file and a program body file 3024 of the bootstrap file.
Specifically, the upper computer 11 performs a first hash operation on the bootstrap file 302 and the function library file 304 to generate a second digest, and stores the second digest at the program header 3022 of the bootstrap file.
Further, as shown in fig. 4, fig. 4 is a schematic diagram of a business program file 306 of the firmware. Business program files 306 include a program header file 3062 of the business program file and a body file 3064 of the business program file.
Specifically, the upper computer 11 further encrypts plaintext data of the service program file 306 compiled by the editor by using the first key through the first encryption algorithm, to obtain ciphertext data of the service program file. And the upper computer 11 also stores the first key at a program Header (Header) 3022 of the boot program file in fig. 3.
In one embodiment of the invention, the first encryption algorithm is a symmetric encryption algorithm including, but not limited to, advanced encryption standard (Advanced Encryption Standard, AES) algorithm, data encryption standard (Data Encryption Standard, DES) algorithm, triple data encryption algorithm (Triple Data Encryption Standard,3 DES) algorithm, national encryption SM4, and the like. The encryption by the symmetric encryption algorithm is a technology known in the art, and will not be described herein.
In particular, the first encryption algorithm is a symmetric encryption algorithm, so the first key may also be referred to as a first public key.
Further, in another embodiment of the present invention, the first encryption algorithm is an asymmetric encryption algorithm.
Specifically, the upper computer 11 performs encryption processing on the service program file 306 by using an asymmetric encryption algorithm, so that confidentiality of ciphertext data of the service program file 306 is stronger. Specifically, the second public key is used to asymmetrically encrypt the business program file 306; and storing the second private key for decrypting it at the bootstrap's program header 3022. The asymmetric encryption and decryption operation performed by the asymmetric encryption algorithm belongs to the conventional technology in the art, and is not described herein.
Further, the upper computer 11 performs a second hash operation on the program header 3062 of the business program file to generate a third digest, and stores the third digest at the program header 3062 of the business program file.
Further, the upper computer 11 performs a third hash operation on the program body file 3064 of the business program file to generate a fifth digest, and stores the fifth digest at the program header file 3062 of the business program file.
In an embodiment of the present invention, the first, second and third hash algorithms may be any one of MD5, SHA series, SM3 hash algorithms, and the first, second and third hash algorithms may be the same or different, and the present invention is not limited thereto. Preferably, the three hash algorithms are different. These hash algorithms may operate on data as a fixed value, which is referred to as a digest. For example, MD5 outputs a fixed 128-bit digest, SHA-256 outputs a fixed 256-bit digest, and SHA-512 outputs a fixed 512-bit digest. Illustratively, the password is processed by a hash algorithm, the password is stored in the server in a digest mode, and when a user logs in an account by using the password, the authentication is performed in a mode that: the password is processed into a digest and then compared with the digest of the server, so that whether the password of the user is correct or not is known. The hash algorithm is used to perform hash operation to obtain the digest, which is a conventional technology in the art and will not be described herein.
In order to solve the problem of the firmware reliability requirement in the firmware burning process of the memory storage device 12, an embodiment of the invention provides a firmware burning method, as shown in fig. 5. Fig. 5 is a flowchart of a firmware burning method according to an embodiment of the invention.
In response to the firmware burning instruction, the memory control circuit 204 receives the boot file 302 and the function library file 304 from the host computer 11, and writes the boot file 302 and the function library file 304 into the rom 208.
Step S52, after the memory control circuit 204 writes the bootstrap file 302 and the function library file 304 into the read-only memory 208, the memory control circuit 204 reads the bootstrap file 302 and the function library file 304 in the read-only memory 208 into the buffer memory 210, and performs a first hash operation on the bootstrap file 302 and the function library file 304 in the buffer memory 210 to obtain a first digest.
Step S53, the memory control circuit 204 obtains the second digest from the program head 3022 of the boot file in the ROM 208 and reads the second digest into the buffer 210; wherein the second digest is generated by the upper computer 11 performing a first hash operation on the bootstrap file 302 and the function library file 304, and the second digest is written into the read-only memory 208 along with the bootstrap file 302 and the function library file 304.
Step S54, the memory control circuit 204 determines whether the first digest and the second digest in the buffer memory 210 are consistent, and if so, writes the business program file 306 into the memory module 122; if not, the process returns to step S52.
Step S55 after the memory control circuit 204 writes the business program file 306 into the memory module 122, the memory control circuit 204 restarts the memory storage device 12.
Step S56, the memory control circuit 204 judges whether the starting address of the business program file 306 can be addressed from the read-only memory 208; if yes, go to step S57; if not, the process returns to step S55.
Step S57: and successfully completing the firmware burning, and ending the firmware burning operation.
In the embodiment of the present application, on the one hand, the firmware file is divided, in the process of burning firmware into the memory storage device 12, the boot program file 302 and the function library file 304 are first burned into the rom 208 of the memory controller 123, and after the successful verification of the burning of the boot program file 302 and the function library file 304, the service program file 306 is burned into the memory module 122. This may increase the success rate of firmware burning, especially for large batches of memory storage devices 12. And further, the split design of the firmware file, compared with the read-only memory, the price of the memory module is relatively cheaper, the small-file bootstrap file 302 and the function library file 304 are burnt into the read-only memory 208, and the large-file business program file is burnt into the memory module, so that the firmware can be also suitable for the memory storage device 12 of the read-only memory with small capacity, and the cost of the memory storage device can be effectively saved.
Further, in another embodiment, in step S52, after the memory control circuit 204 writes the boot program file 302 and the function library file 304 into the read only memory 208, the method includes: the memory control circuit 204 determines whether or not the boot program can be loaded from the rom 208; if so, the memory control circuit 204 reads the bootstrap file 302 and the function library file 304 into the buffer memory 210, and performs a first hash operation on the bootstrap file 302 and the function library file 304 to obtain a first digest; if not, the process returns to step S51. By judging whether the firmware can be loaded into the guide program which has completed the writing, the success rate of the firmware writing can be effectively improved.
Further, in another embodiment, in step S55, the memory control circuit 204 writes the business program file 306 into the memory module 122, including: the memory control circuit 204 receives ciphertext data of the service program file from the upper computer, and the memory control circuit 204 obtains a first key from a program head 3022 of the boot program and decrypts the service program file 306 by using the first key to obtain plaintext data of the service program file; the memory control circuit 204 successfully decrypts the ciphertext data of the business program file 306 using the first key; and the memory control circuit 204 writes the plaintext data of the business program file 306 into the memory module 122 after obtaining the plaintext data of the business program file 306. The business program file 306 is encrypted, so that the business program file 306 is ciphertext data in the firmware burning process. After the service program file 306 is successfully decrypted, the service program file 306, which is plaintext data, is written into the memory module. By the aid of the method, the safety and reliability of the firmware in the firmware burning process are improved, and the risk of tampering of the firmware is reduced.
Further, in another embodiment, in step S55, the memory control circuit 204 writes the business program file 306 into the memory module 122, including step S551: the memory control circuit 204 writes the program body file 3064 of the business program file into a first entity unit and writes the program header file 3062 of the business program file into a second entity unit, wherein the physical address of the first entity unit and the physical address of the second entity unit are different. Wherein the first physical unit may comprise one or more blocks (blocks) or pages (pages). Similarly, the second physical unit may include one or more blocks (blocks) or pages (pages).
Illustratively, the first and second entity units include one or more blocks (blocks) to illustrate how the business program files 306 are stored in the memory module 122, as shown in fig. 6. Where A, B, C is the physical address value of the block or the serial number of the block. Fig. 6 is a schematic diagram of business program files 306 stored in memory module 122.
Further, in another embodiment, the memory control circuit 204 writes the program header file 3062 of the business program file into the second entity unit, comprising: the memory control circuit 204 writes the start address of the business program file 306 to the second physical unit, wherein the physical address of the second physical unit is generated by the first address in the read only memory 208. Wherein the start address of the business program file 306 may be used to load the business program file 306. In other words, the business program file 306 is loaded to operate, and the operation of the business program file 306 is further realized through the start address. The physical address of the start address is set in the first address in the rom 208, and if the service program file 306 needs to be loaded for operation, the start address is quickly addressed by the first address in the rom 208, so that the operation of loading the service program file 306 is quickly realized. The method can verify the success or failure of the firmware burning, improves the safety and reliability of the firmware in the firmware burning process, and reduces the risk of the firmware being tampered.
Further, in another embodiment, after step S551, step S60 is included: the memory control circuit 204 reads a third digest from the second entity unit, wherein the third digest is generated by performing a second hash operation on the header 3062 of the service program file by the upper computer 11, and the third digest is written into the second entity unit along with the header 3062 of the service program file; the memory control circuit 204 reads the header 3062 of the service program file in the second entity unit into the buffer memory 210, and performs a second hash operation on the header 3062 of the service program file to obtain a fourth digest; the memory control circuit 204 determines whether the third abstract is consistent with the fourth abstract, and if so, determines that the header 3062 of the business program file burned into the second entity unit is complete; if the program header files are inconsistent, the program header files 3062 of the business program files burnt into the second entity unit are judged to be incomplete, and the program header files 3062 of the business program files are written into the second entity unit again. The burning of the program header 3062 of the business program file is completed. The aim of the method is to verify whether the firmware is burnt or not, so that the safety and reliability of the firmware in the firmware burning process are improved, and the risk of the firmware being tampered is reduced.
Further, in another embodiment, after determining that the header 3062 of the business program file burned into the second entity unit is complete, the memory control circuit 204 includes: the memory control circuit 204 reads a fifth digest from the second entity unit, wherein the fifth digest is generated by performing a third hash operation on the program body file 3064 of the service program file by the upper computer 11, and the fifth digest is written into the second entity unit together with the program body file 3064 of the service program file; reading a program main body file 3064 of the service program file in the first entity unit into the buffer memory 210, and performing a third hash operation on the program main body file 3064 of the service program file to obtain a sixth digest; judging whether the fifth abstract is consistent with the sixth abstract, if so, judging that the program main body file 3064 of the business program file burnt into the first entity unit is complete, and ending the burning of the business program file 306; if the program main files 3064 of the business program files are inconsistent, the program main files 3064 of the business program files burnt into the first entity unit are judged to be incomplete, and the program main files 3064 of the business program files are written into the first entity unit again. The burning of the program file body 3064 of the business program file is completed. The aim of the method is to verify whether the firmware is burnt or not, so that the safety and reliability of the firmware in the firmware burning process are improved, and the risk of the firmware being tampered is reduced.
Further, in another embodiment, the method further includes: the memory control circuit 204 performs read protection on the entity unit to which the business program file 306 is being written during the process of writing the business program file to the memory module 122. This prevents business program file 306 from being read during writing to storage module 122. The aim of the method is to improve the safety and reliability of the firmware in the firmware burning process and reduce the risk of the firmware being tampered.
Further, in another embodiment, the method further includes: after writing business program file 306 to memory module 122, memory control circuit 204 performs write protection on the first and second physical units in which business program file 306 is stored. This is done so that the first and second entity units storing business program files 306 are not used for other purposes. And secure the firmware stored in the memory module 122 or the memory device 12.
Further, in another embodiment, the memory controller 123 in the memory storage device 12 is configured to execute the firmware burning method in each of the above embodiments, and detailed implementation procedures of the method are shown in the corresponding method embodiments, and technical features in the method embodiments are correspondingly applicable in the above embodiments, which are not repeated herein.
Specifically, the first, second, and third hash operations in the above embodiments and the decryption of the ciphertext data of the service program file 306 by using the first key obtain the execution subject of the plaintext data of the service program file 306 as the encryption/decryption circuit 212. Specifically, when the memory controller 123 has an encryption/decryption instruction, the encryption/decryption circuit 212 responds to the encryption/decryption instruction of the memory control circuit 204, and loads the corresponding encryption/decryption code in the function library from the read-only memory 208, inputs the parameter corresponding to the encryption/decryption code into the encryption/decryption circuit 212, and the encryption/decryption circuit 212 performs encryption/decryption processing according to the input and outputs an encryption/decryption result.
In summary, in order to improve the security and reliability of firmware programming, on the one hand, after the boot program file 302 and the function library file 304 are successfully verified, the business program file 306 is programmed into the memory module 122. This may increase the success rate of firmware burning, especially for large batches of memory storage devices 12. And encrypting the service program file by using a symmetric encryption algorithm or an asymmetric encryption algorithm, so that the file is ciphertext data in the burning process. Specifically, the cipher text data of the service program file and the decrypted secret key are separately burnt, so that the safety and reliability in the firmware burning process are further improved. Further, after the service program file is decrypted and written into the memory module 122, hash operations are performed twice, and the program header 3062 of the service program file and the program body 3064 of the service program file are checked, respectively. This further ensures the safe reliability of the firmware burned into the memory module 122 or the memory storage device 12. Only after the 2 passes of the verification, the firmware burning operation is ended.
It should be understood that the sequence number of each step in the foregoing embodiment does not mean that the execution sequence of each process should be determined by the function and the internal logic, and should not limit the implementation process of the embodiment of the present application.
It will be clearly understood by those skilled in the art that, for convenience and brevity of description, only the above-described division of the functional units and modules is illustrated, and in practical application, the above-described functional allocation may be performed by different functional units and modules according to needs. The functional units and modules in the embodiment may be integrated in one processor, or each unit may exist alone physically, or two or more units may be integrated in one unit, where the integrated units may be implemented in a form of hardware or a form of a software functional unit. In addition, the specific names of the functional units and modules are only for distinguishing from each other, and are not used for limiting the protection scope of the present application. The specific working process of the units and modules in the above system may refer to the corresponding process in the foregoing method embodiment, which is not described herein again.
In the foregoing embodiments, the descriptions of the embodiments are emphasized, and in part, not described or illustrated in any particular embodiment, reference is made to the related descriptions of other embodiments.
Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.
The above embodiments are only for illustrating the technical solution of the present application, and not for limiting the same; although the application has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit and scope of the technical solutions of the embodiments of the present application, and are intended to be included in the scope of the present application.
Claims (6)
1. The firmware burning method is applied to a memory storage device and is characterized in that the memory storage device comprises a memory controller and a memory module, and the memory controller comprises a read-only memory and a buffer memory; the memory module comprises a plurality of entity units, and the firmware burning method comprises the following steps:
writing a bootstrap file and a function library file into the read-only memory;
reading the bootstrap file and the function library file into the buffer memory, and executing first hash operation on the bootstrap file and the function library file to obtain a first digest;
obtaining a second digest from a program head of the bootstrap file, wherein the second digest is generated by executing first hash operation on the bootstrap file and the function library file by an upper computer, and the second digest is written into the read-only memory along with the bootstrap file and the function library file;
responsive to the first digest being consistent with the second digest, writing a business program file into the memory module, including,
receiving ciphertext data of the service program file from an upper computer, acquiring a first key from a program head of the bootstrap program file, decrypting the ciphertext data of the service program file by using the first key to obtain plaintext data of the service program file,
Writing a program main body file of the service program file into a first entity unit and writing a program head file of the service program file into a second entity unit after the plaintext data of the service program file is successfully obtained, wherein the program head file comprises a starting address of the service program file,
the physical address of the first entity unit is different from the physical address of the second entity unit, and the physical address of the second entity unit is generated through a first address in the read-only memory;
reading a third abstract from the second entity unit, wherein the third abstract is generated by performing a second hash operation on a program header file of the service program file by an upper computer, and the third abstract is written into the second entity unit along with the program header file of the service program file;
reading the program header file of the service program file in the second entity unit into the buffer memory, and executing a second hash operation on the program header file of the service program file to obtain a fourth abstract;
judging whether the third abstract is consistent with the fourth abstract, if so, judging that the program header file of the business program file burnt into the second entity unit is complete;
If the program head files are inconsistent, judging that the program head files of the business program files burnt into the second entity unit are incomplete, and writing the program head files of the business program files into the second entity unit again;
restarting the memory storage device, and judging whether the starting address of the business program file can be addressed from the read-only memory;
if yes, the firmware burning operation is finished, and the successful completion of the firmware burning is indicated.
2. The firmware burning method according to claim 1, wherein after writing a boot program file and a function library file into the read only memory, comprising:
judging whether the boot program file can be loaded from the read-only memory;
if yes, reading the bootstrap file and the function library file into the buffer memory, and executing first hash operation on the bootstrap file and the function library file to obtain a first abstract;
if not, writing the bootstrap file into the read-only memory until the bootstrap file can be successfully loaded.
3. The firmware burning method according to claim 1, comprising:
after judging that the program header file of the business program file burnt into the second entity unit is complete;
Reading a fifth abstract from the second entity unit, wherein the fifth abstract is generated by performing a third hash operation on a program main body file of the service program file by an upper computer, and the fifth abstract is written into the second entity unit along with the program main body file of the service program file;
reading the program main body file of the service program file in the first entity unit into the buffer memory, and executing a third hash operation on the program main body file of the service program file to obtain a sixth abstract;
judging whether the fifth abstract is consistent with the sixth abstract, if so, judging that the program main body file of the business program file burnt into the first entity unit is complete, and ending the burning of the business program file;
if the program main files are inconsistent, judging that the program main files of the business program files burnt into the first entity unit are incomplete, and writing the program main files of the business program files into the first entity unit again;
and responding to the fifth abstract and the sixth abstract to be consistent, and completing the burning of the program main body file of the business program file.
4. The firmware burning method of claim 1, further comprising:
and in the process of writing the business program file into the memory module, performing read protection on the entity unit in which the business program file is being written.
5. The firmware burning method of claim 4, further comprising:
after writing the business program file to the memory module, write protection is performed on the first entity unit and the second entity unit.
6. A memory storage device comprising a memory controller, wherein the memory controller is configured to perform the steps of the firmware burning method of any of claims 1-5.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211507872.8A CN115599407B (en) | 2022-11-29 | 2022-11-29 | Firmware burning method, firmware burning system and memory storage device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211507872.8A CN115599407B (en) | 2022-11-29 | 2022-11-29 | Firmware burning method, firmware burning system and memory storage device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN115599407A CN115599407A (en) | 2023-01-13 |
| CN115599407B true CN115599407B (en) | 2023-08-15 |
Family
ID=84852232
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211507872.8A Active CN115599407B (en) | 2022-11-29 | 2022-11-29 | Firmware burning method, firmware burning system and memory storage device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115599407B (en) |
Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103914658A (en) * | 2013-01-05 | 2014-07-09 | 展讯通信（上海）有限公司 | Safe starting method of terminal equipment, and terminal equipment |
| CN104461641A (en) * | 2014-12-15 | 2015-03-25 | 福州瑞芯微电子有限公司 | Data burning and writing method, system and equipment and target equipment |
| US9213881B1 (en) * | 2014-06-13 | 2015-12-15 | The Code Corporation | Providing operating instructions for a barcode reader from a server |
| CN113741792A (en) * | 2020-05-29 | 2021-12-03 | 广州极飞科技股份有限公司 | Method for storing data by single chip microcomputer, single chip microcomputer and readable storage medium |
| CN113806774A (en) * | 2021-09-15 | 2021-12-17 | 惠州市德赛电池有限公司 | Encryption method, decryption method and system |
| CN114398598A (en) * | 2021-12-31 | 2022-04-26 | 乐鑫信息科技（上海）股份有限公司 | Library file encryption method, decryption method and encryption device |
| CN114416147A (en) * | 2022-01-21 | 2022-04-29 | 深圳宏芯宇电子股份有限公司 | Firmware loading method, memory and computer readable storage medium |
| CN114756885A (en) * | 2022-05-20 | 2022-07-15 | 深圳宏芯宇电子股份有限公司 | Firmware loading method, storage device and computer readable storage medium |
| CN115129332A (en) * | 2022-08-30 | 2022-09-30 | 深圳市航顺芯片技术研发有限公司 | Firmware burning method, computer equipment and readable storage medium |
| CN115390880A (en) * | 2022-09-14 | 2022-11-25 | 广州八爪鱼教育科技有限公司 | Firmware upgrading method and device, storage medium and electronic equipment |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP7393226B2 (en) * | 2020-01-29 | 2023-12-06 | キヤノン株式会社 | Information processing equipment and how to start it |
-
2022
- 2022-11-29 CN CN202211507872.8A patent/CN115599407B/en active Active
Patent Citations (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103914658A (en) * | 2013-01-05 | 2014-07-09 | 展讯通信（上海）有限公司 | Safe starting method of terminal equipment, and terminal equipment |
| US9213881B1 (en) * | 2014-06-13 | 2015-12-15 | The Code Corporation | Providing operating instructions for a barcode reader from a server |
| CN104461641A (en) * | 2014-12-15 | 2015-03-25 | 福州瑞芯微电子有限公司 | Data burning and writing method, system and equipment and target equipment |
| CN113741792A (en) * | 2020-05-29 | 2021-12-03 | 广州极飞科技股份有限公司 | Method for storing data by single chip microcomputer, single chip microcomputer and readable storage medium |
| CN113806774A (en) * | 2021-09-15 | 2021-12-17 | 惠州市德赛电池有限公司 | Encryption method, decryption method and system |
| CN114398598A (en) * | 2021-12-31 | 2022-04-26 | 乐鑫信息科技（上海）股份有限公司 | Library file encryption method, decryption method and encryption device |
| CN114416147A (en) * | 2022-01-21 | 2022-04-29 | 深圳宏芯宇电子股份有限公司 | Firmware loading method, memory and computer readable storage medium |
| CN114756885A (en) * | 2022-05-20 | 2022-07-15 | 深圳宏芯宇电子股份有限公司 | Firmware loading method, storage device and computer readable storage medium |
| CN115129332A (en) * | 2022-08-30 | 2022-09-30 | 深圳市航顺芯片技术研发有限公司 | Firmware burning method, computer equipment and readable storage medium |
| CN115390880A (en) * | 2022-09-14 | 2022-11-25 | 广州八爪鱼教育科技有限公司 | Firmware upgrading method and device, storage medium and electronic equipment |
Also Published As
| Publication number | Publication date |
|---|---|
| CN115599407A (en) | 2023-01-13 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20100058073A1 (en) | Storage system, controller, and data protection method thereof | |
| TWI536199B (en) | Data protection method, memory control circuit unit and memory storage device | |
| US11088856B2 (en) | Memory storage system, host system authentication method and memory storage device | |
| US11736276B2 (en) | Delegation of cryptographic key to a memory sub-system | |
| US8996933B2 (en) | Memory management method, controller, and storage system | |
| CN109445705B (en) | Firmware authentication method and solid state disk | |
| TWI443517B (en) | Memory stroage apparatus, memory controller and password verification method | |
| US11960632B2 (en) | Data attestation in memory | |
| TW201333701A (en) | Data protecting method, memory controller and memory storage device | |
| US11683155B2 (en) | Validating data stored in memory using cryptographic hashes | |
| US11157181B2 (en) | Card activation device and methods for authenticating and activating a data storage device by using a card activation device | |
| CN113632066A (en) | Error identification in executed code | |
| US11669643B2 (en) | Block chain based validation of memory commands | |
| CN115599407B (en) | Firmware burning method, firmware burning system and memory storage device | |
| JP2022527903A (en) | Secure communication when accessing the network | |
| CN113826071A (en) | Over-the-air update acknowledgement | |
| CN115688120A (en) | Secure chip firmware importing method, secure chip and computer readable storage medium | |
| CN110069934B (en) | Memory storage system, host system verification method and memory storage device | |
| US11468159B2 (en) | Memory system | |
| CN103778073A (en) | Data protection method, mobile communication device and storage storing device | |
| CN116627314A (en) | Semiconductor device and system and method for managing secure operation thereof |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |