linux-kernel - Re: [GIT PULL] vfs fixes

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] [day] [month] [year] [list]

Message-ID: <20240320-ameisen-werktag-86c781724557@brauner>
Date: Wed, 20 Mar 2024 11:21:00 +0100
From: Christian Brauner <brauner@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] vfs fixes

> > Again, this comment (and the previous email) is more based on "this
> > does not feel right to me" than anything else.
> > 
> > That code just makes my skin itch. I can't say it's _wrong_, but it
> > just FeelsWrongToMe(tm).
> 
> So, initially I think the holder ops were intended to be generic by
> Christoph but I agree that it's probably not needed. I just didn't
> massage that code yet. Now on my todo for this cycle!

So, the block holder ops will gain additional implementers in the block
layer that will implement their own separate ops. So I trust the block
layer with this.

The holder is used to determine whether a block device can be reopened.
So both for internal (mounting, log device initialization) or userspace
opens we compare the holders of the block device. We do have allowed for
quite some time to open the same block device exclusively with different
flags. So there are multiple files open to the same block device and the
holder is used as proof that it can be reopened. So always using the
file as the holder would still mean that we have to compare
file->private_data to determine whether the block device can be
reopened. So it won't get us as much as we'd want.

The reason for the holder to remain valid is that the block layer does
have ioctl operations such as removal of a device in the case of nbd,
suspend and resume used in stuff like cryptsetup. In all such cases we
go from arbitrary block device to arbitrary holder and then inform them
about the operation calling the appropriate callback. So we would still
have to guarantee the validity of the holder in file->private_data.

There are also two internal codepaths where the block device is
temporarly marked as being in the process of being claimed. This will
cause actual openers to wait until bd_holder is really set or aborted
but not fail the actual open. This has traditionally been the case in
the loop code and during user initiated and internally triggered
partition scanning. That could be reworked but would be pretty ugly.

We'll continue considering additional cleanups and latest next merge
window I'll give you a detailed write up what happened.