An encrypted file system for confidential container scenarios

Abstract

The present invention discloses an encrypted file system for confidential container scenarios, including: using different encrypted image formats for read-only layers and writable layers to support multi-layer encrypted image stacking; supporting encryption protection mode and integrity verification mode to meet the needs of different scenarios; hierarchical management of encryption and decryption keys, that is, reflecting the cryptographic information of each layer of data structure to its logical upper layer, and the final key of the top layer is saved by the image owner of the encrypted file system; targeted optimization of the space and time efficiency of the index of the directory entry table; providing a cache mechanism to maintain the ciphertext cache inside the trusted execution environment through the cache mechanism; using an independent encrypted image construction program to build encrypted images for the read-only layer and the writable layer, thereby improving the adaptability and construction efficiency of the confidential container file system.

Description

Technical Field

[0001] The present invention belongs to the technical field of the combination of trusted computing systems and file systems, and specifically relates to an encrypted file system for confidential container scenarios. Background Art

[0002] In recent years, with the rapid advancement of computer technology and the rapid development of the internet industry, cloud computing has become widely used, but this has also led to numerous security issues. Complex architectures, numerous deployment scenarios, and diverse software sources make it difficult for cloud computing to maintain security capabilities as it continues to scale through traditional security measures such as resource isolation and permission authentication. Against this backdrop, hardware manufacturers have introduced hardware support for Trusted Execution Environments (TEEs). TEEs use hardware to run private programs and data in an isolated environment, effectively preventing external access and tampering.

[0003] Confidential container technology emerged in the context of TEEs. It seeks to combine TEE and container technologies, leveraging existing container runtime frameworks and adhering to existing container standards (such as OCI) to enable simple, fast, and efficient deployment of user applications within TEE environments. Container operation often requires stacking multiple container images into a single layer using layered file systems like overlayfs for use within the container environment, facilitating container creation and management. Furthermore, in TEE scenarios, since all data within the TEE must be protected from external access, data generated within the TEE generally requires encryption before being written to disk. Data read from external disks or images also requires decryption before being accessed and processed within the TEE. This typically requires the TEE runtime to provide encrypted file system capabilities. Therefore, in confidential container scenarios, the payload container must support both capabilities to operate without compromising the TEE threat model. Currently, there are few encrypted file systems specifically designed for confidential container scenarios, and those actually used in confidential container scenarios have not been deeply adapted for this scenario.

[0004] The technical shortcomings of the encrypted file systems used by existing confidential containers are as follows:

[0005] 1) Block-level data protection is not supported. Some encrypted file systems for TEEs only provide file-level encryption protection, using a single key or a limited number of keys for the entire file, such as Graphene-SGX. This significantly reduces the protection capabilities of encrypted files: if the key is accidentally leaked due to malicious or side-channel means, an attacker can obtain the ciphertext of the file. Furthermore, most encrypted file systems used in TEE scenarios do not use data structures such as hash trees for fast integrity verification. Integrity verification is either completely missing or the integrity verification unit is too large (such as the file level), resulting in very low latency and efficiency when opening files.

[0006] 2) Lack of support for file system-level protection. Currently used encrypted file systems in TEE scenarios generally lack file system-level protection capabilities. This involves embedding keys within the file system structure, treating different data types or data structures within the file system differently, and forming a more efficient metadata and data management mechanism. For example, the popular LibOS Occlum uses the built-in SEFS encrypted file system to provide data sealing capabilities for Occlum workloads, but the SEFS implementation is entirely based on the encrypted file functionality of the Intel SGX SDK. While the latter implements block-level data protection and fast integrity verification, because SEFS is layered on top, the different data structures of the file system are not differentiated during encryption, resulting in lower efficiency.

