Memory system and controller

Abstract

To provide a memory system that achieves both reduction in interrupt latency and non-interruption of security processing.SOLUTION: According to an embodiment, a memory system includes a nonvolatile memory and a controller. The controller includes a security block that provides a security function related to the nonvolatile memory. The security block includes a first 1CPU and a second 2CPU. The first 1CPU executes communication with the outside requesting a security function, receives interruption generated in the security block, and executes task management in the security block so that security processing corresponding to the request is executed as one task without interruption. The first 2CPU executes security processing under the control of the first 1CPU.SELECTED DRAWING: Figure 2

Description

[Technical Field]

[0001] FIELD OF THE INVENTION Embodiments of the present invention relate to memory systems and controllers. [Background technology]

[0002] It is becoming commonplace these days for embedded devices to incorporate security functions. While some security functions are simply for the purpose of security, such as in IC (integrated circuit) cards, in other devices that play video, such as Blu-ray Disc players, STBs (set top boxes), and network-connected streaming devices, security functions are important components that enable the functionality and services of those devices.

[0003] In general, security-related processes are required to be initiated when necessary, completed without interruption, and to erase traces of critical security parameters and other information used in the process when the process is terminated. This is because there are attacks that intentionally interrupt security-related or related processes to obtain and use security-related information from system memory or cache memory, which is a resource of the central processing unit (CPU). On the other hand, as an embedded device, it is necessary to implement interrupt processing to realize the device's functions, and depending on the implementation, it may be necessary to interrupt security processing.

[0004] The role of the OS (operating system) in embedded systems is also important. When a security function runs as a task on the OS, the security function is not only subject to interruptions due to CPU exceptions and external interrupts, but its execution is also controlled by the OS scheduler, with dispatching taking place according to priority. A task that handles a security function cannot resume processing unless certain conditions are met, such as its priority and position in the ready queue managed by the OS. This situation is not ideal for security processing.

[0005] One type of embedded device is one in which security processing is performed by a dedicated CPU, with pioneering examples being the B-cas card in televisions and the TPM (Trusted Platform Module) in personal computers. However, even mechanisms that independently handle security processing like this are not immune to the use of CPU exceptions, interrupts, and dispatching by the OS. [Prior art documents] [Patent documents]

[0006] [Patent Document 1] US Patent Application Publication No. 2022 / 0334847 [Patent Document 2] US Patent Application Publication No. 2015 / 0013002 [Patent Document 3] US Patent Application Publication No. 2012 / 0204059 Summary of the Invention [Problem to be solved by the invention]

[0007] One embodiment of the present invention provides a memory system and controller that reduces interrupt latency while providing uninterrupted security processing. [Means for solving the problem]

[0008] According to an embodiment, a memory system includes a nonvolatile memory and a controller. The controller has a security block that provides security functions related to the nonvolatile memory. The security block includes a first CPU and a second CPU. The first CPU executes communication with an external device that requires a security function, accepts interrupts that occur within the security block, and performs task management within the security block to ensure that security processing corresponding to the request is executed without interruption, treating the security processing as one task. The second CPU executes security processing under the control of the first CPU. [Brief explanation of the drawings]

[0009] [Figure 1] FIG. 1 is a diagram showing an example of the configuration of a memory system according to a first embodiment. [Figure 2] FIG. 2 is a diagram showing an example of the configuration of an SECB in the memory system of the first embodiment. [Figure 3] FIG. 10 is a diagram for explaining the operation of a kernel CPU that enables a task CPU to execute security processing without interruption in the SECB of the memory system of the first embodiment. [Figure 4] FIG. 10 is a diagram for explaining optimization of power consumption by alternately using power between task CPUs / IPs, which is realized by the memory system of the second embodiment. [Figure 5] FIG. 10 is a diagram for explaining individual power control of task CPUs / IPs by a plurality of mutexes realized by the memory system of the second embodiment. [Figure 6] FIG. 11 is a diagram for explaining efficient updating of calculation parameters of a calculation unit having a plurality of channels, which is realized by the memory system of the third embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0010] Hereinafter, embodiments will be described with reference to the drawings.

