System on chip providing virtualized environment and electronic device including same

Abstract

A system on chip is provided. The system on chip includes: a storage host controller including a virtual machine identifier register configured to store an operating virtual machine identifier of an operating virtual machine that is currently running among a plurality of virtual machines, and a buffer configured to buffer the operating virtual machine identifier of the operating virtual machine that is currently running among the plurality of virtual machines; and the buffer is configured to store a message queue including commands generated by operating the virtual machine; and a storage encryption controller configured to store a plurality of encrypted storage keys of a plurality of virtual machine identifiers respectively assigned to the plurality of virtual machines, a first encrypted storage key is selected from among the plurality of encrypted storage keys based on the operating virtual machine identifier stored in the virtual machine identifier register, and data corresponding to the command is encrypted or decrypted based on the first encrypted storage key.

Description

[0001] Cross-references to related applications

[0002] This application claims priority to Korean Patent Application No. 10-2024-0114493, filed on August 26, 2024, with the Korean Intellectual Property Office, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] This disclosure relates to a system-on-a-chip, and more specifically, to a system-on-a-chip for providing a virtualized environment. Background Technology

[0004] With the increasing demand for virtualization-based security services in mobile environments, there is a growing need for technologies that securely store data used by virtual machines in storage devices.

[0005] In this regard, there is an increasing demand to isolate the data storage area of ​​each virtual machine and ensure the confidentiality of the data. Summary of the Invention

[0006] One or more embodiments provide a system-on-a-chip that can separate the storage areas accessible to each virtual machine and assign different storage keys to each virtual machine.

[0007] According to one aspect of the embodiment, the storage host controller includes a virtual machine identifier register and a buffer, wherein the virtual machine identifier register is configured to store the operation virtual machine identifier of the currently running operation virtual machine among a plurality of virtual machines, and the buffer is configured to store commands generated by the operation virtual machine; and a storage encryption controller is configured to store a plurality of encrypted storage keys for a plurality of virtual machine identifiers respectively assigned to a plurality of virtual machines, select a first encrypted storage key from the plurality of encrypted storage keys based on the operation virtual machine identifier stored in the virtual machine identifier register according to the command, and encrypt or decrypt data corresponding to the command based on the first encrypted storage key.

[0008] According to another aspect of the embodiments, a method for controlling access to a storage device in a virtualization environment including multiple virtual machines and a hypervisor is provided. The method includes: generating multiple storage key encryption keys (KEKs) corresponding to virtual machine identifiers of the multiple virtual machines respectively by the hypervisor; generating multiple encrypted storage keys corresponding to virtual machine identifiers respectively by the hypervisor; obtaining a first storage KEK from the multiple storage KEKs based on a first virtual machine identifier, a virtual machine identifier, and the first virtual machine identifier; obtaining a first encrypted storage key from the multiple encrypted storage keys based on the first virtual machine identifier; decrypting the first encrypted storage key based on the first storage KEK to obtain a first storage key; and encrypting or decrypting data related to commands generated by a first virtual machine based on the first storage key.

[0009] According to another aspect of the embodiment, the method includes extracting a slot identifier based on a command, identifying a storage key slot based on a first virtual machine identifier and a slot identifier, and obtaining a first encrypted storage key from the storage key slot.

[0010] According to another aspect of the embodiments, an electronic device includes: a memory including volatile memory cells; a storage device including non-volatile memory cells; and a system-on-a-chip configured to: store a plurality of encrypted storage keys for a plurality of virtual machine identifiers respectively assigned to a plurality of virtual machines; store a plurality of storage key keys assigned to the plurality of virtual machine identifiers; select a first encrypted storage key from the plurality of encrypted storage keys based on a command generated by a first virtual machine among the plurality of virtual machines and based on the first virtual machine identifier of the first virtual machine; select the first storage key from the plurality of storage key keys based on the first virtual machine identifier; decrypt the first encrypted storage key based on the first storage key to obtain a storage key; read data related to a command from the memory based on the command being a write command, encrypt the read data based on the storage key; and store the encrypted data in the storage device.

[0011] According to another aspect of the embodiment, the on-chip system is also configured to read data related to a command from a storage device based on a read command, decrypt the read data based on a storage key, and store the decrypted data in a memory.

[0012] According to another aspect of the embodiment, the command includes a first virtual machine identifier and a key slot identifier, and the on-chip system is further configured to select a first key slot from a plurality of key slots based on the first virtual machine identifier and key slot identifier provided in the command, and select an encrypted storage key stored in the first key slot as a first encrypted storage key. Attached Figure Description

[0013] The above and other aspects and features will become clearer from the following description of embodiments in conjunction with the accompanying drawings, wherein:

[0014] Figure 1 This is a block diagram illustrating an electronic device according to an embodiment;

[0015] Figure 2 This is a block diagram illustrating a virtualization system according to an embodiment;

[0016] Figure 3 This is a block diagram illustrating a virtualization system according to an embodiment;

[0017] Figure 4 This is a diagram illustrating the storage key slot according to an embodiment;

[0018] Figure 5 This is a diagram illustrating a table of stored key encryption keys (KEKs) according to an embodiment;

[0019] Figure 6 This is a block diagram illustrating storage protection setting operations and storage input / output operations according to an embodiment;

[0020] Figure 7 This is a diagram illustrating an access control list according to an embodiment;

[0021] Figure 8 This is a block diagram illustrating a storage key generation operation according to an embodiment;

[0022] Figure 9 This is a block diagram illustrating a stored KEK table update operation according to an embodiment;

[0023] Figure 10 This is a block diagram illustrating the storage input / output operation according to an embodiment;

