From: Kees Cook <keescook@chromium.org>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Guenter Roeck <linux@roeck-us.net>, Peter Rosin <peda@axentia.se>,
Andy Shevchenko <andy@kernel.org>,
Matteo Croce <mcroce@microsoft.com>,
Nathan Chancellor <nathan@kernel.org>,
Nick Desaulniers <ndesaulniers@google.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
llvm@lists.linux.dev, linux-hardening@vger.kernel.org
Subject: Re: [PATCH] lib/test_string.c: Add test for strlen()
Date: Thu, 3 Feb 2022 08:41:24 -0800 [thread overview]
Message-ID: <202202030840.74FCB6868@keescook> (raw)
In-Reply-To: <CAMuHMdWssK2=NFc6NO-inQg5dWxZP4Wv41K3J3RqRXThXatovw@mail.gmail.com>
On Thu, Feb 03, 2022 at 09:04:22AM +0100, Geert Uytterhoeven wrote:
> Hi Günter,
>
> On Thu, Feb 3, 2022 at 12:12 AM Guenter Roeck <linux@roeck-us.net> wrote:
> > On 2/2/22 12:52, Kees Cook wrote:
> > > On Wed, Feb 02, 2022 at 08:01:49AM -0800, Guenter Roeck wrote:
> > >> On Sun, Jan 30, 2022 at 10:36:53AM -0800, Kees Cook wrote:
> > >>> Add a simple test for strlen() functionality, including using it as a
> > >>> constant expression.
> > >>>
> > >>> Cc: Geert Uytterhoeven <geert@linux-m68k.org>
> > >>> Cc: Peter Rosin <peda@axentia.se>
> > >>> Signed-off-by: Kees Cook <keescook@chromium.org>
> > >>> ---
> > >>> I'll be taking this as part of my Clang FORTIFY_SOURCE series.
> > >>> ---
> > >>> lib/test_string.c | 37 +++++++++++++++++++++++++++++++++++++
> > >>> 1 file changed, 37 insertions(+)
> > >>>
> > >>> diff --git a/lib/test_string.c b/lib/test_string.c
> > >>> index 9dfd6f52de92..59994f552c48 100644
> > >>> --- a/lib/test_string.c
> > >>> +++ b/lib/test_string.c
> > >>> @@ -179,6 +179,38 @@ static __init int strnchr_selftest(void)
> > >>> return 0;
> > >>> }
> > >>>
> > >>> +/*
> > >>> + * Unlike many other string functions, strlen() can be used in
> > >>> + * static initializers when string lengths are known at compile
> > >>> + * time. (i.e. Under these conditions, strlen() is a constant
> > >>> + * expression.) Make sure it can be used this way.
> > >>> + */
> > >>> +static const int strlen_ce = strlen("tada, a constant expression");
> > >>> +
> > >>
> > >> This results in:
> > >>
> > >> lib/test_string.c:188:30: error: initializer element is not constant
> > >> 188 | static const int strlen_ce = strlen("tada, a constant expression");
> > >>
> > >> for several of my tests. I don't think you can mandate that a compiler
> > >> implements this.
> > >
> > > Which tests?
> > >
> >
> > Some examples:
> >
> > Build reference: next-20220202
> > Compiler version: m68k-linux-gcc (GCC) 11.2.0
> >
> > Building m68k:defconfig ... failed
> > --------------
> > Error log:
> > lib/test_string.c:188:30: error: initializer element is not constant
> > 188 | static const int strlen_ce = strlen("tada, a constant expression");
> >
> > Building mips:malta_defconfig:nocd:smp:net,e1000:initrd ... failed
> > ------------
> > Error log:
> > lib/test_string.c:188:30: error: initializer element is not constant
> > static const int strlen_ce = strlen("tada, a constant expression");
> >
> > Building i386:q35:Broadwell:defconfig:smp:ata:net,rtl8139:hd ... failed
> > ------------
> > Error log:
> > lib/test_string.c:188:30: error: initializer element is not constant
> > 188 | static const int strlen_ce = strlen("tada, a constant expression");
> >
> > i386 and is defconfig + CONFIG_STRING_SELFTEST=y; mips is
> > malta_defconfig + CONFIG_STRING_SELFTEST=y. All use gcc 11.2.
> >
> > There may be more, but there are so many failures in -next right now
> > that I may be missing some.
> >
> > > This property of strlen() is already required by our builds (this is how
> > > I tripped over it). For example:
> > >
> > > drivers/firmware/xilinx/zynqmp-debug.c:
> > >
> > > #define PM_API(id) {id, #id, strlen(#id)}
> > > static struct pm_api_info pm_api_list[] = {
> > > PM_API(PM_GET_API_VERSION),
> > > PM_API(PM_QUERY_DATA),
> > > };
> >
> > I do not think that it is a C standard that strlen() on a constant string
> > must be compile-time evaluated and result in a constant.
>
> Not if -ffreestanding, which is what several architectures are
> using nowadays, to a.o. prevent gcc from replacing calls to stdlib
> functions to other stdlib functions (e.g. strncat() -> strlen() +
> store, strncmp() -> strcmp()), which breaks linking if the latter is
> only provided inline.
>
> > Anyway, key difference, I think, is the presence of an architecture-specific
> > version of strlen(), or the maybe non-presence of __HAVE_ARCH_STRLEN,
> > or the definition of strlen() in include/linux/fortify-string.h.
>
> It works after dropping -ffreestanding.
Ah-ha, thanks for the clue here. I'll see if there is some way to
detect this (or, I guess, drop the patch). I don't like that this
requirement depends on the architecture, so I'd rather it behave the
same everywhere. Hmm
--
Kees Cook
next prev parent reply other threads:[~2022-02-03 16:41 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-30 18:36 [PATCH] lib/test_string.c: Add test for strlen() Kees Cook
2022-01-30 18:56 ` Andy Shevchenko
2022-01-30 20:34 ` Kees Cook
2022-01-30 20:13 ` kernel test robot
2022-01-30 20:13 ` kernel test robot
2022-01-30 20:35 ` Kees Cook
2022-01-30 20:35 ` Kees Cook
2022-02-02 16:01 ` Guenter Roeck
2022-02-02 16:16 ` Andy Shevchenko
2022-02-02 20:52 ` Kees Cook
2022-02-02 23:12 ` Guenter Roeck
2022-02-03 8:04 ` Geert Uytterhoeven
2022-02-03 16:41 ` Kees Cook [this message]
2022-02-03 17:15 ` Kees Cook
2022-02-03 18:09 ` Geert Uytterhoeven
2022-02-03 19:50 ` Nick Desaulniers
2022-02-03 20:25 ` Kees Cook
2022-02-03 20:45 ` Kees Cook
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=202202030840.74FCB6868@keescook \
--to=keescook@chromium.org \
--cc=andy@kernel.org \
--cc=geert@linux-m68k.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=llvm@lists.linux.dev \
--cc=mcroce@microsoft.com \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=peda@axentia.se \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.