[0011] (First embodiment) First, the first embodiment will be described.

[0012] Fig. 1 is a diagram showing an example of the configuration of a memory system 1 according to the first embodiment. Fig. 1 also shows an example of the configuration of an information processing system including the memory system 1 according to the first embodiment and a host 2 connected to the memory system 1. The host 2 is, for example, an information processing device such as a PC or a server.

[0013] Here, an example is shown in which the memory system 1 is realized as an SSD (solid state drive). The memory system 1 is not limited to an SSD, and can be realized as various types of data storage devices, such as an HDD (hard disk drive).

[0014] The memory system 1 includes a controller 11 and a flash memory 12. The flash memory 12 here is a NAND-type flash memory.

[0015] The controller 11 writes data to the flash memory 12 and reads data from the flash memory 12 in response to commands from the host 2. The controller 11 is realized as, for example, an SoC (system on a chip).

[0016] The controller 11 includes a processor 111, a host interface unit 112, a memory interface unit 113, a system memory 114, a bus controller 115, a memory controller 116, and a security block (SECB) 117. The units within the controller 11 are interconnected via a system bus.

[0017] The processor 111 is a device that comprehensively controls the operation of the memory system 1. Specifically, the processor 111 controls the operations of the host interface unit 112, the memory interface unit 113, the system memory 114, the bus controller 115, the memory controller 116, and the SECB 117 as appropriate.

[0018] The host interface unit 112 is a PCI Express TM (PCIe TM ) or other interface standards. The host interface unit 112 stores write data received from the host 2 in the system memory 114, or transmits read data that has been read from the flash memory 12 and stored in the system memory 114 to the host 2. The host interface unit 112 can supply an interrupt signal to the processor 111 or the SECB 117 using a data path whose purpose is defined in advance. For example, the host interface unit 112 can notify the processor 111 or the SECB 117 by an interrupt signal that it has received a command from the host 2. The host interface unit 112 has a function of analyzing a command from the host 2 to determine whether it is a command that should be notified to the processor 111 or the SECB 117.

[0019] The memory interface unit 113 is a circuit that controls writing of data to the flash memory 12 and reading of data from the flash memory 12. Specifically, the memory interface unit 113 writes write data stored in the system memory 114 to the flash memory 12, or reads data from the flash memory 12 and stores it in the system memory 114 as read data.

[0020] The system memory 114 is a storage medium used as a working area for each unit in the controller 11. The system memory 114 is, for example, an SRAM (static RAM [random access memory]).

[0021] The bus controller 115 is a device that arbitrates the acquisition of the right to use the system bus. When a conflict occurs between two or more devices connected to the system bus over the acquisition of the right to use the system bus, the bus controller 115 grants the right to use the system bus to those devices in a time-sharing manner, for example.

[0022] The memory controller 116 is a circuit that controls, based on instructions from the processor 111, the allocation of areas in the system memory 114 for temporarily storing write data and read data, and the release of allocated areas in the system memory 114 in which write data that has been written to the flash memory 12 and read data that has been transferred to the host 2 are stored.

[0023] The SECB 117 is a device that provides security functions related to the flash memory 12. The SECB 117 has a dedicated CPU that handles security processing. Details of the dedicated CPU that the SECB 117 has and handles security processing will be described later.

[0024] The SECB 117 performs security processing such as authenticating users who are permitted to write data to or read data from the flash memory 12. The controller 11 prohibits users who have failed authentication by the SECB 117 from accessing data in the flash memory 12.

[0025] The SECB 117 may have a function of allocating an area of ​​the flash memory 12 for each user who is permitted to access data in the flash memory 12. In this case, it is possible to prevent data written to the flash memory 12 by one user from being read from the flash memory 12 by another user. The SECB 117 may also have a function of generating and managing an encryption key for each user who is permitted to access data in the flash memory 12. In this case, by using a different encryption key for each user generated and managed by the SECB 117 to encrypt write data and write it to the flash memory 12, or by decrypting encrypted read data read from the flash memory 12, it is possible to substantially prevent data in the flash memory 12 from being stolen by a third party even if the memory system 1 is taken away.