[0024] Figure 11 This is a flowchart explaining the operation method of the encryption controller according to an embodiment; and

[0025] Figure 12 This is a flowchart illustrating a method for controlling access to a storage device in a virtualized environment, according to an implementation scheme. Detailed Implementation

[0026] In the following detailed description, embodiments are given with reference to the accompanying drawings. Throughout the specification, similar components are indicated by similar reference numerals, and repeated descriptions thereof are omitted. It should be understood that when an element or layer is referred to as "on" another element or layer, "connected to," or "coupled to" another element or layer, it may be directly on, connected to, or coupled to the other element or layer, or there may be intermediate elements or layers present. In contrast, when an element is referred to as "directly on" another element or layer, "directly connected to," or "directly coupled to" another element or layer, there are no intermediate elements or layers present. The embodiments described herein are exemplary embodiments, and therefore, this disclosure is not limited thereto, and various other forms may be implemented. Each embodiment provided in the following description does not exclude association with one or more features of another example or another embodiment also provided herein or not provided herein but consistent with this disclosure.

[0027] Figure 1 This is a block diagram illustrating an electronic device according to an embodiment.

[0028] refer to Figure 1 Electronic device 1 may include system-on-chip (SoC) 10, memory 20 and storage device 30.

[0029] SoC 10 can be connected to components of electronic device 1 and perform operations or data processing related to the control and / or communication of each component. SoC 10 can be referred to as a host device.

[0030] Memory 20 may include volatile memory. For example, memory 20 may include dynamic random access memory (DRAM), static random access memory (SRAM), magnetic random access memory (MRAM), etc. However, embodiments are not limited thereto, and memory 20 may include non-volatile memory, or both volatile and non-volatile memory.

[0031] Storage device 30 may include non-volatile memory. For example, storage device 30 may include NAND flash memory, NOR flash memory, resistive random access memory, phase-change memory, magnetoresistive random access memory, etc.

[0032] SoC 10 may include a host processor 110 and a storage controller 120. The host processor 110 controls the operation of SoC 10. The host processor 110 manages requests from various applications, software, or virtual machines VM1 to VMn running on SoC 10. SoC 10 can send write commands for storing data to memory 20 or storage device 30 via storage controller 120. SoC 10 can send read commands to read data from memory 20 or storage device 30 via storage controller 120. For example, storage controller 120 may include a memory controller that controls access to memory 20. Storage controller 120 may include a storage host controller that controls access to storage device 30 (e.g., ...). Figure 3 (210). During storage input / output operations, SoC 10 can encrypt or decrypt data. For example, during a storage write operation, SoC 10 can read data loaded into memory 20, encrypt the read data, and store the encrypted data in storage device 30. For example, during a storage read operation, SoC 10 can read encrypted data stored in storage device 30, decrypt the read encrypted data, and store the decrypted data in memory 20.

[0033] The storage controller 120 may include a protection circuit 121 and an encryption controller 122.

[0034] Protection circuit 121 can manage the storage areas allocated to virtual machines VM1 through VMn. Protection circuit 121 can allow or block access from virtual machines VM1 through VMn, ensuring that each virtual machine VM1 through VMn can only access its allocated storage area. Protection circuit 121 can manage the storage areas allocated to virtual machines VM1 through VMn. Specifically, protection circuit 121 can dynamically map the storage areas of storage device 30 that virtual machines VM1 through VMn may access to the virtual machine identifiers of virtual machines VM1 through VMn. For example, protection circuit 121 can dynamically manage the mapping relationship between virtual machine identifiers and storage areas of storage device 30 by generating and updating access control lists (e.g., ...). Figure 7The protection circuit 121 can map two or more virtual machines VM1 to VMn to a common storage area (i.e., the same storage area) of the storage area of ​​the storage device 30. The storage controller 120 can store data in or read data from the storage area of ​​the storage device 30 that is controlled and permitted by the protection circuit 121. According to the embodiment, because virtual machines VM1 to VMn can share some storage areas of the storage device 30, efficient use of the storage device 30 can be achieved. Furthermore, because the storage areas allocated to virtual machines VM1 to VMn are distinguished from each other by virtual machine identifiers, the confidentiality of the data of virtual machines VM1 to VMn can be provided.

[0035] The encryption controller 122 can encrypt or decrypt data during storage input / output operations. For example, when performing a storage write operation, data of virtual machines VM1 to VMn loaded into storage 20 can be encrypted. During the storage write operation, the encrypted data can be stored in storage device 30. For example, the encryption controller 122 can decrypt the encrypted data stored in storage device 30 during a storage read operation. During the storage read operation, the decrypted data can be loaded into storage 20.

[0036] The encryption controller 122 can store multiple storage keys assigned to virtual machines VM1 through VMn. The encryption controller 122 can select a storage key based on a virtual machine identifier. During a storage write operation, the encryption controller 122 can encrypt data read from storage device 20 based on the selected storage key. During a storage read operation, the encryption controller 122 can decrypt encrypted data read from storage device 30 based on the selected storage key.

[0037] In some embodiments, the encryption controller 122 may store multiple encrypted storage keys assigned to virtual machines VM1 to VMn. For example, the encryption controller 122 may store at least one encrypted storage key corresponding to a virtual machine identifier in a storage key slot ( Figure 3 In 231).

[0038] The encryption controller 122 can store multiple key encryption keys (KEKs) assigned to virtual machines VM1 to VMn. For example, the encryption controller 122 can store the KEK corresponding to the virtual machine identifier in a storage KEK table (…). Figure 3 In section 232), the encryption controller 122 can obtain the storage key by selecting the KEK and the encrypted storage key based on the virtual machine identifier and decrypting the encrypted storage key based on the KEK.

