Magnetic disk apparatus

The integration of a non-volatile memory and encryption key management system in magnetic disk drives addresses the issue of unauthorized updates and firmware damage, ensuring secure and reliable firmware operations.

JP2025099160APending Publication Date: 2025-07-03KK TOSHIBA +1
View PDF 3 Cites 0 Cited by

Patent Information

Application Number
JP2023215598
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Filing Date
2023-12-21
Publication Date
2025-07-03

AI Technical Summary

Technical Problem

Magnetic disk drives lack protection against unintended firmware updates and do not have a mechanism to detect and repair firmware damage, leading to potential operational failures.

Method used

Incorporation of a non-volatile memory with a firmware area and a key area for storing encryption keys, along with a controller that manages firmware updates and determines firmware integrity, enabling secure and reliable updates and repairs.

Benefits of technology

Ensures secure firmware updates and automatic repair, maintaining the firmware in a normal state and enhancing the reliability of the magnetic disk drive.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 2025099160000001_ABST
    Figure 2025099160000001_ABST
Patent Text Reader

Abstract

To provide a magnetic disk apparatus with high reliability which maintains a firmware in its normal state.SOLUTION: The present invention is directed to a magnetic disk apparatus provided with: a non-volatile memory having a firmware region in which firmware is stored and a cryptographic key region in which a first cryptographic key is stored; and a controller for reading the first cryptographic key from the cryptographic key region to, if information including a second cryptographic key is programmed in the cryptographic key region, allow the firmware to be updated.SELECTED DRAWING: Figure 2
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] Embodiments of the present invention relate to a magnetic disk drive.

Background Art

[0002] In a magnetic disk drive, firmware update (rewrite) is performed by protocol communication between a SoC (System-on-a-Chip) that constitutes a main controller and a non-volatile memory that stores the firmware. Conventionally, a magnetic disk drive does not have a protection function for firmware update (rewrite). Therefore, an unintended firmware update may be performed from the outside. Also, conventionally, when the firmware is damaged, it does not have a function to detect and repair the damage of the firmware at arbitrary intervals. If the firmware is not in a normal state due to damage or an unintended update, the magnetic disk drive may not start. When the magnetic disk drive falls into a state where it does not start, it becomes difficult to analyze the state.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Patent Document 2

Patent Document 3

Summary of the Invention

Problems to be Solved by the Invention

[0004] This embodiment provides a highly reliable magnetic disk drive that maintains the firmware in a normal state.

Means for Solving the Problems

[0005] A magnetic disk drive according to an embodiment includes a non-volatile memory having a firmware area in which firmware is stored and a key area in which a first encryption key is stored, and a controller that reads the first encryption key from the key area and enables updating of the firmware when a second encryption key is programmed into the key area.

[0006] Also, a magnetic disk drive according to an embodiment includes a host operated by a user, a non-volatile memory having a firmware area in which first firmware and second firmware are stored, and a controller that determines whether the first firmware and the second firmware are normal at each arbitrary period, and when it is determined that at least one of the first firmware and the second firmware is not normal, notifies the user via the host of information regarding whether the first firmware and the second firmware are normal.

Brief Description of the Drawings

[0007]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

DETAILED DESCRIPTION OF THE INVENTION

[0008] Hereinafter, embodiments of the present invention will be described with reference to the drawings. It should be noted that the disclosure is merely an example, and those that can be easily conceived by those skilled in the art for appropriate modifications while maintaining the gist of the invention are naturally included in the scope of the present invention. In addition, in order to make the drawings and the description clearer, the width, thickness, shape, etc. of each part may be schematically represented compared to the actual state, but this is merely an example and does not limit the interpretation of the present invention. Also, in this specification and each figure, elements that are the same as those described above with respect to the previously shown figures may be given the same reference numerals, and detailed descriptions may be appropriately omitted. Hereinafter, a magnetic disk device according to an embodiment will be described in detail with reference to the drawings.