[0026] The security processing performed by the SECB 117 is not limited to user authentication and may include various other processing. For example, the security processing performed by the SECB 117 may include allocating an area in the flash memory 12 and generating and managing an encryption key for each user. Furthermore, the security processing performed by the SECB 117 may include encrypting and decrypting data using an encryption key that the SECB 117 generates and manages.

[0027] 2 is a diagram showing an example of the configuration of the SECB 117 in the memory system 1 of the first embodiment. In FIG. 2, application [A] 101, application [B] 101, and application [C] 101 are programs executed by the processor 111 of the controller 11, and each of them can request the SECB 117 to execute security processing. In other words, these are external modules that request security functions.

[0028] For example, assume that while a dedicated CPU for security processing of SECB 117 is executing security processing in response to a request from application [A] 101, application [B] 101 requests SECB 117 to execute security processing. In this case, an interrupt process occurs within SECB 117 to accept the request from application [B] 101. Generally, to handle this interrupt process, the dedicated CPU for security processing of SECB 117 must suspend the ongoing security process that responds to the request from application [A] 101. Suspending security processing is undesirable from the perspective of preserving security-related information.

[0029] On the other hand, if interrupts are not accepted while a certain security process is being executed, the interrupt latency time from when an interrupt occurs until the interrupt is accepted (not until the interrupt process starts) increases.

[0030] Therefore, the SECB 117 in the memory system 1 of the first embodiment is provided with a mechanism for achieving both a reduction in the interrupt latency time and non-interruption of security processing, which will be described in detail below.

[0031] As shown in FIG. 2, the SECB 117 includes a kernel CPU 21, a task CPU 22, a shared memory 23, and a plurality of processing circuits (IPs: intellectual property) [1, 2, . . . , N] 24.

[0032] In an embedded system with a dedicated CPU for security processing, some means of communication is required between the CPU that handles applications and the CPU that handles security processing. Here, this communication mechanism is called a mailbox. However, this is not intended for a specific OS specification or specific hardware, and is positioned here as a general-purpose means of communication between CPUs.

[0033] A single CPU responsible for security processing receives requests via a mailbox and executes the processing corresponding to that request, but it is assumed that the request originates from multiple tasks running on a CPU running multiple applications or on a CPU running a single application. In this case, communication between CPUs should be protected by an exclusive control mechanism (for example, a semaphore or mutex). However, if multiple tasks running on a single CPU use this mailbox, it is sufficient to simply set the short period during which the mailbox is operated as an interrupt disabled section (or task dispatch disabled section).

[0034] On the other hand, the CPU dedicated to security processing must receive requests from multiple tasks via mailboxes and manage them appropriately, regardless of the processing status. In this case, in order to minimize interruptions to security processing, in the memory system 1 of the first embodiment, the SECB 117 is configured with two CPUs dedicated to security processing (a kernel CPU 21 and a task CPU 22).

[0035] Here, one CPU (kernel CPU 21) is positioned as the kernel CPU, and is responsible for operating system functions such as accepting interrupts from the mailbox 31 and IP 24, receiving requests from outside and sending responses to outside, managing the priority of received requests, and managing tasks. The other CPU (task CPU 22) is positioned as the task CPU that executes security processing based on instructions from the kernel CPU 21. The task CPU 22 is controlled by the kernel CPU 21 via the shared memory 23. The task CPU 22 also requests processing from one or more IPs 24 as necessary.

[0036] With reference to FIG. 3, the operation of the kernel CPU 21 for enabling the task CPU 22 to execute security processing without interruption will be described.

[0037] The kernel CPU 21 manages the received requests in a priority-based queue (mailbox queue 41) based on the processing priority assigned to the received requests. The kernel CPU 21 creates the mailbox queue 41 in the shared memory 23, for example.

[0038] 3 shows an example in which four commands, namely, command Y having the highest priority, command F and command D having the second highest priority, and command G having the lowest priority, are managed in the mailbox queue 41 by the kernel CPU 21. Commands F and D, which have the same priority, are arranged in the order in which they are received by the SECB 117. The execution order of the four commands shown in FIG. 3 is command Y, command F, command D, and command G.