[0039] The encryption controller 122 can encrypt data read from the memory 20 based on an acquired storage key during a storage write operation. The encryption controller 122 can also decrypt encrypted data read from the storage device 30 based on an acquired storage key during a storage read operation.

[0040] According to the embodiment, because the encrypted data is stored in storage device 30, the data can be securely stored in storage device 30. Furthermore, because different storage keys are assigned to virtual machines VM1 to VMn, the confidentiality of the data in virtual machines VM1 to VMn can be provided.

[0041] Figure 2 This is a block diagram illustrating a virtualization system according to an embodiment.

[0042] refer to Figure 2 The virtualization system 2 may include the host application HAPP, the host operating system HOS, the guest application GAPP, the guest operating system GOS, the hypervisor 40, and hardware 3. Hardware 3 may correspond to... Figure 1 The electronic device 1 may include a SoC 10, a memory 20, and a storage device 30. However, the embodiments are not limited thereto, and the hardware 3 may include various physical hardware devices, such as a camera, a graphics processing unit (GPU), a neural processing unit (NPU), a peripheral component interconnect fast (PCIe) device, a universal flash storage device (UFS) device, etc.

[0043] SoC 10 provides the functionality for implementing a virtualized environment. The host application (HAPP), host operating system (HOS), guest application (GAPP), guest operating system (GOS), and hypervisor 40 can run within the virtualized environment. For example, the host operating system (HOS) can run on the host virtual machine (HOST VM) within the virtualized environment. The guest operating system (GOS) can run on the guest virtual machine (GUEST VM) within the virtualized environment and can operate independently of the host operating system (HOS). The host application (HAPP) can run on the host operating system (HOS). The guest application (GAAP) can run on the guest operating system (GOS). Hypervisor 40 can utilize the functionality of hardware 3 to implement the virtualized environment and create and control the host virtual machine (HOST VM) and guest virtual machine (GUEST VM) within the virtualized environment.

[0044] exist Figure 2 Only one guest virtual machine (GUEST VM) is shown in the example, but the embodiment is not limited to this, and the number of guest virtual machines (GUEST VMs) operating on hypervisor 40 can be determined in various ways depending on the virtualization environment.

[0045] The host operating system (HOS) may include a host storage service (HSS) and a host storage drive (HSDRV). The HSS manages the logical block addresses of the storage areas of storage device 30. The HSS can allocate storage areas of storage device 30 to guest virtual machines (GUEST VMs). Specifically, the HSS can assign logical block addresses to guest virtual machines (GUEST VMs). The HSS may include file systems. For example, the HSS may include at least one of various file system formats, such as File Allocation Table (FAT), FAT32, New Technology File System (NTFS), Hierarchical File System (HFS), Journaling File System 2 (JSF2), Extended File System (XFS), Structure on Disk-5 (ODS-5), Universal Disk Format (UDF), Zettabyte File System (ZFS), Unix File System (UFS), Second Extended File System (ext2), Third Extended File System (ext3), Fourth Extended File System (ext4), Reiser File System (ReiserFS), Reiser4, ISO 9660, GNOME Virtual File System (GNOME VFS), BFS, Windows Future Storage (WinFS), etc. The host storage driver HSDRV can control the SoC 10 to write data to or read data from the storage device 30 in response to requests from the host application HAPP sent via the host storage service HSS.

[0046] The Guest Operating System (GOS) may include a Guest Storage Service (GSS) and a Guest Storage Driver (GSDRV). The Guest Storage Service (GSS) can manage the logical block addresses of storage regions allocated by the Host Storage Service (HSS). The Guest Storage Service (GSS) may contain a file system. The Guest Storage Driver (GSDRV) can control the SoC 10 to write data to or read data from the storage device 30 in response to requests from the Guest Application (GAPP) delivered via the Guest Storage Service (GSS).

[0047] exist Figure 2 In this context, the host application HAPP, the host operating system HOS, the guest application GAPP, the guest operating system GOS, and the management program 40 can be loaded as software programs into the memory 20 and executed by the SoC 10.

[0048] In detail, memory 20 stores data and program code, and can load software programs such as host application (HAPP), host operating system (HOS), guest application (GAPP), guest operating system (GOS), and supervisory program 40 for implementing the virtualization environment into memory 20. Storage device 30 can store host application (HAPP), host operating system (HOS), guest application (GAPP), guest operating system (GOS), and supervisory program 40. For example, when the virtualization system 2 is boosted, the software programs stored in storage device 30 are loaded into memory 20 according to the boot order, and SoC 10 can provide a virtualization environment based on the software programs loaded into memory 20. In this way, memory 20 can also function as the working memory of virtualization system 2.

[0049] Hardware 3 can be controlled by the host operating system (HOS), the guest operating system (GOS), and the hypervisor 40. The hypervisor 40 can create, schedule, and manage virtual machines. The hypervisor 40 provides the interface between the virtual machine and hardware 3, and can manage data transfer and instruction execution associated with the virtual machine. The hypervisor 40 can also be referred to as a virtual machine monitor or virtual machine manager.

[0050] Figure 3 This is a block diagram illustrating a virtualization system according to an embodiment. Figure 4 This is a diagram illustrating the storage key slot according to an embodiment. Figure 5 This is a diagram illustrating the storage of a KEK table according to an embodiment.

[0051] Reference Figure 3 The virtualization system 2 may include a host virtual machine (HOST VM), multiple guest virtual machines (GUST VM1 to GUST VMn), a hypervisor 40, a storage controller 120, a storage device 20, and a storage device 30. Among the guest virtual machines (GUST VM1 to GUST VMn), guest virtual machine GUST VM1 is described below, but the description of guest virtual machine GUST VM1 can also be applied to the other guest virtual machines (GUST VM2 to GUST VMn).

