File write protection methods, devices, electronic devices, storage media, and products

Abstract

Various embodiments of this disclosure provide file write protection methods, apparatuses, electronic devices, storage media, and products. The file write protection method according to an embodiment includes: when an application modifies a page of a target file in the page cache through a file write operation, intercepting the dirty page marking function of the system call executing the file write operation; determining that the target file is in a protected state if the inode of the target file has a protection flag set; and based on the target file being in a protected state, intercepting the dirty page marking function's dirty page marking of the target file's pages. Through this disclosure, file write protection can intercept file writes in a timely manner at the page cache level, effectively blocking malicious file writes.

Description

Technical Field

[0001] This disclosure relates to the field of computer science, and more specifically, to a method, apparatus, electronic device, storage medium, and product for protecting against file write errors. Background Technology

[0002] In Linux systems, file read and write operations are typically performed using a page cache. The page cache consists of a copy of the file content maintained in memory by the kernel, which improves file access performance. When an application writes data to a file, it usually performs a page-cached file write. Traditional file protection technologies often intercept suspicious writes at the file system level, which is difficult to precisely control the underlying write behavior and has many technical shortcomings. Especially for page-cached file writes, traditional file protection technologies lack effective blocking mechanisms. Summary of the Invention

[0003] Various embodiments of this disclosure provide a file write protection method, apparatus, electronic device, storage medium, and product that can promptly intercept file writes when suspicious write activity is detected.

[0004] Other aspects will be set forth in part in the description which follows, and in part will be apparent from the description or may be learned by practice of the embodiments presented.

[0005] According to a first aspect of the embodiments of this disclosure, a file write protection method is provided, the file write protection method comprising: when an application modifies a page of a target file in a page cache through a file write operation, intercepting a dirty page marking function of a system call executing the file write operation; determining that the target file is in a protected state if it is determined that the inode of the target file has a protection flag set; and based on the target file being in a protected state, intercepting the dirty page marking function for dirty page marking of the target file's pages.

[0006] Optionally, the step of intercepting the dirty page marking function for the pages of the target file based on the target file being in a protected state includes: based on the target file being in a protected state, not marking the pages of the target file in the page cache as dirty pages, and retaining the modified data in the pages of the target file.

[0007] Optionally, the file write protection method further includes: when the application writes dirty pages of the target file from the page cache back to non-volatile memory through the file write operation, hijacking the dirty page write-back function of the system call executing the file write operation; and if it is determined that the target file is in a protected state, intercepting the dirty page write-back of the dirty pages of the target file by the dirty page write-back function.

[0008] Optionally, the step of intercepting the dirty page write-back function for the dirty pages of the target file when it is determined that the target file is in a protected state includes: when it is determined that the target file is in a protected state, not writing the dirty pages of the target file to the non-volatile memory, marking the dirty pages of the target file as non-dirty pages, and retaining the data of the dirty pages of the target file in the non-dirty pages of the target file.

[0009] Optionally, the file write protection method further includes: upon determining that a predetermined event has occurred, clearing the protection flag bit in the inode of the target file to remove the protection status of the target file; marking non-dirty pages of the target file in the page cache as dirty pages, wherein the predetermined event includes at least one of a manual confirmation write recovery event, a timeout automatic write recovery event, and a process whitelist write recovery event.

[0010] Optionally, the file write protection method further includes: when suspicious write behavior is detected by the application, setting the protection flag bit for the inode of at least one file within the scope of the suspicious write behavior.

[0011] Optionally, setting the protection flag for the inode of at least one file within the scope of the suspicious write behavior includes: determining the directory range covered by the suspicious write behavior; setting the protection flag for the inode of at least one file within the directory range that meets predetermined conditions, wherein the predetermined conditions include the file being a preset type file and the inode of the file existing in memory.

[0012] Optionally, the file write operation includes standard write operations and memory-mapped write operations.

[0013] Optionally, the file write protection method further includes: when the application directly writes the modified data of the target file to non-volatile memory through the file write operation, hijacking the direct write function of the system call executing the file write operation; and when it is determined that the target file is in a protected state, intercepting the direct write of the modified data of the target file by the direct write function.

[0014] Optionally, when it is determined that the target file is in a protected state, intercepting the direct write function's direct write of the modified data of the target file includes: when it is determined that the target file is in a protected state, not writing the modified data of the target file to the non-volatile memory, and writing the modified data of the target file to the page cache or not storing the modified data of the target file.

[0015] Optionally, at least one step in the file write protection method is implemented at the page cache level by modifying kernel code and / or hijacking function calls of kernel modules, or at the file system level by modifying file system code.

[0016] According to a second aspect of the embodiments of this disclosure, a file write protection device is provided, the file write protection device comprising: a function call hijacking unit configured to hijack a dirty page marking function called by an application when an application modifies a page of a target file in a page cache through a file write operation; a file state identification unit configured to determine that the target file is in a protected state if a protection flag is set on the inode of the target file; and a file write protection unit configured to intercept dirty page marking of the target file's pages by the dirty page marking function based on the target file being in a protected state.

[0017] Optionally, the file write protection unit is configured to intercept the dirty page marking function for the pages of the target file based on the target file being in a protected state by: not marking the pages of the target file in the page cache as dirty pages based on the target file being in a protected state, and retaining the modified data in the pages of the target file.

[0018] Optionally, the function call hijacking unit is further configured to hijack the dirty page write-back function of the system call executing the file write operation when the application writes dirty pages of the target file from the page cache back to non-volatile memory through the file write operation; the file write protection unit is further configured to intercept the dirty page write-back of the dirty pages of the target file by the dirty page write-back function when it is determined that the target file is in a protected state.

[0019] Optionally, the file write protection unit is further configured to intercept the dirty page write-back function for dirty pages of the target file when it is determined that the target file is in a protected state by the following operations: when it is determined that the target file is in a protected state, not writing the dirty pages of the target file to the non-volatile memory, marking the dirty pages of the target file as non-dirty pages, and retaining the data of the dirty pages of the target file in the non-dirty pages of the target file.

[0020] Optionally, the file write protection device further includes a file write recovery unit, wherein the file write recovery unit is configured to: clear the protection flag bit in the inode of the target file to remove the protection status of the target file when a predetermined event is determined to have occurred; and mark the non-dirty pages of the target file in the page cache as dirty pages, wherein the predetermined event includes at least one of a manual confirmation write recovery event, a timeout automatic write recovery event, and a process whitelist write recovery event.

[0021] Optionally, the file write protection device further includes a file status marking unit, wherein the file status marking unit is configured to: when a suspicious write behavior is detected by the application, set the protection flag bit for the inode of at least one file within the coverage of the suspicious write behavior.

[0022] Optionally, the file status marking unit is configured to set the protection flag bit for the inode of at least one file within the scope of the suspicious write behavior by: determining the directory range covered by the suspicious write behavior; and setting the protection flag bit for the inode of at least one file within the directory range that meets predetermined conditions, wherein the predetermined conditions include that the file is a preset type file and that the inode of the file exists in memory.

