From: Kees Cook <keescook@chromium.org>
To: David Laight <David.Laight@aculab.com>
Cc: "'Anders Roxell'" <anders.roxell@linaro.org>,
"Horia Geantă" <horia.geanta@nxp.com>,
"Pankaj Gupta" <pankaj.gupta@nxp.com>,
"Gaurav Jain" <gaurav.jain@nxp.com>,
"Herbert Xu" <herbert@gondor.apana.org.au>,
"David S. Miller" <davem@davemloft.net>,
"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
"kernel test robot" <lkp@intel.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-hardening@vger.kernel.org"
<linux-hardening@vger.kernel.org>
Subject: Re: [PATCH] crypto/caam: Avoid GCC constprop bug warning
Date: Fri, 2 Dec 2022 10:58:11 -0800 [thread overview]
Message-ID: <202212021057.B1B1BDE380@keescook> (raw)
In-Reply-To: <4f7ffdd948a84013a0e84876b3e3944b@AcuMS.aculab.com>
On Fri, Dec 02, 2022 at 10:01:50AM +0000, David Laight wrote:
> From: Anders Roxell
> > Sent: 02 December 2022 00:58
> >
> > On 2022-10-28 14:05, Kees Cook wrote:
> > > GCC 12 appears to perform constant propagation incompletely(?) and can
> > > no longer notice that "len" is always 0 when "data" is NULL. Expand the
> > > check to avoid warnings about memcpy() having a NULL argument:
> > >
> > > ...
> > > from drivers/crypto/caam/key_gen.c:8:
> > > drivers/crypto/caam/desc_constr.h: In function 'append_data.constprop':
> > > include/linux/fortify-string.h:48:33: warning: argument 2 null where non-null expected [-
> > Wnonnull]
> > > 48 | #define __underlying_memcpy __builtin_memcpy
> > > | ^
> > > include/linux/fortify-string.h:438:9: note: in expansion of macro '__underlying_memcpy'
> > > 438 | __underlying_##op(p, q, __fortify_size); \
> > > | ^~~~~~~~~~~~~
> ...
>
> Is this really a bug in the fortify-string wrappers?
> IIRC the call is memcpy(NULL, ptr, 0) (or maybe memcpy(ptr, NULL, 0).
> In either case call can be removed at compile time.
>
> I'd bet that the constant propagation of 'len' fails because
> of all the intermediate variables that get used in order to
> avoid multiple evaluation.
>
> The some 'tricks' that are used in min() (see minmax.h) to
> generate a constant output for constant input could be
> use to detect a compile-time zero length.
>
> Something like:
> #define memcpy(dst, src, len) \
> (__is_constzero(len) ? (dst) : memcpy_check(dst, src, len))
>
> With:
> #define __is_constzero(x) sizeof(*(1 ? (void *)(x) : (int *)0) != 1)
> Which could go into const.h and used in the definition of __is_constexpr().
While it could be possible to strip the nonnull attribute, I think it's
not an unreasonable check to have. This is literally the only case in
the entire kernel that is tripped, for example.
--
Kees Cook
next prev parent reply other threads:[~2022-12-02 18:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-28 21:05 [PATCH] crypto/caam: Avoid GCC constprop bug warning Kees Cook
2022-10-29 11:40 ` David Laight
2022-11-04 9:03 ` Herbert Xu
2022-12-01 11:52 ` Anders Roxell
2022-12-01 12:10 ` Herbert Xu
2022-12-02 0:59 ` Anders Roxell
2022-12-02 0:58 ` Anders Roxell
2022-12-02 10:01 ` David Laight
2022-12-02 18:58 ` Kees Cook [this message]
2022-12-02 22:08 ` David Laight
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202212021057.B1B1BDE380@keescook \
--to=keescook@chromium.org \
--cc=David.Laight@aculab.com \
--cc=anders.roxell@linaro.org \
--cc=davem@davemloft.net \
--cc=gaurav.jain@nxp.com \
--cc=herbert@gondor.apana.org.au \
--cc=horia.geanta@nxp.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=pankaj.gupta@nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox