From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D9DA4C433EF for ; Tue, 8 Feb 2022 23:17:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235849AbiBHXR2 (ORCPT ); Tue, 8 Feb 2022 18:17:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38558 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235837AbiBHXR1 (ORCPT ); Tue, 8 Feb 2022 18:17:27 -0500 Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D7E7FC061577 for ; Tue, 8 Feb 2022 15:17:26 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id u6so905222lfc.3 for ; Tue, 08 Feb 2022 15:17:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uV9MHzT3yqaSJ8VvyobC0sdXGQe9fB58ozgnu6xiqyY=; b=o9cIyt5bY7tBJycqX+8faJX72GU6lGkN/ohJfrqEdo0bZnpl6VntHVjHKLxO6fpEeS iLf8pFroVszcKHeVggFtDlA+/ahQl3iX1R9v4sYDnfrhyannRYLCftIoDkTkZ4LWdZ8e eTTW3/lWIDj82yqfzAs6m33+pXHmp+1TZM6C5KQ3xixSli3TEnfD9bLpdm+Ayj3FoQgG SA5BZBXbeirjsZcyi7cw5gEhLmJvfNhrSqTn8AVDVcHxUN6yKrr/cwPpVdE+tUgSOeZ5 eOi3DyPC6N0NZbjqqScdyo/fT+aS95PhLxpARudPtka+wNBCsaFXjp7qXE/MZCXgcaXz Yyjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uV9MHzT3yqaSJ8VvyobC0sdXGQe9fB58ozgnu6xiqyY=; b=B6DYR5aGquA3HPRJlY2C6zuK09in9hFot7lpQF5S4dG3tu7hJJSIttCCz5Db2R3AiH LHnCW4pRjg06GiK+sfcF7ZL708Z0eL+uOp9+tkGDNpPcN58fBW5tfdvqvmeMtB/cbf9/ h+0kwgub2jC0UJdFPCjv1GKzlbjGxaC9ElDK/oi1kvdM+QU65Fpdn9EahpD4NlOkW6ld JRqDdya//D2/+g55YQUe+FKY8oZ288Lpc8Zpt0EYLyHGY4CoWw7oj4yFWYidWmsOy37J qWlIs6o/wzU2yLJWr39+RSfVaZyDbv9NU5SOe9u411y2cMOOvAISeT6NqWWyODQyS/Q5 K69w== X-Gm-Message-State: AOAM532sz9Ohooo73lNtJSNvU+EKTIgsU0actCH+ccM3umgdqyuHZXTS jCt4bcuzI/bZTOnepD7AUjOihLl5ickGlTG6Khj3nw== X-Google-Smtp-Source: ABdhPJzEdVmqLDi7X6N3Z46Ig8r2EtxJrWgkjU4z9gBLfTsztBj2W7LYuSaUTleZLNiFoJLMfZzFlIFwEMqAL3kJPUI= X-Received: by 2002:ac2:4c4c:: with SMTP id o12mr4287394lfk.523.1644362244992; Tue, 08 Feb 2022 15:17:24 -0800 (PST) MIME-Version: 1.0 References: <20220208225350.1331628-1-keescook@chromium.org> <20220208225350.1331628-8-keescook@chromium.org> In-Reply-To: <20220208225350.1331628-8-keescook@chromium.org> From: Nick Desaulniers Date: Tue, 8 Feb 2022 15:17:13 -0800 Message-ID: Subject: Re: [PATCH v7 7/8] fortify: Make sure strlen() may still be used as a constant expression To: Kees Cook Cc: Miguel Ojeda , Nathan Chancellor , George Burgess IV , linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org, llvm@lists.linux.dev Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-hardening@vger.kernel.org On Tue, Feb 8, 2022 at 2:53 PM Kees Cook wrote: > > In preparation for enabling Clang FORTIFY_SOURCE support, redefine > strlen() as a macro that tests for being a constant expression > so that strlen() can still be used in static initializers, which is > lost when adding __pass_object_size and __overloadable. > > An example of this usage can be seen here: > https://lore.kernel.org/all/202201252321.dRmWZ8wW-lkp@intel.com/ > > Notably, this constant expression feature of strlen() is not available > for architectures that build with -ffreestanding. This means the kernel > currently does not universally expect strlen() to be used this way, but > since there _are_ some build configurations that depend on it, retain > the characteristic for Clang FORTIFY_SOURCE builds too. > > Signed-off-by: Kees Cook > --- > include/linux/fortify-string.h | 13 +++++++++++-- > 1 file changed, 11 insertions(+), 2 deletions(-) > > diff --git a/include/linux/fortify-string.h b/include/linux/fortify-string.h > index db1ad1c1c79a..f77cf22e2d60 100644 > --- a/include/linux/fortify-string.h > +++ b/include/linux/fortify-string.h > @@ -2,6 +2,8 @@ > #ifndef _LINUX_FORTIFY_STRING_H_ > #define _LINUX_FORTIFY_STRING_H_ > > +#include > + > #define __FORTIFY_INLINE extern __always_inline __gnu_inline > #define __RENAME(x) __asm__(#x) > > @@ -95,9 +97,16 @@ __FORTIFY_INLINE __kernel_size_t strnlen(const char * const p, __kernel_size_t m > return ret; > } > > -/* defined after fortified strnlen to reuse it. */ > +/* > + * Defined after fortified strnlen to reuse it. However, it must still be > + * possible for strlen() to be used on compile-time strings for use in > + * static initializers (i.e. as a constant expression). > + */ > +#define strlen(p) \ > + __builtin_choose_expr(__is_constexpr(__builtin_strlen(p)), \ Is `__is_constexpr(p) == __is_constexpr(__builtin_strlen(p))`? i.e. can we drop the first `__builtin_strlen`? It seems redundant. So instead, we'd have: #define strlen(p) __builtin_choose_expr(__is_constexpr(p), __builtin_strlen(p), __fortify_strlen(p)) Or is there some funny business where p isn't constexpr but strlen(p) somehow is? I doubt that. (Or is it that p is constexpr, but strlen(p) is not?) (Guess I'm wrong: https://godbolt.org/z/19ffz7vjx) Ok then. Reviewed-by: Nick Desaulniers > + __builtin_strlen(p), __fortify_strlen(p)) > __FORTIFY_INLINE __diagnose_as(__builtin_strlen, 1) > -__kernel_size_t strlen(const char * const p) > +__kernel_size_t __fortify_strlen(const char * const p) > { > __kernel_size_t ret; > size_t p_size = __builtin_object_size(p, 1); > -- > 2.30.2 > -- Thanks, ~Nick Desaulniers