[0023] Optionally, the file write operation includes standard write operations and memory-mapped write operations.

[0024] Optionally, the function call hijacking unit is further configured to hijack the direct write function of the system call executing the file write operation when the application directly writes the modified data of the target file to non-volatile memory through the file write operation; the file write protection unit is further configured to intercept the direct write of the modified data of the target file by the direct write function when it is determined that the target file is in a protected state.

[0025] Optionally, the file write protection unit is configured to intercept the direct write of the modified data of the target file by the direct write function when it is determined that the target file is in a protected state by the following operations: when it is determined that the target file is in a protected state, the modified data of the target file is not written to the non-volatile memory, and the modified data of the target file is written to the page cache or the modified data of the target file is not stored.

[0026] Optionally, at least one operation of the file write protection device is implemented at the page cache level by modifying kernel code and / or hijacking function calls of kernel modules, or at the file system level by modifying file system code.

[0027] According to a third aspect of the embodiments of the present disclosure, an electronic device is provided, the electronic device comprising: at least one processor; at least one memory storing computer-executable instructions, wherein the computer-executable instructions, when executed by the at least one processor, cause the at least one processor to perform the file write protection method as described above.

[0028] According to a fourth aspect of the embodiments of the present disclosure, a computer-readable storage medium is provided, wherein instructions in the computer-readable storage medium, when executed by at least one processor, cause the at least one processor to perform the file write protection method as described above.

[0029] According to a fifth aspect of the embodiments of the present disclosure, a computer program product is provided, including computer executable instructions, wherein the computer executable instructions, when run by at least one processor, implement the file write protection method as described above.

[0030] The file write protection method, apparatus, electronic device, storage medium, and product according to embodiments of this disclosure can hijack the dirty page marking function called by an application when writing a file, and determine whether dirty page marking is allowed based on whether a protection flag is set in the file's inode. When the file is determined to be protected based on the protection flag being set, dirty page marking by the application is not allowed, thereby preventing dirty pages containing malicious data from entering the write-back queue and achieving real-time blocking of malicious writing behavior. Correspondingly, malicious data that is not written back will not affect the data on the disk, thereby achieving effective file protection.

[0031] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0032] The above and other aspects, features and advantages of various embodiments of the present disclosure will become more apparent from the following description taken in conjunction with the accompanying drawings.

[0033] Figure 1 This is a flowchart illustrating the processing of kernel layer file tags according to an embodiment of the present disclosure.

[0034] Figure 2 This is a flowchart illustrating a file write protection method according to an embodiment of the present disclosure.

[0035] Figure 3 This is a flowchart illustrating the process of intercepting dirty page write-back according to an embodiment of the present disclosure.

[0036] Figure 4 This is a flowchart illustrating the write-back process according to an embodiment of the present disclosure.

[0037] Figure 5 This is a flowchart illustrating the process of direct write interception according to an embodiment of the present disclosure.

[0038] Figure 6 This is a block diagram illustrating a file write protection device according to an embodiment of the present disclosure. Detailed Implementation

[0039] To enable those skilled in the art to better understand the technical solutions of this disclosure, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings.

[0040] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of methods and apparatus consistent with some aspects of this disclosure as detailed in the claims.

[0041] It should be noted that the phrase "at least one of several items" in this disclosure refers to three parallel cases: "any one of the several items", "a combination of any number of the several items", and "all of the several items". For example, "including at least one of A and B" includes the following three parallel cases: (1) including A; (2) including B; (3) including A and B. Another example is "performing at least one of step one and step two", which means the following three parallel cases: (1) performing step one; (2) performing step two; (3) performing both step one and step two.

[0042] As described in the background section, traditional file protection technologies suffer from numerous technical shortcomings. For example, file system access control technology restricts process access to files solely by setting permissions and policies at the file system level. However, it has at least the following drawbacks: the interception granularity is insufficient, primarily performing access control when a file is opened, making it difficult to precisely control subsequent write operations after the file is opened; it is difficult to detect certain write operations, such as memory-mapped writes that directly modify memory, which are difficult to detect at the file system level; there is a time window between detecting suspicious write behavior and executing write interception, during which the suspicious write may have already written malicious data to the disk, especially for direct disk writes, which cannot be undone; and it is ineffective against attacks that inject malicious code into legitimate processes. If suspicious write behavior injects malicious code into a legitimate process, the access control policy allows that process to access the file, and therefore, access control is based on the legitimate process identity and does not recognize malicious writes within the process, thus failing to perform access control. Furthermore, traditional file protection technologies typically employ snapshots and backups for data recovery. These technologies periodically save the file system state and recover data after corruption. However, this data recovery method has several drawbacks: high recovery costs (snapshots and backups require additional storage space, the recovery process is time-consuming, and system services may be interrupted during recovery); the risk of data loss (due to periodic saving, data changes between snapshots may be lost, or if suspicious write activity occurs immediately after a snapshot, the latest data cannot be recovered, or the backed-up data itself may be modified by suspicious write activity); lack of real-time protection (snapshots and backups are post-incident recovery mechanisms and cannot block malicious writes in real time, making them unsuitable for applications with high real-time requirements); and poor versatility (snapshots and backups rely on specific file systems (such as Btrfs and ZFS), making data migration to snapshot-enabled file systems costly). In addition, traditional file protection technologies lack effective kernel write-back mechanisms for blocking.

[0043] Therefore, the related technologies suffer from at least several problems, including imprecise write control, inability to cover multiple write paths, inability to block in real time, and / or poor recoverability. To address at least some of the aforementioned defects and / or problems, various embodiments of this disclosure propose file write protection methods and apparatuses, electronic devices, computer-readable storage media, and computer program products.

[0044] Specifically, embodiments of this disclosure relate to file write protection based on page cache control, which achieves real-time blocking of malicious writes by intercepting file writes at the page cache level of the Linux kernel. In particular, considering that suspicious write activity may have already written encrypted or modified data to part of the page cache before triggering file write protection, embodiments of this disclosure do not prevent suspicious write activity from writing to the page cache, but rather prevent dirty pages written to the page cache from being written back to disk. This avoids the risk of suspicious write activity that has already written dirty pages to the page cache being written to disk, which is ignored by only intercepting write operations. Therefore, embodiments of this disclosure protect more files as early as possible by intercepting write-back paths to the greatest extent possible.

[0045] Various embodiments according to the present disclosure will now be described in detail with reference to the accompanying drawings. Before describing the various embodiments of the present disclosure, some terms used in the embodiments will first be explained.

[0046] Page Cache: A memory area in the Linux kernel used to cache the contents of disk files.

[0047] Dirty page: A page in memory that has been modified but has not yet been written back to disk.

[0048] Writeback: The process of synchronizing dirty pages to disk.

[0049] Memory mapping (mmap) is a mechanism that maps file content to the process address space.

[0050] Direct Input / Output (I / O) Flag (O_DIRECT): A file open flag that indicates that the page cache can be bypassed and the disk can be accessed directly.

[0051] Address space: A data structure in the kernel used to manage the page cache of files.

[0052] Index node (inode): A data structure in a file system that stores file metadata.

[0053] To provide early and real-time protection against suspicious write activity, this disclosure proposes that, upon detecting suspicious write activity, a protected tag be attached to a file that may be maliciously modified. During subsequent file write operations, the disclosure determines whether to implement file write protection based on whether the file has a protected tag, for example, whether to allow the modified data to be written to disk. In this disclosure, this process of marking files as protected can be referred to as kernel-level file tagging.

[0054] According to embodiments of this disclosure, when suspicious write activity is detected by an application, a protection flag is set for the inode of at least one file within the scope of the suspicious write activity. See below for further details. Figure 1 This will be described in detail.

[0055] Figure 1 This is a flowchart illustrating the processing of kernel layer file tags according to an embodiment of the present disclosure.

[0056] Specifically, refer to Figure 1 In step S110, the application is detected to have suspicious write behavior. In this disclosure, suspicious write behavior can refer to suspicious actions performed by an application that may be malware, such as writing, modifying, and / or encrypting files, for example, ransomware extortion. For example, decoy file techniques or user-space behavior detection can be used to detect suspicious write behavior by malware. This disclosure does not impose specific limitations on the detection of suspicious write behavior.

[0057] When suspicious write activity is detected, step S120 determines the directory range covered by the suspicious write activity. That is, the suspicious write activity may involve or affect files in one or more directories. When the security software detects a suspicious write event, it can notify the affected directory range. By determining all directories covered by the suspicious write activity and performing file protection, as many files as possible can be protected.

[0058] In step S130, it is determined whether the files within the directory range covered by the suspicious write behavior are files of a preset file type.

[0059] As an example, the default file type can be a regular file type. However, this disclosure is not limited to this. In this disclosure, a regular file can represent a normal file of an entity in a file type. As an example, step S130 may include traversing files in one or more directories within the directory range that triggered the suspicious write behavior to determine whether each file is a regular file. For example, when a file is a directory or symbolic link, it is determined that the file is not a regular file. As another example, when a file is an image file or a text file, it is determined that the file is a regular file. In this disclosure, there is no limitation on the specific method of distinguishing between regular and non-regular files; for example, a file may be determined to be a regular file based on DT_REG, which indicates a regular file type, but this disclosure is not limited to this.

[0060] When a file being traversed is not a file of the preset file type, in step S170, the kernel-level file marking process is skipped. For example, if the file is an unconventional file such as a symbolic link, there is no need to write protection for that file, and therefore no need to mark the file as protected.

[0061] When a file being traversed is a file of a preset file type, in step S140, the inode of the file is searched from the inode cache to determine whether the inode of the file exists in memory.

[0062] In this disclosure, the inode cache can be used to store a copy of the inode table on disk in memory; that is, the inode cache is a cache in memory. Specifically, if a file is open, the inode corresponding to that file exists in the cache; that is, the inode cache stores the inode of that file. Therefore, if the inode of a file is found in the cache, it can be determined that the file is open or has been accessed.

[0063] If the inode of a file does not exist in memory, the kernel-level file marking process is skipped in step S180. Specifically, if the inode of a file does not exist in memory, it is determined that the file has not been opened or accessed, and therefore the file does not pose a risk of being modified, written to, or encrypted. Thus, it is not necessary to mark the file as protected.

[0064] When the inode of a file exists in memory, the inode of that file can be retrieved in step S150. For example, the inode of the file can be retrieved from the inode cache, such as a backing inode for a memory object.

[0065] In step S160, a protection flag is set in the inode of the file to indicate that the file or the inode is in a protected state.

[0066] As an example, step S160 may include: acquiring the i_lock spinlock corresponding to the inode of the file, that is, acquiring the i_node->i_lock spinlock to lock; setting or adding a protection flag S_BAIT in the i_flags flag field of the inode's structure, that is, setting inode->i_flags |= S_BAIT, for example, using the protection flag S_BAIT to represent a specific flag position in the i_flags flag field and setting the value of that specific flag position to 1; and releasing the i_lock spinlock after setting the protection flag S_BAIT.

[0067] According to embodiments of this disclosure, setting a protection flag for the inode of at least one file within the scope of suspicious write behavior includes: determining the directory range covered by the suspicious write behavior; setting a protection flag for the inode of at least one file within the directory range that meets predetermined conditions, wherein the predetermined conditions include the file being a preset type file and the file's inode existing in memory.

[0068] In this disclosure, by setting the protection flag S_BAIT to indicate that the corresponding file or the corresponding inode is in a protected state, the file write protection method according to the embodiments of this disclosure can be executed in a timely manner based on the file or inode being in a protected state when suspicious write behavior modifies, writes, or encrypts the file.

[0069] As described above, perform the above operations for each file within the directory scope to comprehensively mark the protection status of files that may be tampered with. Furthermore, for files newly created after directory traversal, their inodes may not have protection flags set. Therefore, system calls to open these files can be intercepted, and protection flags can be set in the file's inode.

[0070] Therefore, according to embodiments of this disclosure, the inode structures of all files within the scope of the suspicious write activity are set with protection flags when the suspicious write activity is detected. In other words, files are marked as protected to perform file write protection as much as possible before the suspicious write activity performs file writing.

[0071] Furthermore, although the embodiments of this disclosure set a protection flag for a file when suspicious write activity is detected, this disclosure is not limited thereto. The protection flag may also be set based on user settings or user input, or based on other conditions.

[0072] Figure 2 This is a flowchart illustrating a file write protection method according to an embodiment of the present disclosure.

[0073] As an example, the file write protection method according to embodiments of the present disclosure may be executed by a file write protection device, electronic device and / or at least one processor or any other electronic device or system according to embodiments of the present disclosure.

[0074] Reference Figure 2 In step S100, when the application modifies a page of the target file in the page cache through a file write operation, the dirty page marking function of the system call that performs the file write operation is hijacked.

[0075] As an example, the application here can be any application that performs file writing, such as malware or currently untrusted software applications, security software or trusted software applications, or other applications that perform file writing. In other words, the write protection in the file write protection method of this application is not performed against a specific application, but against a specific file (i.e., the file in the protected state described below), which will be described in detail in step S200 below.

[0076] As an example, the target file can be a file that the application will write data to, which will also be referred to simply as the file below.

[0077] As an example, the dirty page marking function may include, but is not limited to, at least one of set_page_dirty, set_page_dirty_lock, and set_page_dirty_nobuffers.

[0078] According to embodiments of this disclosure, file write operations may include standard write operations and memory-mapped write operations. However, this disclosure is not limited thereto, and file write operations may also include any other write operations based on page caching.