[0009] First, the configuration of the magnetic disk device 1 will be described. FIG. 1 is a block diagram showing the configuration of the magnetic disk device 1. As shown in FIG. 1, the magnetic disk device 1 includes a rectangular housing 10, a magnetic disk 11 as a storage medium disposed within the housing 10, a spindle motor (SPM) 12 that supports and rotates the magnetic disk 11, and a magnetic head 13 having a write head 13W for writing data to the magnetic disk 11 and a read head 13R for reading data from the magnetic disk 11.

[0010] The magnetic disk device 1 includes a head actuator 14 that moves and positions the magnetic head 13 on an arbitrary track on the magnetic disk 11. The head actuator 14 includes a carriage assembly 15 that movably supports the magnetic head 13, and a voice coil motor (VCM) 16 that rotates the carriage assembly 15.

[0011] The magnetic disk device 1 includes a head amplifier IC (preamplifier) 30 that drives the magnetic head 13, a main controller 130, a driver IC 20, a nonvolatile memory 70, a volatile memory 80, and a buffer memory 90. The head amplifier IC 30 is electrically connected to the magnetic head 13. The head amplifier IC 30 includes a read amplifier and a write driver. The read amplifier amplifies a read signal read from the magnetic disk 11 by the read head 13R and outputs it to the main controller 130 (more specifically, a read / write (R / W) channel 40 described later). The write driver outputs a write current corresponding to the signal output from the R / W channel 40 to the write head 13W.

[0012] The main controller 130 and the driver IC 20 are configured, for example, on a control circuit board (not shown) provided on the back side of the housing 10. The main controller (controller) 130 is realized, for example, using a large-scale integrated circuit (LSI) called a System-on-a-Chip (SoC) in which a plurality of elements are integrated on a single chip. The main controller 130 has an R / W channel 40, a hard disk controller (HDC) 50, and a microprocessor (MPU) 60. The main controller 130 is electrically connected to the VCM 16 and the SPM 12 via the driver IC 20. The HDC 50 can be connected to a host system (host) 100.

[0013] The R / W channel 40 is a signal processing circuit for read / write data. The HDC 50 controls data transfer between the host 100 and the R / W channel 40 in response to an instruction from the MPU 60. The HDC 50 is electrically connected to the R / W channel 40, the MPU 60, the nonvolatile memory 70, the volatile memory 80, and the buffer memory 90. Note that the main controller 130 (HDC 50) and the nonvolatile memory 70 may be connected via a wireless connection.

[0014] The non-volatile memory 70 is a semiconductor memory that records data stored even when the power supply is cut off. In one example, the non-volatile memory 70 is a flash ROM (Flash Read Only Memory: FROM). The non-volatile memory 70 has a firmware area 71 in which firmware is stored and a key area 72 in which an encryption key is stored. In one example, two pieces of firmware are stored in the firmware area 71. In the key area 72, an address different from that of the firmware area 71 is assigned in the non-volatile memory 70. Also, the initial value of the encryption key when the magnetic disk device 1 is manufactured is a unique value, for example, the serial number of the control circuit board.

[0015] The volatile memory 80 is a semiconductor memory in which data stored is lost when the power supply is cut off. The volatile memory 80 stores data necessary for processing in each part of the magnetic disk device 1. The volatile memory 80 is, for example, a DRAM (Dynamic Random Access Memory) or an SDRAM (Synchronous Dynamic Random Access Memory). The buffer memory 90 is a semiconductor memory that temporarily records data transmitted and received between the magnetic disk device 1 and the host 100. Note that the buffer memory 90 may be integrally configured with the volatile memory 80. The buffer memory 90 is, for example, a DRAM, an SRAM (Static Random Access Memory), an SDRAM, a FeRAM (Ferroelectric Random Access memory), an MRAM (Magnetoresistive Random Access Memory), or the like.

[0016] The MPU60 is the main control unit of the magnetic disk device 1, and executes servo control necessary for controlling read / write operations and positioning the magnetic head 13. When performing a write operation, the MPU60 controls the VCM16 via the driver IC20 according to a command from the host 100 or the like, positions the magnetic head 13 at a predetermined position on the magnetic disk 11, and writes data. When performing a read operation, the MPU60 controls the VCM16 via the driver IC20 according to a command from the host 100 or the like, positions the magnetic head 13 at a predetermined position on the magnetic disk 11, and reads data.

