Received-SPF: pass (google.com: domain of linux-kernel+bounces-143376-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Fri, 12 Apr 2024 14:21:36 -0700
From: Nathan Chancellor <nathan@kernel.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Kees Cook <keescook@chromium.org>, Arnd Bergmann <arnd@kernel.org>,
	Steffen Klassert <steffen.klassert@secunet.com>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	"David S . Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Bill Wendling <morbo@google.com>,
	Justin Stitt <justinstitt@google.com>,
	"Gustavo A. R. Silva" <gustavoars@kernel.org>,
	Leon Romanovsky <leon@kernel.org>, Lin Ma <linma@zju.edu.cn>,
	Simon Horman <horms@kernel.org>, Breno Leitao <leitao@debian.org>,
	Tobias Brunner <tobias@strongswan.org>,
	Raed Salem <raeds@nvidia.com>, Netdev <netdev@vger.kernel.org>,
	linux-kernel@vger.kernel.org, llvm@lists.linux.dev
Subject: Re: [PATCH] [RFC] xfrm: work around a clang-19 fortifiy-string
 false-positive
Message-ID: <20240412212136.GD2252629@dev-arch.thelio-3990X>
References: <20240216202657.2493685-1-arnd@kernel.org>
 <202402161301.BBFA14EE@keescook>
 <763214eb-20eb-4627-8d4b-2e7f29db829a@app.fastmail.com>
 <20240409161517.GA3219862@dev-arch.thelio-3990X>
 <f94c6943-eb93-4533-8e4d-3645ef38b990@app.fastmail.com>
 <20240410174540.GB3649628@dev-arch.thelio-3990X>
 <773febee-ace3-4ad6-8ff6-04563dbbb759@app.fastmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <773febee-ace3-4ad6-8ff6-04563dbbb759@app.fastmail.com>

On Thu, Apr 11, 2024 at 01:35:05PM +0200, Arnd Bergmann wrote:
> On Wed, Apr 10, 2024, at 19:45, Nathan Chancellor wrote:
> 
> > Unfortunately, I have no idea why it is complaining nor why your patch
> > resolves it but the combination of FORTIFY_SOURCE and KASAN certainly
> > seems like a reasonable place to start looking. I will see if I can come
> > up with a smaller reproducer to see if it becomes more obvious why this
> > code triggers this warning.
> 
> I know at least why my patch avoids the warning -- it removes the
> call to memset() that contains the check.

Yeah duh... :/ I should have realized that before I sent that message
heh.

> Unfortunately that still doesn't explain what caused it.

Right, I'll see if I can cvise something out now that we have a more
isolated set of conditions. I guess the only question will be if I can
build a file preprocessed with CONFIG_KASAN=y will build with and
without '-fsanitize=kernel-address'...

Cheers,
Nathan