linux-hardening - Re: [PATCH v2] ubsan: Tighten UBSAN

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: <CAKwvOdkeQa7xOJUZnUYu4v1wmM54z=y0yPzGKfVofr2Fh27A3A@mail.gmail.com>
Date:   Fri, 7 Apr 2023 15:00:35 -0700
From:   Nick Desaulniers <ndesaulniers@...gle.com>
To:     Kees Cook <keescook@...omium.org>
Cc:     Marco Elver <elver@...gle.com>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Nathan Chancellor <nathan@...nel.org>,
        Nicolas Schier <nicolas@...sle.eu>, Tom Rix <trix@...hat.com>,
        Josh Poimboeuf <jpoimboe@...nel.org>,
        Miroslav Benes <mbenes@...e.cz>, linux-kbuild@...r.kernel.org,
        llvm@...ts.linux.dev, Sudip Mukherjee <sudipm.mukherjee@...il.com>,
        Lukas Bulwahn <lukas.bulwahn@...il.com>,
        linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org
Subject: Re: [PATCH v2] ubsan: Tighten UBSAN_BOUNDS on GCC

On Tue, Apr 4, 2023 at 7:24 PM Kees Cook <keescook@...omium.org> wrote:
>
> The use of -fsanitize=bounds on GCC will ignore some trailing arrays,
> leaving a gap in coverage. Switch to using -fsanitize=bounds-strict to
> match Clang's stricter behavior.
>
> Cc: Marco Elver <elver@...gle.com>
> Cc: Masahiro Yamada <masahiroy@...nel.org>
> Cc: Nathan Chancellor <nathan@...nel.org>
> Cc: Nick Desaulniers <ndesaulniers@...gle.com>
> Cc: Nicolas Schier <nicolas@...sle.eu>
> Cc: Tom Rix <trix@...hat.com>
> Cc: Josh Poimboeuf <jpoimboe@...nel.org>
> Cc: Miroslav Benes <mbenes@...e.cz>
> Cc: linux-kbuild@...r.kernel.org
> Cc: llvm@...ts.linux.dev
> Signed-off-by: Kees Cook <keescook@...omium.org>
> ---
> v2: improve help text (nathan)
> v1: https://lore.kernel.org/lkml/20230302225444.never.053-kees@kernel.org/
> ---
>  lib/Kconfig.ubsan      | 56 +++++++++++++++++++++++-------------------
>  scripts/Makefile.ubsan |  2 +-
>  2 files changed, 32 insertions(+), 26 deletions(-)
>
> diff --git a/lib/Kconfig.ubsan b/lib/Kconfig.ubsan
> index fd15230a703b..65d8bbcba438 100644
> --- a/lib/Kconfig.ubsan
> +++ b/lib/Kconfig.ubsan
> @@ -27,16 +27,29 @@ config UBSAN_TRAP
>           the system. For some system builders this is an acceptable
>           trade-off.
>
> -config CC_HAS_UBSAN_BOUNDS
> -       def_bool $(cc-option,-fsanitize=bounds)
> +config CC_HAS_UBSAN_BOUNDS_STRICT
> +       def_bool $(cc-option,-fsanitize=bounds-strict)
> +       help
> +         The -fsanitize=bounds-strict option is only available on GCC,
> +         but uses the more strict handling of arrays that includes knowledge
> +         of flexible arrays, which is comparable to Clang's regular
> +         -fsanitize=bounds.
>
>  config CC_HAS_UBSAN_ARRAY_BOUNDS
>         def_bool $(cc-option,-fsanitize=array-bounds)
> +       help
> +         Under Clang, the -fsanitize=bounds option is actually composed
> +         of two more specific options, -fsanitize=array-bounds and

Heh, that was literally the latest blog post I was working on...2
weeks ago? WIP.

Would it make sense to use CC_IS_CLANG (as in lib/Kconfig.k{a|c}san)
and CC_IS_GCC in addition to the cc-option tests, since the help texts
make it clear there's compiler specific differences here?

I've also sent
https://lore.kernel.org/llvm/20230407215406.768464-1-ndesaulniers@google.com/
while looking at this patch.  Maybe more cc-option tests are no longer
necessary at this point, but I haven't checked the rest.

