Message-ID: <d9209144-4b20-61c7-aff3-942150806b9a@gmail.com>
Date:   Mon, 16 Mar 2020 16:01:18 +0800
From:   brookxu <brookxu.cn@...il.com>
To:     "Theodore Y. Ts'o" <tytso@....edu>
Cc:     adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ext4: mark extents index blocks as dirty to avoid
 information leakage

Thanks for your reply, but threre's some points implement inconsistently

1. + s attribute will cause a big performance problem. With only data
   blocks but no index blocks, it is difficult to recover the complete
   data. Therefore, we can also improve data security with the lowest
   cost.
2. In the SSD scenario, discard on some devices cannot guarantee that
   data is erased. but if we update the dirty pages of memory to disk.
   ssd will remap the corresponding lba, then the user will not be able
   to access the old data, it's security.
3. In the small file scenario, the file extent is stored on the inode.
   Because the inode block will not be forgotten by jbd2, the extent on
   the disk is always cleared after the small file is deleted. If security
   is only pretended, why not take effect on the small file.
4. If to facilitate data recovery, why do need to clear extents in
   memory? This operation does not seem to make sense.

I think that the page of the index block is not updated to disk after
the file is deleted, which may be a logical defect.

Theodore Y. Ts'o wrote on 2020/3/12 22:46:
> On Tue, Mar 03, 2020 at 04:51:06PM +0800, brookxu wrote:
>> From: Chunguang Xu <brookxu@...cent.com>
>>
>> In the scene of deleting a file, the physical block information in the
>> extent will be cleared to 0, the buffer_head contains these extents is
>> marked as dirty, and then managed by jbd2, which will clear the
>> buffer_head's dirty flag by clear_buffer_dirty. However, when the entire
>> extent block is deleted, it is revoked from the jbd2, but  the extents
>> block is not redirtied.
>>
>> Not quite reasonable here, for the following concerns:
>>
>> 1. This has the risk of information leakage and leads to an interesting
>> phenomenon that deleting the entire file is no more secure than truncate
>> to 1 byte, because the whole extents physical block clear to zero in cache
>> will never written back as the page is not redirtied.
>>
>> 2. For large files, the number of index block is usually very small.
>> Ignoring index pages not get much more benefit in IO performance. But if
>> we remark the page as dirty, the page is then written back by the system
>> writeback mechanism asynchronously with little performance impact. As a
>> result, the risk of information leakage can be avoided. At least not wrose
>> than truncate file length to 1 byte
>>
>> Therefore, when the index block is released, we need to remark its page
>> as dirty, so that the index block on the disk will be updated and the
>> data is more security.
>>
>> Signed-off-by: Chunguang Xu <brookxu@...cent.com>
> Trying to zero the extent block is only going to provide pretend
> security; the data blocks are still there, and anyone looking for the
> data can still find it if they look hard enough.  Also, for most
> files, it really doesn't matter.
>
> So, no, I don't think this patch is appropriate.a
>
> If you are really worried about the security for deleted files, I
> would suggest trying to implement the secure delete flag (chattr +s)
> for ext4, and actually trying to zero out the data blocks for those
> files where this kind of security is required.  (Please note that for
> SSD's, this probably won't provide as much security as you would like
> unless they implement the secure discard operation.)
>
> 							- Ted

Powered by blists - more mailing lists