[0017] Here, the processing that the main controller 130 can perform will be described. When the main controller 130 receives a firmware update command (FW update command) for updating the firmware in the firmware area 71 from the host 100, the firmware can be updated by implementing a predetermined protocol (procedure) using an encryption key. The main controller 130 can read an encryption key from the encryption key area and program information including the encryption key in the encryption key area. In the following description, "program" can be read as "store", "write", or "overwrite".

[0018] The main controller 130 can change the encryption key read from the encryption key area (referred to as the "first encryption key") to a second encryption key different from the first encryption key. The main controller 130 can generate encryption key information associating the update timing, the number of updates, etc. with the encryption key when receiving an FW update command from the host 100. The main controller 130 can copy one of the two firmwares to the other.

[0019] The main controller 130 can determine whether the firmware in the firmware area 71 is normal for each arbitrary period. The above-mentioned arbitrary period is, for example, the period from the timing when the magnetic disk device 1 is started to the timing when the magnetic disk device 1 is started next. Also, the above-mentioned arbitrary period can be appropriately changed by a command from the user via the host 100.

[0020] When the firmware is not normal, the main controller 130 can notify the user of information regarding whether the firmware is normal via the host 100. Furthermore, the main controller 130 can repair the firmware by copying the firmware determined to be normal to the firmware determined to be not normal. As described above, the magnetic disk device 1 is configured.

[0021] Next, the process for updating the firmware will be described. FIG. 2 is a flowchart showing the procedure when updating the firmware. FIG. 3 is a block diagram for explaining the update of the firmware. As shown in FIGS. 2 and 3, when the main controller 130 receives an FW update command from the host 100 (S1a) and the process for updating the firmware is started, the main controller 130 reads an encryption key (referred to as the "first encryption key") from the encryption key area 72 (S2a).

[0022] Next, the main controller 130 changes the first encryption key to a second encryption key different from the first encryption key (S3a). More specifically, the main controller 130 adds a randomly generated random value α to the first encryption key to change the first encryption key to the second encryption key. The random value α is, for example, a pseudo-random number or a random variable. Subsequently, the main controller 130 generates key information associating the second encryption key with information on the update timing and the number of updates (S4a). More specifically, the main controller 130 attaches a time stamp of the update timing and the number of updates to the end of the second encryption key.

[0023] Thereafter, the main controller 130 programs the key information into the key area 72 (S5a). In one example, when the key information is programmed into the key area 72, the firmware in the non-volatile memory 70 outputs a notification signal notifying the main controller 130 that the key information has been programmed. Next, the main controller 130 determines whether the key information has been programmed into the key area 72 (S6a). In one example, depending on whether the main controller 130 has received the notification signal, it is determined whether the key information has been programmed into the key area 72.

[0024] If it is determined that the key information has not been programmed into the key area 72 (S6a), the main controller 130 proceeds to step S2a. Although not shown in FIG. 2, when determined as above, the main controller 130 may end the process to update the firmware. If it is determined that the key information has been programmed into the key area 72 (S6a), the main controller 130 enables the update of the firmware (S7a). More specifically, the main controller 130 releases the protection of the firmware area 71 by setting the protect bit in the firmware area 71 to 0.

[0025] Subsequently, the main controller 130 updates the firmware according to the FW update command from the host 100 (S8a). Here, an example of the procedure of step S8a is described below. The main controller 130 acquires information of one of the two firmware (for example, the first firmware F1). Then, if the firmware is encrypted, the main controller 130 decrypts the firmware, updates the firmware according to the FW update command, and encrypts the updated firmware. And the main controller 130 transmits the updated firmware to the firmware area 71.

[0026] Thereafter, the main controller 130 duplicates the updated firmware (S9a). More specifically, the main controller 130 copies the updated one of the firmware (for example, the first firmware F1) to the other firmware (for example, the second firmware F2). Next, the main controller 130 prohibits the update of the firmware (S10a) and ends the process for updating the firmware. For step S10a, more specifically, the main controller 130 protects the firmware area 71 by setting the protect bit in the firmware area 71 to 1.