[0039] 3 also shows an example in which the state of the task CPU 22 is managed by the kernel CPU 21 using a wait queue 42 and a ready queue 43. Similar to the mailbox queue 41, the kernel CPU 21 creates the wait queue 42 and the ready queue 43 in the shared memory 23, for example.

[0040] When the task CPU 22 is in a waiting state, the kernel CPU 21 stores information indicating the task CPU 22 in the wait queue 42. When information indicating the task CPU 22 is stored in the wait queue 42, the kernel CPU 21 stores in the shared memory 23 information required to execute command Y, which should be executed first among the commands stored in the mailbox queue 41, and instructs the task CPU 22 to execute command Y using the information stored in the shared memory 23 (FIG. 3(1)). At this time, the kernel CPU 21 deletes command Y from the mailbox queue 41.

[0041] When the kernel CPU 21 determines that the task CPU 22 is able to process command Y, it removes the information indicating the task CPU 22 from the wait queue 42 and connects it to the ready queue 43, changing the state of the task CPU 22 to the execution (run) state (FIG. 3(2)). The fact that the task CPU 22 is able to process command Y means that the information indicating the task CPU 22 is connected to the wait queue 42. When the task CPU 22 has finished processing command Y, the kernel CPU 21 removes the information indicating the task CPU 22 from the ready queue 43 and moves it to the wait queue 42. When the information indicating the task CPU 22 is in the wait queue 42, the kernel CPU 21 causes the task CPU 22 to execute a command waiting for execution in the mailbox queue 41, if any. In other words, the kernel CPU 21 stores information required to execute command F, which is to be executed next, in the shared memory 23, and instructs the task CPU 22 to execute command F using the information stored in the shared memory 23.

[0042] In this way, the kernel CPU 21 monitors the state of the task CPU 22. At this time, the kernel CPU 21 refers to and operates the control information of the task CPU 22. This may have the same data structure as a TCB (task control block) that is generally used when an OS controls a task.

[0043] If the state of the task CPU 22 recorded in the TCB is waiting to receive a request (from the kernel CPU 21), the kernel CPU 21 provides information about the processing target to the task CPU 22 via the shared memory 23, and switches the state of the task CPU 22 to the run state. At this time, the kernel CPU 21 searches the mailbox queue 41 for a high-priority request from among the managed requests, selects the highest-priority request located at the top of the mailbox queue 41 as the request to be processed, removes that request from the mailbox queue 41, and transmits it to the task CPU 22. This management of requests prevents security processing from being interrupted by interrupts, and also enables task scheduling according to processing priority. Furthermore, since the kernel CPU 21 accepts interrupts generated by the mailbox 31 or the IP 24, for example, the interrupt latency time can be reduced.

[0044] As described above, in the memory system 1 of the first embodiment, by configuring the SECB 117 to have two dedicated CPUs (kernel CPU 21 and task CPU 22) that handle security processing, it is possible to achieve both a reduction in interrupt latency time and non-interruption of security processing.

[0045] The number of CPUs dedicated to security processing is not limited to two, and may be three or more. Specifically, under the control of one kernel CPU 21, two or more task CPUs 22 may each execute a different security process.

[0046] (Second embodiment) Next, a second embodiment will be described. Similar to the first embodiment, the second embodiment is also a memory system 1 realized as, for example, an SSD, and the same components as those in the first embodiment are designated by the same reference numerals and will not be described again.

[0047] The memory system 1 of the second embodiment is an application example that utilizes the configuration described in the first embodiment, which has two CPUs, a kernel CPU 21 and a task CPU 22, and in which the task CPU 22 operates under the control of the kernel CPU 21.

[0048] Power consumption is an important issue that cannot be ignored in embedded devices. In the case of contactless IC cards that use the limited power available from the antenna, the requirement for power consumption is particularly significant, but even in automobiles that are equipped with generators, the requirement for power consumption of the onboard devices is quite strict.