[0007] 3) No cache or inefficient cache. Current encrypted file systems often lack plaintext caching (such as Graphene-SGX) or use general caching capabilities specific to the scenario. For example, Occlum's SEFS uses the SDX SDK's encrypted file cache, and confidential virtual machine scenarios often use the general buffer cache provided by the Linux kernel. These implementations can only meet basic caching requirements and are not optimized for TEE and confidential container scenarios. For example, the SGX SDK's encrypted file function uses a 48-block cache for each file, failing to consider the actual size of the protected object. This can easily result in significant idle space, increasing the TCB and posing security risks. Its hash tree implementation lacks a specific caching algorithm, making it prone to cache overflows.

[0008] 4) The local image building process is not optimized. Existing confidential container solutions lack specific optimizations for container building in confidential container scenarios. For example, Occlum's SEFS image building process simply creates an empty image and copies its contents into it using the same file system writing process. This process involves the use of a corresponding space allocation algorithm, resulting in repeated modifications to the same data structure. These unnecessary accesses generate additional system calls. In TEE scenarios, especially SGX scenarios, IO system calls incur additional memory copies to ensure security, reducing efficiency.

[0009] In summary, there are many issues that need to be addressed in the encrypted file system of confidential containers, and the industry needs more efficient and dedicated support for confidential container data sealing. Summary of the Invention

[0010] In view of the above, the purpose of the present invention is to provide an encrypted file system for confidential container scenarios to address the technical shortcomings of the encrypted file system used in the above-mentioned existing confidential containers.

[0011] To achieve the above-mentioned purpose of the invention, an embodiment provides an encrypted file system for confidential container scenarios, including:

[0012] Provides a cascaded structure based on image layer stacking, and uses different encrypted image formats for read-only and writable layers to support multi-layer encrypted image stacking;

[0013] Encryption and decryption are performed in data blocks, and encryption and decryption keys are managed hierarchically. That is, the encryption and decryption keys for each layer of the data structure are reflected in the logical upper layer data structure, and the final key of the top layer is saved by the image owner of the encrypted file system.

[0014] Provide a caching mechanism to maintain the plaintext cache within the trusted execution environment;

[0015] Use independent encrypted image building programs to build encrypted images for read-only and writable layers, ensuring efficiency and reliability in terms of build time and space.

[0016] Optimize the space and time efficiency of the directory entry table index.

[0017] Preferably, a compact encrypted image format is used for the read-only layer, leaving no free area, and starting from offset 0, it is the super block, inode table, directory entry table, long path table and file data area;

[0018] The super block is the metadata area of ​​the encrypted file system, storing meta information for the encrypted file system;

[0019] The inode table is a collection of file system objects. The representation size of file system objects in the read-only layer is inconsistent, and byte offsets are required to determine the location.

[0020] The directory entry table stores all directory entries. Its size is uniform, and the directory entries of the same directory are continuous in the table. The directory inode only needs to store the actual offset and number.

[0021] The long path table stores long path names that cannot be placed in the reserved space, including the names of soft links and directory entries. The strings in the table are not aligned and do not have trailing zeros. The inode must record the exact starting position and byte length.

[0022] The file data area stores file data, which is arranged randomly and requires a starting position to be specified in the inode.

[0023] Preferably, a sparse encrypted image format is used for the writable layer to provide space for easy expansion and contraction of the allocation algorithm. Each data structure unit can represent file content data, inode table, directory entry table of each directory, super block or bitmap data. Each data structure unit is presented as an encrypted file on the host side. All encrypted files are placed in the same directory, representing a writable layer.

[0024] The superblock is the metadata area of ​​the encrypted file system, which stores meta-information for the encrypted file system. An inode bitmap area is appended to the superblock file to record the allocation of the inode table.

[0025] The inode table is a collection of file system objects. In the writable layer, the inode size is consistent and the specific location is determined by number offset.

[0026] The directory entry table of each directory is regarded as the data of the inode and is stored separately in an encrypted file like the file data area.

