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: <CAHk-=wgGFUAPb7z5RzUq=jxRh2PO7yApd9ujMnC5OwXa-_e3Qw@mail.gmail.com>
Date: Thu, 30 Oct 2025 11:07:16 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Mateusz Guzik <mjguzik@...il.com>, Thomas Gleixner <tglx@...utronix.de>
Cc: 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

[ 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).

I was thinking more along the lines of forcing linker errors or
something like that.

ENTIRELY UNTESTED PATCH attached - may not compile at all, but
something like this *might* work to show when a module uses the
runtime_const infrastructure.

And I think I should have made the default runtime const value
something small. But the original use of this was just the dcache
code, and that used it purely as a pointer, so a non-fixed-up address
would cause a nice clean oops. Then I started using it for the user
access limit, and now it's actually wrong if used by modules.

Thanks for making me think about this. I thought about the module case
*originally*, but then with some of the expanded use I definitely did
not.

               Linus

View attachment "patch.diff" of type "text/x-patch" (894 bytes)