linux-kernel - Re: [PATCH] devtmpfs: don't use vfs_getattr_nosec to query i

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: <20250425171745.GA3071749@ax162>
Date: Fri, 25 Apr 2025 13:17:45 -0400
From: Nathan Chancellor <nathan@...nel.org>
To: Kees Cook <kees@...nel.org>
Cc: Christoph Hellwig <hch@....de>, Christian Brauner <brauner@...nel.org>,
	Heiko Carstens <hca@...ux.ibm.com>, gregkh@...uxfoundation.org,
	rafael@...nel.org, dakr@...nel.org, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org,
	Shin'ichiro Kawasaki <shinichiro.kawasaki@....com>,
	Xiao Ni <xni@...hat.com>
Subject: Re: [PATCH] devtmpfs: don't use vfs_getattr_nosec to query i_mode

On Fri, Apr 25, 2025 at 08:40:23AM -0700, Kees Cook wrote:
> 
> 
> On April 25, 2025 6:32:59 AM PDT, Christoph Hellwig <hch@....de> wrote:
> >On Fri, Apr 25, 2025 at 12:12:36PM +0200, Christian Brauner wrote:
> >> > That is: if dev_mynode(dev, inode) is not true some random value will be returned.
> >> 
> >> Don't bother resending, Christoph.
> >> I've already fixed this with int err = 0 in the tree.
> >
> >Thanks!  Let me use this as a platform to rant about our option
> >defaults and/or gcc error handling.  It seems like ever since we started
> >zeroing on-stack variables by default gcc stopped warnings about using
> >uninitialized on-stack variables, leading to tons of these case where
> >we don't catch uninitialized variables.  Now in this and in many cases
> >the code works fine because it assumed zero initialization, but there are
> >also cases where it didn't, leading to new bugs.

I don't think developers can assume that zero initialization is
universally available because 1. there are supported compiler versions
that might not support it and 2. someone may have turned it off or
switched to pattern initialization. Isn't default initialization of
variables supposed to be viewed more as a mitigation against missed
initializations than something to be relied on implicitly? We still want
to know unambiguously and explicitly what the default value of variables
should be.

> This isn't the case: the feature was explicitly designed in both GCC
> and Clang to not disrupt -Wuninitialized. But -Wuninitialized has been
> so flakey for so long that it is almost useless (there was even
> -Wmaybe-uninitialized added to try to cover some of the missed

Right, the fact that GCC does not warn on uninitialized variables is
somewhat self inflicted for the kernel because of 6e8d666e9253 ("Disable
"maybe-uninitialized" warning globally"); I say somewhat because I
understand that the warning was disabled for false positives but it does
mean that there are no true positives either.

> diagnostics). And it's one of the many reasons stack variable zeroing
> is so important, since so much goes undiagnosed. :(
> 
> Fixing -Wuninitialized would be lovely, but it seems no one has been
> able to for years now.

I think clang at one point had a similar problem to GCC's
-Wmaybe-uninitialized (it is -Wconditional-uninitialized there) and that
is how -Wsometimes-uninitialized came into existence. Perhaps GCC could
explore something similar to help gain back some coverage?

There is another big difference between clang and GCC's -Wuninitialized
is that clang's -Wuninitialized will trigger whenever a variable is
guaranteed to be used initialized at its first use, regardless of what
control flow may happen between the declaration and that point, whereas
GCC may turn it into a -Wmaybe-uninitialized.

https://godbolt.org/z/MYxeozc36

Cheers,
Nathan