linux-kernel - Re: [PATCH v4] fs: hide names_cachep behind runtime access machinery

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: <CAGudoHH817CKv0ts4dO08j5FOfEAWtvoBeoT06KarjzOh_U6ug@mail.gmail.com>
Date: Thu, 30 Oct 2025 22:39:46 +0100
From: Mateusz Guzik <mjguzik@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Thomas Gleixner <tglx@...utronix.de>, brauner@...nel.org, viro@...iv.linux.org.uk, 
	jack@...e.cz, linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org, 
	pfalcato@...e.de
Subject: Re: [PATCH v4] fs: hide names_cachep behind runtime access machinery

On Thu, Oct 30, 2025 at 7:07 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> [ Adding Thomas, because he's been working on our x86 uaccess code,
> and I actually think we get this all wrong for access_ok() etc ]
>
> On Thu, 30 Oct 2025 at 09:35, Mateusz Guzik <mjguzik@...il.com> wrote:
> >
> > I don't know if you are suggesting to make the entire thing fail to
> > compile if included for a module, or to transparently convert
> > runtime-optimized access into plain access.
> >
> > I presume the former.
>
> I think *including* it should be ok, because we have things like
> <asm/uaccess.h> - or your addition to <linux/fs.h> - that use it for
> core functionality that is then not supported for module use.
>
> Yeah, in a perfect world we'd have those things only in "internal"
> headers and people couldn't include them even by mistake, but that
> ends up being a pain.
>
> So I don't think your
>
> +#ifdef MODULE
> +#error "this functionality is not available for modules"
> +#endif
>
> model works, because I think it might be too painful to fix (but hey,
> maybe I'm wrong).
>

In my proposal the patch which messes with the namei cache address
would have the following in fs.h:
#ifndef MODULE
#include <asm/runtime-const.h>
#endif

As in, unless the kernel itself is being compiled, it would pretend
the runtime machinery does not even exist, which imo is preferable to
failing later at link time.

Then whatever functionality using runtime-const is straight up not
available and code insisting on providing something for modules anyway
is forced to provide an ifdefed implementation.

Ignoring the safety vs modules thing and back to the names_cachep
patch: the reported riscv build failure has proven problematic to fix.
Turns out mm.h includes mm_huge.h, which then includes fs.h(!). Adding
the runtime-const.h include into fs.h then results in compilation
failure on that platform as it depends on vmalloc-related symbols
which are only getting declared *after* fs.h gets included.

I tried to get rid of the fs.h inclusion in mm_huge.h, but that
uncovered a bunch of other build failures where code works only
because fs.h got sneaked in by someone else.

Given the level of bullshit here it may be it is just straight up
infeasible to include runtime-const.h in fs.h without major
rototoiling, which I'm not signing up for.

I wonder if it would make sense to bypass the problem by moving the
pathname handling routines to a different header -- might be useful in
its own right to slim down the kitchen sink that fs.h turned out to
be, but that's another bikeshed-y material.

I may end up just ditching this for the time being.