[0079] As an example, a standard write operation may include: when data in the target file is modified by an application, the modified data is first written to a page in the page cache, and that page becomes a dirty page; then, the dirty page is asynchronously written back to non-volatile memory, such as disk. For example, the write path of a standard write operation may include calling the write function `write`, calling the generic page cache file write function `generic_file_write_iter`, calling the function `mark_page_accessed` to mark the page as accessed, and calling the dirty page marking function `set_page_dirty`. As an example, when the file write operation is a standard write operation, the dirty page marking function `set_page_dirty` is hijacked from the system call executing the standard write operation.

[0080] As an example, a memory-mapped write operation may involve mapping a target file into memory, directly modifying the contents of the memory region, and triggering a page update in the page cache. For instance, in a memory-mapped write operation that maps a file into memory by calling the memory mapping function mmap(), when the process first attempts to write data to the mapped memory region, a page fault interrupt is triggered. The kernel can then call the callback function page_mkwrite to make the page writable and can also call the dirty page marking function set_page_dirty. As another example, when the file write operation is a memory-mapped write operation, the dirty page marking function set_page_dirty can be hijacked during the system call executing the memory-mapped write operation.

[0081] According to embodiments of this disclosure, the inode of the target file can be obtained by hijacking the dirty page marking function of the system call that performs a file write operation on the target file.

[0082] As an example, for a standard write operation, the address space of the corresponding page of the target file can be obtained to determine whether cached data corresponding to the target file exists in memory. If the corresponding cached data exists, the inode of the file is obtained. For example, the existence of corresponding cached data can be determined by checking whether the mapping of the target file is empty based on the address space. When the mapping is empty, it indicates that the cached data of the file is not stored in memory; when the mapping is not empty, it indicates that the cached data of the target file is stored in memory. As an example, when the cached data of the file is not stored in memory, since there is no data in the target file that needs to be protected from modification, file write protection can not be performed for the target file. Therefore, the call to the dirty page marking function of the I / O operation and its subsequent processing can continue or be resumed, that is, the file write processing of the target file can be performed normally. As an example, when the cached data of the target file is stored in memory, since the target file may be a file in a protected state, the inode of the target file can be obtained to perform file write protection.

[0083] As an example, for a memory-mapped write operation, the inode of the target file can be obtained, for example, by obtaining the target file from the virtual memory region and obtaining the inode of the map based on the obtained target file, i.e., vma->vm_file->f_inode.

[0084] In step S200, if it is determined that the inode of the target file has a protection flag set, the target file is determined to be in a protected state.

[0085] As an example, the protection flag S_BAIT of the target file can be checked to determine if the target file is in a protected state; for example, by checking inode->i_flags&S_BAIT. Here, since it has already been referenced... Figure 1 The details regarding the setting of protection flags have been described in detail, so they will not be repeated here.

[0086] When the inode does not have the protection flag S_BAIT set (e.g., S_BAIT=0), it is determined that the target file is not in a protected state. Therefore, file write protection can be omitted for this target file. Consequently, dirty page marking can be allowed, and the calls to the dirty page marking function for I / O operations and their subsequent processing can continue or resume; that is, normal file write processing for the target file can be performed. For example, for standard write operations, at least one of the original dirty page marking function and the write function can continue to be called. For example, for memory-mapped write operations, at least one of the original dirty page marking function and the page_mkwrite function can continue to be called.

[0087] As an example, before checking if the inode has the protection flag S_BAIT set, it's also possible to check if the inode is empty. When the inode is empty, file write protection for the target file can be omitted. Therefore, dirty page marking can be allowed, and the calls to the dirty page marking function for I / O operations and their subsequent processing can continue or resume; that is, normal file write processing for the target file can be performed. For example, for a standard write operation, at least one of the original dirty page marking function and the write function can continue to be called. For example, for a memory-mapped write operation, at least one of the original dirty page marking function and the page_mkwrite function can continue to be called. When the inode is not empty, checking if the inode has the protection flag S_BAIT set determines whether the target file is in a protected state.

[0088] When the inode has the protection flag S_BAIT set (e.g., S_BAIT=1), it is determined that the target file is in a protected state, and step S300 is continued.

[0089] In step S300, based on the fact that the target file is in a protected state, the dirty page marking function intercepts the dirty page marking of the pages of the target file.

[0090] According to embodiments of this disclosure, intercepting the dirty page marking function for pages of the target file, based on the target file being in a protected state, may include: not marking pages of the target file in the page cache as dirty pages, and retaining modified data in the pages of the target file, even though the file is protected and suspicious write operations modify the file; retaining the modified data in the page cache for possible subsequent data recovery, and not marking the corresponding pages in the page cache as dirty pages to prevent the modified data from being written back to non-volatile memory. For example, for a standard write operation, intercepting the dirty page marking can block the write path: write → generic_file_write_iter → mark_page_accessed → set_page_dirty. As another example, for a memory-mapped write operation, intercepting the dirty page marking can block the write path: mmap → page fault → page_mkwrite → set_page_dirty. However, this disclosure is not limited to these; for example, for a buffer write operation, intercepting the dirty page marking can block the write path: buffer_head → mark_buffer_dirty → set_page_dirty.

[0091] As an example, the file write protection method according to the embodiments of this disclosure may further include: recording audit logs about suspicious write behavior for analysis based on the target file being in a protected state, such as recording information related to the target file, the corresponding inode, and dirty page markers, and recording protection timestamps for auditing and timeout control.

[0092] As an example, the file write protection method according to embodiments of this disclosure may further include: in the case of intercepting the dirty page marking function for a page of the target file, returning the result that the page is already dirty or that the dirty page marking was successful, such as returning false or 0.

[0093] The dirty page marking interception method according to embodiments of this disclosure can prevent dirty pages containing malicious data from entering the write-back queue by hijacking the dirty page marking function and determining whether dirty page marking is allowed based on the protection flag bits of the target file's inode. Furthermore, the dirty page marking interception method according to embodiments of this disclosure only intercepts the marking of dirty pages, without intercepting data writing to pages in the page cache. This interception method does not affect the further storage of data written to the page cache after file write recovery.

[0094] Considering that dirty pages existing before dirty page marking interception may be dirty pages modified by suspicious write operations, this disclosure also proposes dirty page write-back interception. Specifically, if some pages have been marked as dirty pages by write operations of suspicious write operations before the protection flag is set or dirty page marking interception according to embodiments of this disclosure, for example, if they already exist in the dirty page queue, then in order to ensure that these dirty pages are not written to non-volatile memory, embodiments of this disclosure propose to perform secondary interception of dirty pages in the write-back path, that is, dirty page write-back interception.

[0095] According to embodiments of this disclosure, the file write protection method may further include: when an application writes dirty pages of a target file from the page cache back to non-volatile memory via a file write operation, hijacking the dirty page write-back function of the system call executing the file write operation; and, if it is determined that the target file is in a protected state, intercepting the dirty page write-back of the dirty pages of the target file by the dirty page write-back function. (Refer to the following...) Figure 3 This will be described in detail.

[0096] Figure 3 This is a flowchart illustrating the process of intercepting dirty page write-back according to an embodiment of the present disclosure.

[0097] Reference Figure 3 In step S310, the dirty page write-back function of the system call for the application to perform file write operations is hijacked.

[0098] As an example, in order to write dirty pages from the page cache back to non-volatile memory, the kernel schedules write-back tasks, such as the pdflush or flush thread.

[0099] For example, dirty page write-back functions may include the writepage or writepages callback functions in address_space_operations.

[0100] In step S320, the inode corresponding to the dirty page write-back function is obtained, and in step S330, it is determined whether the obtained inode has a protection flag set.

[0101] For example, the dirty page write-back function retrieves the corresponding inode of the target file and determines whether the inode has a protection flag set. The details of retrieving the inode and determining whether a protection flag is set have already been described above, and will not be repeated here; furthermore, this disclosure is not limited thereto.

[0102] When the inode does not have the protection flag set, the dirty pages of the target file are written back normally in step S340.

[0103] For example, when the inode does not have the protection flag set, the target file is not in a protected state. File write protection can be omitted for the target file. Therefore, dirty page write-back can be allowed, and the call to the dirty page write-back function of I / O operation and its subsequent processing can continue or be resumed. That is, the file write-back processing of the target file can be performed normally.

[0104] When the inode has a protection flag set, in step S350, dirty pages of the target file are cleaned up to non-dirty pages.

[0105] As an example, the dirty page label can be changed to non-dirty page by executing the dirty page cleanup function ClearPageDirty for each dirty page in the dirty pages of the page cache target file. That is, the dirty page is marked as non-dirty page while retaining but not writing back the data in the dirty page.

[0106] As an example, before cleaning up dirty pages, you can also check whether the processing path is the `writepage` path or the `writepages` path. For the `writepage` path, dirty page cleanup is achieved by executing `ClearPageDirty(page)` and `unlock_page(page)`, while for the `writepages` path, dirty page cleanup is achieved by traversing all dirty pages and executing `ClearPageDirty` on each dirty page.

[0107] In step S360, the result of the dirty page write-back is returned to the application. For example, even though no dirty page was written back, a result indicating a successful dirty page write-back is returned to the application, such as returning 0.

[0108] As an example, step S360 may also include logging audit logs about suspicious write behavior for analysis based on the file being in a protected state, such as logging information related to the target file, the corresponding inode, and dirty page write-backs, and logging protection timestamps for auditing and timeout control.

[0109] Therefore, according to embodiments of this disclosure, when it is determined that the target file is in a protected state, intercepting the dirty page write-back function for the dirty page write-back of the target file may include: when it is determined that the target file is in a protected state, not writing the dirty pages of the target file to non-volatile memory, marking the dirty pages of the target file as non-dirty pages, and retaining the data of the dirty pages of the target file in the non-dirty pages of the target file.

[0110] The dirty page write-back interception according to embodiments of this disclosure ensures that, prior to the implementation of file write protection, and especially prior to the implementation of kernel-level file marking and dirty page marking interception, modified and marked dirty pages will not be written back to non-volatile memory, i.e., disk, thereby achieving full control over all dirty pages.

[0111] Furthermore, considering the possibility of false positives for suspicious write activity, such as when suspicious write activity is detected and the user confirms the trust of the principal program, the file write should be allowed. In this case, data in pages that have already been processed by dirty page marking and dirty page write-back interception may not be written back. Therefore, this disclosure also proposes a method for recovering from false positives regarding dirty page write-back.

[0112] According to embodiments of this disclosure, the file write protection method may further include: upon determining that a predetermined event has occurred, clearing the protection flag bit in the inode of the target file to remove the protection status of the target file; and marking non-dirty pages of the target file in the page cache as dirty pages. (Refer to the following...) Figure 4 This will be described in detail.

[0113] Figure 4 This is a flowchart illustrating the write-back process according to an embodiment of the present disclosure.

[0114] Reference Figure 4 In step S410, based on the occurrence of a predetermined event, it is determined to remove the protection status of a specific file or a file in a specific directory.

[0115] As an example, the scheduled events may include at least one of the following: manual confirmation write event, timeout automatic write event, and process whitelist write event.

[0116] For example, a manual confirmation of write recovery events can be at least one of the following: the administrator confirms through the management interface that the alert for suspicious write activity is a false alarm, and specifies the resumption of data writes to a specific directory or file. That is, a manual confirmation of write recovery events can include manually confirming the removal of protection status through the management interface.

[0117] For example, an automatic write recovery event after timeout could be an event where, when the start time of file write protection is recorded (e.g., a protection timestamp), or when a timer is enabled at the start of file write protection, the automatic deprotection status is determined based on the time elapsed since the start time or the timeout period being greater than or equal to a set threshold. That is, file writing is automatically resumed based on the fact that file write protection has continued for more than a specific period of time.

[0118] For example, if the duration of file write protection for a specific file is greater than or equal to a set threshold, then the protection status of that file is lifted. For instance, a process whitelist write recovery event could be an event where, when a whitelisted process accesses a file under protection, the protection status of the directory or file associated with that whitelisted process is automatically lifted, and data writing to the associated directory or file is resumed.

[0119] In step S420, the protection status of the file is removed.

[0120] As an example, the protection status can be removed by clearing the protection flag S_BAIT in the file's inode.

[0121] As an example, based on the one or more files in the protection state to be removed determined in step S410, an inode list of one or more inodes corresponding to the one or more files in the protection state to be removed is obtained, and each inode is traversed to clear the protection flag bit.

[0122] As an example, for each inode, the protection flag S_BAIT in inode->i_flags can be cleared while using spinlock protection to remove the protection state. Concurrency safety is ensured by locking while clearing the protection flag.

[0123] Therefore, according to embodiments of this disclosure, write-back recovery may include: based on determining that a file has been written back, clearing the protection flags in the file's inode structure to remove the file's protection status.

[0124] In step S430, the pages of files whose protection status has been removed in the page cache are marked as dirty pages in order to restore normal dirty page write-back.

[0125] As an example, you can obtain the address space of an inode (address_space), and based on the obtained address space, traverse all pages in the inode's page cache, marking all these pages as dirty pages. For example, you can traverse all pages corresponding to an inode using radix_tree or pagevec, and re-mark the traversed pages as dirty pages by calling the dirty page marking function mark_page_dirty().

[0126] As an example, the step of marking a page as dirty can also include checking whether the page to be marked is already dirty. If the page to be marked is already dirty, it does not need to be marked again. If the page to be marked is not dirty, the dirty page marking function mark_page_dirty() is called to mark the page as dirty.

[0127] As an example, the file write protection method according to embodiments of this disclosure may further include: recording an audit log about the unprotected state for analysis based on the file's unprotected state and dirty page markers, such as recording information related to the file, the corresponding inode, and the dirty page markers.

