linux-kernel - Re: [PATCH] fs: convert mount flags to enum

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: <aBvo_-Ee7QQtd3YU@telecaster>
Date: Wed, 7 May 2025 16:13:03 -0700
From: Omar Sandoval <osandov@...ndov.com>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: Stephen Brennan <stephen.s.brennan@...cle.com>,
	Christian Brauner <brauner@...nel.org>,
	Mateusz Guzik <mjguzik@...il.com>, linux-kernel@...r.kernel.org,
	linux-debuggers@...r.kernel.org,
	Sentaro Onizuka <sentaro@...zon.com>
Subject: Re: [PATCH] fs: convert mount flags to enum

On Thu, May 08, 2025 at 12:05:11AM +0100, Al Viro wrote:
> On Wed, May 07, 2025 at 03:34:01PM -0700, Stephen Brennan wrote:
> > In prior kernel versions (5.8-6.8), commit 9f6c61f96f2d9 ("proc/mounts:
> > add cursor") introduced MNT_CURSOR, a flag used by readers from
> > /proc/mounts to keep their place while reading the file. Later, commit
> > 2eea9ce4310d8 ("mounts: keep list of mounts in an rbtree") removed this
> > flag and its value has since been repurposed.
> > 
> > For debuggers iterating over the list of mounts, cursors should be
> > skipped as they are irrelevant. Detecting whether an element is a cursor
> > can be difficult. Since the MNT_CURSOR flag is a preprocessor constant,
> > it's not present in debuginfo, and since its value is repurposed, we
> > cannot hard-code it. For this specific issue, cursors are possible to
> > detect in other ways, but ideally, we would be able to read the mount
> > flag definitions out of the debuginfo. For that reason, convert the
> > mount flags to an enum.
> 
> Just a warning - there's a bunch of pending changes in that area,
> so debuggers are going to be in trouble anyway.
> 
> Folks, VFS data structures do *NOT* come with any stability warranties.
> Especially if the object in question is not even defined in include/*/*...
> 
> _Anything_ that tries to play with these objects must be version-dependent
> and be ready to be broken by changes in underlying code at zero notice.

That's totally fine, we can deal with breakages as long as we can
reliably detect what version we're dealing with. We can see changed enum
values, renamed/removed structure members, etc., so that's why those are
preferable. Macros are invisible at the debug info level (since no one
compiles with -g3), so those are no good for us. We also avoid version
checks as much as possible because backports in RHEL and co. make
version numbers mostly meaningless.