linux-ext4 - Re: [bug report] tune2fs: filesystem inconsistency occurs by concurrent write

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4e647e9b-4f2f-b89f-6825-838f22c4bf2e@huawei.com>
Date:   Tue, 4 Jul 2023 16:35:43 +0800
From:   zhanchengbin <zhanchengbin1@...wei.com>
To:     Theodore Ts'o <tytso@....edu>
CC:     <linux-ext4@...r.kernel.org>, linfeilong <linfeilong@...wei.com>,
        <louhongxiang@...wei.com>, <liuzhiqiang26@...wei.com>,
        Ye Bin <yebin@...weicloud.com>
Subject: Re: [bug report] tune2fs: filesystem inconsistency occurs by
 concurrent write

Hi Tytso,

Referring to you kind and insightful advice, I have come up with three
solutions, listed as follows:

1) Add interface blkdev_bh_read and blkdev_bh_write in blkdev_ioctl. 
Lock the
bh_lock when blkdev_bh_read is called, then change the value of the data and
write back it, and finally unlock_buffer;

This solution ensures that there is no coupling between the block layer and
the file system layer, but the interfaces are invoked by user processes, and
since user processes are subject to scheduling, there may be potential
performance overhead. Additionally, if user process is killed before 
releasing
the bh_lock, it can result in a deadlock situation.

2) Add interface write_super in blkdev_ioctl. In this case, a hook is 
used in
the write_super to invoke the commit_super function of each file system. 
During
the mount process, the commit_super function of the respective filesystem is
saved into the hook. Since the metadata cache is stored through bdev, it is
sufficient to memcpy the data to bh->b_data and then flush it to disk.

This solution allows each file system to implement its own method of 
flushing
the superblock. However, it introduces coupling between the block layer and
the filesystem layer, and there needs to be a place to store this 
commit_super
hook function pointer. Is it stored in the block_device? It seems a 
little bit
strange to me.

3) Add interface write_super in ext4_ioctl. The mount point is obtained 
through
the block device, and open a random file in the file system, the 
superblock is
passed to the kernel through ioctl of the file, and finally, the 
superblock is
flushed to disk. Due to the inherent risks associated with granting user 
space
write permissions to the superblock, it is deemed unsafe to utilize the 
entire
superblock as provided by user space. Instead, the superblock should be
validated, followed by selective data writing and recording. Of course, 
it is
dangerous to directly modify the data in the super block, so I plan to add a
flag in the super block to record that this modification is from the 
user state.

This solution has no coupling with other layers, but uses the ioctl of 
ordinary
files.

Personally speaking, I favour the third solution the most, what are your
opinions? If you already have other schemes, I will be more than 
delighted to
discuss it with you.
Looking foward to hearing from you soon!

Thanks,
  - bin.