[0128] As an example, step S430 can be performed for each of one or more inodes in which the contact protection state is determined in step S420, that is, traversing each inode to recover the dirty page.

[0129] Therefore, according to embodiments of this disclosure, dirty page write-back recovery may further include marking the corresponding non-dirty pages of the file in the page cache as dirty pages.

[0130] In step S440, the kernel triggers a write-back process.

[0131] As an example, the kernel can wake up the write-back thread by calling wakeup_flusher_thresads() to perform dirty page write-back normally.

[0132] As an example, step S440 can be performed for each of one or more inodes in which the contact protection state is determined in step S420, that is, traversing each inode to write back or synchronize dirty pages.

[0133] Because the file write protection method according to embodiments of this disclosure retains the blocked write data in the page cache in memory, embodiments of this disclosure can support dirty page write-back recovery. Dirty page write-back recovery according to embodiments of this disclosure can be triggered by a normal write-back operation after the protection state is lifted, without the need for additional data backup and recovery.

[0134] Furthermore, for write operations using the O_DIRECT flag, data can bypass the page cache and be written directly to non-volatile memory. In response, this disclosure also proposes direct write interception for direct write operations.

[0135] According to embodiments of this disclosure, the file write protection method may further include: when an application directly writes modified data of a target file to non-volatile memory via a file write operation, hijacking the direct write function of the system call executing the file write operation; and, if it is determined that the target file is in a protected state, intercepting the direct write of modified data of the target file by the direct write function. (Refer to the following...) Figure 5 This will be described in detail.

[0136] Figure 5 This is a flowchart illustrating the process of direct write interception according to an embodiment of the present disclosure.

[0137] Reference Figure 5 In step S510, it is detected that the application opened a file using the O_DIRECT flag.

[0138] As an example, when opening a file using the open system call, the application can open the file using the O_DIRECT flag. In this case, the data can be written to non-volatile memory, i.e., disk, by calling the write() system call to skip the buffer and write the data directly to the disk using I / O.

[0139] As an example, the kernel can detect the presence or use of the O_DIRECT flag. When the kernel detects the use of the O_DIRECT flag, it determines that suspicious write behavior will use direct I / O write.

[0140] In response to the detection of the O_DIRECT flag, in step S520, the direct I / O write function called by the direct I / O write function is hijacked. For example, the call to the generic_file_direct_write function is hijacked.

[0141] In step S530, the inode corresponding to the target file of the direct write function is obtained, and in step S540, it is determined whether the obtained target file inode has a protection flag set. For example, the inode corresponding to the target file to be processed by the direct write function is obtained, and it is determined whether the inode has a protection flag set. The details of obtaining the inode and determining whether the protection flag is set have been described above, and will not be repeated here, and this disclosure is not limited thereto.

[0142] When the inode of the target file does not have a protection flag set, in step S560, direct writing of the modified data of the target file is performed normally. For example, when the inode of the target file does not have a protection flag set, the target file is not in a protected state, and file write protection does not need to be performed on the target file. Therefore, direct writing to the disk can be allowed, that is, direct writing of the target file is performed normally.

[0143] When the inode of the target file has a protection flag set, in step S550, the data or file content to be written is not written to non-volatile memory, and the data or file content to be written is written to the page cache or not stored. In other words, when writing to non-volatile memory is not allowed, direct file writing can be rolled back to normal standard cached I / O writing, i.e., page cache-based writing, or data writing can be completely disallowed.

[0144] As an example, the file write protection method according to embodiments of this disclosure may further include recording audit logs about suspicious write behavior for analysis based on the target file being in a protected state, such as recording information related to the target file, the corresponding inode, and direct I / O writes, and recording protection timestamps for auditing and timeout control.

[0145] As an example, the file write protection method according to embodiments of this disclosure may further include returning an error message to the application, such as an error message indicating "operation not allowed".

[0146] Therefore, according to the embodiments of this disclosure, when it is determined that the target file is in a protected state, intercepting the direct write function's direct write of the target file's modified data includes: when it is determined that the target file is in a protected state, not writing the target file's modified data to non-volatile memory, and writing the target file's modified data to a page cache or not storing the target file's modified data.

[0147] Write or write-back interception according to embodiments of this disclosure can cover as many mainstream file write methods as possible to achieve comprehensive multi-write path interception at the kernel level, such as standard write, mmap and / or O_DIRECT, thereby preventing certain write methods of suspicious write behavior from going undetected.

[0148] The above steps are merely illustrative examples. According to embodiments of this disclosure, one or more steps may be omitted, one or more steps may be performed in a different order, or one or more other steps may be added.

[0149] At least one step in the file write protection method according to embodiments of this disclosure is implemented at the page cache level by modifying kernel code and / or hijacking function calls of kernel modules, or at the file system level by modifying file system code. As an example, directly modifying kernel code or hijacking function calls using kernel modules can enable timely write interception at the Linux kernel page cache level, such as preventing dirty page marking or write-back. As an example, modifying file system code can utilize the internal mechanisms of the file system to achieve write interception at the file system level, such as preventing file writes like `writepage` through file system hook-based implementations, providing fine-grained write control.

[0150] According to embodiments of this disclosure, write interception can also be implemented at the block layer, which offers good versatility.

[0151] According to embodiments of this disclosure, the original data can also be copied on write to preserve historical versions of the file. This copy-on-write (COW) protection supports version rollback and provides higher data security.

[0152] According to embodiments of this disclosure, write protection can also be implemented using the snapshot function (dm-snapshot) of the device mapper. This dm-snapshot-based implementation can utilize existing kernel mechanisms and is relatively simple to implement.

[0153] The page cache control of the file write protection method according to the embodiments of this disclosure can at least balance protection accuracy, real-time protection, and versatility, and has at least the following advantages: kernel-level precise control, control is performed when data is written to the page cache and before dirty page write-back, realizing full path control from the page cache to the disk; full coverage of multiple write paths, covering cached I / O and direct I / O of standard I / O as well as memory-mapped writes of file mapping, supporting a variety of mainstream file write methods; fine-grained protection, protection is performed on a file inode basis without affecting other files, and write control is performed on a page basis, such as with a granularity as precise as 4KB; transparency, implemented based on kernel mechanisms, application is unaware, no application code needs to be modified, and there is no performance impact on normal file operations; real-time performance, the time window from detecting suspicious write behavior or executing file write to executing write interception is small, the latency is low, at least the user-space detection time window is eliminated, and malicious operations can be prevented in time before data is written to disk.

[0154] Figure 6 This is a block diagram illustrating a file write protection device according to an embodiment of the present disclosure.

[0155] Reference Figure 6 The file write protection device 600 according to the embodiments of the present disclosure may include a function call hijacking unit 610, a file status identification unit 620 and a file write protection unit 630.

