linux-ext4 - Re: A problem about BLK_OPEN_RESTRICT

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]

Date: Wed, 21 Feb 2024 17:19:54 +0100
From: Jan Kara <jack@...e.cz>
To: JunChao Sun <sunjunchao2870@...il.com>
Cc: Ext4 Developers List <linux-ext4@...r.kernel.org>,
	Jan Kara <jack@...e.cz>, Theodore Ts'o <tytso@....edu>
Subject: Re: A problem about BLK_OPEN_RESTRICT_WRITES

Hello,

On Wed 21-02-24 23:29:39, JunChao Sun wrote:
> I saw that ext4 has supported BLK_OPEN_RESTRICT_WRITES in commits
> aca740cecbe("fs: open block device after superblock creation")  and
> afde134b5bd0("ext4: Block writes to journal device"). I'm not certain
> whether these commits caused the following issue.
> 
> Environment:
> 6.8.0-rc3-00279-g4a7bbe7519b6-dirty(commit 4a7bbe7519b6a5).
> sjc@...-laptop:~/linux$ mkfs.ext4 -V
> mke2fs 1.47.0 (5-Feb-2023)
> Using EXT2FS Library version 1.47.0
> sjc@...-laptop:~/linux$ mount -V
> mount from util-linux 2.39.1 (libmount 2.39.1: selinux, smack, btrfs,
> verity, namespaces, idmapping, assert, debug)
> 
> Problem:
> When I mounted the ext4 file system in the qemu system, I encountered
> the following error:
> root@q:~/linux# mount -t ext4 ext4.img  /mnt/ext4/
> [  848.897532] loop1: detected capacity change from 0 to 2097152
> [  848.905535] /dev/loop1: Can't open blockdev
> mount: /mnt/ext4: /dev/loop1 already mounted or mount point busy.
>        dmesg(1) may have more information after failed mount system call.
> 
> I reviewed the relevant code and found that the mount program first
> calls the openat system call to open the /dev/loop1 file, followed by
> the mount system call (with /dev/loop1 as the first parameter).
> 
> As for the former openat system call, it eventually reaches the chain
> of (vfs_open->do_dentry_open->blkdev_open->bdev_open_by_dev->bdev_claim_write_access).
> In bdev_claim_write_access, the following logic applies:
>             /* Claim exclusive or shared write access. */
>             if (mode & BLK_OPEN_RESTRICT_WRITES)
>                     bdev_block_writes(bdev);
>             else if (mode & BLK_OPEN_WRITE)
>                     bdev->bd_writers++;
> The argument mode here doesn't set BLK_OPEN_RESTRICT_WRITES flag, so
> goes bdev->bd_writers++.
> 
> And in the latter mount system call, the following logic is followed:
> (vfs_get_tree->get_tree_bdev->setup_bdev_super->bdev_open_by_dev->bdev_may_open).
> In bdev_may_open, the following logic applies:
>             if (mode & BLK_OPEN_RESTRICT_WRITES && bdev->bd_writers > 0)
>                     return false;
> 
> Due to the fact that the argument mode has already been set with the
> BLK_OPEN_RESTRICT_WRITES flag in the setup_bdev_super function, and
> since bdev->bd_writers is already 1 at this point, the function
> returns false. This ultimately leads to the mount system call
> returning the EBUSY error.

Yes, this is correct. How mount(8) sets up loop devices gets broken by when
BLK_OPEN_RESTRICT_WRITES is enabled.

> Is this indeed a problem, or is there a misunderstanding in my
> comprehension? If it is indeed a problem, can we resolve it by
> removing the BLK_OPEN_RESTRICT_WRITES from the sb_open_mode macro
> definition?

No. Cases like above are the reason why there's still a config option
CONFIG_BLK_DEV_WRITE_MOUNTED and it defaults to 'y'. We need to be fixing
userspace - util-linux in this case - to avoid having writeable file handle
open to block devices that are being mounted.

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR