A multi-level domain refinement command locking permission management method, system and device

Abstract

This invention discloses a multi-level domain fine-grained command locking and access control method, system, and device, relating to the field of solid-state drive (SSD) storage security and access control technology. Addressing the problems of coarse-grained access control in existing NVMe storage devices, easy bypassing of host-side controls, easy tampering of access configurations, and excessive backend hardware resources consumed by command verification, this invention creates a three-level access isolation domain within the SSD controller: an administrator domain, a business domain, and a read-only domain. Each domain is bound to independent storage hardware resources. An independent command execution whitelist is configured for each access isolation domain, and encrypted storage is located in an independent secure partition with read / write permissions only granted to the underlying firmware. Before parsing NVMe commands, the firmware performs access domain identification and whitelist matching; if verification passes, the command is parsed and executed; otherwise, unauthorized commands are directly intercepted, discarded, and reported. This invention achieves hierarchical fine-grained access control, improving security, reliability, and anti-tampering capabilities, while reducing the hardware resource overhead of unauthorized commands.

Description

Technical Field

[0001] This invention relates to the field of solid-state drive storage security and access control technology, and in particular to a multi-level domain fine-grained command locking access control method, system and device. Background Technology

[0002] With the large-scale application of NVMe protocol solid-state drives in cloud computing, virtualization, and multi-tenant shared storage scenarios, command and permission management of storage devices has become a core technical requirement for ensuring data security and access isolation. In multi-physical / virtual function sharing scenarios under the SR-IOV architecture, different access subjects have significantly different levels of operational permissions for storage devices, necessitating a fine-grained permission control mechanism that balances operational management needs with business access security.

[0003] The current access control for NVMe storage devices is mainly divided into two types of solutions: one is logical access control based on host-side drivers or upper-layer management software, which pre-filters and verifies the permissions of NVMe commands issued by the host-side software; the other is a global command locking mechanism on the device side, which uniformly opens or prohibits the execution of specified types of NVMe commands through global configuration.

[0004] The aforementioned existing technologies have significant drawbacks: First, the global command locking mechanism has a coarse-grained control, which cannot achieve hierarchical and differentiated control, and it is difficult to simultaneously meet the different permission requirements of administrators for high-risk operation and maintenance operations and ordinary business access, resulting in insufficient applicability. Second, host-side software control is easily bypassed, resulting in low security and reliability. Furthermore, some device-side verification schemes only perform permission verification after the command enters the backend execution pipeline, which consumes hardware resources such as flash memory channels and IO queues, affecting the overall IO performance of the device. Third, permission configuration parameters are usually stored in a general storage area accessible to the host, which is easily tampered with. The configuration is easily lost and invalidated when the device is powered on and restarted, making it impossible to achieve persistent and tamper-proof permission control. Summary of the Invention

[0005] To address the aforementioned problems, this invention proposes a multi-level domain fine-grained command locking permission control method, system, and device.

[0006] To achieve the above objectives, the present invention employs the following technical solution:

[0007] A multi-level domain fine-grained command locking permission control method includes:

[0008] S1. Create a three-level permission isolation domain inside the solid-state drive controller. The permission isolation domains in the three-level permission isolation domains are the administrator domain, the business domain, and the read-only domain. Each permission isolation domain is bound to an independent storage hardware resource.

[0009] S2. Configure independent command execution whitelists for each permission isolation domain in the three-level permission isolation domain, and encrypt and store all command execution whitelists in an independent security partition inside the solid-state drive, which only has read and write permissions for the underlying firmware of the solid-state drive controller.

[0010] S3. Before the firmware parses the NVMe command sent by the host, it determines the permission isolation domain to which the NVMe command belongs. If the NVMe command matches the command execution whitelist corresponding to the permission isolation domain, the NVMe command is parsed and sent for execution. Otherwise, it is directly intercepted and discarded, and an exception log is recorded and reported to the host.

[0011] As a preferred embodiment of the present invention, the storage hardware resources include independent flash memory channels, IO submission queues, IO completion queues, and endurance groups.

[0012] As a preferred embodiment of the present invention, the command execution whitelist includes an administrator domain whitelist table, a business domain whitelist table, and a read-only domain whitelist table in array form; the administrator domain whitelist table stores NVMe command opcodes that are allowed to be executed by the administrator domain, the business domain whitelist table stores NVMe command opcodes that are allowed to be executed by the business domain, and the read-only domain whitelist table stores NVMe command opcodes that are allowed to be executed by the read-only domain.

[0013] As a preferred embodiment of the present invention, the NVMe command opcodes that allow the administrator domain to execute include at least firmware upgrade opcodes, namespace formatting opcodes, global erase opcodes, and storage domain reset opcodes.

[0014] The NVMe command opcodes that are allowed to be executed by the business domain include at least data read / write opcodes, status query opcodes, and refresh opcodes.

[0015] The NVMe command opcodes that allow execution in the read-only domain include at least the data read opcode, the log query opcode, and the device status monitoring opcode.

[0016] As a preferred embodiment of the present invention, the step of determining the permission isolation domain to which the NVMe command belongs; if the NVMe command matches the command execution whitelist corresponding to its permission isolation domain, then the NVMe command is parsed and executed; otherwise, it is directly intercepted and discarded, including:

[0017] The firmware extracts the function identifier from the PCIe packet header carrying the NVMe command, queries the pre-established function identifier-permission domain mapping table based on the function identifier, confirms the permission isolation domain to which the current NVMe command belongs, and retrieves the corresponding command execution whitelist according to the permission isolation domain.

[0018] Extract the NVMe command opcode of the current NVMe command, and search and match it in the command execution whitelist based on the NVMe command opcode; if the NVMe command opcode matches the corresponding command execution whitelist, then the NVMe command is parsed and sent to the command execution pipeline at the back end of the solid-state drive controller for execution; otherwise, the NVMe command is determined to be an unauthorized NVMe command and is intercepted and discarded.

[0019] As a preferred embodiment of the present invention, the step of recording the abnormal log and reporting it to the host includes: the firmware generating an abnormal log for the NVMe command determined to be unauthorized and storing it; the abnormal log includes the function identifier, NVMe command opcode, and the permission isolation domain to which the unauthorized NVMe command belongs; the firmware reporting the abnormal log to the host through the asynchronous event notification mechanism of the NVMe protocol.

[0020] As a preferred embodiment of the present invention, when the device is powered on and initialized, the firmware automatically performs hash integrity verification on the command execution whitelist of each permission isolation domain. If the verification passes, the command execution whitelist corresponding to each permission isolation domain is loaded; if the verification fails, the firmware automatically locks all high-risk NVMe commands and reports the command execution whitelist anomaly to the host.

[0021] The high-risk NVMe commands include, but are not limited to, firmware upgrade commands, namespace formatting commands, global erase commands, and storage domain reset commands.

[0022] A multi-level domain fine-grained command locking and access control system includes:

[0023] An isolation domain creation module is used to create a three-level permission isolation domain within the solid-state drive controller. The three-level permission isolation domains are an administrator domain, a business domain, and a read-only domain, and each permission isolation domain is bound to an independent storage hardware resource.

[0024] The whitelist configuration module is used to configure independent command execution whitelists for each permission isolation domain in the three-level permission isolation domain, and to encrypt and store all command execution whitelists in an independent security partition inside the solid-state drive, which is read and written only by the underlying firmware of the solid-state drive controller.

[0025] The command determination module is used to determine the permission isolation domain to which the NVMe command belongs before the firmware parses the NVMe command issued by the host. If the NVMe command matches the command execution whitelist corresponding to the permission isolation domain, the NVMe command is parsed and issued for execution; otherwise, it is directly intercepted and discarded, and an exception log is recorded and reported to the host.

[0026] An electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the steps of a multi-level domain fine-grained command locking permission control method.

[0027] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of a multi-level domain fine-grained command locking permission control method.

[0028] The beneficial effects of this invention are as follows: By binding independent storage hardware resources to a three-tiered permission isolation domain architecture, hierarchical and differentiated permission control is achieved, solving the problems of coarse-grained traditional global command locking mechanisms that cannot simultaneously meet the needs of operation and maintenance management and business access. Hardware-level resource isolation ensures access isolation between different permission domains, adapting to multi-tenant shared storage application scenarios under the SR-IOV architecture. By configuring independent command execution whitelists for each permission isolation domain and encrypting and storing these whitelists in an independent security partition with read and write permissions only for the underlying firmware, fine-grained permission matching is achieved, and the possibility of host-side tampering with permission configurations is physically eliminated, ensuring the persistent effectiveness of permission policies and significantly improving the security and reliability of permission control. A pre-access permission verification mechanism before command parsing is adopted, intercepting and discarding unauthorized NVMe commands before they enter the parsing stage. This eliminates the need to consume command parsing computing power or backend flash memory channels, IO queues, and other storage hardware resources, effectively reducing invalid resource overhead compared to traditional backend verification schemes and ensuring overall device IO performance. Attached Figure Description

[0029] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Wherein: Figure 1 This is a flowchart of the method in an embodiment of the present invention; Figure 2 This is a system structure diagram in an embodiment of the present invention. Detailed Implementation

[0030] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the described embodiments of the present invention are within the scope of protection of the present invention.

[0031] like Figure 1 As shown, this is an embodiment of the present invention, which provides a multi-level domain fine-grained command locking permission control method, including:

[0032] S1. Create a three-level permission isolation domain within the solid-state drive controller. The three-level permission isolation domains are the administrator domain, the business domain, and the read-only domain. Each permission isolation domain is bound to an independent storage hardware resource.

[0033] In this embodiment, the solid-state drive controller constructs a three-level logical permission hierarchy within the firmware runtime framework, and maps dedicated storage hardware resources to each logical permission level, forming a three-level permission isolation domain with hardware-level physical isolation characteristics. The three-level permission isolation domains are the administrator domain, the business domain, and the read-only domain; the administrator domain is the highest logical permission level, corresponding to device operation and maintenance management access subjects; the business domain is the regular business logical permission level, corresponding to business read and write access subjects; and the read-only domain is the restricted access logical permission level, corresponding to read-only monitoring access subjects.

[0034] In this embodiment, the storage hardware resources include independently configured flash channels, IO submission queues, IO completion queues, and endurance groups. Specifically, the solid-state drive controller allocates independent physical links for flash channels, independent hardware depths for IO submission queues, independent hardware depths for IO completion queues, and independent flash address spaces for endurance groups to each permission isolation domain through a built-in hardware resource allocation register. The resource ownership relationship of each permission isolation domain is fixed and locked through the hardware resource allocation register, prohibiting hardware resource calls and address access across permission isolation domains. This ensures that NVMe commands within different permission isolation domains can only schedule the storage hardware resources they are bound to, achieving permission isolation and resource preemption prevention at the physical level.

[0035] S2. Configure independent command execution whitelists for each permission isolation domain in the three-level permission isolation domain, and encrypt and store all command execution whitelists in an independent security partition inside the solid-state drive, which only has read and write permissions for the underlying firmware of the solid-state drive controller.

[0036] Specifically, based on the three-level permission isolation domains, each permission isolation domain is configured with a separate command execution whitelist; the command execution whitelist permissions of each permission isolation domain have clear boundaries and do not overlap, corresponding only to the NVMe command types that are allowed to be executed.

[0037] In this embodiment, the command execution whitelist includes an administrator domain whitelist table, a service domain whitelist table, and a read-only domain whitelist table stored in an array structure. Each whitelist table uses NVMe command opcodes as the smallest storage unit. The administrator domain whitelist table stores NVMe command opcodes allowed to be executed by the administrator domain, the service domain whitelist table stores NVMe command opcodes allowed to be executed by the service domain, and the read-only domain whitelist table stores NVMe command opcodes allowed to be executed by the read-only domain. Using an array-based storage format allows firmware to quickly index and match commands, resulting in short verification times and meeting the low-latency requirements of high-concurrency NVMe command processing.

[0038] Specifically, the NVMe command opcodes allowed for execution by the administrator domain include, but are not limited to, firmware upgrade opcodes, namespace formatting opcodes, global erase opcodes, and storage domain reset opcodes. These cover high-privilege maintenance operations such as device firmware updates, namespace configuration management, full disk data erasure, and storage domain resource reset, and can only be executed by access subjects with administrator privileges. The NVMe command opcodes allowed for execution by the business domain include, but are not limited to, data read / write opcodes, status query opcodes, and refresh opcodes. These cover regular business operations such as reading and writing business data, querying device operating status, and refreshing cached data, meeting the data access needs of normal business operations. The NVMe command opcodes allowed for execution by the read-only domain include, but are not limited to, data read opcodes, log query opcodes, and device status monitoring opcodes. These cover read-only access operations such as reading business data, querying operating logs, and monitoring device status, and do not grant any data modification or device configuration modification permissions.

[0039] All command execution whitelists corresponding to the three-level permission isolation domains are encrypted using an encryption algorithm and stored in a dedicated secure partition within the solid-state drive (SSD). This dedicated secure partition is a private, hidden storage area defined by the SSD controller through hardware address mapping. Its storage address space is mapped only to the underlying firmware runtime environment of the SSD controller. Upper-layer business firmware, host-side NVMe drivers, and management tools cannot access the physical address of this dedicated secure partition via the NVMe protocol, nor can they modify the command execution whitelist within it. This physically eliminates the risk of malicious tampering with permission policies, ensuring the persistent effectiveness of permission configurations.

[0040] S3. Before the firmware parses the NVMe command sent by the host, it determines the permission isolation domain to which the NVMe command belongs. If the NVMe command matches the command execution whitelist corresponding to the permission isolation domain, the NVMe command is parsed and sent for execution. Otherwise, it is directly intercepted and discarded, and an exception log is recorded and reported to the host.

[0041] In this embodiment, specifically, after the firmware receives the transmission message sent by the host through the PCIe link, it first extracts the function identifier from the PCIe message header carrying the NVMe command, queries the pre-established function identifier-permission domain mapping table embedded in the firmware, matches and confirms the permission isolation domain to which the current NVMe command belongs, and retrieves the corresponding command execution whitelist according to the permission isolation domain. The function identifier-permission domain mapping table is stored in the non-volatile storage area of ​​the underlying firmware of the solid-state drive controller in a key-value mapping structure. The key of the function identifier-permission domain mapping table is the function identifier, and the value is the corresponding permission isolation domain. The function identifier corresponds one-to-one with the physical and virtual functions under the SR-IOV architecture, and each function identifier uniquely maps to one of the three-level permission isolation domains. The function identifier-permission domain mapping table can be updated and adjusted according to actual deployment needs by issuing configuration commands through administrator domain permissions.

[0042] In this embodiment, the function identifier-permission domain mapping table is shown in Table 1:

[0043] Table 1 Function Identifier-Permission Domain Mapping Table

[0044] Among them, physical function PF0 is a dedicated function for device management, which is only open to the operation and maintenance management entity and mapped to the administrator domain at the highest logical permission level; virtual functions VF0~VF7 are dedicated functions for business data access, which are open to the business access entity and mapped to the business domain at the regular logical permission level; virtual functions VF8~VF11 are dedicated functions for status monitoring, which are open to the read-only monitoring entity and mapped to the read-only domain at the restricted logical permission level.

[0045] The firmware extracts the NVMe command opcode field from the header of the current NVMe command and performs a fast search and match between the NVMe command opcode and the opcode array in the command execution whitelist.

[0046] If the NVMe command opcode matches the corresponding command execution whitelist, the NVMe command is determined to be a legitimate access command. The firmware continues to parse the complete payload of the NVMe command, and after parsing, it is sent to the command execution pipeline at the back end of the SSD controller to perform the corresponding operation. If the NVMe command opcode does not match the corresponding command execution whitelist, the NVMe command is determined to be an unauthorized NVMe command, and the NVMe command is directly intercepted and discarded without proceeding to the subsequent command parsing and execution stage.

