linux-hardening - Re: [PATCH] crypto/caam: Avoid GCC constprop bug warning

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: <202212021057.B1B1BDE380@keescook>
Date:   Fri, 2 Dec 2022 10:58:11 -0800
From:   Kees Cook <keescook@...omium.org>
To:     David Laight <David.Laight@...lab.com>
Cc:     'Anders Roxell' <anders.roxell@...aro.org>,
        Horia Geantă <horia.geanta@....com>,
        Pankaj Gupta <pankaj.gupta@....com>,
        Gaurav Jain <gaurav.jain@....com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>,
        "linux-crypto@...r.kernel.org" <linux-crypto@...r.kernel.org>,
        kernel test robot <lkp@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-hardening@...r.kernel.org" <linux-hardening@...r.kernel.org>
Subject: Re: [PATCH] crypto/caam: Avoid GCC constprop bug warning

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