[0049] In the memory system 1 of the second embodiment, power consumption is optimized by considering power as one resource and introducing appropriate execution control between the CPU (task CPU 22) and the IP (IP 24).

[0050] In the first embodiment, the TCB was introduced for the purpose of controlling the task CPU 22. In the second embodiment, each IP 24 is also regarded as a task, and the same TCB is used for controlling the task, and the state of the hardware is controlled.

[0051] Therefore, in the second embodiment, the task CPU 22 and each IP 24 are treated by the kernel CPU 21 as being equivalent to a software-implemented task, and have the same states (idle, wait, run, etc.) as normal tasks. The states of the task CPU 22 and each IP 24 are managed and controlled by the kernel CPU 21, and their operations are managed by the schedule function of the kernel CPU 21.

[0052] (1) Optimizing power consumption by alternately using power between task CPU22 / IP24 FIG. 4 is a diagram for explaining optimization of power consumption by alternately using power between the task CPU 22 / IP 24, which is realized by the memory system 1 of the second embodiment.

[0053] The kernel CPU 21 creates a mutex wait queue 51 and a ready queue 52 in, for example, the shared memory 23 .

[0054] Task CPU22 and IP24 attempt to lock mutex_0 when using power. Under mutex_0, task CPU22 and IP24 can be in either a mutex lock waiting state (power is unavailable) or a mutex locked state (power is available). Kernel CPU21 monitors these states.

[0055] As with a normal mutex, the operation of a task CPU22 or IP24 in a mutex-locked state is not hindered by a task CPU22 or IP24 waiting for the mutex to be locked. The kernel CPU21 appropriately controls the priority of a task CPU22 or IP24 in a mutex-locked state.

[0056] A single task can lock only one mutex. However, in power control, there may be exceptional cases where a system task locks multiple mutexes. When a task CPU22 or IP24 in a mutex-locked state unlocks a mutex, the task CPU22 or IP24 waiting for the mutex to be locked transitions to a mutex-locked state. After unlocking the mutex, the task CPU22 transitions to a mutex-lock waiting state after being removed from the ready queue 52. In other words, the task CPU22 is always in a state where it can return to the ready queue 52.

[0057] On the other hand, the IP 24 that has unlocked the mutex transitions to a dormant state where it is removed from the ready queue 52. The IP 24 in the dormant state transitions to a mutex lock waiting state in response to a system call from the task CPU 22.

[0058] Figure 4 shows a situation in which task CPU22, which was in the running state, unlocks mutex_0 and transitions to a power-saving state (Figure 4(1)), and IP[3]24, which was waiting to lock mutex_0, obtains the right to execute (Figure 4(2)).

[0059] (2) Individual power control of task CPU22 / IP24 using multiple mutexes FIG. 5 is a diagram for explaining individual power control of the task CPU 22 / IP 24 by a plurality of mutexes realized by the memory system 1 of the second embodiment.

[0060] When the system is started or when the entire system transitions to a power-saving state, the task CPU 22 and each IP 24 may operate independently. In such cases, an individual mutex (mutex_n) is assigned to each task CPU 22 and each IP 24.

[0061] Even in this case, the task CPU 22 and each IP 24 are under the control of the kernel CPU 21. Since an individual mutex is assigned to each task CPU 22 and each IP 24, the task CPU 22 and each IP 24 can, in principle, operate simultaneously. For example, mutex_1 is assigned to the task CPU 22, and mutex_n with subsequent numbers, such as mutex_2, is assigned to the other IPs 24.

[0062] The task CPU 22 or IP 24 that locks these mutexes transitions to a special priority on the ready queue 52, and all tasks are assumed to be in the run state at that special priority. For example, at system startup, the task CPU 22, IP 24, and programs running on the task CPU 22 require initialization and initial settings, and furthermore, testing must be performed. By performing these tasks simultaneously in parallel, the startup time can be shortened.

[0063] On the other hand, these mutexes are also allowed to be locked by the power control IP. The power control IP locks these mutexes when the entire system transitions to a power-saving state. When transitioning to a power-saving state, the power control IP attempts to lock all mutexes. When the task CPU 22 and each IP 24 unlock their respective mutexes, all mutexes are locked by the power control IP. The task CPU 22 and each IP 24 transition to a dormant state and are no longer able to lock mutexes.