[0047] For access behaviors determined to be unauthorized NVMe commands, the firmware generates a corresponding permission exception log and stores it in a dedicated log buffer within the SSD controller. The permission exception log includes the function identifier, NVMe command opcode, and associated permission isolation domain of the unauthorized NVMe command, used for subsequent maintenance tracing and permission policy optimization. The firmware reports the permission exception log to the host-side management driver through the asynchronous event notification mechanism specified in the NVMe protocol, promptly informing maintenance personnel of the unauthorized access event.

[0048] For example, after receiving a transmission packet carrying an NVMe write command sent by the host via the PCIe link, the firmware extracts the function identifier 0x01 from the PCIe packet header. The firmware queries a pre-defined function identifier-permission domain mapping table and obtains the permission isolation domain corresponding to function identifier 0x01 as the service domain through key-value matching. Based on the matched service domain, the firmware retrieves the service domain whitelist table from the command execution whitelist of the corresponding service domain. Subsequently, the firmware extracts the NVMe command opcode from the header of the NVMe write command as a data write opcode and performs a search and match between the data write opcode and the service domain whitelist table. If a match is found, the firmware determines that the NVMe write command is a legitimate access command, continues to parse the complete payload of the NVMe write command, and after parsing, sends it to the command execution pipeline at the back end of the solid-state drive controller to execute the corresponding write operation.

[0049] For example, after receiving a transmission packet carrying an NVMe formatting command from the host via the PCIe link, the firmware extracts the function identifier 0x09 from the PCIe packet header. The firmware queries the function identifier-permission domain mapping table, matches the permission isolation domain corresponding to function identifier 0x09 to be a read-only domain, and retrieves the read-only domain whitelist from the command execution whitelist corresponding to the read-only domain. The firmware extracts the NVMe command opcode from the NVMe formatting command header as a namespace formatting opcode, and searches and matches the namespace formatting opcode with the read-only domain whitelist. If no match is found, the firmware determines that the NVMe formatting command is an unauthorized NVMe command, directly intercepts and discards the command, and does not proceed to the subsequent command parsing and execution stage. Simultaneously, the firmware generates a corresponding permission exception log and stores it in a dedicated log buffer inside the solid-state drive controller. The permission exception log includes the function identifier 0x09 corresponding to the unauthorized NVMe command, the namespace formatting opcode, and the read-only permission isolation domain. The firmware reports the permission exception log to the host-side management driver through the asynchronous event notification mechanism specified in the NVMe protocol.

[0050] In this embodiment, when the device powers on and initializes, the underlying firmware of the solid-state drive controller first reads the command execution whitelists corresponding to all three-level permission isolation domains from the independent security partition. After decryption, it performs hash integrity verification on the command execution whitelists of each permission isolation domain. Specifically, the firmware uses a preset hash algorithm to calculate the hash value of the currently decrypted command execution whitelist and compares it with the baseline hash value pre-stored in the read-only area of ​​the independent security partition. If the two match, the verification is considered successful; if they do not match, the verification is considered abnormal.

[0051] If the verification passes, the firmware loads the command execution whitelist of each permission isolation domain into the runtime cache inside the solid-state drive controller as the benchmark strategy for runtime permission verification, and the device officially enters the NVMe command receiving and processing process.

[0052] If the verification fails, it is determined that there is a risk of data corruption or malicious tampering in the current command execution whitelist. The firmware automatically triggers the default security policy, which is as follows: all high-risk NVMe commands are locked in the runtime permission rules, that is, all permission isolation domains prohibit the execution of high-risk NVMe commands; at the same time, the firmware generates a command execution whitelist exception event and reports the exception event to the host through the asynchronous event notification mechanism specified by the NVMe protocol, prompting the operation and maintenance personnel to check and repair the permission policy.

[0053] The high-risk NVMe commands include, but are not limited to, firmware upgrade commands, namespace formatting commands, global erase commands, and storage domain reset commands. These commands all have the high-risk attributes of modifying device firmware configurations and erasing batch user data. They are globally blocked in scenarios with verification anomalies, which can maximize the avoidance of data security and device security risks when the permission policy is untrusted.

[0054] Specifically, the default security policy only blocks high-risk management NVMe commands, while low-risk basic business commands such as data reading and status query can still be executed normally. This maximizes the availability of basic services on the device while ensuring core security, and avoids complete service interruption due to abnormal permission configuration.