[0027] Preferably, when encryption and decryption are performed in units of data blocks, the AES-GCM algorithm is used for encryption and decryption.

[0028] Preferably, when integrity verification is performed in units of data blocks, the SHA3-256 algorithm is used to obtain a hash value.

[0029] Preferably, the encryption and decryption keys for each layer of the data structure are reflected in the logical upper layer data structure, and the final key of the uppermost layer is saved by the image owner of the encrypted file system, including:

[0030] Except for the super block or the encrypted file, all structures are wrapped in a hash tree. The expansion of the hash tree can be directly appended to the end of the encrypted file, and the contraction of the hash tree will truncate the end of the encrypted file.

[0031] For ordinary data blocks and hash tree index blocks, the key is located in the hash tree parent node; for the hash tree root node, the key is located in the corresponding inode. If it is the file system metadata part, the key is located in the super block; the key of the super block is kept by the image owner of the encrypted file system.

[0032] Preferably, a caching mechanism is provided to maintain a plaintext cache within the trusted execution environment, including:

[0033] The cache types in the provided cache mechanism include data block cache, inode cache, and path cache. The cache contains plaintext data and occupies the private memory of the trusted execution environment.

[0034] The cache mechanism is dynamic. When opening a file, the cache is increased or decreased based on the existing cache and the size of the file to be opened, so as to minimize the TCB.

[0035] The cache threshold and ratio can be set manually at startup.

[0036] Preferably, it also includes providing a cache mechanism for the hash tree write-back operation, specifically:

[0037] The cache provided for the hash tree write-back operation is a dynamic key temporary storage area, where the key to be updated is temporarily stored, suppressing continuous key cache write-back operations and maintaining stable performance.

[0038] Preferably, the method further comprises: adopting an inline data structure at multiple locations, wherein the data adopting the inline data structure includes file data, a directory entry table, and a soft link path.

[0039] Preferably, an independent encryption image building program is used to build encrypted images for the read-only layer and the writable layer, including:

[0040] An additional independent encrypted image builder analyzes the characteristic indicators of the target file tree, including the number of files, the number of directories, the file tree depth, and the file size, and writes the encrypted data into the encrypted image file at one time without causing additional input and output, thereby reducing unnecessary memory copies in the trusted execution environment.

[0041] Preferably, the space and time efficiency of the index of the directory entry table is optimized, including:

[0042] For the read-only layer, the directory entry tables of all directories are connected into one table. Each directory inode needs to record its starting position and length. The inode of the read-only layer stores a limited number of index entries. When searching for a directory entry, the encrypted file system first calculates the minor hash of the path, searches for the index entry based on the minor hash, determines the segment where the target directory entry exists based on the index entry, and then performs a traversal search. The segment length pointed to by the index entry has a constant upper limit to reduce the number of search traversals. The construction of the index entry is completed by the encrypted image construction program. During the construction, the appropriate index segment is selected based on the number of directory entries. When there are few directory entries, the index has at most one layer.

[0043] For the writable layer, the directory entry table is split up and its parts are indexed in the same way as for the read-only layer.

[0044] Compared with the prior art, the present invention has the following beneficial effects:

[0045] The present invention provides block-level data protection capabilities, deeply integrates with the file system structure, and is supplemented by multiple optimizations such as algorithm optimization, cache optimization, and image construction optimization to improve the adaptability and efficiency of the confidential container file system. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0047] Figure 1 1 is a schematic diagram of an improved process of an encrypted file system provided in an embodiment;

[0048] Figure 2 This is a read-only layer image format diagram provided by the embodiment;

[0049] Figure 3 This is a writable layer image format diagram provided by the embodiment;

[0050] Figure 4 This is a flowchart of basic file operations of the encrypted file system provided by the embodiment. DETAILED DESCRIPTION

[0051] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention is further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and do not limit the scope of protection of the present invention.