[0064] As a result, when the situation is realized in which there are no active tasks on the ready queue 52, the kernel CPU 21 permits the power control IP to transition to the power saving state.

[0065] For example, in the example of Figure 5, a low-priority power-saving task managed by the kernel CPU 21 locks mutex_1 to mutex_N in advance. When it is determined that a transition to a power-saving state is necessary, the kernel CPU 21 sends a message to tasks other than the power-saving task. Upon receiving this message, each task attempts to lock mutex_1 to mutex_N, which are dedicated to that task. When all tasks have transitioned to the mutex lock waiting state, the power-saving task obtains execution rights and transitions the entire system to a power-saving state.

[0066] As described above, the memory system 1 of the second embodiment can optimize power consumption by considering power as one resource and introducing appropriate execution control between the task CPU 22 and each IP 24 by the kernel CPU 21.

[0067] (Third embodiment) Next, a third embodiment will be described. Similar to the first embodiment, the third embodiment is also a memory system 1 realized as, for example, an SSD, and the same components as those in the first embodiment are designated by the same reference numerals, and their description will be omitted.

[0068] The memory system 1 of the third embodiment is also an application example that utilizes the configuration described in the first embodiment, which has two CPUs, a kernel CPU 21 and a task CPU 22, and in which the task CPU 22 operates under the control of the kernel CPU 21. Specifically, it realizes efficient updating of calculation parameters of a calculation unit having multiple channels.

[0069] FIG. 6 is a diagram for explaining efficient updating of the calculation parameters of a calculation unit having a plurality of channels, which is realized by the memory system 1 of the third embodiment.

[0070] As shown in Fig. 6, it is assumed here that a computing unit 62 having a DMA (direct memory access) controller 61 is connected to a system bus, and that multiple tasks operate this computing unit 62. In order to accept multiple processes, an interface 63 including multiple channels is implemented in the DMA controller 61. The computing unit 62 is equipped with multiple computing methods, and the computing method can be specified via the interface 63 by selecting a channel.

[0071] On the other hand, if parameters related to a specific calculation method are changed at any timing, it becomes extremely difficult to control the calculator 62. If security processing were to change the parameters of the calculator 62, it would require procedures such as stopping requests to the calculator 62 and confirming that the calculator 62 has stopped, which would force the interruption of processing due to factors other than an interrupt.

[0072] To avoid such a situation, in the third embodiment, each channel of the arithmetic unit 62 is made into a task. The task CPU 22 notifies the kernel CPU 21 of the arithmetic method to be changed and the parameters to be updated (FIG. 6(1)). Upon receiving this notification, the kernel CPU 21 generates a parameter change task to be managed by itself (FIG. 6(2)).

[0073] When the parameter change task transitions to the run state, it attempts to lock Mutex_algorithm#N, which corresponds to the algorithm to be operated. If locking this mutex is successful, the parameter change task accesses the arithmetic unit 62 and updates the parameters of the target algorithm. After updating the parameters, the parameter change task unlocks the mutex. On the other hand, if the mutex cannot be locked, the parameter change task transitions to a mutex lock waiting state, and is connected to and managed by a mutex wait queue managed by the kernel CPU 21.

[0074] In this way, in the third embodiment, each channel of the arithmetic unit 62 is treated as a task. The channel (channel task) that is requested to perform an operation attempts to lock Mutex_algorithm#N that corresponds to the specified operation method. If locking the mutex is successful, the channel setting becomes valid and the operation begins. Then, after the operation is completed, the channel task unlocks the mutex that it had locked.

[0075] When the execution rights of the channel task and the parameter change task are switched in a round-robin manner (assuming that the dispatcher is called after the calculation start setting), the mutex that the parameter change task attempts to lock may not be in a lockable state when the parameter change task transitions to the run state. In this case, the parameter change task transitions to a mutex lock waiting state and is removed from the ready queue 71 managed by the kernel CPU 21. The parameter change task locks the target mutex when it is unlocked.