[0055] like Figure 2 As shown, another embodiment of the present invention provides a multi-level domain fine-grained command locking permission control system, including:

[0056] An isolation domain creation module is used to create a three-level permission isolation domain within the solid-state drive controller. The three-level permission isolation domains are an administrator domain, a business domain, and a read-only domain, and each permission isolation domain is bound to an independent storage hardware resource.

[0057] The whitelist configuration module is used to configure independent command execution whitelists for each permission isolation domain in the three-level permission isolation domain, and to encrypt and store all command execution whitelists in an independent security partition inside the solid-state drive, which is read and written only by the underlying firmware of the solid-state drive controller.

[0058] The command determination module is used to determine the permission isolation domain to which the NVMe command belongs before the firmware parses the NVMe command issued by the host. If the NVMe command matches the command execution whitelist corresponding to the permission isolation domain, the NVMe command is parsed and issued for execution; otherwise, it is directly intercepted and discarded, and an exception log is recorded and reported to the host.

[0059] In this embodiment, it further includes: an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement a multi-level domain fine-grained command locking permission control method.

[0060] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of a multi-level domain fine-grained command locking permission control method.

[0061] In summary, this invention creates three levels of permission isolation domains—administrator domain, business domain, and read-only domain—within the solid-state drive controller, and binds each permission isolation domain to independent storage hardware resources. This achieves hierarchical and differentiated permission control, solving the problem that traditional global command locking mechanisms have coarse-grained control and cannot simultaneously meet the needs of operation and maintenance management and business access. Hardware-level resource isolation ensures access isolation between different permission isolation domains, making it suitable for multi-tenant shared storage application scenarios under the SR-IOV architecture. By configuring independent command execution whitelists for each permission isolation domain and encrypting and storing all command execution whitelists in an independent secure partition with read and write permissions only for the underlying firmware of the solid-state drive controller, fine-grained permission matching is achieved, and the possibility of host-side tampering with permission configurations is physically eliminated, ensuring the persistent effectiveness of permission policies and significantly improving the security and reliability of permission control. Employing a pre-parsing permission verification mechanism, unauthorized NVMe commands are intercepted and discarded before entering the parsing stage. This eliminates the need for command parsing computational power and avoids consuming backend flash channels, IO submission queues, IO completion queues, and other storage hardware resources. Compared to traditional backend verification schemes, this effectively reduces unnecessary resource overhead and ensures overall device IO performance. Through a hash integrity verification mechanism during device power-on initialization, all high-risk NVMe commands are automatically locked and the exception is reported to the host when verification fails. This provides a safety fallback when permission policies are untrusted, while also ensuring the continuity of basic business operations, thus improving the device's fault tolerance and operational stability.

[0062] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any other combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product, which includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions according to this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another.

[0063] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. This storage medium can be a read-only memory, a disk, or an optical disk, etc.

[0064] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various variations or substitutions within the technical scope disclosed in this application, and these should all be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A multi-level domain fine-grained command locking permission control method, characterized in that, include: S1. Create a three-level permission isolation domain inside the solid-state drive controller. The permission isolation domains in the three-level permission isolation domains are the administrator domain, the business domain, and the read-only domain. Each permission isolation domain is bound to an independent storage hardware resource. S2. Configure independent command execution whitelists for each permission isolation domain in the three-level permission isolation domain, and encrypt and store all command execution whitelists in an independent security partition inside the solid-state drive, which only has read and write permissions for the underlying firmware of the solid-state drive controller. S3. Before the firmware parses the NVMe command issued by the host, it determines the permission isolation domain to which the NVMe command belongs. If the NVMe command matches the command execution whitelist corresponding to its respective permission isolation domain, then the NVMe command will be parsed and executed. Otherwise, the data will be directly intercepted and discarded, and the exception will be logged and reported to the host.

2. The multi-level domain fine-grained command locking permission control method according to claim 1, characterized in that, The storage hardware resources include independent flash channels, IO submission queues, IO completion queues, and endurance groups.

