linux-kernel - Re: [RFC PATCH 3/4] fs: Implement support for fsx_xflags_mask, fsx_xflags2 and fsx_xflags2

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20250225200738.gtgc3rdfpe5d4esm@pali>
Date: Tue, 25 Feb 2025 21:07:38 +0100
From: Pali Rohár <pali@...nel.org>
To: Theodore Ts'o <tytso@....edu>
Cc: Amir Goldstein <amir73il@...il.com>,
	"Darrick J. Wong" <djwong@...nel.org>,
	ronnie sahlberg <ronniesahlberg@...il.com>,
	Chuck Lever <chuck.lever@...cle.com>,
	Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
	Steve French <sfrench@...ba.org>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	linux-fsdevel@...r.kernel.org, linux-cifs@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 3/4] fs: Implement support for fsx_xflags_mask,
 fsx_xflags2 and fsx_xflags2_mask into vfs

On Friday 21 February 2025 13:24:16 Theodore Ts'o wrote:
> On Sun, Feb 16, 2025 at 05:40:28PM +0100, Pali Rohár wrote:
> > This change adds support for new struct fileattr fields fsx_xflags_mask,
> > fsx_xflags2 and fsx_xflags2_mask into FS_IOC_FSGETXATTR and
> > FS_IOC_FSSETXATTR ioctls.
> 
> I don't think I saw an answer to this question (but the discussions of
> the mail thread have really sprawled a bit and so it's hard to review
> all of the messages in the thread) --- so.... what's your reason for
> creating this new fsx_xflags2 field as opposed to just defining new
> flags bits for fsx_xflags field?  There are plenty of unused bits in
> the FS_XFLAG_* space.
> 
> Cheers,
> 
> 					- Ted
> 					

If all bits which I currently defined in fsx_xflags2 should be instead
defined in fsx_xflags then in fsx_xflags would be only 2 or 3 free bits.

And it is possible that I forgot to include some bits in this RFC
series, or that Windows starts (or already started) using some reserved
bits. And that would mean that we are out of the fsx_xflags space.

Also there are 4-5 Windows get-only bits which are not covered by this
RFC series. It is questionable if they should or should not be.

So IMHO, we do not have enough space in fsx_xflags to cover everything.