[0052] The guest virtual machine GUST VM1 can include the guest storage service GSS, the guest storage drive GSDRV, and the storage encryption drive SCDRV.

[0053] Guest storage service GSS can provide protection requests for the allocated storage area to management program 40 (e.g., Figure 6 In addition, when performing a storage key generation operation, the Guest Storage Service (GSS) can provide a storage key generation request to the Storage Encryption Driver (SCDRV) (e.g., PT_REQ). Figure 8The KEY_REQ in the code is used to encrypt the allocated storage area and to receive and store the wrapped key.

[0054] The storage encryption driver SCDRV can manage storage keys used to encrypt data stored in the storage area of ​​storage device 30. Specifically, when performing a storage key generation operation, the storage encryption driver SCDRV sends a storage key generation request (e.g., ...) Figure 8 The KEY_REQ is provided to the storage encryption manager SCMNG of the management program 40, which can receive the encapsulated key and provide the received encapsulated key to the guest storage service GSS. Additionally, when performing a storage key slot update operation, a slot ID request (e.g., ) is received from the guest storage drive GSDRV. Figure 10 When the SLOTID_REQ is obtained, the storage encryption driver SCDRV can store the storage key in the storage key slot 231 within the encryption controller 122 and provide the guest storage driver GSDRV with a slot ID that distinguishes the key slot.

[0055] When performing a storage key slot update operation, upon receiving a request from the guest application GAPP, the guest storage drive GSDRV can provide a slot ID request to the storage encryption drive SCDRV (e.g., Figure 10 The SLOTID_REQ in the storage encryption drive (SCDRV) is used to generate a slot ID (e.g., SLOTID_REQ). The guest storage drive (GSDRV) can generate a slot ID that includes the slot ID (e.g., SLOTID_REQ). Figure 10 The command is CMD[SLOTID] in the context of SLOTID.

[0056] The hypervisor 40 may include a VM context manager VMCMNG, a storage protection manager SPMNG, and a storage encryption manager SCMNG.

[0057] When a context switch occurs between virtual machines, the VM Context Manager VMCMNG can store the virtual machine identifier VMID used to run the virtual machine in VMID register 211.

[0058] Upon receiving a protection request for a storage area (e.g., Figure 6 When the virtual machine accesses the PT_REQ (as specified in the original text), the Storage Protection Manager (SPMNG) can identify the storage areas accessible to the virtual machine and control the protection circuit 121 to restrict the storage areas of storage device 30 that the virtual machine can access. For example, the Storage Protection Manager (SPMNG) can control the protection circuit 121 to generate or update the access control table (PT_REQ). Figure 7 (ACT in the context of ACT).

[0059] The Storage Encryption Manager (SCMNG) can generate storage keys corresponding to multiple virtual machines. Specifically, when performing a storage key generation operation, a storage key generation request is received from the Storage Encryption Driver (SCDRV) (e.g., ...). Figure 8 When the KEY_REQ request is received from the storage cryptography driver (SCDRV), the Storage Cryptography Manager (SCMNG) can identify the virtual machine identifier of the virtual machine that generated the request and generate a storage key corresponding to the virtual machine. The SCMNG can encrypt the storage key based on the encapsulation key to generate an encapsulated key and provide the encapsulated key to the storage cryptography driver (SCDRV). Therefore, data confidentiality can be provided because the decrypted storage key is not exposed to the virtual machine. Additionally, when performing a storage KEK table update operation, upon receiving a storage key encryption request from the storage cryptography driver (SCDRV) (e.g., ...), Figure 9 When the ENKEY_REQ is specified, the Storage Encryption Manager (SCMNG) can generate a storage key encryption key and use it to encrypt the storage key. The SCMNG can provide the encrypted storage key to the Storage Encryption Driver (SCDRV) and store the storage key in the storage key table 232.

[0060] The storage controller 120 may include a storage host controller 210, a protection circuit 121, and an encryption controller 122.

[0061] Storage host controller 210 can access storage device 30 by providing write and read requests to storage device 30. Storage host controller 210 may include a VMID register 211 and a message queue 222. The number of VMID registers 211 and message queues 222 is not limited thereto. VMID register 211 may store the virtual machine identifier (VMID) of a virtual machine. When a context switch occurs between virtual machines, the VMID of the virtual machine running on host processor 110 may be stored in VMID register 211. The VMID stored in VMID register 211 can be used to distinguish which virtual machine generated the command stored in message queue 222. Message queue 222 may be a buffer storing commands generated by virtual machines.

[0062] The encryption controller 122 may include a key storage slot 231, a KEK storage table 232, and encryption circuitry 233. For example, the encryption controller 122 may include a non-volatile memory or a volatile memory, which includes a key storage slot 231 and a KEK storage table 232.

[0063] Storage key slot 231 can store storage keys used to encrypt data to be stored in storage device 30 or to decrypt data read from storage device 30. In some embodiments, storage key slot 231 can store encrypted storage keys. Storage key slot 231 can be managed by the storage encryption drive SCDRV of guest virtual machine GUEST VM1. Figure 4 As shown, storage key slot 231 may include at least one key slot corresponding to a virtual machine identifier (VMID). For example, storage key slot 231 may include two or more key slots corresponding to each of virtual machine identifiers VMID1 and VMID2. A key slot ID may be assigned to each key slot. When a storage key slot update operation occurs, the storage encryption drive SCDRV may obtain the key slot ID and provide it to the guest storage drive GSDRV. Storage key slot 231 may include multiple key slots corresponding to virtual machine identifiers (VMID), and at least one storage key may be stored in multiple key slots.

[0064] Storage KEK table 232 can store keys used for encrypting storage keys. Storage KEK table 232 can be managed by the Storage Encryption Manager (SCMNG) included in hypervisor 40. Therefore, data confidentiality can be provided because the virtual machine does not need to access storage KEK table 232. Figure 5 As shown, the KEK storage table 232 can store the KEK corresponding to the virtual machine identifier VMID. For example, the KEK storage table 232 can store KEK1 corresponding to the virtual machine identifier VMID1 and KEK2 corresponding to the virtual machine identifier VMID2.

[0065] The encryption circuit 233 can encrypt or decrypt data based on a storage key set for each virtual machine. Specifically, during a storage write operation, the encryption circuit 233 can encrypt data loaded into the memory 20 based on the storage key. The encrypted data can be stored in the storage device 30. During a storage read operation, the encryption circuit 233 can decrypt data read from the storage device 30 based on the storage key. The decrypted data can be loaded into the memory 20.

[0066] Figure 6 This is a block diagram illustrating storage protection setting operations and storage input / output operations according to an embodiment. Figure 7 This is a diagram illustrating the access control list according to an embodiment.

[0067] refer to Figure 6 During the storage protection setup operation, the host storage service HSS of the host virtual machine HOST VM can assign the address (e.g., logical block address) of the storage region of storage device 30 to the guest virtual machine GUEST VM1 (①).

[0068] During storage protection setup operations, the Guest Storage Service (GSS) can provide a protection request PT_REQ (②) to the Storage Protection Manager (SPTMNG) of the hypervisor 40. The protection request PT_REQ may include a virtual machine identifier (VMID) and an assigned address (ADDR). For example, the assigned address (ADDR) provided to the Storage Protection Manager (SPTMNG) may be one of the addresses assigned to the guest virtual machine (GUST VM1) based on the assigned address (ADDR) provided by the host virtual machine (HOST VM).

[0069] During storage protection setup operations, the Storage Protection Manager SPTMNG can control the protection circuit 121 to generate or update the access control table ACT (③) included in the protection circuit 121. (See reference...) Figure 7 The Access Control List (ACT) can represent the mapping between virtual machine identifiers (VMIDs) and addresses (ADDRs). However, the embodiments are not limited to this, and the ACT can distinguish the addresses of storage device 30 by cell size, and stores bitmap information indicating the cell size of the storage area allocated to each virtual machine identifier (VMID).

[0070] During storage I / O operations, the host storage drive HSDRV or guest storage drive GSDRV can provide the storage host controller 210 with a command CMD (④) corresponding to an I / O request from the host application HAPP or guest application GAPP. The command CMD can be a read command or a write command for accessing the storage device 30. The command CMD can include the address ADDR of the storage region to be accessed. The hypervisor 40 can provide the virtual machine identifier VMID to the storage host controller 210. The virtual machine identifier VMID can be stored in the VMID register 211. The command CMD can be stored in the message queue 222.

[0071] During storage input / output operations, protection circuit 121 can search the access control list ACT based on command CMD and virtual machine identifier VMID, and determine whether access to storage device 30 is permitted based on the search results (⑤). Specifically, protection circuit 121 retrieves address ADDR based on command CMD, allowing access if a mapping relationship exists between virtual machine identifier VMID and address ADDR in the access control list ACT, and blocking access if no mapping relationship exists. When access is permitted, storage host controller 210 can perform storage input / output operations by accessing storage device 30, and when access is blocked, storage host controller 210's storage input / output operations can be stopped.

[0072] When the guest virtual machine (GUEST VM1) no longer uses its assigned address, the host storage service (HSS) can reclaim that address, and the storage protection manager (SPTMNG) can remove the mapping information between that address and the virtual machine identifier from the access control list (ACT). The SPTMNG can then update the mapping information between the virtual machine and the storage address in the deleted space.

[0073] According to the embodiments, data confidentiality of virtual machines can be provided because the storage areas allocated to virtual machines are distinguished from each other by virtual machine identifiers, virtual machines can only access the allocated storage areas, and the data is encrypted with an encryption key allocated to the virtual machine.

[0074] Figure 8 This is a block diagram illustrating the storage key generation operation according to an embodiment.

[0075] refer to Figure 8 The Guest Storage Service (GSS) can search the Wrapped Key Database (WDRV) to determine if a wrapped key exists for the required encrypted storage area. If no wrapped key exists in the Wrapped Key Database, the GSS can provide a Storage Key Generation Request (KEY_REQ) to the Storage Encryption Manager (SCMNG) via the Storage Encryption Driver (SCDRV) (①). The KEY_REQ may include the Virtual Machine Identifier (VMID) and the storage area address (ADDR).

[0076] The Storage Encryption Manager (SCMNG) can generate storage keys corresponding to virtual machine identifiers (VMIDs). That is, different VMIDs can result in the generation of different storage keys. In some embodiments, the SCMNG can generate storage keys corresponding to both the VMID and the address ADDR. That is, even if the VMID is the same, the SCMNG can generate different storage keys for different addresses ADDR. However, the embodiments are not limited to this, and storage keys can be generated in various ways.

[0077] The Storage Encryption Manager (SCMNG) can generate a sealed key using a storage key encrypted with a sealed key. The SCMNG can then provide this sealed key to the Guest Storage Service (GSS) via the Storage Encryption Driver (SCDRV) (②).

[0078] The Guest Storage Service (GSS) can store the encapsulated key in the Wrapped_KEY DB database (③).

[0079] refer to Figure 8 The guest virtual machine (GUEST VM1) can store the storage key as an encapsulated key encrypted with the encapsulation key. Therefore, data confidentiality can be provided because the original storage key is not exposed to the guest virtual machine (GUEST VM1).

[0080] Figure 9 This is a block diagram illustrating the update operation of the stored KEK table according to an embodiment.

[0081] refer to Figure 9 When encryption is required for data to be stored in the storage area of ​​storage device 30 or decryption is required for data read from the storage area of ​​storage device 30, the Guest Storage Service (GSS) can load the encapsulated key for the corresponding storage area from the Wrapped_KEY DB (①).

[0082] The Guest Storage Service (GSS) can provide a Key ID Request (KEYID_REQ) to the Storage Encryption Drive (SCDRV). This Key ID Request (KEYID_REQ) requests a Key ID that identifies the storage key and the encapsulated key (②).

[0083] The storage encryption driver SCDRV can provide the encrypted storage key request ENCKEY_REQ and the encapsulated key to the storage encryption manager SCMNG (③). The encrypted storage key request ENCKEY_REQ may include the virtual machine identifier VMID.

[0084] The Storage Encryption Manager (SCMNG) can obtain the storage key by decrypting the encapsulated key based on the encapsulation key.

[0085] The Storage Encryption Manager (SCMNG) can generate a storage key (KEK) corresponding to the virtual machine identifier (VMID) and encrypt the storage key based on the storage KEK. The Storage Encryption Manager (SCMNG) can update the storage KEK table 232 included in the encryption controller 122, so that the storage KEK corresponding to the virtual machine identifier (VMID) is stored in the storage KEK table (④).

[0086] The storage encryption manager SCMNG can provide the storage encryption key ENC_KEY based on the storage KEK to the storage encryption driver SCDRV (⑤).

[0087] The storage encryption driver SCDRV can store the encrypted storage key ENC_KEY in the encrypted storage key database ENC_KEY DB and generate a key ID that can identify the encrypted storage key ENC_KEY (⑥).

[0088] The storage encryption drive SCDRV can provide key IDs to the guest storage service GSS (⑦). The guest storage service GSS can manage key IDs by mapping key IDs to the addresses of storage areas that require encryption.

[0089] Figure 10 This is a block diagram illustrating the storage input / output operation according to an embodiment. (Refer to the above...) Figure 6 The access control table (ACT) can be generated in the protection circuit 121 through storage protection setting operations. Storage key slot update operations can also be performed simultaneously with storage I / O operations.

[0090] The Virtual Machine Context Manager (VMCMNG) can store the virtual machine identifier (VMID) of the currently running virtual machine in the VMID register 211 (①). The virtual machine that generated the command stored in the message queue 222 can be identified by referring to the VMID register 211. For example, the command stored in the message queue 222 can be generated by a virtual machine that has the virtual machine identifier (VMID) stored in the VMID register 211.

[0091] The guest application GAPP can provide an input / output request (REQ) to the guest storage service GSS (②). The input / output request REQ can include the address (ADDR) of the storage area where the data is stored.

[0092] The Guest Storage Service (GSS) can provide an Input / Output Request (REQ) to the Guest Storage Drive (GSDRV) (③). The REQ may include a key ID associated with the storage key used to encrypt data corresponding to the storage region at address ADDR. (See above reference.) Figure 9 The Guest Storage Service (GSS) can obtain the key ID of the storage area through the storage key generation operation.

[0093] The guest storage drive GSDRV can request the storage encryption drive SCDRV a key slot ID request SLOTID_REQ(④) for the key slot. For example, refer to Figure 4 You can assign a slot ID to each key slot. The slot ID request SLOTID_REQ can include the key ID.

[0094] The storage encryption driver SCDRV can obtain the encrypted storage key ENC_KEY corresponding to the key ID from the encrypted storage key database ENC_KEY DB, and store the obtained encrypted storage key ENC_KEY in storage key slot 231 through the storage encryption manager SCMNG (⑤). Specifically, the storage encryption driver SCDRV can update storage key slot 231 through the storage encryption manager SCMNG, so that the virtual machine identifier VMID of the guest virtual machine GUEST VM1 and the obtained encrypted storage key ENC_KEY are mapped to each other. In some embodiments, the storage encryption driver SCDRV can store the slot ID of the key slot in the encrypted storage key database ENC_KEY DB. For example, refer to... Figure 4 The storage encryption drive SCDRV can obtain the slot ID of the key slot for the storage encryption key ENC_KEY through the storage encryption manager SCMNG, and store the slot ID in the encryption storage key database ENC_KEY DB. The storage encryption manager SCMNG can provide the virtual machine identifier VMID of the guest virtual machine GUESTVM1 to the encryption controller 122.

[0095] The storage encryption drive SCDRV can provide the slot ID of the key slot containing the encrypted storage key ENC_KEY in the storage key slot 231 to the guest storage drive GSDRV (⑥).

[0096] The guest storage drive GSDRV can store a command CMD, including the slot ID, in message queue 222 (⑦). The command CMD may include the address ADDR.

[0097] Protection circuit 121 can extract address ADDR based on command CMD and control access based on the mapping relationship between virtual machine identifier VMID and address ADDR in access control list ACT. Storage host controller 210 can provide command CMD and virtual machine identifier VMID to encryption controller 122 (⑧) when protection circuit 121 grants access to address ADDR.

[0098] Encryption controller 122 can obtain a storage key based on command CMD and virtual machine identifier VMID. When command CMD is a write command, encryption controller 122 can encrypt data read from memory 20 based on the storage key (⑨). The encrypted data can be stored in storage device 30 (⑨). Alternatively, when command CMD is a read command, encryption controller 122 can decrypt the encrypted data read from storage device 30 based on the storage key (⑨). The decrypted data can be loaded into memory 20 (⑥). Specifically, encryption controller 122 can obtain a storage KEK from storage KEK table 232 based on virtual machine identifier VMID. Encryption controller 122 can obtain an encrypted storage key from storage key slot 231 based on slot ID included in command CMD. Encryption controller 122 can obtain a storage key by decrypting the encrypted storage key based on storage KEK. Encryption circuit 233 can encrypt or decrypt data based on the storage key.

[0099] Figure 11 This is a flowchart explaining the operation method of the encryption controller according to an embodiment. See also... Figure 10 To describe Figure 11 .

[0100] refer to Figure 11 In operation S1101, the encryption controller 122 can identify the virtual machine identifier VMID stored in the VMID register 211.

[0101] In operation S1102, the encryption controller 122 can search the storage KEK table 232 based on the virtual machine identifier VMID.

[0102] When a matching virtual machine identifier (VMID) exists in the storage KEK table 232 (S1103=Y), in operation S1104, the encryption controller 122 can obtain the storage KEK corresponding to the virtual machine identifier (VMID). When no matching virtual machine identifier (VMID) exists in the storage KEK table 232 (S1103=N), in operation S1111, the encryption controller 122 can generate a VMID error signal.

[0103] In operation S1105, the encryption controller 122 can identify the slot ID included in the command CMD stored in the message queue 222.

[0104] In operation S1106, the encryption controller 122 can search for the storage key slot 231 based on the virtual machine identifier VMID.

[0105] In operation S1108, when a matching virtual machine identifier (VMID) exists in storage key slot 231 (S1107=Y), the encryption controller 122 can obtain the encrypted storage key corresponding to the slot ID. In operation S1111, when a matching virtual machine identifier (VMID) does not exist in storage key slot 231 (S1107=N), the encryption controller 122 can generate a VMID error signal.

[0106] In operation S1109, the encryption controller 122 can decrypt the encrypted storage key based on the storage KEK.

[0107] In operation S1110, the encryption controller 122 can encrypt data loaded into the memory 20 based on the storage key, or decrypt encrypted data read from the storage device 30.

[0108] Figure 12 This is a flowchart illustrating a method for controlling access to a storage device in a virtualized environment, according to an implementation scheme.

[0109] refer to Figure 12 In operation S1210, the management program 40 can refer to the above. Figure 9 The described storage KEK table update operation generates multiple storage KEKs corresponding to virtual machine identifiers. Although Figure 9 The guest virtual machine GUEST VM1 is described, but the hypervisor 40 can also generate storage KEKs for other virtual machines and update the storage KEK table 232.

[0110] In operation S1220, the hypervisor 40 can generate multiple encrypted storage keys corresponding to virtual machine identifiers. For example, as referenced above... Figure 9 The hypervisor 40 can generate a storage key by decrypting the encapsulated key based on the encapsulation key, and can generate an encrypted storage key by encrypting the storage key based on the storage KEK. The encrypted storage key can be stored in the encrypted storage key database ENC_KEY DB. The hypervisor 40 can also generate multiple encrypted storage keys for the guest virtual machine VM1. Although... Figure 9 The guest virtual machine GUEST VM1 is described, but hypervisor 40 can also generate at least one encrypted storage key for other virtual machines. Furthermore, as referenced above... Figure 10 The hypervisor 40 can store encrypted storage keys in storage key slot 231. Storage key slot 231 can store at least one encrypted storage key for each of a plurality of virtual machine identifiers.

[0111] In operation S1230, the encryption controller 122 can obtain the first storage KEK based on the first virtual machine identifier of the first virtual machine among a plurality of virtual machines. For example, refer to Figure 10 The encryption controller 122 can obtain the virtual machine identifier VMID from the VMID register 211 and search the storage KEK table 232 based on the virtual machine identifier VMID to obtain the storage KEK.

[0112] In operation S1240, the encryption controller 122 can obtain the first encrypted storage key based on the first virtual machine identifier. For example, refer to... Figure 10 The encryption controller 122 can obtain the virtual machine identifier VMID from the VMID register 211, extract the slot ID from the command CMD, and search the storage key slot 231 based on the virtual machine identifier VMID and the slot ID to obtain the encrypted storage key.

[0113] In operation S1250, the encryption controller 122 can decrypt the first encrypted storage key based on the first storage KEK to obtain the first storage key.

[0114] In operation S1260, the encryption controller 122 can encrypt data in the memory 20 based on the first storage key, or decrypt encrypted data read from the storage device 30.

[0115] While various aspects of the embodiments have been specifically shown and described, it will be understood that various changes in form and detail may be made therein without departing from the spirit and scope of the appended claims.

Claims

1. A system-on-a-chip, comprising: A storage host controller includes a virtual machine identifier register and a buffer, wherein the virtual machine identifier register is configured to store the operation virtual machine identifier of the currently running operation virtual machine among a plurality of virtual machines, and the buffer is configured to store commands generated by the operation virtual machine; and A storage encryption controller is configured to store multiple encrypted storage keys for multiple virtual machine identifiers respectively assigned to the plurality of virtual machines, select a first encrypted storage key from the plurality of encrypted storage keys based on the operation virtual machine identifier stored in the virtual machine identifier register according to the command, and encrypt or decrypt data corresponding to the command based on the first encrypted storage key.

2. The system-on-a-chip according to claim 1, further comprising protection circuitry configured to store information about a storage region of a plurality of storage regions of the storage device, which is the storage region of the operating virtual machine identifier assigned to the operating virtual machine.

3. The system-on-a-chip according to claim 2, wherein, The protection circuit is also configured to delete information about the storage area of ​​the operating virtual machine identifier assigned to the operating virtual machine based on the termination of the execution of the operating virtual machine.

4. The system-on-a-chip according to claim 2, wherein, The storage host controller is also configured to provide the storage device with the address of the storage area, encrypted data, and the commands.

5. The system-on-a-chip according to claim 2, wherein, The storage host controller is also configured to read the data from the address of the storage region according to the command, and to provide the read data to the storage encryption controller.

6. The system-on-a-chip according to claim 1, wherein, The storage encryption controller further includes multiple storage key encryption keys (KEKs) assigned to the plurality of virtual machine identifiers, and is further configured to select a first storage key from the plurality of storage key KEKs based on the command and the operation virtual machine identifier stored in the virtual machine identifier register, decrypt the first encrypted storage key based on the first storage key to obtain a decrypted first storage key, and decrypt or encrypt the data corresponding to the command based on the decrypted first storage key.

7. The system-on-a-chip according to claim 6, wherein, The storage encryption controller includes a memory, the memory comprising: The storage key slots include multiple key slots for storing the multiple encrypted storage keys corresponding to the multiple virtual machine identifiers; and Store a KEK table to store the plurality of stored KEKs corresponding to the plurality of virtual machine identifiers.

8. The system-on-a-chip according to claim 7, wherein, The command includes the operation virtual machine identifier and the key slot identifier, and The storage encryption controller is further configured to select a first key slot from the plurality of key slots based on the operating virtual machine identifier and the key slot identifier provided in the command, and to select the encrypted storage key stored in the first key slot as the first encrypted storage key.

9. A method for controlling access to a storage device in a virtualized environment comprising multiple virtual machines and a hypervisor, the method comprising: The management program generates multiple storage key encryption keys KEK, each corresponding to a virtual machine identifier of one of the multiple virtual machines. The management program generates multiple encrypted storage keys, each corresponding to the virtual machine identifier. Based on the first virtual machine among the plurality of virtual machines, the virtual machine identifier, and the first virtual machine identifier, the first storage KEK is obtained from the plurality of storage KEKs; The first encrypted storage key is obtained from the plurality of encrypted storage keys based on the first virtual machine identifier; Based on the first storage KEK, the first encrypted storage key is decrypted to obtain the first storage key; and Data related to commands generated by the first virtual machine is encrypted or decrypted based on the first storage key.

10. The method according to claim 9, wherein, The generation of the plurality of storage KEKs by the management program includes: The management program generates a second encrypted storage key by encrypting the first storage key based on the first key; and The second encrypted storage key is stored by the first virtual machine.

11. The method according to claim 10, wherein, The generation of the plurality of storage KEKs by the management program includes: The first virtual machine provides the second encrypted storage key to the management program; The management program decrypts the second encrypted storage key based on the first key to obtain the first storage key; The management program generates the first encrypted storage key by encrypting the first storage key based on the first storage KEK corresponding to the first virtual machine identifier among the plurality of storage KEKs; and The first virtual machine stores the first encrypted storage key in the database.

12. The method according to claim 11, wherein, The generation of the plurality of storage KEKs by the management program also includes obtaining a key identifier corresponding to the first encrypted storage key from the database by the first virtual machine.

13. The method according to claim 12, wherein, The generation of the plurality of encrypted storage keys by the management program further includes: The first virtual machine obtains the first encrypted storage key from the database based on the key identifier; and The first virtual machine stores the first encrypted storage key in the storage key slot corresponding to the first virtual machine identifier.

14. The method according to claim 13, wherein, The generation of the plurality of encrypted storage keys by the management program also includes the first virtual machine generating the command based on the slot identifier of the storage key slot.

15. The method of claim 9, further comprising: Generate mapping information between the first virtual machine identifier and the address of the storage region of the storage device; and Access to the storage device is blocked based on the address provided in the command and the first virtual machine identifier.

16. The method of claim 15, further comprising, based on the termination of execution of the first virtual machine, removing the mapping information between the first virtual machine identifier and the address of the storage region of the storage device.

17. An electronic device comprising: Memory, including volatile memory cells; Storage devices, including non-volatile memory cells; and The on-chip system is configured as follows: The storage contains multiple encrypted storage keys for multiple virtual machine identifiers assigned to multiple virtual machines. The storage key encryption key KEK is assigned to the plurality of virtual machine identifiers; Based on the command generated by the first virtual machine among the plurality of virtual machines, and based on the first virtual machine identifier of the first virtual machine, a first encrypted storage key is selected from the plurality of encrypted storage keys; Select a first storage KEK from the plurality of storage KEKs based on the first virtual machine identifier; Based on the first storage KEK, the first encrypted storage key is decrypted to obtain the storage key; Based on the fact that the command is a write command, data related to the command is read from the memory, and the read data is encrypted based on the storage key; and The encrypted data is stored in the storage device.

18. The electronic device according to claim 16, wherein, The system-on-chip includes a memory, the memory comprising: The storage key slots include multiple key slots for storing the multiple encrypted storage keys corresponding to the multiple virtual machine identifiers; and The storage key encryption key table stores the multiple storage KEKs corresponding to the multiple virtual machine identifiers.

19. The electronic device according to claim 16, wherein, The system-on-chip includes a protection circuit configured to store information about a storage region within the storage region of the storage device that is assigned to the first virtual machine identifier.

20. The electronic device according to claim 19, wherein, The protection circuit is also configured to delete information about the storage area assigned to the first virtual machine identifier based on the termination of the execution of the first virtual machine.

Images