[0052] After analysis, this paper believes that in the confidential container scenario, the encrypted file system needs to make the following adaptations and optimizations to improve the efficiency and adaptability of the encrypted file system:

[0053] 1) Ability to encrypt and decrypt data blocks using different randomly generated keys. Symmetric encryption algorithms can generally be used to achieve more ideal and stable performance.

[0054] 2) Provide data sealing capabilities at the encrypted file system level, treating each part of the file system's metadata separately and modifying the format of the encrypted file system image to support encryption protection. The keys for each layer of the encrypted file system's data structure, such as the key, should be reflected in the logical upper-level data structure layer by layer. Ultimately, the security protection of the entire file system should be reflected in the top-level key layer, which will be stored by the file system image owner.

[0055] 3) Provide a certain degree of caching mechanism for encrypted data. Because the encryption and decryption process will seriously slow down the TEE's IO performance, the file system needs to maintain a ciphertext cache within the TEE to help the load program maintain a reasonable performance overhead.

[0056] 4) Provide support for overlay-like layered file systems. Container images in confidential container scenarios often follow the OCI standard, requiring multiple layers of encrypted images to be stacked to form the final container rootfs. Therefore, an encrypted file system that supports stacking multiple layers of encrypted images is required in confidential containers.

[0057] 5) Provide an efficient encrypted local image build process. Since confidential container images cannot be read or accessed by software outside the TEE, the OCI encrypted format must be converted to the local encrypted file system image format when pulling the image to facilitate local operation. Because TEE's I / O performance is limited by encryption and decryption, the local image build process must minimize I / O operations to reduce container startup latency.

[0058] Based on the above analysis, the encrypted file system for confidential container scenarios provided by the embodiment provides block-level data protection capabilities, is deeply integrated with the file system structure, and is supplemented by multiple optimizations such as algorithm optimization, cache optimization, and image construction optimization to improve the adaptability and efficiency of the confidential container file system. Figure 1 As shown, specifically including:

[0059] The encrypted file system of the present invention provides a stacked structure based on image layer overlay, and adopts different encrypted image formats for the read-only layer and the writable layer, supporting multi-layer encrypted image stacking.

[0060] Specifically, compared to common containers, only the top layer is writable and the remaining layers are read-only. Since the content of the read-only layer will not change, in order to improve efficiency and save space, the present invention separates the formats of the read-only layer and the writable layer, and supports multi-layer encrypted image stacking to form a layered structure.

[0061] like Figure 2 As shown, the read-only layer uses a compact encrypted image format, minimizing free space. Starting from offset 0, the following are the superblock, inode table, directory entry table, long path table, and file data area. The superblock is the metadata area of ​​the encrypted file system, storing metadata specific to the encrypted file system, such as the starting position and range of other areas, the encryption mode, size, and data statistics. It is one block in size. The inode table is a collection of file system objects (inodes). In the read-only layer, inode sizes are inconsistent, so byte offsets are used to determine their positions. The directory entry table stores all directory entries of uniform size, and entries for the same directory are contiguous in the table. Directory inodes only need to store their actual offsets and sizes. The long path table stores long path names that cannot fit into the reserved space, including soft link names and directory entry names. The strings in the table are misaligned and lack trailing zeros, requiring the inode to record the exact starting position and byte length. The file data area stores file data in a random order, requiring a specific starting position in the inode.

[0062] like Figure 3 As shown, the writable layer uses a sparse encrypted image format to provide sufficient space for the allocation algorithm and facilitate expansion and contraction. Specifically, each data structure unit can include a file data area, an inode table, a directory entry table for each directory, bitmap data, or a superblock. Each data structure unit appears as an encrypted file on the host side. All encrypted files are placed in the same directory, representing a writable layer. The superblock, inode table and other structures are similar to those of the read-only layer. The difference is that an inode bitmap area is appended to the superblock file to record the allocation status of the inode table. The directory entry table of each directory is regarded as the data of the inode and is stored separately in an encrypted file like the file data area.