3. The multi-level domain fine-grained command locking permission control method according to claim 1, characterized in that, The command execution whitelist includes an array-based whitelist table for administrator domains, a whitelist table for business domains, and a whitelist table for read-only domains. The administrator domain whitelist table stores NVMe command opcodes that are allowed to be executed by the administrator domain, the business domain whitelist table stores NVMe command opcodes that are allowed to be executed by the business domain, and the read-only domain whitelist table stores NVMe command opcodes that are allowed to be executed by the read-only domain.

4. The multi-level domain fine-grained command locking permission control method according to claim 3, characterized in that, The NVMe command opcodes that are allowed to be executed by the administrator domain include at least the firmware upgrade opcode, namespace format opcode, global erase opcode, and storage domain reset opcode; The NVMe command opcodes that are allowed to be executed by the business domain include at least data read / write opcodes, status query opcodes, and refresh opcodes. The NVMe command opcodes that allow execution in the read-only domain include at least the data read opcode, the log query opcode, and the device status monitoring opcode.

5. The multi-level domain fine-grained command locking permission control method according to claim 1, characterized in that, The permission isolation domain to which the NVMe command belongs is determined; If the NVMe command matches the command execution whitelist corresponding to its respective permission isolation domain, then the NVMe command will be parsed and executed. Otherwise, the data will be directly intercepted and discarded, including: The firmware extracts the function identifier from the PCIe packet header carrying the NVMe command, queries the pre-established function identifier-permission domain mapping table based on the function identifier, confirms the permission isolation domain to which the current NVMe command belongs, and retrieves the corresponding command execution whitelist according to the permission isolation domain. Extract the NVMe command opcode of the current NVMe command, and search and match it in the command execution whitelist based on the NVMe command opcode; if the NVMe command opcode matches the corresponding command execution whitelist, then the NVMe command is parsed and sent to the command execution pipeline at the back end of the solid-state drive controller for execution; otherwise, the NVMe command is determined to be an unauthorized NVMe command and is intercepted and discarded.

6. The multi-level domain fine-grained command locking permission control method according to claim 5, characterized in that, The step of recording the abnormal log and reporting it to the host includes: the firmware generating and storing an abnormal log for an NVMe command that is determined to be unauthorized; the abnormal log includes the function identifier, NVMe command opcode, and the permission isolation domain to which the unauthorized NVMe command belongs; and the firmware reporting the abnormal log to the host through the asynchronous event notification mechanism of the NVMe protocol.

7. The multi-level domain fine-grained command locking permission control method according to claim 1, characterized in that, When the device is powered on and initialized, the firmware automatically performs hash integrity verification on the command execution whitelist of each permission isolation domain. If the verification passes, the command execution whitelist corresponding to each permission isolation domain is loaded. If the verification fails, the firmware will automatically lock all high-risk NVMe commands and report the command execution whitelist error to the host. The high-risk NVMe commands include, but are not limited to, firmware upgrade commands, namespace formatting commands, global erase commands, and storage domain reset commands.

8. A multi-level domain fine-grained command locking permission control system, applied to the multi-level domain fine-grained command locking permission control method described in any one of claims 1 to 7, characterized in that, include: An isolation domain creation module is used to create a three-level permission isolation domain within the solid-state drive controller. The three-level permission isolation domains are an administrator domain, a business domain, and a read-only domain, and each permission isolation domain is bound to an independent storage hardware resource. The whitelist configuration module is used to configure independent command execution whitelists for each permission isolation domain in the three-level permission isolation domain, and to encrypt and store all command execution whitelists in an independent security partition inside the solid-state drive, which is read and written only by the underlying firmware of the solid-state drive controller. The command determination module is used to determine the permission isolation domain to which the NVMe command belongs before the firmware parses the NVMe command issued by the host. If the NVMe command matches the command execution whitelist corresponding to its respective permission isolation domain, then the NVMe command will be parsed and executed. Otherwise, the data will be directly intercepted and discarded, and the exception will be logged and reported to the host.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the multi-level domain fine-grained command locking permission control method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the multi-level domain fine-grained command locking permission control method as described in any one of claims 1 to 7.

Images