linux-kernel - Re: [PATCH 0/2] v3: F_OFD_GETLK extension to read lock info

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: <b18c49ada119b6904b92375a847ce8c764cb1663.camel@kernel.org>
Date:   Tue, 27 Jun 2023 12:23:40 -0400
From:   Jeff Layton <jlayton@...nel.org>
To:     Stas Sergeev <stsp2@...dex.ru>, linux-kernel@...r.kernel.org
Cc:     Chuck Lever <chuck.lever@...cle.com>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Christian Brauner <brauner@...nel.org>,
        linux-fsdevel@...r.kernel.org, Shuah Khan <shuah@...nel.org>,
        linux-kselftest@...r.kernel.org, linux-api@...r.kernel.org
Subject: Re: [PATCH 0/2] v3: F_OFD_GETLK extension to read lock info

On Thu, 2023-06-22 at 21:52 +0500, Stas Sergeev wrote:
> This extension allows to use F_UNLCK on query, which currently returns
> EINVAL. Instead it can be used to query the locks on a particular fd -
> something that is not currently possible. The basic idea is that on
> F_OFD_GETLK, F_UNLCK would "conflict" with (or query) any types of the
> lock on the same fd, and ignore any locks on other fds.
> 
> Use-cases:
> 
> 1. CRIU-alike scenario when you want to read the locking info from an
> fd for the later reconstruction. This can now be done by setting
> l_start and l_len to 0 to cover entire file range, and do F_OFD_GETLK.
> In the loop you need to advance l_start past the returned lock ranges,
> to eventually collect all locked ranges.
> 
> 2. Implementing the lock checking/enforcing policy.
> Say you want to implement an "auditor" module in your program,
> that checks that the I/O is done only after the proper locking is
> applied on a file region. In this case you need to know if the
> particular region is locked on that fd, and if so - with what type
> of the lock. If you would do that currently (without this extension)
> then you can only check for the write locks, and for that you need to
> probe the lock on your fd and then open the same file via another fd and
> probe there. That way you can identify the write lock on a particular
> fd, but such trick is non-atomic and complex. As for finding out the
> read lock on a particular fd - impossible.
> This extension allows to do such queries without any extra efforts.
> 
> 3. Implementing the mandatory locking policy.
> Suppose you want to make a policy where the write lock inhibits any
> unlocked readers and writers. Currently you need to check if the
> write lock is present on some other fd, and if it is not there - allow
> the I/O operation. But because the write lock can appear at any moment,
> you need to do that under some global lock, which can be released only
> when the I/O operation is finished.
> With the proposed extension you can instead just check the write lock
> on your own fd first, and if it is there - allow the I/O operation on
> that fd without using any global lock. Only if there is no write lock
> on this fd, then you need to take global lock and check for a write
> lock on other fds.
> 
> 
> The second patch adds a test-case for OFD locks.
> It tests both the generic things and the proposed extension.
> 
> 
> The third patch is a proposed man page update for fcntl(2)
> (not for the linux source tree)
> 
> 
> Changes in v3:
> - Move selftest to selftests/filelock
> 
> Changes in v2:
> - Dropped the l_pid extension patch and updated test-case accordingly.
> 
> Stas Sergeev (2):
>   fs/locks: F_UNLCK extension for F_OFD_GETLK
>   selftests: add OFD lock tests
> 
>  fs/locks.c                                  |  23 +++-
>  tools/testing/selftests/filelock/Makefile   |   5 +
>  tools/testing/selftests/filelock/ofdlocks.c | 132 ++++++++++++++++++++
>  3 files changed, 157 insertions(+), 3 deletions(-)
>  create mode 100644 tools/testing/selftests/filelock/Makefile
>  create mode 100644 tools/testing/selftests/filelock/ofdlocks.c
> 
> CC: Jeff Layton <jlayton@...nel.org>
> CC: Chuck Lever <chuck.lever@...cle.com>
> CC: Alexander Viro <viro@...iv.linux.org.uk>
> CC: Christian Brauner <brauner@...nel.org>
> CC: linux-fsdevel@...r.kernel.org
> CC: linux-kernel@...r.kernel.org
> CC: Shuah Khan <shuah@...nel.org>
> CC: linux-kselftest@...r.kernel.org
> CC: linux-api@...r.kernel.org
> 

I've taken the first two patches into my locks-next branch, so they
should end up in linux-next soon. Adding support for testing this to
fstests is a hard requirement before this will be merged into mainline.

Thanks,
-- 
Jeff Layton <jlayton@...nel.org>