[0027] In this embodiment, steps S3a and S4a may not be performed. In that case, after reading the first encryption key from the encryption key area 72 (S2a), the main controller 130 programs the encryption key area 72 with encryption key information including a second encryption key identical to the first encryption key (S5a). Also, in this embodiment, step S3a may not be performed. In that case, after reading the first encryption key from the encryption key area 72 (S2a), the main controller 130 generates encryption key information in which information on the update time is associated with a second encryption key identical to the first encryption key (S4a). Furthermore, in this embodiment, step S4a may not be performed. In that case, after changing the first encryption key to a second encryption key different from the first encryption key (S3a), the main controller 130 programs the encryption key area 72 with encryption key information including a second encryption key different from the first encryption key (S5a).

[0028] Next, a process of detecting and repairing the state of the firmware will be described. FIG. 4 is a flowchart showing an example of the procedure of a process of detecting and repairing the state of the firmware. FIG. 5 is a flowchart showing an example of the procedure of a process of detecting and repairing the state of the firmware following FIG. 4. FIG. 6 is a flowchart showing an example of the procedure of a process of detecting and repairing the state of the firmware following FIG. 4. FIG. 7 is a block diagram for explaining the repair of the firmware when one of the first firmware or the second firmware is normal and the other is not normal.

[0029] As shown in FIGS. 4 to 7, when the process of detecting and repairing the state of the firmware is started, first, the main controller 130 detects the presence or absence of damage to the first firmware F1 and the second firmware F2 (S1b), and performs error correction by ECC (Error Correction Code) on the codes of the first firmware F1 and the second firmware (S2b). ECC is a method used to correct data errors. In step S2b, the error correction by ECC may be performed by the firmware in the firmware area 71 in the program.

[0030] Next, the main controller 130 determines whether the first firmware F1 is normal (S3b), and then determines whether the second firmware F2 is normal (S4b, S5b). In one example, the main controller 130 determines as normal when no damage is detected in step S1b or when error correction is possible in step S2b. Further, the main controller 130 determines as not normal when damage is detected in step S1b and error correction is not possible in step S2b.

[0031] When it is determined that both the first firmware F1 and the second firmware F2 are normal (S3b, S4b), the main controller 130 proceeds to step S1b. When it is determined that both the first firmware F1 and the second firmware F2 are not normal (S3b, S5b), the main controller 130 notifies the user via the host 100 that the first firmware F1 and the second firmware F2 are not normal (S6b), detects the state of the firmware, and ends the process of repairing. Regarding step S6b, more specifically, the main controller 130 raises an alarm indicating that both the first firmware F1 and the second firmware F2 are irreparable.

[0032] When it is determined that the first firmware F1 is not normal (S3b) and the second firmware F2 is determined to be normal (S5b), the main controller 130 notifies the user via the host 100 that the first firmware F1 is not normal (S7b). More specifically, the main controller 130 raises an alarm indicating that the first firmware F1 is damaged and the second firmware F2 is normal.

[0033] Next, the main controller 130 reads the second firmware F2 determined to be normal (S8b), sets the protection bit to 0 to enable firmware update (S9b). Subsequently, the main controller 130 copies the second firmware F2 to the first firmware F1 (S10b), sets the protection bit to 1 to prohibit firmware update (S11b), detects the state of the firmware, and ends the process of repairing.

[0034] When it is determined that the first firmware F1 is normal (S3b) and the second firmware F2 is determined to be not normal (S4b), the main controller 130 notifies the user via the host 100 that the second firmware F2 is not normal (S12b). More specifically, the main controller 130 raises an alarm indicating that the second firmware F2 is damaged and the first firmware F1 is normal.

[0035] Next, the main controller 130 reads the first firmware F1 determined to be normal (S13b), sets the protection bit to 0, and enables firmware update (S14b). Subsequently, the main controller 130 copies the first firmware F1 to the second firmware F2 (S15b), sets the protection bit to 1 to prohibit firmware update (S16b), detects the state of the firmware, and ends the process of repairing.