[0063] Considering that the image layer in confidential container scenarios is not overly large or complex, and that many files, directory entries, and other data are generally small, this invention employs inline data structures in various locations. Data that can be inlined includes file data, directory entry tables, and soft link paths. This inline data can better maintain spatial consistency, improve cache hit rates, and enhance overall file system efficiency.

[0064] The encrypted file system of the present invention performs encryption and decryption in units of data blocks and manages the encryption and decryption keys in a hierarchical manner, that is, the encryption and decryption keys for each layer of the data structure are reflected in the logical upper layer data structure, and the final key of the top layer is saved by the mirror owner of the encrypted file system.

[0065] Specifically, the encrypted file system uses two configurable protection modes: encryption mode and integrity mode. Encryption mode performs encryption and decryption on a per-block basis while also recording integrity information. Specifically, the AES-GCM algorithm can be used to balance confidentiality and integrity. Integrity mode only verifies the integrity of data blocks without encryption protection. In this case, the SHA3-256 algorithm is used to generate hash values.

[0066] Specifically, the encryption and decryption keys are managed hierarchically, including:

[0067] All structures, except for the superblock or the encrypted file, are wrapped in a Merkle Hash Tree (MHT) to achieve reasonable data integrity checking performance and convenient hierarchical key management. Due to the structural characteristics of the MHT, MHT expansion can be directly appended to the end of the encrypted file, while MHT contraction truncates the end of the encrypted file, which facilitates the use of writable mode.

[0068] The key of each data structure is stored at its upper level in the file system logical hierarchy: for ordinary data blocks and hash tree index blocks, the key is located in the hash tree parent node; for the hash tree root node, the key is located in the corresponding inode; if it is the file system metadata part, the key is located in the superblock; the key of the superblock is kept by the image owner.

[0069] The encrypted file system of the present invention provides a caching mechanism that maintains a ciphertext cache within the Trusted Execution Environment (TEE). Specific cache types include data block cache, inode cache, and path cache. The cache contains plaintext data and occupies the private memory of the Trusted Execution Environment (TEE). The caching mechanism provided by the encrypted file system of the present invention is dynamic. When opening a file, the cache is increased or decreased based on the existing cache and the size of the file to be opened, minimizing the TCB. Furthermore, the cache threshold and ratio can be manually set at startup, improving convenience.

[0070] The encrypted file system of the present invention provides a caching mechanism, including a cache for hash tree writeback operations. For MHT, when a leaf node data block needs to be written back from the cache to the mirror image, the key of its parent node must be updated. The parent node may also update its own key, which can cause continuous cache writeback operations. This phenomenon significantly reduces cache efficiency and leads to unstable performance. To address this problem, the MHT cache uses a dynamic key temporary storage area to temporarily store the key to be updated, preventing continuous cache writebacks and maintaining stable performance.

[0071] The encrypted file system of the present invention also uses an additional independent encrypted image construction program that is not a local encrypted image construction program to build encrypted images for the read-only layer and the writable layer. As described above, the process of building a local encrypted image will affect the container startup delay. In this regard, the present invention speeds up the construction speed by designing an independent encrypted image construction program instead of writing an empty image. Specifically, the additional independent encrypted image construction program will analyze the size of the target file tree, the number of files, the number of directories and other information, and write the encrypted data into the encrypted image file at one time, without causing additional IO, thereby reducing unnecessary memory copies in the TEE environment.

[0072] The encrypted file system of the present invention also optimizes the index of the directory entry table. The structure and index design of the directory entry table directly determine the efficiency of directory entry search. The present invention makes targeted optimizations to the directory entry table index, specifically including:

[0073] For the read-only layer, the directory entry tables of all directories are concatenated into a single table. Each directory inode (inode) records its starting position and length. A limited number of index entries are stored in the read-only layer's inodes. When searching for a directory entry, the encrypted file system first calculates the path's minor hash (the specific algorithm is similar to the minor hash implementation of the ext4 file system in the Linux kernel). It then searches for the index entry based on the minor hash. The index entry then determines the segment where the target directory entry exists, and then performs a traversal search. The segment length pointed to by the index entry has a constant upper limit, significantly reducing the number of search traversals. Index entry construction is performed by the encrypted image build program. During construction, the appropriate index segment is selected based on the number of directory entries. When there are few directory entries, the directory entry may not exist. Considering the efficiency of the build program and the use case, since image build time affects container startup latency and complex image layers are generally not used in confidential container scenarios, the index is limited to a maximum of one layer.

[0074] For the writable layer, although the directory entry table is split, the indexing method of each part is the same as that of the read-only layer, so I will not go into details.

[0075] The encrypted file system of the present invention is written in Rust, and the file system logic is presented as a Rust Crate, which can be easily integrated with various programs, such as LibOS such as Occlum written in Rust, or presented as a FUSE daemon in the virtual machine TEE through the FUSE interface.

[0076] The embodiment also provides the operation process of the above-mentioned encrypted file system, such as Figure 4 As shown, the following steps are involved: When the upper-layer software issues a file read or write operation, the virtual file system (VFS) layer (provided by LibOS or the guest kernel, or using the VFS that comes with this file system) parses the file operation, splits the path, and finds the corresponding file system instance (read-only layer, read-write layer, or overlay). For each layer of the path, the file system searches the inode cache for the corresponding inode number. If there is no cache, it reads and decrypts it from the encrypted image. For file-type inodes, the corresponding data block is found in the MHT based on the offset. For directory-type inodes, the directory entry table offset and any existing indexes are analyzed to the corresponding table interval and traversed for search. If the corresponding data block is not in the cache, it is retrieved from the encrypted image and decrypted. This process is repeated for each layer of the path, and the result is finally returned to the upper-layer software.

[0077] The specific implementation methods described above provide a detailed description of the technical solutions and beneficial effects of the present invention. It should be understood that the above is only the most preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, supplements and equivalent substitutions made within the scope of the principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. An encrypted file system for confidential container scenarios, characterized by: include: Provides a cascaded structure based on image layer stacking, and uses different encrypted image formats for read-only and writable layers to support multi-layer encrypted image stacking; Encryption and decryption are performed in data blocks, and encryption and decryption keys are managed hierarchically. That is, the encryption and decryption keys for each layer of the data structure are reflected in the logical upper layer data structure, and the final key of the top layer is saved by the image owner of the encrypted file system. Provide a caching mechanism to maintain the plaintext cache within the trusted execution environment; Use independent encrypted image building programs to build encrypted images for read-only and writable layers, ensuring efficiency and reliability in terms of build time and space. Optimize the space and time efficiency of the directory entry table index.

2. The encrypted file system for confidential container scenarios according to claim 1, characterized in that: For the read-only layer, a compact encrypted image format is used to avoid idle areas. Starting from offset 0, it contains the super block, inode table, directory entry table, long path table, and file data area. The super block is the metadata area of ​​the encrypted file system, storing meta information for the encrypted file system; The inode table is a collection of file system objects. The representation size of file system objects in the read-only layer is inconsistent, and byte offsets are required to determine the location. The directory entry table stores all directory entries. Its size is uniform, and the directory entries of the same directory are continuous in the table. The directory inode only needs to store the actual offset and number. The long path table stores long path names that cannot be placed in the reserved space, including the names of soft links and directory entries. The strings in the table are not aligned and do not have trailing zeros. The inode must record the exact starting position and byte length. The file data area stores file data, which is arranged randomly and requires a starting position to be specified in the inode.