> +         -fsanitize=local-bounds. However, -fsanitize=local-bounds can
> +         only be used when trap mode is enabled. (See also the help for
> +         CONFIG_LOCAL_BOUNDS.) Explicitly check for -fsanitize=array-bounds
> +         so that we can build up the options needed for UBSAN_BOUNDS
> +         with or without UBSAN_TRAP.
>
>  config UBSAN_BOUNDS
>         bool "Perform array index bounds checking"
>         default UBSAN
> -       depends on CC_HAS_UBSAN_ARRAY_BOUNDS || CC_HAS_UBSAN_BOUNDS
> +       depends on CC_HAS_UBSAN_ARRAY_BOUNDS || CC_HAS_UBSAN_BOUNDS_STRICT
>         help
>           This option enables detection of directly indexed out of bounds
>           array accesses, where the array size is known at compile time.
> @@ -44,33 +57,26 @@ config UBSAN_BOUNDS
>           to the {str,mem}*cpy() family of functions (that is addressed
>           by CONFIG_FORTIFY_SOURCE).
>
> -config UBSAN_ONLY_BOUNDS
> -       def_bool CC_HAS_UBSAN_BOUNDS && !CC_HAS_UBSAN_ARRAY_BOUNDS
> -       depends on UBSAN_BOUNDS
> +config UBSAN_BOUNDS_STRICT
> +       def_bool UBSAN_BOUNDS && CC_HAS_UBSAN_BOUNDS_STRICT
>         help
> -         This is a weird case: Clang's -fsanitize=bounds includes
> -         -fsanitize=local-bounds, but it's trapping-only, so for
> -         Clang, we must use -fsanitize=array-bounds when we want
> -         traditional array bounds checking enabled. For GCC, we
> -         want -fsanitize=bounds.
> +         GCC's bounds sanitizer. This option is used to select the
> +         correct options in Makefile.ubsan.
>
>  config UBSAN_ARRAY_BOUNDS
> -       def_bool CC_HAS_UBSAN_ARRAY_BOUNDS
> -       depends on UBSAN_BOUNDS
> +       def_bool UBSAN_BOUNDS && CC_HAS_UBSAN_ARRAY_BOUNDS
> +       help
> +         Clang's array bounds sanitizer. This option is used to select
> +         the correct options in Makefile.ubsan.
>
>  config UBSAN_LOCAL_BOUNDS
> -       bool "Perform array local bounds checking"
> -       depends on UBSAN_TRAP
> -       depends on $(cc-option,-fsanitize=local-bounds)
> -       help
> -         This option enables -fsanitize=local-bounds which traps when an
> -         exception/error is detected. Therefore, it may only be enabled
> -         with CONFIG_UBSAN_TRAP.
> -
> -         Enabling this option detects errors due to accesses through a
> -         pointer that is derived from an object of a statically-known size,
> -         where an added offset (which may not be known statically) is
> -         out-of-bounds.
> +       def_bool UBSAN_ARRAY_BOUNDS && UBSAN_TRAP
> +       help
> +         This option enables Clang's -fsanitize=local-bounds which traps
> +         when an access through a pointer that is derived from an object
> +         of a statically-known size, where an added offset (which may not
> +         be known statically) is out-of-bounds. Since this option is
> +         trap-only, it depends on CONFIG_UBSAN_TRAP.
>
>  config UBSAN_SHIFT
>         bool "Perform checking for bit-shift overflows"
> diff --git a/scripts/Makefile.ubsan b/scripts/Makefile.ubsan
> index 7099c603ff0a..4749865c1b2c 100644
> --- a/scripts/Makefile.ubsan
> +++ b/scripts/Makefile.ubsan
> @@ -2,7 +2,7 @@
>
>  # Enable available and selected UBSAN features.
>  ubsan-cflags-$(CONFIG_UBSAN_ALIGNMENT)         += -fsanitize=alignment
> -ubsan-cflags-$(CONFIG_UBSAN_ONLY_BOUNDS)       += -fsanitize=bounds
> +ubsan-cflags-$(CONFIG_UBSAN_BOUNDS_STRICT)     += -fsanitize=bounds-strict
>  ubsan-cflags-$(CONFIG_UBSAN_ARRAY_BOUNDS)      += -fsanitize=array-bounds
>  ubsan-cflags-$(CONFIG_UBSAN_LOCAL_BOUNDS)      += -fsanitize=local-bounds
>  ubsan-cflags-$(CONFIG_UBSAN_SHIFT)             += -fsanitize=shift
> --
> 2.34.1
>


-- 
Thanks,
~Nick Desaulniers