linux-kernel - Re: [PATCHv3] gcc: disable '-Wstrignop-overread' universally for gcc-13+ and FORTIFY

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: <Z1dWinzDPuC8iEXk@yury-ThinkPad>
Date: Mon, 9 Dec 2024 12:43:54 -0800
From: Yury Norov <yury.norov@...il.com>
To: Nathan Chancellor <nathan@...nel.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Nilay Shroff <nilay@...ux.ibm.com>, linux-kernel@...r.kernel.org,
	briannorris@...omium.org, kees@...nel.org, gustavoars@...nel.org,
	steffen.klassert@...unet.com, daniel.m.jordan@...cle.com,
	gjoyce@....com, linux-crypto@...r.kernel.org, linux@...ssschuh.net
Subject: Re: [PATCHv3] gcc: disable '-Wstrignop-overread' universally for
 gcc-13+ and FORTIFY_SOURCE

On Mon, Dec 09, 2024 at 01:03:00PM -0700, Nathan Chancellor wrote:
> Maybe people are not using CONFIG_WERROR=y and W=e when hitting this so
> they do not notice? It also only became visible in 6.12 because of the
> 'inline' -> '__always_inline' changes in bitmap.h and cpumask.h, since
> prior to that, the size of the objects being passed to memcpy() were not
> known, so FORTIFY could not catch them (another +1 for that change).

Thanks, but I'm actually not happy with that series (ab6b1010dab68f6d4).
The original motivation was that one part of compiler decided to outline
the pure wrappers or lightweight inline implementation for small bitmaps,
like those fitting inside a machine word. 

After that, another part of compiler started complaining that outlined
helpers mismatch the sections - .text and .init.data.

(Not mentioning that the helpers were not designed to be real outlined
functions, and doing that adds ~3k to kernel image.)

I don't like forcing compiler to do this or that, but in this case I
just don't know how to teach it to outline the function twice, if it
wants to do that. This should be done automatically, I guess...

Similarly, I don't know how to teach it to keep the functions inlined,
other than forcing it to do so. I really wonder what made it thinking
that this deserves to be a real function:

 static __always_inline
 bool cpumask_andnot(struct cpumask *dstp, const struct cpumask *src1p,
                     const struct cpumask *src2p)
 {
         return bitmap_andnot(cpumask_bits(dstp), cpumask_bits(src1p),
                                           cpumask_bits(src2p), small_cpumask_bits);
 }

I guess, there are more 'functions' of that sort that outlined for nothing
in the kernel, and who knows how bloated is it?