3. The encrypted file system for confidential container scenarios according to claim 1, characterized in that: The writable layer uses a sparse encrypted image format to provide space for easy expansion and contraction of the allocation algorithm. Each data structure unit can represent file content data, inode table, directory entry table of each directory, super block, or bitmap data. Each data structure unit is presented as an encrypted file on the host side. All encrypted files are placed in the same directory, representing a writable layer. The superblock is the metadata area of ​​the encrypted file system, which stores meta-information for the encrypted file system. An inode bitmap area is appended to the superblock file to record the allocation of the inode table. The inode table is a collection of file system objects. In the writable layer, the inode size is consistent and the specific location is determined by number offset. The directory entry table of each directory is regarded as the data of the inode and is stored separately in an encrypted file like the file data area.

4. The encrypted file system for confidential container scenarios according to claim 1, characterized in that When encrypting and decrypting in data blocks, the AES-GCM algorithm is used for encryption and decryption; when performing integrity verification in data blocks, the SHA3-256 algorithm is used to obtain the hash value.

5. The encrypted file system for confidential container scenarios according to claim 1, characterized in that: The encryption and decryption keys for each layer of the data structure are reflected in the logical upper layer data structure, and the final key of the top layer is saved by the image owner of the encrypted file system, including: Except for the super block or the encrypted file, all structures are wrapped in a hash tree. The expansion of the hash tree can be directly appended to the end of the encrypted file, and the contraction of the hash tree will truncate the end of the encrypted file. For ordinary data blocks and hash tree index blocks, the key is located in the hash tree parent node; for the hash tree root node, the key is located in the corresponding inode. If it is the file system metadata part, the key is located in the super block; the key of the super block is kept by the mirror owner of the encrypted file system.

6. The encrypted file system for confidential container scenarios according to claim 1, characterized in that: Provides a caching mechanism to maintain a plaintext cache within the trusted execution environment, including: The cache types in the provided cache mechanism include data block cache, inode cache, and path cache. The cache contains plaintext data and occupies the private memory of the trusted execution environment. The cache mechanism is dynamic. When opening a file, the cache is increased or decreased based on the existing cache and the size of the file to be opened, so as to minimize the TCB. The cache threshold and ratio can be set manually at startup.

7. The encrypted file system for confidential container scenarios according to claim 5, characterized in that: Also includes: Provides a caching mechanism for hash tree writeback operations, specifically: The cache provided for the hash tree write-back operation is a dynamic key temporary storage area, where the key to be updated is temporarily stored, suppressing continuous key cache write-back operations and maintaining stable performance.

8. The encrypted file system for confidential container scenarios according to claim 1, characterized in that: Also includes: Inline data structures are used in multiple places, wherein the data using the inline data structure include file data, directory entry table, and soft link path.

9. The encrypted file system for confidential container scenarios according to claim 1, characterized in that: Use independent encrypted image building programs to build encrypted images for read-only and writable layers, including: An additional independent encrypted image builder analyzes the characteristic indicators of the target file tree, including the number of files, the number of directories, the file tree depth, and the file size, and writes the encrypted data into the encrypted image file at one time without causing additional input and output, thereby reducing unnecessary memory copies in the trusted execution environment.

10. The encrypted file system for confidential container scenarios according to claim 1, characterized in that: Optimize the space and time efficiency of the directory entry table index, including: For the read-only layer, the directory entry tables of all directories are connected into one table. Each directory inode needs to record its starting position and length. The inode of the read-only layer stores a limited number of index entries. When searching for a directory entry, the encrypted file system first calculates the minor hash of the path, searches for the index entry based on the minor hash, determines the segment where the target directory entry exists based on the index entry, and then performs a traversal search. The segment length pointed to by the index entry has a constant upper limit to reduce the number of search traversals. The construction of the index entry is completed by the encrypted image construction program. During the construction, the appropriate index segment is selected based on the number of directory entries. When there are few directory entries, the index has at most one layer. For the writable layer, the directory entry table is split up and its parts are indexed in the same way as for the read-only layer.

Images