[0076] In the third embodiment of the memory system 1, which is realized as an SSD or the like, the relationship between the aforementioned channel task and parameter change task can also be replaced with, for example, a relationship between a channel task that is responsible for accessing a specific namespace in accordance with a request from the host 2, and a task CPU 22 that manipulates parameters related to the specific namespace in accordance with a request from the host 2.

[0077] In this case, the memory system 1 of the third embodiment can realize access and parameter updates via a mutex corresponding to the namespace. This mechanism can eliminate unintended interruptions and delays not only in security processing but also in data access.

[0078] As described above, the memory system 1 of the third embodiment can realize efficient updating of the calculation parameters of a calculation unit having a plurality of channels.

[0079] Although several embodiments of the present invention have been described, these embodiments are presented as examples and are not intended to limit the scope of the invention. These novel embodiments can be embodied in various other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and their modifications are included within the scope and spirit of the invention, and are also included in the scope of the invention and its equivalents as defined in the claims. [Explanation of symbols]

[0080] 1...memory system, 2...host, 11...controller, 12...flash memory, 21...kernel CPU, 22...task CPU, 23...shared memory, 24...IP (intellectual property), 31...mailbox, 41...mailbox queue, 42...wait queue, 43...ready queue, 51...mutex wait queue, 52...ready queue, 61...controller, 61...DMA controller, 62...arithmetic unit, 63...interface, 71...ready queue, 111...processor, 112...host interface unit, 113...memory interface unit, 114...system memory, 115...bus controller, 116...memory controller, 117...SECB (security block).

Claims

1. a non-volatile memory; a controller having a security block that provides security functions related to the non-volatile memory; Equipped with The security block comprises: a first CPU that communicates with an external module that requests the security function, accepts an interrupt that occurs within the security block, and manages tasks within the security block so that the security processing corresponding to the request is performed as one task without interruption; a second CPU that executes the security processing under the control of the first CPU; A memory system comprising:

2. The first CPU monitoring whether the second CPU is in a standby state or an execution state; managing one or more tasks, each of which is a security process corresponding to a request from the external module, in descending order of priority; When the second CPU is in a standby state, the second CPU is caused to execute the task with the highest priority among the one or more tasks.

10. The memory system of claim 1.

3. the security block comprises a shared memory; the first CPU stores data used in the execution of the security processing in the shared memory and instructs the second CPU to execute the security processing; 10. The memory system of claim 1.

4. The first CPU creating a first queue in which requests from the external module are stored, a second queue in which information indicating the second CPU is stored when the second CPU is in a standby state, and a third queue in which information indicating the second CPU is stored when the second CPU is in an execution state in the shared memory; when a request from the external module is stored in the first queue and information indicating the second CPU is stored in the second queue, instructing the second CPU to execute the security process corresponding to the request from the external module stored in the first queue, and removing the information indicating the second CPU from the second queue and storing it in the third queue; When the second CPU has completed the security process, information indicating the second CPU is removed from the third queue and stored in the second queue.

4. The memory system of claim 3.

5. 2. The memory system of claim 1, further comprising a mailbox mechanism for communication between said external module and said first CPU.

6. the controller includes a processor; the processor requests the security function from the security block as the external module; 10. The memory system of claim 1.

7. a non-volatile memory; a controller that controls the nonvolatile memory; Equipped with the controller comprises a first CPU, a second CPU, and one or more processing circuits; the first CPU performs task management within the controller, treating the second CPU and each of the one or more processing circuits as one task, so that power supplied to the controller is used exclusively by the second CPU and any one of the one or more processing circuits; Memory system.

8. the second CPU and the one or more processing circuits exclusively acquire operation authority through an exclusive control mechanism provided in the controller; The first CPU monitoring whether the second CPU and the one or more processing circuits are in a state of having acquired the operation authority; performing task management within the controller so as to operate only either the second CPU or the one or more processing circuits that have acquired the operation authority; 8. The memory system of claim 7.