[0036] The effects of this embodiment will be described. According to the magnetic disk device 1 according to this embodiment, when the main controller 130 reads the first encryption key and programs the information including the second encryption key, the firmware update is enabled. Thereby, the firmware is protected from unauthorized updates. Furthermore, the initial value of the encryption key is the serial number of the control circuit board. Thereby, the initial value of the encryption key can be set to a unique value different from that of other magnetic disk devices.

[0037] The main controller 130 changes the first encryption key to a second encryption key different from the first encryption key. Thereby, the protection performance of the firmware can be improved. The main controller 130 generates encryption key information associating the update time information with the second encryption key. Thereby, it can be determined whether the firmware update has been intentionally performed. With the above-described configuration using the encryption key, the security level of the firmware can be improved, and it can be suppressed that the firmware becomes in an abnormal state due to an unauthorized update.

[0038] The main controller 130 determines whether the first firmware F1 and the second firmware F2 are normal. If it is determined that at least one of the first firmware F1 and the second firmware F2 is abnormal, information regarding whether the first firmware F1 and the second firmware F2 are normal is notified to the user. Thereby, the user can recognize the abnormality of the firmware.

[0039] The main controller 130 determines whether the firmware is normal based on error correction and detection of damage by ECC. Further, error correction and detection of damage by ECC can be performed at arbitrary intervals. Thereby, the user can determine whether the firmware is normal at an interval desired by the user. When the main controller 130 determines that one of the two firmwares is normal and the other firmware is abnormal, the firmware determined to be normal is copied to the firmware determined to be abnormal. Thereby, even if one of the firmwares is damaged, the firmware can be automatically repaired. In summary, with the above-described configuration, the firmware can be maintained in a normal state, and the highly reliable magnetic disk device 1 can be obtained.

[0040] Although the embodiments of the present invention have been described, the above embodiments are presented as examples and are not intended to limit the scope of the invention. The novel embodiments described above can be implemented in various other forms, and various omissions, replacements, and changes can be made without departing from the gist of the invention. The above embodiments and their modifications are included in the scope and gist of the invention, and are included in the invention described in the claims and the equivalent scope thereof.

Explanation of Reference Numerals

[0041] 1... Magnetic disk device, 11... Magnetic disk, 13... Magnetic head, 60... MPU, 70... Non-volatile memory, 71... Firmware area, 72... Encryption key area, 100... Host system, 130... Main controller, F1... First firmware, F2... Second firmware.

Claims

1. A non-volatile memory having a firmware area in which firmware is stored and a key area in which a first encryption key is stored; A controller that enables updating of the firmware when the first encryption key is read from the key area and information including a second encryption key is programmed into the key area. A magnetic disk drive.

2. The controller is configured on a control circuit board; The first encryption key is the serial number of the control circuit board. The magnetic disk drive according to claim 1.

3. The controller changes the first encryption key to a second encryption key different from the first encryption key. The magnetic disk drive according to claim 1.

4. The controller generates key information associating information on the firmware update timing with the second encryption key. The magnetic disk drive according to claim 1.

5. A host operated by a user; A non-volatile memory having a firmware area in which first firmware and second firmware are stored; A controller that determines, at each arbitrary period, whether the first firmware and the second firmware are normal, and when it is determined that at least one of the first firmware and the second firmware is not normal, notifies the user via the host of information regarding whether the first firmware and the second firmware are normal. A magnetic disk drive.

6. The controller: Performs error correction by ECC and detection of presence or absence of damage on the first firmware and the second firmware at each arbitrary period; Determines that it is normal when error correction is possible or when there is no damage; Determines that it is not normal when error correction is not possible and there is damage. The magnetic disk drive according to claim 5.

7. When the controller determines that the first firmware is normal and the second firmware is not normal, the controller copies the first firmware to the second firmware. The magnetic disk drive according to claim 5.

Citation Information

Patent Citations

  • Information processor with function to automatically restore firmware

    JP2004054616A

  • Image processor and firmware upgrading method

    JP2007011944A

  • Information processor and firmware update method

    JP2009009237A