[0156] According to embodiments of this disclosure, the function call hijacking unit 610 can be configured to hijack the dirty page marking function called by the file write operation when the application modifies a page of the target file in the page cache through a file write operation; the file status identification unit 620 can be configured to determine that the target file is in a protected state when it is determined that the inode of the target file has a protection flag bit set; the file write protection unit 630 can be configured to intercept the dirty page marking function for the pages of the target file based on the fact that the target file is in a protected state.

[0157] In other words, the file write protection device 600 can be configured to perform at least the file write protection method according to the embodiments of the present disclosure as described above, wherein the function call hijacking unit 610 can be configured to perform at least step S100, the file status identification unit 620 can be configured to perform at least step S200, and the file write protection unit 630 is configured to perform at least step S300. Therefore, the details of the file write protection method described above can be applied to the file write protection device 600, and some details will not be described again here.

[0158] Optionally, the file write protection unit 630 can be configured to intercept dirty page marking of pages of the target file based on the target file being in a protected state by: not marking pages of the target file in the page cache as dirty pages based on the target file being in a protected state, and retaining the modified data in the pages of the target file.

[0159] Optionally, the function call hijacking unit 610 can also be configured to: hijack the dirty page write-back function of the system call executing the file write operation when the application writes dirty pages of the target file from the page cache back to non-volatile memory through a file write operation; the file write protection unit 630 can also be configured to intercept the dirty page write-back of the dirty pages of the target file by the dirty page write-back function when it is determined that the target file is in a protected state.

[0160] Optionally, the file write protection unit 630 can also be configured to intercept the dirty page write-back function for dirty pages of the target file when it is determined that the target file is in a protected state by the following operations: when it is determined that the target file is in a protected state, the dirty pages of the target file are not written to non-volatile memory, the dirty pages of the target file are marked as non-dirty pages, and the data of the dirty pages of the target file are retained in the non-dirty pages of the target file.

[0161] Optionally, the file write protection device 600 further includes a file write recovery unit, wherein the file write recovery unit can be configured to: clear the protection flag bit in the inode of the target file to remove the protection status of the target file when a predetermined event is determined to have occurred; mark the non-dirty pages of the target file in the page cache as dirty pages, wherein the predetermined event includes at least one of a manual confirmation write recovery event, a timeout automatic write recovery event, and a process whitelist write recovery event.

[0162] Optionally, the file write protection device 600 further includes a file status marking unit, wherein the file status marking unit can be configured to set a protection flag bit for the inode of at least one file within the scope of the suspicious write behavior when a suspicious write behavior is detected by the application.

[0163] Optionally, the file status marking unit can be configured to set a protection flag for the inode of at least one file within the scope of the suspicious write behavior by: determining the directory range covered by the suspicious write behavior; and setting a protection flag for the inode of at least one file within the directory range that meets predetermined conditions, wherein the predetermined conditions include that the file is a preset type file and that the inode of the file exists in memory.

[0164] Optionally, file write operations include standard write operations and memory-mapped write operations.

[0165] Optionally, the function call hijacking unit 610 can also be configured to: hijack the direct write function of the system call executing the file write operation when the application directly writes the modified data of the target file to non-volatile memory through a file write operation; the file write protection unit 630 is further configured to intercept the direct write of the modified data of the target file by the direct write function when it is determined that the target file is in a protected state.

[0166] Optionally, the file write protection unit 630 can be configured to intercept direct writes of modified data of the target file by the direct write function when it is determined that the target file is in a protected state by: not writing the modified data of the target file to non-volatile memory when it is determined that the target file is in a protected state, and writing the modified data of the target file to the page cache or not storing the modified data of the target file.

[0167] Optionally, at least one of the operations of the file write protection device 600 is implemented at the page cache level by modifying kernel code and / or hijacking function calls of kernel modules, or at the file system level by modifying file system code.

[0168] The specific methods by which each unit in the aforementioned file writing protection device 600 performs its operations have been described in detail in the embodiments of the relevant methods, and will not be elaborated upon here.

[0169] The dirty page marking interception method of the file write protection device according to embodiments of this disclosure can prevent dirty pages containing malicious data from entering the write-back queue by hijacking the dirty page marking function and determining whether dirty page marking is allowed based on the protection flag bits of the file's inode. Furthermore, the dirty page marking interception method of the file write protection device according to embodiments of this disclosure only intercepts the marking of dirty pages, without intercepting data writing to pages in the page cache. This interception method does not affect the further storage of data written to the page cache after file write recovery.

[0170] Furthermore, the dirty page write-back interception of the file write protection device according to the embodiments of this disclosure can ensure that, before file write protection is implemented, especially before kernel-level file marking and dirty page marking interception is implemented, modified and marked dirty pages will not be written back to non-volatile memory, i.e., disk, thereby achieving full control over all dirty pages.

[0171] Furthermore, since the file write protection device according to embodiments of this disclosure retains the blocked write data in the page cache in memory, the file write protection device according to embodiments of this disclosure can support dirty page write-back recovery. Dirty page write-back recovery of the file write protection device according to embodiments of this disclosure can be triggered by a normal write-back operation after the protection state is lifted, without the need for additional data backup and recovery.

[0172] In addition, the write or write-back interception of the file write protection device according to the embodiments of this disclosure can cover as many mainstream file write methods as possible, so as to achieve comprehensive multi-write path interception at the kernel level, such as standard write, mmap and / or O_DIRECT, thereby preventing certain write methods of suspicious write behavior from going undetected.

[0173] Furthermore, it should be understood that the various units in the document write protection device 600 according to the exemplary embodiments of this disclosure may be implemented as hardware components and / or software components. Those skilled in the art, based on the processes performed by the defined various units, may implement the various units, for example, using a field-programmable gate array (FPGA) or an application-specific integrated circuit (ASIC).

[0174] Furthermore, according to embodiments of this disclosure, an electronic device is also provided.

[0175] An electronic device according to an embodiment of the present disclosure may include at least one processor and at least one memory storing computer-executable instructions, wherein the computer-executable instructions, when executed by at least one processor, cause at least one processor to perform the file write protection method according to an embodiment of the present disclosure as described above.

[0176] As an example, an electronic device can be a personal computer (PC), a tablet device, a personal digital assistant, a smartphone, or other device capable of executing the aforementioned set of instructions. Here, the electronic device is not necessarily a single electronic device, but can be any collection of devices or circuits capable of executing the aforementioned instructions (or instruction sets) individually or in combination. The electronic device can also be part of an integrated control system or system manager, or can be configured to interconnect locally or remotely (e.g., via wireless transmission) through an interface.

[0177] In electronic devices, at least one processor may include a central processing unit (CPU), a graphics processing unit (GPU), a programmable logic device, a dedicated processor system, a microcontroller, and / or a microprocessor. By way of example and not limitation, at least one processor may also include analog processors, digital processors, microprocessors, multi-core processors, processor arrays, and / or network processors, etc.

[0178] At least one processor can execute instructions or code stored in at least one memory, wherein the at least one memory can also store data. Instructions and data can also be sent and received over a network via a network interface device, wherein the network interface device can employ any known transport protocol.