9. a non-volatile memory; a controller that controls the nonvolatile memory; Equipped with the controller includes a CPU and a computing unit having an interface including a plurality of channels, each of which is associated with a corresponding arithmetic process; the CPU manages tasks within the controller such that each of a plurality of arithmetic processes associated with the plurality of channels is treated as one task, and when a parameter update occurs for a arithmetic process associated with any one of the plurality of channels, the parameter update process is treated as one task equivalent to the plurality of arithmetic processes, and the plurality of arithmetic processes and the parameter update process are executed exclusively. Memory system.

10. the plurality of arithmetic processes and the parameter update process are exclusively authorized to be executed by an exclusive control mechanism provided in the controller; The CPU monitor whether the execution authority has been acquired for each of the plurality of arithmetic processes and the parameter update process; performing task management within the controller so that the parameter update process is executed under a condition in which all of the plurality of arithmetic processes are in a waiting state; 10. The memory system of claim 9.

11. A controller for controlling a nonvolatile memory, a security block that provides a security function related to the nonvolatile memory; The security block comprises: a first CPU that communicates with an external module that requests the security function, accepts an interrupt that occurs within the security block, and manages tasks within the security block so that the security processing corresponding to the request is performed as one task without interruption; a second CPU that executes the security processing under the control of the first CPU; A controller comprising:

12. The first CPU monitoring whether the second CPU is in a standby state or an execution state; managing one or more tasks, each of which is a security process corresponding to a request from the external module, in descending order of priority; When the second CPU is in a standby state, the second CPU is caused to execute the task with the highest priority among the one or more tasks. The controller of claim 11.

13. the security block comprises a shared memory; the first CPU stores data used in the execution of the security processing in the shared memory and instructs the second CPU to execute the security processing; The controller of claim 11.

14. The first CPU creating a first queue in which requests from the external module are stored, a second queue in which information indicating the second CPU is stored when the second CPU is in a standby state, and a third queue in which information indicating the second CPU is stored when the second CPU is in an execution state in the shared memory; when a request from the external module is stored in the first queue and information indicating the second CPU is stored in the second queue, instructing the second CPU to execute the security process corresponding to the request from the external module stored in the first queue, and removing the information indicating the second CPU from the second queue and storing it in the third queue; When the second CPU has completed the security process, information indicating the second CPU is removed from the third queue and stored in the second queue. The controller of claim 13.

15. 12. The controller of claim 11, wherein a mailbox mechanism is provided for communication between the external module and the first CPU.

16. a processor; the processor requests the security function from the security block as the external module; The controller of claim 11.

17. A controller for controlling a nonvolatile memory, A first CPU; A second CPU; one or more processing circuits; the first CPU performs task management within the controller, treating the second CPU and each of the one or more processing circuits as one task, so that power supplied to the controller is used exclusively by the second CPU and any one of the one or more processing circuits; controller.

18. the second CPU and the one or more processing circuits exclusively acquire operation authority through an exclusive control mechanism provided in the controller; The first CPU monitoring whether the second CPU and the one or more processing circuits are in a state of having acquired the operation authority; performing task management within the controller so as to operate only either the second CPU or the one or more processing circuits that have acquired the operation authority; 18. The controller of claim 17.

19. A controller for controlling a nonvolatile memory, A CPU and a computing unit having an interface including a plurality of channels, each of which is associated with a corresponding arithmetic process; the CPU manages tasks within the controller such that each of a plurality of arithmetic processes associated with the plurality of channels is treated as one task, and when a parameter update occurs for a arithmetic process associated with any one of the plurality of channels, the parameter update process is treated as one task equivalent to the plurality of arithmetic processes, and the plurality of arithmetic processes and the parameter update process are executed exclusively. controller.

20. the plurality of arithmetic processes and the parameter update process are exclusively authorized to be executed by an exclusive control mechanism provided in the controller; The CPU monitor whether the execution authority has been acquired for each of the plurality of arithmetic processes and the parameter update process; performing task management within the controller so that the parameter update process is executed under a condition in which all of the plurality of arithmetic processes are in a waiting state; 20. The controller of claim 19.

Images