[0179] At least one memory may be integrated with at least one processor, for example, by arranging RAM or flash memory within an integrated circuit microprocessor. Alternatively, at least one memory may comprise a separate device, such as an external disk drive, storage array, or other storage device that can be used by any database system. At least one memory and at least one processor may be operatively coupled, or may communicate with each other, for example, via I / O ports, network connections, etc., enabling at least one processor to read files stored in at least one memory.

[0180] In addition, electronic devices may include video displays (such as liquid crystal displays) and user interaction interfaces (such as keyboards, mice, touch input devices, etc.). All components of the electronic device may be interconnected via buses and / or networks.

[0181] According to embodiments of the present disclosure, a computer-readable storage medium is also provided, wherein instructions in the computer-readable storage medium, when executed by at least one processor, cause at least one processor to perform the file write protection method as described above.

[0182] As examples, computer-readable storage media may include: read-only memory (ROM), random access programmable read-only memory (PROM), electrically erasable programmable read-only memory (EEPROM), random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), flash memory, non-volatile memory, CD-ROM, CD-R, CD+R, CD-RW, CD+RW, DVD-ROM, DVD-R, DVD+R, DVD-RW, DVD+RW, DVD-RAM, BD-ROM, BD-R, BD-R LTH, BD-RE, Blu-ray or optical disc storage, hard disk drive (HDD), solid-state drive (SSD), card storage (such as multimedia cards, secure digital (SD) cards, or ultra-fast digital (XD) cards), magnetic tape, floppy disk, magneto-optical data storage device, optical data storage device, hard disk, solid-state drive, and any other device configured to store a computer program and any associated data, data files, and data structures in a non-transitory manner and to provide the computer program and any associated data, data files, and data structures to a processor or computer so that the processor or computer can execute the computer program. The computer program in the computer-readable storage medium can run in an environment deployed in computer devices such as clients, hosts, agent devices, servers, etc. Furthermore, as an example, the computer program and any associated data, data files, and data structures are distributed across a networked computer system, such that the computer program and any associated data, data files, and data structures are stored, accessed, and executed in a distributed manner through one or more processors or computers.

[0183] According to exemplary embodiments of the present disclosure, a computer program product (or computer software) including computer-executable instructions is also provided, wherein the computer-executable instructions, when executed by at least one processor, implement the file write protection method as described above.

[0184] Furthermore, according to embodiments of this disclosure, the memory may be the system's main storage device or main memory, and may include volatile memory for temporarily storing computational data in the CPU, as well as data exchanged with external non-volatile memory such as a hard disk. However, embodiments of this disclosure are not limited thereto, and the memory may optionally or additionally include non-volatile memory.

[0185] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.

[0186] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the claims.

Claims

1. A method for protecting against file write operations, characterized in that, include: When an application modifies a page of a target file in the page cache via a file write operation, the dirty page marking function of the system call executing the file write operation is hijacked; If it is determined that the inode of the target file has a protection flag set, the target file is determined to be in a protected state; Since the target file is in a protected state, the dirty page marking function is intercepted for dirty page marking of the pages of the target file.

2. The file write protection method according to claim 1, characterized in that, The step of intercepting the dirty page marking function for pages of the target file based on the target file being in a protected state includes: Since the target file is in a protected state, the pages of the target file in the page cache are not marked as dirty pages, and the modified data is retained in the pages of the target file.

3. The file write protection method according to claim 1, characterized in that, The file write protection method further includes: When the application writes dirty pages of the target file from the page cache back to non-volatile memory through the file write operation, the dirty page write-back function of the system call that executes the file write operation is hijacked; If it is determined that the target file is in a protected state, the dirty page write-back function is intercepted for the dirty page write-back of the target file.

4. The file write protection method according to claim 3, characterized in that, The step of intercepting the dirty page write-back function for dirty pages of the target file when it is determined that the target file is in a protected state includes: If the target file is determined to be in a protected state, the dirty pages of the target file are not written to the non-volatile memory, the dirty pages of the target file are marked as non-dirty pages, and the data of the dirty pages of the target file are retained in the non-dirty pages of the target file.

5. The file write protection method according to any one of claims 1 to 4, characterized in that, The file write protection method further includes: If a predetermined event is determined to have occurred, the protection flag bit in the inode of the target file is cleared to remove the protection status of the target file; Mark the non-dirty pages of the target file in the page cache as dirty pages. The pre-defined events include at least one of the following: manual confirmation write event, timeout automatic write event, and process whitelist write event.

6. The file write protection method according to claim 1, characterized in that, The file write protection method further includes: When suspicious write behavior is detected by the application, the protection flag is set for the inode of at least one file within the scope of the suspicious write behavior.

7. The file write protection method according to claim 6, characterized in that, Setting the protection flag for the inode of at least one file within the scope of the suspicious write behavior includes: Determine the directory range covered by the suspicious write behavior; The protection flag is set for the inode of at least one file within the directory range that meets predetermined conditions. The predetermined conditions include that the file is a preset type file and that the file's inode exists in memory.

8. The file write protection method according to claim 1, characterized in that, The file write operations include standard write operations and memory-mapped write operations.

9. The file write protection method according to claim 1, characterized in that, The file write protection method further includes: When the application writes the modified data of the target file directly to non-volatile memory through the file write operation, the direct write function of the system call that executes the file write operation is hijacked; If the target file is determined to be in a protected state, the direct write function is intercepted from directly writing modified data to the target file.

10. The file write protection method according to claim 9, characterized in that, The step of intercepting the direct write function's direct write of modified data to the target file when it is determined that the target file is in a protected state includes: If the target file is determined to be in a protected state, the modified data of the target file is not written to the non-volatile memory, and the modified data of the target file is written to the page cache or not stored.

11. The file write protection method according to claim 1, characterized in that, At least one step in the file write protection method is implemented at the page cache level by modifying kernel code and / or hijacking function calls of kernel modules, or at the file system level by modifying file system code.

12. A file write protection device, characterized in that, include: The function call hijacking unit is configured to hijack the dirty page marking function called by the file write operation when the application modifies a page of a target file in the page cache through a file write operation; The file status identification unit is configured to determine that the target file is in a protected state when it is determined that the inode of the target file has a protection flag bit set. The file write protection unit is configured to intercept the dirty page marking function for pages of the target file based on the target file being in a protected state.

13. An electronic device, characterized in that, include: At least one processor; At least one memory that stores computer-executable instructions. Wherein, when the computer-executable instructions are executed by the at least one processor, they cause the at least one processor to execute the file write protection method as described in any one of claims 1 to 11.

14. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by at least one processor, the at least one processor causes the at least one processor to perform the file write protection method as described in any one of claims 1 to 11.

15. A computer program product comprising computer-executable instructions, wherein, The computer-executable instructions, when executed by at least one processor, implement the file write protection method as described in any one of claims 1 to 11.

Images